Experian API Security Incident — What Happened and How can you Protect Yourself
While using an unnamed lender site, an independent security researcher by the name of Bill Demirkapi discovered a flaw in an API that was designed to assess an individual’s credit worthiness as part of promotional inquiries. The lender site called an Experian API to validate the user provided PII including first name, last name, address, zip code and birthdate. This API was found to be leaky based on the information it used to identify the API caller and the personal data it served back in the response.
The credit information returned by the Experian API included FICO scores and risk factors that impact the given individual’s credit history, such as proportion of balances to credit, number of accounts, and length of time accounts have been open. The API was designed to use authentication material that is largely public or semi-public. Much of the authentication material for a given person can be gathered through Internet searches of public repositories or by harvesting data from prior breaches at other organizations.
Get the free customizable API Security Best Practices Checklist.
Download NowDetails of the API weaknesses
The leaky API from Experian exhibited the following weaknesses:
- Weak authentication
- Security misconfiguration
- Excessive data exposure
- Lack of resources and rate limiting (potential)
Weak authentication
The API used PII that is largely public information as authentication material. Birthdate was also not being properly enforced, but it’s likely someone could guess this info anyway. Attackers can find PII such as what was used here readily with Internet searches and by scouring social media services. The issue maps to OWASP API2:2019 Broken User Authentication, though in this case the situation is more about choosing a weak authentication factor rather than the authentication mechanism being broken. Knowledge-based authentication (KBA) mechanisms often rely on information that’s essentially “public” as a result of prior data breaches, which weakens authentication for any API that is designed to use KBA. It is not an issue specific to just Experian. It’s also common to find these types of KBA mechanisms within forgotten password flows. If KBA isn’t paired with other strong authentication factors, such controls can be brute forced by an attacker given enough time.
Security misconfiguration
The Experian API was not properly validating the birthdate value provided in the API request. It should never be possible to supply an invalid value such as 00/00/00 as a birthdate. The API was already relying on weak authentication, and this lack of validation for the most private authentication material weakened things even further. We can only presume this birthdate validation was disabled as a result of debugging or testing functionality that made its way to production. If this were the case, OWASP API7:2019 Security Misconfiguration would be the relevant classification of the issue. A developer or infrastructure engineer may have inadvertently left something disabled to speed up testing efforts, neglected to re-enable the authentication factor, or used an inappropriate build tag. The validation of birthdate in code or configuration is something that could likely be audited for in build pipelines.
Excessive data exposure
Typically this issue is a result of returning too many details in an API response that are in turn filtered by the front end. The issue maps closest to OWASP API3:2019 Excessive Data Exposure. In the Experian case, it’s more about the context of the API transaction sequence and what authentication material was provided to even obtain the credit information. It’s reasonable for consumers to argue that providing such a small set of publicly available information shouldn’t be enough authentication material to obtain their FICO score and impacting credit risk factors. No individual would be OK with their credit information being public knowledge. The user data should have been treated more delicately and secured adequately.
Lack of resources and rate limiting (potential)
The researcher created a script in the form of “Bill’s Cool Credit Score Lookup Utility.”
It’s not clear if the Experian API could be enumerated to scrape customer data at scale. Presumably, resource and rate limits were not in place for the API if the researcher thought to create a script to automate queries. Such a finding would map to OWASP API4:2019 Lack of Resources & Rate Limiting. There is no code currently posted on Demirkapi’s github repo or Demirkapi’s blog to validate this weakness further.
Top recommendations to avoid an incident similar to the Experian leaky API
The Salt Security API Protection Platform is built to stop attackers that aim to abuse these types of API weaknesses and scrape leaky APIs for sensitive data.
Specific to the Experian leaky API incident, recommendations include:
- Don’t rely solely on IP address allow or deny lists and static rate limits as your primary means of preventing API abuse. Demirkapi was concerned that Experian would fall back to this type of control to fix the issue with the leaky API. Meanwhile, the API stayed in existence to be used by other partner lenders, slightly obscured now by network access control lists to allow or deny certain IP addresses. We don’t have a lot of information about the design of the Experian API or how it was intended to be used with lending partners.
For smaller sets of partners, many organizations will restrict access for their hosted APIs so only known IP addresses or IP address ranges of API callers are permitted. Using the Experian scenario as an example, only the backend of the lending partner (the API caller) should request information from the Experian API (the callee), and only the IP addresses or IP address ranges of the lending partner should be permitted. A user should not be able to query the Experian API directly. However, depending how many partners there are that need access to the API, it may not have been possible for Experian to operationalize such controls. Such are the limitations of traditional traffic management approaches like allow/deny lists and static rate limits. - As a consumer, ensure you have a credit freeze in place with the credit bureaus. In this case with Experian, it was not possible to call the leaky API to retrieve information on individuals with a credit freeze in place. If we give Experian any credit here, it’s that it at least enforced this access control properly.
- Test authentication and authorization mechanisms but also acknowledge the limitations of automated scanning. A given DAST tool would have to validate the negative test case of no authentication factors supplied or authenticating using other types of data. Unfortunately, these types of privilege escalation issues aren’t well handled in the world of security testing.
Security testing of authentication and authorization is not a “set it and forget it” affair. You’re looking at a manual testing effort involving multiple subject matter experts for the application itself, the associated IAM mechanisms, and the security testing tools. Some organizations coordinate focused, periodic testing efforts, possibly as part of red team activity, to assess customer or employee authentication in business critical applications. A SAST analysis may have uncovered that the authentication factors weren’t properly validated in the codebase, but this would hold true only if a validation was performed in the code of the API. It’s possible that access control was handled by IAM mechanisms that are external to code.
Concede access control approaches for public and anonymous APIs
Public APIs create inherent risk, since the design leans more towards allowing anonymous access. For such public APIs, traditional authentication and authorization mechanisms are a luxury. It’s simply not possible to enforce strong authentication and authorization without registering users or employing additional authentication factors such as 2FA. Forcing such controls can impact customer experience too greatly. A given organization may also have too many client types to support as API consumers. This range of client types common in omni-channel experiences and large partner ecosystems makes client-side profiling and enforcement a non-starter. As a result, runtime security and behavior analysis are critical for understanding normal API consumption patterns and identifying anomalies. Obtaining this context is the last line of defense since traditional access control approaches at the network or identity layer are usually not feasible.
The Experian API was designed to be more open in order to facilitate business with lending partners. In the world of financial services, identifying API callers quickly gets in the weeds of know-your-customer (KYC) guidelines, anti-fraud mechanisms, and how credit bureaus and data brokers do business. An organization must accept the risk that an API that is designed to be more open that serves sensitive data may be targeted by attackers and have privacy ramifications. While the Experian API was not anonymous, the material (“something you know”) used to identify and authenticate callers was very limited. Even if birthdate was being properly validated, this is still a weak authentication factor. Much of these types of data have been leaked from other breaches, can be easily searched for, or can be harvested from social media.
Understand attacker archetypes and methodology
Attackers will take advantage of API weaknesses to enumerate those endpoints and scrape data en masse. In the case of Experian, an individual by the name of Hieu Minh Ngo had established an identity fraud service making $125,000 per month selling users’ private data that was scraped from many data brokers including an Experian partner service. He ran this identity fraud business from 2010 to 2018, making millions of dollars by reselling the private data of Americans. The resulting fraud that was enabled by Ngo’s scraped data totaled well over $1 billion as it was repurposed by fraudsters in other schemes over the years. Data holds value, and fraudsters frequently use it as an illegitimate business model.
It’s not just hackers or fraudsters that should concern organizations. Security researchers, doing the right thing, also probe APIs to find weaknesses. Ethical researchers will follow responsible disclosure best practices such as Demirkapi did here. Demirkapi has also reported vulnerabilities on the bug bounty service, HackerOne. Organizations with mature security programs will often institute responsible disclosure policies, follow coordinated vulnerability disclosure, and/or make use of crowd-sourced security testing and bug bounty services. Organizations suffer significant brand damage when someone finds and discloses an issue. How quickly you respond to the event and relay information is critical. Transparency is often in the best interest of all parties involved.
Conclusion
Experian hasn’t fully owned up to the ramifications of what happened with this leaky API. It’s not clear if other attackers may have used the leaky API to scrape data on individuals. This small detail is a difference between millions of individual’s credit history being at risk by the leaky API and that data having been actually leaked through the leaky API. Experian’s public statement was as follows:
“While the situation did not implicate or compromise any of Experian’s systems, we take this matter very seriously. Data security has always been, and always will be, our highest priority.”
While it is technically true that Experian’s systems weren’t directly breached, private data was most certainly leaked. The only question is the volume of data leaked. This public statement is a spin on the security language of incidents and breaches without properly acknowledging privacy impacts. It’s also relevant to one of the myths we regularly try to expose here at Salt where organizations sometimes focus too heavily on restricting access and limiting blast radius of infrastructure without acknowledging the application security and data security elements of API security.
The lender hasn’t come forth and taken responsibility for the site that called the Experian API. It’s not clear if the website was enforcing birthdate in the front-end before calling the Experian API. it’s largely irrelevant though, since as we know from other API security incidents and attacker methodology, front ends aren’t the thing of value. APIs are the key to functionality and data. Attackers regularly reverse engineer front ends to figure out how back-end API calls work, and then they invoke and abuse the APIs directly.
Time is always on the side of attackers, which is why we stress the importance of having adequate runtime security to detect and stop attackers early in reconnaissance phases. You can test for certain types of vulnerabilities and weaknesses in build pipelines, but as we see time and again, attackers don’t often exploit those types of issues. Business logic abuse and automated attacks aren’t detectable with traditional security testing done in pipelines, which is where many organizations focus their efforts as part of DevSecOps programs. A mature DevSecOps approach stresses design-time, build-time and runtime measures.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
Sources:
https://krebsonsecurity.com/2021/04/experian-api-exposed-credit-scores-of-most-americans/
https://twitter.com/BillDemirkapi/status/1387514273904144384
https://twitter.com/briankrebs/status/1387510858146848768
https://krebsonsecurity.com/2021/04/experians-credit-freeze-security-is-still-a-joke/
https://krebsonsecurity.com/2017/09/experian-site-can-give-anyone-your-credit-freeze-pin/
https://krebsonsecurity.com/2020/08/confessions-of-an-id-theft-kingpin-part-i/
https://krebsonsecurity.com/2020/08/confessions-of-an-id-theft-kingpin-part-ii/
