The Facts on Equifax

This is Recorded Future, inside threat intelligence for cybersecurity.

Dave Bittner:

Hello everyone, I’m Dave Bittner from the CyberWire. Thanks for joining us for episode 27 of the Recorded Future podcast. By now, you have surely heard that Equifax, one of the large credit reporting companies here in the U.S., suffered a huge data breach. How bad was it? Well, reports say over 143 million sets of personal information may have been lost on U.S. residents alone, including names, social security numbers, birth dates, addresses, and in some cases, driver’s license numbers — so, pretty bad. And the story is still developing.

John Wetzel is head of threat intelligence training at Recorded Future, and he joins us today to help make sense of what happened to Equifax, how it might’ve been prevented, and what a breach of this size means for all of us. Stay with us.

John Wetzel:

Equifax was a very large data breach of, presumably, consumer records that had been gathered from Equifax’s vast trove of information of monitoring credit cards, banks, financial services, and companies. Anything that you have — a credit card, a debit card, a mortgage or a loan, if you’ve ever borrowed money — and anything that’s ever been exchanged or touched on is what they use. They basically use a simple identifier, most often, your social security number.

The Equifax breach was likely those full pieces of data — essentially, all of your financial, digital life that was stolen — and this was most likely done through a new technical exploitation technique called server-side template injection. The way that works is they took advantage of a very common open source software called Apache Struts — actually, Struts 2. There was a vulnerability in that, a 2017-5638, which allowed people to essentially inject this type of template into the web application. What that does is it started being able to allow them to shut off certain preferences, and then open up that full web app for a lot of data leakage.

Dave Bittner:

So, they get access and then it’s simple for them to exfiltrate all this data?

John Wetzel:

So, you’re an attacker. You know that there is a really valuable target like Equifax because they have so much information. They are the hallmark for what you want to achieve. They have full personas, pretty much, all of the digital transaction information, so you have to ask yourself, “How do I attack them?” As an attacker, you look at, “What’s already available to me?”

Many times, these types of companies have websites and web applications that are fully open to them. You may not even realize you’re on an application. It could just look like a form. It could just look like, “Hey, I’m going through there and I’m asking this thing some questions and then it’s providing me some answers. Maybe I’m asking it to provide me my entire digital history through an annual credit report. Maybe I’m asking it to protect me by signing up for some kind of service.” Well, all of that information gets documented, and then it’s exposed to the public, so they want it there.

As an attacker, though, I know that behind that is a database, and that’s what I want to get to. You see these types of attacks all the time. The most common one that’s talked about is the SQL injection. I know that there is a type of database called the SQL, and MySQL behind that, and I use particular strings of characters that I know are going to make that database go a little crazy.

This is an extension of that type of attack, where you inject a little piece of what looks like code, but the database reads that as a code, not as just a straightforward answer like, “What is John Wetzel’s name?” Then, it executes that code, and because it does, it now dumps groups of information. Maybe it’s the full information, maybe it’s only partially the information that’s in that database. That’s how you start getting that type of leakage here.

Dave Bittner:

Once this happens, once the bad guys start sucking this data away from Equifax, should alarms have been going off inside of Equifax central?

John Wetzel:

There’s a lot of different answers to that. The core answer is absolutely, but I do understand the challenges as well. Many times, in the web application security, we think that we have security procedures set up such as … The most common technique is a web application firewall, and what this is, is it allows certain types of behavior to exist, and for other types, no.

We also use things like vulnerability scanning where we’re going out there and saying, “Hey, are we exposed to recently critical vulnerabilities? Do we have to stay overnight? Do we have to patch these things?” That’s always the continual challenge and struggle.

In this case, though, this vulnerability was documented as a critical vulnerability by the National Vulnerability Database back in March. We knew that these types of open frameworks were vulnerable to this type of attack. We also knew that attacks against web applications have been rising. In fact, they’re one of the leading attacks that are out there because attackers know behind that web application, there’s a lot of data, and that data can be really, really valuable.

