Issue 116: Facebook and Parler API vulnerabilities, clairvoyance 🔭

Pouya Darabi found an API vulnerability in Facebook that allowed him to create posts on other users’ pages. The posts were not popping up in the newsfeed, but they were visible and looked legitimate to anyone who would have accessed them through a direct link.

The vulnerability was caused by the lack of authorization checks for “invisible” (unlisted) posts. Darabi created such a post using his own account and was able to intercept the API request that Facebook sent. He then substituted the value of the parameter page_id with a value that belonged to a different user account:

Darabi then made the API call to share the post that generated a preview page for it. In that call, he also substituted the page_id value. That allowed him to create a post on behalf of another page.

The business impact here could have been quite nasty. Page administrators would not even see such posts because they were unlisted, so they could not review and delete them. Meanwhile, an attacker could distribute a direct link to the post and spread misinformation in the name of the victim.

This is another example of the Broken Object-Level Authorization (BOLA/IDOR) API vulnerability. The API call contains identifiers of a resource among the parameters, yet there is no authorization check to ensure that the caller has the right to access that resource.

Darabi received a total of $30,000 for his finding ($15,000 for the original report and then $15,000 more for a bypass to Facebook’s initial fix.)

The recent political drama in the US has affected the tech companies as well and led to an API breach. 70 TB of data from Parler, the Twitter-like social network that was popular among Trump supporters, got scraped through insecure APIs.

Judging by the various articles and discussion threads, it looks like the following happened:

1. Parler was using Twilio for account verification for password resets.
2. Twilio decided to stop serving Parler, and the account verification was removed.
3. Attackers were able to take over some of the administrative accounts in Parler.
4. The attackers used these accounts to create more admins in the system.
5. The hijacked and new admin accounts were used to access and scrape Parler data, such as posts, pictures, and videos that users had shared.

The IDs of Parler posts were sequential, so it was easy for the attackers to enumerate them all. The picture and video files were accessible in raw format, which included all metadata, like location information.

It also turned out that even deleted posts were still accessible: when a user deleted a post, Parler did not actually remove the content, just marked it deleted and stowed it out of sight.

These are serious security flaws, so here are a few lessons that one could take heed of, regardless of your political views:

• Authentication is key to security (see OWASP API:2 Broken Authentication) and should include all the ways of accessing accounts, including password reset.
• Using sequential identifiers is an open invitation to get your records enumerated and scraped. Use random IDs instead.
• Do not store any data that you do not need or should not be storing. The less data you keep, the smaller the risk.
• Monitoring, logging, and incident handling processes can help take quick mitigation steps should a breach occur.

Nikita Stupin has developed an open-source tool called clairvoyance that effectively does brute-force discovery of GraphQL APIs. This can be helpful for reconnaissance of GraphQL APIs that have retrospection disabled.

The tool makes use of a flaw in the GraphQL Apollo Server. The server error messages try to be helpful and, as a result, leak resource names when a call contains wrong values.

Here are a few examples:

See Stupin’s explanation and demo in this recording of his recent talk in OWASP AppSec Israel. The demo starts around the 13:15 mark.

Corey Ball is a cybersecurity consultant and the author of the upcoming “Hacking APIs” book (the title might still change). PortSwigger has published an interview with him on API security.

The topics included:

• The current state of API security
• Why API security is often overlooked
• Examples of breaches
• The role of API standards
• Advice to companies: scanning, API security testing, business logic review, not relying upon security by obscurity, and so forth.