Here’s How Easily You Could’ve Hacked Equifax

We’ve received a ton of community interest over the past week around the Equifax hack. When your company sits on the personal information for virtually all of the United States, you are subject to attacks from all angles. Phishing, social engineering, and zero day exploits are not out of the question when hundreds of millions of credit cards and SSNs are sitting on your server.

But this hack was different.

The script to run this attack was public, open for the world to see. The company was aware of the exploit for months. To make matters worse, this hack could have been executed with minimal programming knowledge and just a half hour of work.

The breach is a great example of why we need to move away from centralized data hubs like Equifax.

Almost all attacks can start with a targeted phishing email or social engineering attack. The phishing email that compromised the Clinton campaign is a good example:

It looks like a real email, but clicking the bit.ly link will of course redirect the user to a page controlled by the hacker.

Once access is granted to one computer in a network at a large company, a hacker will try to compromise other computers to increase the amount of access they have to sensitive resources. The attacker compromises other computers and gains access to more accounts (email, internal file servers, etc.) until they are able to carry out whatever malicious attack they wanted to do in the first place.

While it is easy to get access to company networks this way, it would probably be hard to get access to large amounts of sensitive credit data with this method. Hopefully only a limited number of employees have access to the core servers used for sensitive information and hopefully those servers are on a separate network. Hackers can probably get access to these sensitive services with some effort by creating fake companies and passing compliance checks, but stealing millions of records would be very slow and expensive.

The Equifax hackers didn’t trick an employee and escalate access, nor did they create a fake company to get access to the service. The hack was much simpler.

The worst kind of vulnerability

One of the worst vulnerabilities an application can have is called “Remote Code Execution.” Basically, an application with a remote code execution vulnerability will let an attacker run anything they want on the application’s server. If your application is online then I can tell it to run a program that lets me connect to the machine and operate it like it is my computer.

In a recent investor report, Equifax said the attack was performed using a remote code execution vulnerability that was reported in March 2017. This vulnerability by itself is not Equifax’s fault. The vulnerability was reported for a widely used Java framework called Apache Struts. Sufficiently complex software inevitably runs into vulnerabilities and bugs and the best we can do about it is fix it when we know about it.

Could they have known?

On March 12th, a security researcher disclosed that annualcreditreport.com was vulnerable to the remote code execution vulnerability for Apache Struts mentioned above.

The publicly disclosed vulnerability demonstrated that an attacker can access the server’s logs which show what traffic it is processing:

If you visit the about section on annualcreditreport.com, you will read the following:

This site is maintained by Central Source, LLC. Central Source, LLC is sponsored by Equifax, Experian and TransUnion so you have a single site where you can ask for all three of your free credit reports.

This attack was being exploited on other servers already when it was discovered, so the credit bureaus probably also found out about it on March 12th.

How hard would it have been to exploit?

If you read the vulnerability report, AnnualCreditReport is obviously vulnerable to this exploit. But knowing this server is vulnerable does not necessarily mean an attacker can access personal information for everyone in the U.S. To get that information you need to find out if the servers that give access to credit reports are vulnerable to the same attack. If you don’t even know the URL for these services then you can probably find them with some clever searching. For example, people usually write code and publish it on Github to interface with these services so:

Seems like a Java app when we try to request that URL:

This isn’t necessarily the endpoint that was exploited, but this process would probably help you find an endpoint to exploit.

How do we get on Equifax servers though? Well, as of March 9th there were tutorials published on YouTube explaining how to hack a server using the reported vulnerability:

So, in order to hack Equifax you had to follow a tutorial which shows you how to run someone else’s program. Basically, you run a program and put in the Equifax URL in order to get access to the server.

Stealing the Data

According to the Equifax investor update:

Based on the company’s investigation, Equifax believes the unauthorized accesses to certain files containing personal information occurred from May 13 through July 30, 2017.

and according to an analyst weighing in on the breach:

core databases not believed to have been breached

so the attacker most likely used the Struts2 vulnerability (as demonstrated in the YouTube tutorial) then ran a program like tcpdump to capture traffic or gcore to dump process memory over the course of 78 days. The attack was very simple and stealing the data was probably just a few more commands to record and download data.

What can we do?

Finance is dependent on the credit bureaus. They have all of important data needed for identity verification and credit scoring. Every company that needs to check real world identity or evaluate credit risk is working with one of the credit bureaus in some capacity (either directly or through a reseller). This fact is why an attacker was able to siphon off 143 million records in just 78 days. Whenever you work with a new business that is checking your credit or verifying your identity, you are probably passing your data through a credit bureau.

The value proposition of starting a credit bureau is having lots of centralized data, so it is hard to start a new bureau and even if you were successful you would just be another centralization point.

We can decrease how often we use the credit bureaus though. If you signup for ten different financial services over the course of six months, you shouldn’t need to give your private data to ten companies so that they can all pass it along to the credit bureaus. Likewise, if your credit score is primarily composed of your financial history, then you shouldn’t have to look up your entire financial history with the credit bureaus each time you want to do take out a loan.

With Bloom, we think identity checks should be linked to the identity you use for all financial transactions. Each new company you work with should be able to see your past checks and decide whether they want to do another check.

Public-key cryptography makes it easy for us to share data with identity verification companies, loan providers, etc. By publishing a detached signature along with the encrypted data, future organizations can collect identifying information for compliance reasons and know it is the same data used for past verifications. This makes it possible to adhere to compliance requirements without piping every check through the credit bureaus.

Financial activity should be privately linked to your identity in a way where you can share it privately if you choose to take out a loan. The detached signature approach lets future lenders know that you are sharing past financial information that hasn’t been tampered with.

Expecting the ancient credit bureaus to suddenly get security right is unrealistic. We should focus on systems that decentralize their roles and phase them out entirely.

Join Us and Sign Up Today

If this sounds interesting to you, sign up for Bloom and join our Telegram.