Issue 139: API vulnerabilities at Apple, Amazon, and 1Sambayan, upcoming Gartner webinar

Laxman Muthiyah was able to demonstrate how he could brute-force his way into taking over someone else’s Apple iCloud account by exploiting the password reset API endpoint.

Apple’s Forgot Password function allows you to change your password by sending a 6-digit verification code to your registered phone number and email address. Muthiyah found that indeed Apple has some protection against attacks in place. For example, after 5 unsuccessful attempts the account was locked for a few hours:

Since attackers likely won’t have access to the user’s phone and inbox, Muthiyah checked if he could programmatically try all the possible combinations (1 million combinations for a 6-digit code) and do that without the account being locked. This would require invoking the API from scripts, possibly from multiple machines at the same time so the system does not have time to lock the account:

It turned out that the rate-limiting of that API was in fact a generic rate-limit across the whole API, not just dedicated to the password reset. Muthiyah could send 6 concurrent POST requests from a single IP address, and he found 6 separate API instances on the Apple side that he could invoke. This meant that he could make 6*6=36 tests from a single virtual machine. To go through all 1 million combinations, he would need less than 28 000 machines.

For that, attackers would need a cloud service that would allow them to spin up multiple machines. Muthiyah found that Apple was blocking calls from popular cloud services, like AWS and Google Cloud Platform, but some less known ones worked for him.

Do read the original story to see how this case unfolded, as well as the Muthiyah’s back and forth with Apple on the disclosure.

Lessons learned here:

• API operations related to login and password reset are more sensitive than the rest of your API. When defining rate limits consider the usage scenario and have the limits on these sensitive operations at the level that prevents the abuse.

We have previously covered Muthiyah’s work on similar vulnerabilities at Instagram and Microsoft in our issues 40 and 124.

If you are an Amazon customer and use their mobile app, you have probably seen that it can show the approximate location of your delivery once the driver is less than 10 stops away.

Jan Masters from Pen Testing Partners found that the API behind this feature discloses a lot more information than the application using the API:

• He could start calling the API right when the courier dispatched (so a lot more than 10 stops were remaining).
• The geolocation coordinates were extremely precise, so he could see, for example, where within the buildings the courier would go.

This raises both privacy and physical concerns, for both the couriers and the recipients of deliveries.

Lessons learned:

• Treat your APIs as your interface and make sure that the APIs do not disclose more information than the users are supposed to get.

APIs behind the volunteer app of the Philippines’ opposition coalition 1Sambayan was found to be leaking highly sensitive personal information (PII).

The API was vulnerable to Broken Object-Level Authorization (BOLA/IDOR) as well as Excessive Data Exposure. The API had an operation to retrieve user profile using the user ID. And boy, did this call return a lot: name, physical address, phone number, date of birth, Apple/Google/Facebook ID, password (!), profile picture, username, and profession.

To make things worse, profile IDs in the app were sequential, making it trivial to script their enumeration and retrieve all user records.

Needless to say, this is a huge privacy — and in many cases, personal safety — risk.

Lessons learned with this one:

• Define, review, and enforce your API outputs. Chances are that a lot of the data that you store actually needs not be available through your apps and APIs.
• Reduce the risk of data exposure by collecting and storing only as little personal data as you really need.
• Prevent account enumeration by implementing long random identifiers (such as GUIDs) rather than sequential IDs.
• Implement authorization checks to make sure that users cannot access records belonging to someone else.

Mark O’Neill and Dionisio Zumerle are leading Gartner analysts on APIs and API security, and we have quoted their research multiple times in our newsletter.

Gartner’s materials are usually only available for purchase or to their corporate clients. However, next month Gartner will be hosting a webinar on API security, by O’Neill and Zumerle, available to anyone (free registration is still required):

API Security: Protect your APIs from Attacks and Data Breaches
July 15, 2021 8:00 a.m. PDT

Discussion Topics:

• Tools and techniques that can protect your APIs from attacks
• Best techniques to protect mobile applications that use APIs
• Ways to ensure the API your teams build are secure

Abstract:

Gartner predicts that by 2022, application programming interface (API) attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications. Already, many well-publicized API security vulnerabilities affected a wide range of organizations. This complimentary webinar explores the attack paths for APIs and how your team can protect against them by building secure APIs. You will learn how API discovery and API security testing help strengthen this initiative.

Not an opportunity that comes often, so make sure to reserve your spot.