Issue 132: Experian API leak, breaches at DigitalOcean and Geico, Burp plugins, vAPI lab

Bill Demirkapi found an unprotected Experian API that returned a credit score based simply on someone’s name and address.

Demirkapi was shopping for a student loan and looked at the API that one of the websites was calling under the hood. The site asked for his name, address, and date of birth. However, it turned out that the date of birth was optional. Supplying all zeros instead of the actual date still produced correct results.

Besides the credit score, the API also returned some major risk factors explaining the score of the person in question:

This is pretty grim. Credit agencies are not supposed to return scores based on publicly available information. Thus, a publicly available API that returns this information on tens of millions of Americans with no authentication or private data required is a big problem.

Experian did not provide further details, but it looks like the problem stemmed from Experian exposing an API to their partners, and one of the partners then proxying the API to their web page, with no security whatsoever. That particular instance has been fixed but it is unclear if the issue could repeat itself on another partner’s website.

Lessons learned:

• When exposing APIs to partners, ensure that you mandate and enforce security rules for using the API. Do not trust your partners to protect your data.
• Assume the worst — that any such API ends up being exposed — and ensure that the API requires the parameters that you would require for public use and does not leak any data that is not supposed to be made available. Experian’s own website is a lot more restrictive in terms of this, and their APIs should definitely be at the same level.

We have covered Facebook GraphQL vulnerabilities in the past. Another one just got reported and fixed. Ahmad Talahmeh found a Broken Object-Level Authorization (BOLA) vulnerability in Facebook’s video editing API.

Talameh was looking at the API calls that the site made when trimming or un-trimming videos. He found that an attacker could replace the parameter video_id with the ID of any other video and thus trim somebody else’s video:

POST
/api/graphql/?__a=1&doc_id=3975916122480615&variables{"input":
{"end_time_ms":12000,"start_time_ms":0,"video_id":"victims_video_id","actor_id":"attackers_user_id","client_mutation_id":"1"}}

Facebook didn’t check whether or not the caller was authorized to make changes to the video (supposedly only the owner of a video was). Trimming the video all the way down to zero length made it disappear entirely, with no chance for the owner to undo this.

Lessons learned here:

• BOLA (aka IDOR) is a serious vulnerability. Always enforce authorization and make sure that resources are accessible only to users who are supposed to access them.

We are lucky when vulnerabilities are reported by researchers. They typically provide lots of details on the vulnerability, making it a case from which we all can learn.

Unfortunately, when companies disclose their API breaches themselves, there’s not much detail. Here are just a couple of recent examples:

• DigitalOcean: “An unauthorized user gained access to some of your billing account details through a flaw that has been fixed.”
• Geico: “We recently determined that between January 21, 2021 and March 1, 2021, fraudsters used information about you – which they acquired elsewhere – to obtain unauthorized access to your driver’s license number through the online sales system on our website. We have reason to believe that this information could be used to fraudulently apply for unemployment benefits in your name.”

Both disclosures look like possible API flaws, but we can only speculate whether or not this is the case and what the exact vulnerabilities were.

Burp is a popular tool for vulnerability testing. In his PimpMyBurp series, Adrien Jeanneau covers Burp plugins that help catch API vulnerabilities. As a teaser, here are quick descriptions of the plugins he covered in detail:

• PwnFox: Allows you to proxy several isolated Firefox sessions into Burp, displayed in different colors. That way you can, for example, access a site using accounts with different access levels (like an administrative and a regular user account), compare the calls, and then try to use the regular user to access administrative APIs to find broken function-level access (BFLA) vulnerabilities.
  
  
• Autorize: Allows you to take authentication (for example, a header or a cookie) from one account (“attacker”), apply it to calls made by another account (“victim”), and see which resources can still be accessed. If “victim’s” private resources can be accessed by the “attacker”,  we are most likely dealing with BOLA again:
  
• Auth Analyzer: Another testing tool for function-level authorization: “Just navigate through the web application with a high privileged user and let the Auth Analyzer repeat your requests for any defined non-privileged user. With the possibility to define Parameters the Auth Analyzer is able to extract and replace parameter values automatically. With this for instance, CSRF tokens or even whole session characteristics can be auto extracted from responses and replaced in further requests. Each response will be analyzed and tagged on its bypass status.”
  
• AutoRepeater: A powerful tool to change/add/remove on the fly any parts of API calls. It also adds conditional highlighting and filtering to the logs, making result analysis easier.

vAPI (Vulnerable Adversely Programmed Interface) is an open-source PHP-based lab by Tushar Kulkarni that you can use to see OWASP API Security Top 10 vulnerabilities in action.

You can set it up yourself, or use a Docker image. There is also a Postman collection file documenting the API calls.

A good resource for your API security exercises.