Experian fixed a weakness with a partner website that let anyone look up the credit score of tens of millions of Americans just by supplying their name and mailing address, KrebsOnSecurity has learned. Experian says it has plugged the data leak, but the researcher who reported the finding says he fears the same weakness may be present at countless other lending websites that work with the credit bureau.
According to KrebsOnSecurity, Bill Demirkapi, an independent security researcher who’s currently a sophomore at the Rochester Institute of Technology, said he discovered the data exposure while shopping around for student loan vendors online.
"Demirkapi encountered one lender’s site that offered to check his loan eligibility by entering his name, address and date of birth. Peering at the code behind this lookup page, he was able to see it invoked an Experian Application Programming Interface or API — a capability that allows lenders to automate queries for FICO credit scores from the credit bureau," KrebsonSecurity reports. "Demirkapi found the Experian API could be accessed directly without any sort of authentication, and that entering all zeros in the “date of birth” field let him then pull a person’s credit score. He even built a handy command-line tool to automate the lookups, which he dubbed “Bill’s Cool Credit Score Lookup Utility.”"
In a written statement, Experian said, “We have been able to confirm a single instance of where this situation has occurred and have taken steps to alert our partner and resolve the matter. 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.”
Security spoke with several industry experts about their thoughts on the Experian news. Here's what they had to say.
Setu Kulkarni, Vice President, Strategy at WhiteHat Security, a San Jose, Calif.-based provider of application security:
This is a wake-up call for Experian, yet again demonstrating that while the use-cases have to be designed for the end user, the abuse cases have to be designed for the super-users (benign or adversarial).
Kulkarni explains, "If you look at the flaw, it was a basic authentication flaw – something that should have been contemplated during the design phase of the software. What is worse here is that there are API Management solutions that allow organizations to compensate for missing authentication in the APIs they want to make public. When two companies decide to integrate their applications, they should explicitly account for the risks both companies inherit — which are posed by insecurities in each other’s applications. If you are an organization looking to partner with other companies, API, web and mobile applications must be tested for security to avoid consequential loss due to security vulnerabilities on the part of a strategic partner. Similar to how we view the spreading virus, it is possible to unintentionally infect your friend or your organizational partner if you do not take the necessary precautionary steps of testing and protecting your applications. Prioritize the requirement for application security assessment with your partners when you are executing on your growth strategy with them."
Hank Schless, Senior Manager, Security Solutions at Lookout, a San Francisco, Calif.-based provider of mobile security solutions, says:
The prominence of cloud-based services and technologies has created a massive ecosystem of interconnected services that help organizations of all types boost their business internally for employees and externally for customers. Integration between various apps and services can make the overall experience much more convenient and seamless for users. APIs, especially for large platforms like airlines or social media, are oftentimes made public so anyone can connect their service to those platforms. However, the convenience of integration shouldn’t put security on the back burner.
This incident highlights how important it is to understand the security posture of all your resources. In this particular case, that means vetting any third party service you decide to integrate into your services or infrastructure. When you integrate your services, there’s always the risk of an attacker getting to your data after initially breaching the partner service.
Integrations aren’t the only thing that can expand the reach of your data. As your cloud infrastructure expands, sensitive data ends up in various storage systems that don’t necessarily have strong native security configurations. In order to make sure your data isn’t leaking out of unsecured storage systems, you need to have visibility into your overall cloud service security posture.
You need to understand who has access to what sensitive data - especially as the digital world continues to get more widely distributed. This mindset should apply to the people, devices, and external services that could access data and present a possible security risk if they’re compromised.
Sean Nikkel, Senior Cyber Threat Intel Analyst at Digital Shadows, a San Francisco-based provider of digital risk protection solutions:
As a good practice, web application penetration testing should happen during the testing and development stages of application development. Developers should also use secure coding principles and work closely with testers to ensure the application itself and information within stays secure. Testing should also continue regularly as part of a product lifecycle, especially as new changes are rolled out to production, to ensure that the application continues to deliver the intended results while also protecting sensitive information.
Jack Mannino, CEO at nVisium, a Falls Church, Virginia-based application security provider:
This isn’t unique to Experian. Many websites being launched for vaccine management and other public health services seem to struggle with the same issues. Making systems accessible to the broader public using private data often has security tradeoffs and consequences. Stronger authentication and verification processes are required along with access controls and sane anti-automation defenses, in order to prevent these attacks.
Michael Isbitski, Technical Evangelist at Salt Security:
The leaky API was stood up by Experian so that lending partners could verify credit worthiness of an individual and potential credit applicant. The data returned by the API included the person’s FICO score and impacting risk factors on credit worthiness such as high credit utilization or too many open revolving accounts.
To authenticate the individual, the public API required only first name, last name, street address, zipcode, and birthdate. Unfortunately, this last authentication factor was not validated properly, and the check could be bypassed by using all zeros for the birthdate.
Even if an individual’s birthday was being properly validated, the authentication factors that were being used were weak. Much of the authentication material that Experian was using is public or semi-public as a result of prior security breaches at other service providers.
It's not clear if this weakness was exploited by other attackers beyond the security researcher's probing and disclosure. Experian confirmed only that they were able to uncover the security researcher’s activity in their backend logs after the problem was disclosed to them. An API that uses weak authentication like this could potentially be enumerated and scraped to obtain large amounts of the private, credit-related data.
From the perspective of the consumer, a credit freeze is always a good idea to protect themselves from identity and credit fraud. If an individual had a credit freeze in place, Experian’s API returned no data for that person.
