APIsecurity.io - Issue 97: How to not leak API keys

Apps use platforms to get to the market faster and to avoid re-inventing the wheel. As a flip side, sometimes the security issues of these platforms can come and bite them.

Fizikal is a management platform for gym apps that is used in about 80 different apps, with a total of about 240 000 users. Sahar Avitan from Security Joes found a set of vulnerabilities in Fizikal’s APIs that allowed attackers to find users on the platform and extract their profile information or take over their accounts.

As often happens, the password reset API was the weakest link. Avitan found out that he could make a call to it and supply a phone number as a parameter. The API response was different for phone numbers that existed in the platform  than on those that didn’t. As phone numbers are easy to enumerate, this gave attackers a way to find who had and account and who did not.

In the next step, the reset code turned out to be just a four digit number, resulting in  just 10 000 possible combinations to try. A lack of proper rate limiting on the API made it simple to brute-force and enumerate all combinations. All this culminated in a full account takeover, meaning that attackers could retrieve personal details, like:

• Phone number
• Full name
• Date of birth
• Email address
• Postal address
• ID number
• Gym attendance schedule

Powerful stuff, especially when combined properly. To avoid similar API vulnerabilities:

• API3:2019 — Excessive data exposure: Make sure that your API responses do not over-communicate. For example, make sure your user lists are not revealed.
• API4:2019 — Lack of resources and rate limiting: Rate limiting is not a one-size-fits-all policy. Sensitive APIs, such as login or password reset, must have much stricter limits and enforced not only by IP address but also by user record.
• API2:2019 — Broken authentication: Remember that the main login API is not the only one used for authentication, things like password reset are as important.

Barak Sternberg did a presentation at DEF CON on the vulnerabilities that he found in the HDL Automation smart home and building management system:

• The endpoint /api/GetRoomBindingDevice was vulnerable to SQL injection and thus leaking information about devices and users.
  
• The configuration management created shadow accounts for all user accounts. These shadow accounts had -debug added to them (as is user-debug@email.com). So, if a user’s email was from public email service like Gmail, attackers could just register a mailbox for the valid shadow account with the -debug and use APIs to reset the password for the shadow account to get full access to account configuration.

Click the link above to read the summary of the story in BleepingComputer, or watch the full recording from DEF CON below:

Lessons learned here:

• API8:2019 — Injection: Define and sanitize your inputs to prevent injections.
• API2:2019 — Broken authentication: Avoid non-standard user record schemes (like the shadow accounts here) that rely on security by obscurity.

Capture the Flag (CTF) is a popular format of hackathon challenges in which participants need to break into an intentionally vulnerable system.

Here is a nice detailed write-up by Brett Buerhaus on solving a CTF challenge at the recent HackerOne HacktivityCon 2020. The challenge included:

• Finding and exploring an API vulnerability
• Endpoint discovery
• Server-Side Request Forgery (SSRF)
• SQL injections
• Cross-Site Scripting (XSS)

If you ever wanted to follow a breakdown on this kind of challenge, this is a prime candidate for it.

Leaked API keys remain one of the key sources of API breaches. See this recording of the Red Team Village session “Have my keys been pwned? – API Edition”  by Jose Hernandez and Rod Soto to learn how API keys leak out from CI/CD, how they can be found, and how to prevent all this from happening.