Issue 141: API vulnerabilities in VeryFitPro and Gettr, AWS Lambda authorizers, AsyncAPI 2.1 🏅

Researchers from Trovent Security have found a serious API vulnerability in VeryFitPro, an Android app with more than 10 million downloads.

It turned out that the app was communicating to the backend API in the cloud over cleartext HTTP protocol.

This means that an attacker on the same network (for example, an open WiFi network) could intercept the API traffic, including calls for login or password reset. Thus, besides intercepting sensitive data, attackers could even fully take over the victim’s account.

To make things worse, the app publisher has not responded to the researchers’ report and has left the issue unaddressed.

Lessons learned:

• It is 2021 and there is absolutely no reason for anyone to use HTTP anymore. Your APIs should only accept encrypted HTTPS communications.
• Implement a clear vulnerability disclosure program and promptly address reported security incidents.

Gettr is a recently launched Twitter clone for Trump supporters. Within days after its launch, attackers found vulnerable APIs and started leaking private user data.

At least two issues have been reported:

1. APIs behind the sign-up page returned a specific error if the supplied email address was already in use. To make things worse, there was no rate limiting in place, so attackers could run a script and iterate through a large number of email addresses to check if their owners had an account in Gettr.
2. Apparently, there was another unsecured API that returned various profile fields, including some not shown on the  Gettr UI, like email address, location, and year of birth.

Security researcher Alan Gal found a post on a hacker forum that included data of more than 90 000 Gettr users:

Lessons learned here:

• Be careful what kind of error messages your login and signup APIs return. There is a fine balance between informing users and leaking details. Prevent account lookups.
• Implement rate-limiting (OWASP API4:2019 — Lack of resources and rate-limiting) and monitoring (API10:2019 — Insufficient logging and monitoring) to prevent API abuse.
• Implement authentication (API2:2019 — Broken authentication) and authorization (API1:2019 — Broken object-level authorization) to prevent attackers from accessing the private data of your customers.
• Define and enforce API outputs to ensure that only the data that the API clients really need and that is OK to be exposed is returned (API3:2019 — Excessive data exposure.)

If your APIs are behind AWS API Gateway and use Lambda authorizers for access control, read this research by Alexandre Sieira and Leonardo Viveiro.

Lambdas are serverless functions in AWS. Lambda authorizers are functions that AWS API Gateway can call to perform authorization checks:

Lambda authorizers return JSON objects with the structure shown below. This structure has the property policyDocument that includes the address of the resource in AWS to which the authorization applies:

The vulnerability arises when wildcards are used in the Resource path. The wildcards allow for * meaning any number of any characters. There is a huge range of possible ways that these can be interpreted. On the one hand, they can match an empty string, on the other – as many characters as they can and would not stop at separators like colons or slashes.

So you might assume that a policy like the one shown below (screenshot from the old AWS documentation) only gives access to a test environment:

But in reality, any of the following resources would be a match as well, thus giving the API caller access they should not have:

• arn:aws:execute-api:us-west-1:12345678:myApiId/test/GET/foo/bar/
• arn:aws:execute-api:us-west-1:12345678:myApiId/myStage/GET/foo/bar/test/hello/world
• arn:aws:execute-api:us-west-1:12345678:myApiId/myStage/GET/foo/bar/test/
• arn:aws:execute-api:us-west-1:12345678:myApiId/myStage/GET/test/hello/world

(Bold font used to indicate the substrings that matched the *s around /test/ in the policy.)

Read the original research for more examples of how the use of wildcards can go wrong with Lambda authorizers in AWS.

Quoting the research for recommendations:

1. Review the use of stars in the policyDocument object. The rule of thumb is that if a star is used at all at the last part of the ARN, it should be in the form of a “/*” at the very end of the resource string (i.e.: “arn:aws:execute-api:us-west-1:12345678:myApiId/test/GET/foo/bar/*”). You can obtain the API ID, stage name and HTTP method dynamically from the input provided to the lambda authorizer. Create one resource string in the policy for each allowed HTTP method.
2. Consider adding Deny statements that help limit the impact or scope of star expansions on the policyDocument. Remember that AWS IAM always gives precedence to Deny over Allow if multiple statements match an operation.
3. Whenever feasible, use defense in depth and check again that the user is authorized to call an endpoint in the lambda that implements it. Don’t rely on the lambda authorizer policy as your only method of authorization unless you are sure you can do it securely.
4. Make sure any code imported from the previous version of the lambda authorizer blueprints is updated to the latest version.
5. If you use URL path parameters in your APIs, avoid cases where the valid values expected to be submitted to them can be chosen by potential attackers. Prefer backend-generated IDs instead of user-chosen names for entities, for example.

AsyncAPI is an open standard, similar to OpenAPI but for asynchronous APIs. These are useful when the API client wants to be called back when a certain event happens.

AsyncAPI Initiative just released version 2.1.0 of the specification as well as the enabling tools. The changes in the new version include:

• Expanded message examples
• Mercure and IBM MQ protocol bindings
• SASL security schemes
• Updated official AsyncAPI tools.

For more details, see release notes by Lukasz Gornicki.