This week, we have three API vulnerabilities in:
- Apple’s Sign in with Apple authentication endpoint
- Qatar’s COVID-19 tracking app
- GitLab’s Repository Files API
In addition, there’s also a new Burp plugin that automatically handles authentication tokens in API calls.
Vulnerability: Sign in with Apple
Sign in with Apple is an OAuth-like social logon system from Apple. It is widely used, and in fact, Apple mandate the inclusion of Sign in with Apple in apps with other social-based login systems. Now, Bhavuk Jain has found a way to impersonate himself as any user in it.
Just like other similar systems, Sign in with Apple authenticates a user and produces a signed JWT token. The user’s client then uses that token to access the site or app that the user wanted to sign in to. The app finds the information about the user from the token (JWT tokens are encoded signed JSON structures), and verifies that the token has been signed by Apple and thus can be trusted.
What makes Sign in with Apple special is that, for privacy reasons, users may request the system to not put their actual email address in the token. Instead, Apple generates a random ID that looks like XXXXX@privaterelay.appleid.com.
Jain found out that Apple had an open endpoint that allowed anyone to request a JWT token with an arbitrary email address in it using a simple API call:
POST /XXXX/XXXX HTTP/1.1
Host: appleid.apple.com
{"email":"contact@bhavukjain.com"}The received token was signed by Apple, and thus would be considered valid by many apps. However, the structure of the token was different than in regular tokens and lacked the important security-related fields, such as sub.
Apps that enforced the token format and checked all security-related fields on the JWT tokens that they received were thus not vulnerable to the attack. Unfortunately, those apps that simply checked the signature and then blindly relied on it could fall prey to attackers.
This vulnerability has been fixed now. However, it serves as another reminder that:
- Identity providers (and in fact any API providers) should only expose publicly the APIs that external clients need, and implement zero-trust approach to the data they receive.
- Authentication consumers should make sure they implement all current JWT security best practices.
For JWT security best practices, see the 3 conference talk recordings that we had in our issue 72.
Vulnerability: Qatar’s COVID-19 app
The government of Qatar has mandated the use of their coronavirus contact tracing app, EHTERAZ, by all citizens. The app is compulsory, and those not using the app risk spending up to 3 years in prison and paying up to about $55,000 USD in fines.
Amnesty International Security Lab found glaring API security holes in the system. The API behind the app was wide open and returned the name, health status, and location for any citizen. (It actually returns a generated QR code but the color of the code reflects the health status.)
The citizen IDs that were used as the parameter for the API call are sequential, so attackers could simply enumerate the whole population of the country to harvest sensitive personal information.
Luckily, the vulnerability was fixed quickly, and the API no longer leaks personal data. This is yet another example of why:
- Even internal APIs of your systems need to be thoroughly protected with both authentication and authorization.
- ID parameters are a bad idea.
- Sequential parameters that attackers can enumerate exacerbate security issues.
Vulnerability: GitLab
GitLab has just fixed a cross-site scripting (XSS) vulnerability in their Repository Files API. They have not provided much details on the vulnerability, except the following:
Under certain conditions, requests involving the repository files API could result in an XSS vulnerability. This issue is now mitigated in the latest release and is waiting for a CVE ID to be assigned.
If you are an API provider, make sure to always strictly define all schemas and enforce proper data validation to avoid similar vulnerabilities.
Tools: Authentication Token Obtain and Replace (ATOR) plugin for Burp
Ashwath Reddy and Manikandan Rajappan from Synopsys have made their Burp plugin Authentication Token Obtain and Replace (ATOR) open-source.
The plugin can automatically request authentication tokens for and insert them in API calls. This can be handy as it eliminates manual token handling during API security research.
There is also the second part of the series covering the tool. Is has info on multi-step login, multi-token replacement, and common regex patterns.
There is also ability to export and import configuration. Pretty helpful when used within CI/CD pipeline.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
