Issue 142: API vulnerabilities in Coursera and Huawei, GraphQL rate limiting and discovery 🔎

Coursera has fixed a number of API vulnerabilities reported by David Sopas, Paulo Silva, Ricardo Gonçalves, and Erez Yalon from Checkmarx:

• Lack of authentication and authorization for reading or modifying user preferences
• Account enumeration using the password reset endpoint
• Lack of resource limiting
• GraphQL misconfiguration

Their article explains how they found the first of the issues. While using various functions of the web app and observing the API calls that the site was making, they noticed GET calls to the endpoint /api/userPreferences.v1/{USER_ID}~{PREFERENCE_TYPE} that could retrieve 10 different types of user preferences.

When replacing the USER_ID of the authenticated user with that of another user, they noticed that they could still access the preferences data, demonstrating a lack of authorization check in the API. Even worse, they noticed that even without any authentication headers or cookies, they could still access the data, thus showing that the API was not protected by any authentication checks either:

Finally, they tried making PUT calls instead of GET and successfully modified user preferences through that same unprotected endpoint:

Obviously a significant breach of user privacy.

Lessons learned here:

• Treat your backend APIs as your security boundary, and make sure they are up to it.
• Ensure that both authentication and authorization checks are in place.

Device manufacturers often resort to default passwords to make the initial setup easier for consumers. If these passwords are not random, they can make such devices vulnerable to attacks.

A researcher found that Huawei DG8045 home gateway uses the last 8 characters of the device serial number as the default password.

To make things worse, the device exposes that number through a public API call GET /api/system/deviceinfo:

This means that if users don’t change the default password, they clearly risk attackers taking over their home gateway.

Lessons learned here:

• Non-random default credentials are extremely dangerous and should be avoided.
• APIs need to be protected with authentication and authorization.
• The information that your APIs return must be clearly defined, reviewed, and enforced to avoid leaking sensitive information.
• As a user, always change the password of any device, especially if it has a hard-coded default password, or the password is easily retrievable (like printed on the device or an easy unauthenticated API call).

API4:2019 — Lack of resources and rate-limiting can be a serious API vulnerability. Attackers can stage denial-of-service (DoS) attacks making the system unresponsive, or launch brute-force or scraping scripts to break into the system or retrieve its data. Traditionally, such attacks are prevented with rate limiting, the number of times within a period of time that an API client can call the API.

As Guilherme Vieira from Shopify explains in his article, this approach is not sufficient for GraphQL APIs. GraphQL is effectively a query language over REST APIs that allows sending complex queries and retrieving or modifying multiple objects in one call. This means that some calls can cause a lot more resource consumption than others, making request-based rate-limiting inefficient. One size clearly does not fit all.

To overcome the problem, engineers at Shopify use a point system. API clients get a certain number of complexity points that they can use within a period of time, such as 50 points per second up to a limit of 1,000 points. Then each query gets its complexity score calculated:

• Objects: One point
• Scalars and enums: Zero points
• Connections: Two points plus the number of returned objects
• Interfaces and unions: One point
• Mutations: Ten points

The API responses returned to the caller include information on how many points were used and how many remain.

All this makes sure that no API client can go wild and consume more API resources than it is allowed. For more details and specific examples, see the original article.

Penetration testers seek to find GraphQL schema information so they can build queries to retrieve the application data. As we have discussed in this newsletter multiple times, this is why it is important to make sure that introspection on GraphQL is not allowed in your production deployments.

In this recording from the null Ahmedabad June Meet, Somdev Sangwan discusses how the Autocorrect feature in GraphQL can be used as an attack vector even after introspection has been switched off, still allowing attackers to discover the schema. His part starts around the 33-minute mark: