Issue 146: Facebook API leaking private group membership, JWT Attacker plugin for Burp

This week, we have the recent API fix involving group membership at Facebook, a case study of a BOLA vulnerability leaking users’ credit coupons, a handy add-on for Burp Suite, plus an interview with a security expert on API security.

Vulnerability: Facebook

Facebook API was leaking information on users’ memberships in private groups. Muhammad Sholikhin found that he could verify if someone was a member of a private Facebook group, as long as the attacker and the victim were connected (friends) in Facebook. Membership information on private Facebook groups is not supposed to be visible to anyone outside the group.

Sholikhin found that an attacker could switch group and user IDs in a valid join request and deduce from the API response if someone was a member in the group in question:

1. The attacker makes a request to join a group and observes the API call: POST /a/group/?gid=GROUP_ID&aid=USER_ID&refid=18
2. The attacker changes IDs in the request to the user ID of the victim and the group ID of the target group and sends a new request to join the new target group as the victim.
3. If the victim was not a member of the group, the API returned a permission error:

   {“__ar”:1,”error”:1376045,”errorSummary”:”Cannot add member”,”errorDescription”:”You need to be an admin or a moderator of the group, or a friend of this person, to add them as a member.”,”payload”:null,”bootloadable”:{},”ixData”:{},”bxData”:{},”gkxData”:{},”qexData”:{},”lid”:”"}

   However, for someone already in the group, the API error explicitly said so:

   {“__ar”:1,”error”:1376015,”errorSummary”:”Already a Member”,”errorDescription”:”The person you’ve just tried to add is already a member of this group.”,”payload”:null,”bootloadable”:{},”ixData”:{},”bxData”:{},”gkxData”:{},”qexData”:{},”lid”:”"}

Facebook has since fixed the vulnerability. Lessons learned here:

• Permission checks should always precede functional errors, otherwise, you risk a Broken Object-Level Authorization vulnerability, like in this case.
• Sometimes API error responses communicate more information than they should. However, in this particular case, one could argue that letting a legitimate user know that the membership already exists is an appropriate response. All the more important then to make sure that the user really is legitimate.

Pentesting case study: Stealing users’ credit coupons through BOLA

Jai Sharma has posted a step-by-step write-up on how he found a way to steal someone else’s credits from a system that he was pentesting.

While observing the API calls that the app was making, he noticed among others this OPTIONS call:

OPTIONS /api/v1/client_info?email=user@web.com&external_id=00000111&customer_token=7ddf32e17a6ac5ce04a8ecbf782ca509&merch_id=60037

As attackers often do, he tried different verbs and noticed that he could perform a GET call on that same API. That call retrieved a lot of confidential user data, including current and expired credit coupons, credit history, and so on.

He could even make this call for other users as long as he knew their email addresses and their external_id in the system, which turned out relatively easy to obtain:

• It was a simple 4-digit number and the API had no rate-limiting in place. Thus, attackers could enumerate all possible values.
• In addition, the password reset call was returning external_id information for any user.

Thus, an attacker could retrieve and use any user’s credit coupons in the system as long as they knew their victim’s email address.

Lessons learned in this one:

• Make sure that your APIs do not respond to operations that they are not supposed to implement. This happens a lot when API generators are used, or additional operations are implemented, just in case.
• Make sure your APIs have both authentication and authorization in place.
• Do not use sequential IDs. Generate long random identifiers, such as GUIDs, to prevent enumeration.
• Apply rate limiting to your APIs to prevent abuse!
• Limit the information that your API returns to the bare minimum required by the application, and enforce that limited schema on your API responses.

Tools: JWT Attacker add-on for Burp Suite

JSON Web Tokens (JWT) remain one of the most frequently used authentication token formats in APIs. As such, JWT attacks are a frequent topic of this newsletter.

(If you need an overview of JWT and possible JWT attacks, see the recording from my JWT security talk at AppSec California 2020. Isabelle Mauny and I also did a webinar on the approach to externalize JWT security checks.)

The add-on JSON Web Token Attacker for Burp Suite helps penetration test some of the common JWT vulnerabilities. The add-on comes with the following features:

• Recognition and marking
• JWS/JWE editors
• Attacks:
  • Bleichenbacher MMA
  • Key confusion (changing the alg value)
  • Signature exclusion
• Base64url encoder and decoder
• Extensibility for new attacks

If pentesting is what you do, or you are just interested, do check this one out.

Opinion: EPAM CISO on API security

EPAM is a large system integrator helping lots of enterprises implement and protect their APIs. Security Boulevard has published an interview on API security with EPAM’s Chief Information Security Officer (CISO), Sam Rehman.

He talks about the challenging balance that API designers have to find:

• Flexibility: expose as much as possible to maximize the potential usefulness and business impact.
• Security: the larger the attack surface the API exposes, the higher the security risks.

Rehman discusses the common threats that EPAM sees in the market, such as:

• Weak authentication and authorization
• Impersonation and credential stuffing attacks, bots, ghost accounts
• Smart scanners automating attacker efforts to find vulnerabilities
• Inside-out-only perspective that limits companies to only test “happy paths” of expected API behavior
• Device security for mobile and smart devices

And on the practical side, Rehman also highlights the following API security best practices:

• Secure identities clearly, combine role-based access control (RBAC), and start enhancing with ABAC to fine-tune your authorization controls.
• Have smaller and more context-driven calls, ensuring that the defense layers can be more effective against attackers and reduce the impact of attacks.
• Consider zero-trust principles.
• Limit the number of exposed API calls, move callers to new APIs, and actively monitor and sunset any unused calls. Developers could also do device checks, as well as binding to subsets and versions of calls when possible.
• Review your API designs with offensive or white hat security experts to help figure out where the gaps are. When testing a function, they should complete both black and grey box testing.

---

Get API Security news directly in your Inbox.

By clicking Subscribe you agree to our Data Policy

---