There are all of these indications that both external threat intelligence as well as internal monitoring can pick up on, and those things, in this case, happen to fail. Now, the avenue for that failure was in fact this type of very critical vulnerability, but that vulnerability was known. It was very well-publicized, and many of the most advanced teams actually took very proactive measures to get ahead of that, and then once that vulnerability came out and was fully disclosed, protected and defended their networks against it.

Dave Bittner:

Certainly, they’ve received a lot of criticism for not patching the vulnerability that was known, as you say, for not patching it quickly, but I’ve heard other people saying that on the other hand, patching large systems like this aren’t as easy as maybe perhaps people think it is.

John Wetzel:

The problem with patching large systems is that it’s hard enough to do on the individual level. I think many of us have been in front of that computer where you are sitting there, and it pops up with a warning that says, “If you don’t patch this, your system could start on fire. Do you want to patch it right now or delay 10 minutes?” I’m guilty of this too, where you just delay 10 minutes because you’re in the middle of something. You’re never not working now.

Take that problem, multiply it by 500,000 and then spread it throughout a bunch of different users, user groups, machines, servers, and this gigantic infrastructure, and then combine that with not just one, but all of the other vulnerabilities, which are also rated as critical at that time, and now you have to choose. How do I prioritize my patching on an enterprise scale?

The way that you can prioritize that, traditionally, is by looking at the CVSS scores that are put out by the National Vulnerability Database. Those are the scores that the vendors come up with to say, “This is how bad we think this is.”

The problem with looking at those scores is that they aren’t always 100% accurate when they first come out. Vendors could think that something is slightly critical, and then later on find out, “No, no, no, this is terribly critical.” A great example of that was Heartbleed.

With this case, not only was the CVSS score very, very high, it was also well known that criminal actors were talking about this, and this fell in line with behaviors that we saw both on the deep and dark web, but also leading up to the six to nine months out. We saw criminal actors saying, “Hey, how do I get into these web applications? Are we seeing an uptempo in these type of injection attacks?” And we were.

Dave Bittner:

Yeah. Let’s dig into that a little bit. You all are in the threat intelligence business. What kinds of things were you seeing specific to this attack, but also more in a general way of this vertical?

John Wetzel:

The vulnerability that was used in this case was a CVE-2017-5638, which is, again, that Struts vulnerability that’s based on this open framework. Now, to that line, we’ve seen attackers utilize these types of open frameworks, so this very, very common attack surfaces, whether it’s common web application frameworks, whether it’s Java-based frameworks.

We’ve seen earlier attacks and blogged about them, like attackers using JBoss and identifying vulnerabilities in that. We’ve seen attackers try and use and identify these tools, especially starting out with very, very simple web shells to attack this common web service. I think we think a website is a website is a website.

In this case, the Equifax attack used about 30 malicious web shells, and you see different hash values for that. Now, these web shells are not uncommon. We’ve seen some of them. For example, Jsprat was a tool that has been publicly known to the security community since at least 2011.

It’s not like these are new and original tools, it’s that the scale and scope of this was done for a target that really had both the financial means and the ability to put down resources and prevent it — if not the breach itself, the scale and scope of that breach.

Dave Bittner:

I think that’s one of the things about that that strikes people, and I think a common thing with these cybersecurity breaches is this sort of disproportionality of it, that with a breach like this, things could’ve gone a little bit bad and perhaps have been stopped in the midst of it, or things can go basically nuclear, which is what happened.

John Wetzel:

Yeah. The role of security is always to mitigate an attack and reduce the time to recovery. That’s always an incident responder’s role. In this case, let’s say, they had been able to breach through the web application firewall, which does not provide anywhere near the level of protection that I think many network administrators think it does.

That’s not an unusual case, especially, because in this case, you have a lot of flaws, not only in these types of vulnerabilities that are published, but also the implementation of those Java methods that are used and save the libraries there.

Attackers know that these type of vulnerabilities exist, and we’ve seen a lot of adversary research that are targeting these types of vulnerabilities in programming languages, whether it’s Struts or JBoss, anything that’s on the .NET, the PHP, PEARL, Python, Ruby, Java, all these different types of common frameworks there that are utilized across the board and across the web.

Because attackers know that “x” target — let’s say, a certain type of target — is always going to have this type of infrastructure set up for their web applications … let’s be honest, when we hire people, we hire people that have done things similar to what we’re trying to build, so they tend to build things in the same way.

