StatewardStateward
← All vulnerabilities
CRITICALAppSeccurated

APPSEC-EQUIFAX-2017

Web · Apache Struts · Equifax (Apache Struts 2)

Summary

Between May and July 2017, attackers stole the personal data of about 147 million people from Equifax, one of the three big US credit bureaus: names, Social Security numbers, birth dates, addresses, and more. The whole catastrophe traced back to a single unpatched dependency. A critical remote-code-execution flaw in Apache Struts 2 (CVE-2017-5638) was patched on 6 March 2017 and Equifax was told to fix it within 48 hours, but the notice never reached the team that ran the affected portal, the scan meant to catch the gap looked in the wrong place, and the hole stayed open. Attackers confirmed they could break in within days; weeks later a separate intrusion quietly siphoned data for about 76 days, helped by a monitoring appliance that had gone blind because its certificate had expired and no one noticed. It remains the canonical lesson, and an uncomfortably on-brand one, that you cannot defend a dependency you do not know you are running, or watch a network you have gone blind to.

How it happened

The flaw itself was simple. CVE-2017-5638 let an attacker put a malicious expression in the Content-Type header of a web request and have the Apache Struts framework execute it: remote-code-execution from an unauthenticated HTTP request, about as bad as a web vulnerability gets. The Apache Software Foundation patched it on 6 March 2017, and on 8 March a US-CERT alert reached Equifax. The next day an internal email went out telling staff to patch within 48 hours.

It did not get patched, and the reason is almost mundane. The email's distribution list was out of date, so the people responsible for the affected system, an online portal where consumers dispute credit-report errors, never received it. A vulnerability scan run days later came back clean, because it never checked the directory where the vulnerable application actually ran. The hole stayed wide open.

On 10 March, attackers confirmed they could run commands on the portal, but took nothing yet. The real theft was a separate intrusion that began around 13 May. Once in, the attackers found a configuration file holding unencrypted credentials, used them to reach 48 unrelated databases, and ran roughly 9,000 queries, successfully locating unencrypted personal data 265 times, pulling it out in small encrypted chunks routed through 34 servers in nearly 20 countries to stay invisible. They had about 76 days, because the network appliance that decrypts and inspects outbound traffic had been useless for many months (by the congressional account, nineteen) after its certificate quietly expired. The day Equifax finally renewed that certificate, 29 July, the device immediately lit up with the suspicious traffic and the breach was found within hours. The detection worked the moment someone turned it back on.

The damage

The stolen data was the worst kind: about 147 million people's Social Security numbers, birth dates, and addresses, plus roughly 209,000 credit-card numbers and 182,000 dispute documents with attached identity records. A Social Security number cannot be rotated like a password; the exposure is effectively permanent. Equifax's CEO, CIO, and chief security officer all left in the aftermath, and one division's former CIO was later singled out and fired for failing to forward the patch email, a vivid example of blaming a person for what was a systems failure. Equifax spent well over a billion dollars on cleanup and agreed in 2019 to a settlement with the FTC, the CFPB, and the states worth up to about $700 million. In 2020 the US Department of Justice indicted four members of the Chinese military over the intrusion.

Why Equifax still matters

Equifax is the case we point to most, because it is the purest example of the problem we work on. Nothing exotic happened. There was no zero-day, no nation-state malware on the way in, no insider. There was a known-vulnerable component with a patch already available, a notice that reached the wrong inbox, a scan that looked in the wrong place, and unsegmented databases with no limit on how many an account could query, so one portal compromise reached 48 of them. The fixes are all process: keep a real software bill of materials, enforce a remediation clock on critical CVEs in internet-facing apps with verification it actually shipped, segment and rate-limit data access, and alert on the health of your own defences.

And it is a lesson that refuses to stick. Four years later Log4Shell showed the same dependency-everyone-was-running-and-forgot pattern at even greater scale, and the xz backdoor showed its supply-chain cousin. "Vulnerable and outdated components" is its own entry in the OWASP Top 10 because Equifax was not a one-off; it is the default failure mode of modern software.

How to fix it

  • Patch or virtually patch the vulnerable component immediately, and confirm every instance is covered, not just the ones the inventory knew about.
  • Renew and monitor the certificates your inspection and monitoring tools depend on, so detection never goes dark silently.
  • Rotate credentials and keys reachable from the compromised application, and hunt for the data the attacker could read.
  • Verify your vulnerability scanner actually detects the issue; Equifax's scan ran and still missed it.

How to avoid it

  • Maintain a software bill of materials (SBOM) and continuously scan dependencies, so a critical CVE in a component like Struts is found the day it drops.
  • Enforce a fast, tracked remediation SLA for critical RCEs in internet-facing apps, with verification (not just a notice email) that the fix shipped everywhere.
  • Alert on the health of your own security controls (expired certs, dead sensors), so a blind spot pages someone.
  • Segment databases and rate-limit queries so a single internet-facing app cannot reach 48 unrelated stores, and watch for large or unusual egress.
  • Treat "use of a known-vulnerable component" as a release blocker, not a backlog item.

References

Related vulnerabilities

All AppSec →