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

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) on 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.

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.

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.

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.

Dear reader,

I hope this latest edition of the newsletter finds you and your families well!

At 42Crunch we are very proud to see how the apisecurity.io community and newsletter have evolved over the past 3 years. Our vision back in 2018 when we started the initiative was to establish the apisecurity.io website as a destination for all things related to API security. We hope you’ll agree that the diet of daily news and the weekly API Security newsletter is delivering on that goal.

A lot of the responsibility for the success of the newsletter has been down to the excellent curation and editorship of our friend and colleague Dmitry Sotnikov, together with the help of the team behind him. I am sad to let you know that Dmitry is now moving on to new pastures at the end of August. I wish Dmitry all the best on the next stage of his career and thank him for all his fantastic contributions to this community.

The need for a voice that researches and addresses the issues the API community faces is now more important than ever as the sophistication and scale of API attacks grows. We at 42Crunch are committed to continue investing in and expanding the research that the community site undertakes, with the same impartiality and quality that you have come to appreciate over the past 3 years.

To oversee this next expansive chapter in the life of APIsecurity.io and continue the production of your weekly newsletter, we have appointed Colin Domoney who joins us as Security Researcher and Developer Relations Advocate.

We’re excited by what lies ahead and look forward to sharing with you the progress of the API security community over the coming months and years.

Yours truly,

Isabelle and the 42Crunch team
Field CTO & Co-Founder