As an attacker, I now know that this is a common attack surface. If I have the knowledge that “x” — let’s say, Apache Struts — is always going to be running on servers that are in this type of business structure, and I identify vulnerabilities or web shells that take advantage of those vulnerabilities and exploit them in a consistent manner, then I can build a very successful career with very little effort, of just my knowledge that those are common vulnerabilities that exist across this type of vertical.

Dave Bittner:

Let’s talk some about the incident response and some of the criticism to Equifax’s response to all of this. Certainly, they’ve been raked over the coals, as many would say justifiably, for the ways they responded immediately after the revelation of these attacks, and even up until now.

John Wetzel:

It’s always a challenge when you’re responding to a large-scale breach, and the very nature of that large-scale breach is always going to be a strategic surprise. That’s the first line that intelligence is supposed to eliminate — strategic surprise. We are so shocked by this event that we are not prepared, both from a resource perspective or from a strategic response perspective, to be able to do anything about it.

Now, in this case, they should’ve been. You generally think about the framework of “How do I prepare for this? What are my worst-case scenarios?” In Equifax’s case, this is, in fact, their worst-case scenario. A large-scale breach of the vast amount of data, to which the individual consumers had not given them permission to have accumulated all this data. They know they’re a target.

How do I gain through that? Usually, what you do in an intelligence process is you sit there and say, “Alright, I’m going to make certain assumptions, and based on that assumption, let’s do a tabletop scenario.” We run through this scenario. You either do it in-house or you have another group or company come in and guide you through that process.

I’ve been through several security conferences where they say, “Hey, nothing like running this type of scenario,” and then halfway through, you pull the CISO out because they don’t have to speak with the press. “Washington Post is on the line and wants to talk about this.”

Those types of things should be practiced and expected, and it’s during that time before the storm that you start building those structures, understanding where you need to apply resources, ensuring that you have those communication bridges built between elements such as your lines of business, your PR, your marketing, your security teams, your legal team, so that when you go out there and say, “These are the ways that we’re going to respond to this,” it in and of itself helps mitigate and helps you get up that time to recovery and get that secured.

In this case, what we saw is a completely delayed response, and then an underwhelming response that came months after the supposed first breach, and we still don’t have all the information about what happened.

Rather than having a clear understanding from the security research side, from the security community, or the consumers at large, knowing what actually is happening and how this is going to be prevented in the future, many people are stuck in this realm of “Well, I can’t trust anyone else. Everything out there is going to be compromised. I don’t know what to do, and I’m just now living in a state of fear.”

Dave Bittner:

Certainly, with 143 million records, perhaps, out there, we’re talking about 400,000, up to 44 million British residents and folks in Canada and other places around the world … I’ve heard people comment that in terms of personal identifiable information records, this is pretty much all of them.

For all intents and purposes, you might as well assume that your information is out there. If nothing else, with this combined with many of the other attacks, you might as well consider that your information is out there. I can’t help but wonder, is it time to do better than the social security number as a piece of identifying information?

John Wetzel:

I think there are multiple lessons to be learned from this, and the one that keeps consistently coming up is a nine digit number that secures our digital identity, in this day and age, is not only inadequate and dangerous, it is irresponsible at a government, nation-state level. We do need to have better security around how we identify.

There are countries that we might consider to be Eastern Europe that provide a digital token from the moment that you’re born, and that token is used to do everything from transactions to establish identity to vote.

These are not impossible standards. They are costly. They do require a lot of infrastructure, and they do require momentum and impetus, not only from the security community or the technology communities in general, but also from the populace. Citizens need to realize these are things out there that are easy that would make them vastly more secure, and they need to be applied at state and federal levels.

The other side of that is that we see these threats increasing, and because of technology, there’s a gap between people understanding what are real threats and what are not, and I think that’s the other side of this tragedy.

We want people to be informed about the threat enough to realize action needs to be taken, but we don’t want people to be in a state of constant fear, where now they think everything is a danger and a threat.

The threat here is that this is exactly what criminal actors want at large, and that’s the idea of … If you look at certain criminal forums, these are called fulls. This is a full identity. If I have a social security number, I can do a little bit. If I have a credit card number, I can do a little bit for a very, very short amount of time. I think we’ve all had a fraud alert where some criminal person has tried to use our credit card at some gas station in a state that’s thousands of miles away.

In this case, what we’re talking about is a criminal actor not needing to pivot through. Say, start with a social security number, pivot to a credit card, and then try and do some human hacking, where they’re calling up a help desk to try and reset a password.

They have all of this validated information, and it’s really hard to change. You can’t change the fact that three years ago, you took out an auto loan. It’s just there. It’s part of your history. It’s part of how we validate.

That’s the other side that I think people have not talked about as much. We need to also consider changing how we validate and verify our identities from not just the nation-state level, but as companies. What are we requiring for people?

I think everyone has gone through and knows the three security questions that come through, they’re usually something like, “What was the first street that you lived on? What was your dog’s name? What place did you get married in?”

I think that we need to start considering, “How do we create better security at a enterprise level that helps assist our customers, the people that are providing this information, helps understand where that information is going?” It may not reach with just that one organization. Banks sell information all the time.

We need to think as companies, “How do we establish things that won’t hamper the business, but help people protect themselves?” Rather than having these common practices, maybe we just make slight changes. Maybe we do things in a better way that will help across our institutions make people make better security decisions.

Dave Bittner:

For organizations who are looking at this Equifax breach and saying, “Oh, that could’ve been us,” what advice do you have to put them at ease, to help prevent them from being the next victims of something like this?

John Wetzel:

To be put at ease, I think, is to be prepared. I really do believe that good threat intelligence helps you look out ahead in a systematic way and say, “What is, might, or is likely to hit me at some point in the future?” You have these structures that are built there that are very well-defined that come mainly from the U.S. government or U.S. military. What’s going to happen in this set period, six to nine months out, that I may have to apply resources to defend myself?

From a tactical and operational level, we look at these types of attacks and say, “How do we make this relevant to us? Yes, we see that this type of breach has occurred, but maybe we’re an energy sector company. Maybe we are in a completely different line of business. How do we make this relevant to us?”

Well, the first play is we start finding the similarities between not only the type of organization I am. I think it’s really easy to think, “I’m a financial organization, so all financial attacks affect me.” Well, maybe certain attacks look at banks, versus investment companies, versus insurance companies. Maybe you’re a manufacturer, but this is towards automobile manufacturers versus medical device manufacturers. It’s important to understand what type of attacker we are looking at. “What is my threat?”

Number two, “What is the infrastructure over which that threat is channeled?” In this case, we saw that web applications were that vector. It is not unexpected to see that criminal actors would then look at that infrastructure and say, “Who else is vulnerable to this? Who else is running web applications that may be poorly secured?”

From there, I get a couple of different actions I can take. Number one, identifying and patching the vulnerabilities which affect those easily exploited, as demonstrated here, web-applications. Build up my defenses.

The second part of that is identifying the threat actors. You don’t have to get down to names and dates, but you can identify the campaigns that are targeting your organizations or those types of vulnerabilities and then add that as part of your threat mapping, so that when you’re sitting there and looking at your full threat picture, you’re going to state, “We’ve seen attackers. Even though they have attacked in this surface area, they may migrate to my type of company because we have similar types of information.” Am I looking ahead and saying, “Do we see that happening?” That’s where intelligence starts. You ask a question and you try to answer it.

Dave Bittner:

Our thanks to John Wetzel for joining us. Don’t forget to sign up for the Recorded Future Cyber Daily email, where every day you’ll receive the top results for trending technical indicators that are crossing the web, cyber news, targeted industries, threat actors, exploited vulnerabilities, malware, suspicious IP addresses, and much more. You can find that at recordedfuture.com/intel.

We hope you’ve enjoyed the show and that you’ll subscribe and help spread the word among your colleagues and online. The Recorded Future podcast team includes Coordinating Producer Amanda McKeon, Executive Producer Greg Barrette. This show is produced by Pratt Street Media with Editor John Petrik, Executive Producer Peter Kilpe, and I’m Dave Bittner. Thanks for listening.