Equi<i>hax</i>: Identifying & Wrangling Vulnerabilities

Equifax recently confirmed that the vulnerability responsible for the massive breach of 143 million records was indeed for the ApacheStruts 2 Web framework, but not CVE-2017-9805 as was initially circulated. Rather, CVE-2017-5638, which could enable an attacker to perform a remote code execution using malicious content in the absence of suitable security measures, has been pinpointed as the flaw that permitted access to the yet-to-be identified actors. CVE-2017-9805 is certainly worthy of our attention: until last week, it was essentially a zero day with exploits available in the wild.

The bug was first found in March, and a patch has been available since its discovery. In essence, Equifax could have been working to address the shortcomings and protect the personal information of millions using publicly available information approximately two months before the breach occurred. For reasons yet unknown, it did not. As a result, millions of Americans are scrambling to find out if they have been breached and to protect their information from being used for identity theft.

On the other hand, Equifax is facing federal scrutiny and a massive hit to its reputation and consumer trust. The firm's top information security executives — its CIO and chief security officer — have departed the company following what's being called one of the worst breaches in US history.

What happened at Equifax, and how can organizations patch their systems and improve their security posture to prevent breaches of this magnitude in the future?

Let's start with what happened: The data exfiltrated between May to July 2017 included names, Social Security numbers (SSNs), dates of birth, and "other information," according to Equifax. That data may now be for sale. Security blogger Krypt3ia found a listing on the Dark Web (shown in the image below) ostensibly placed by the Equifax hackers offering records for sale in return for digital currency. The listing includes some samples of the data in the form of screenshots. How much are the records worth? Four Bitcoins would net you 1 million entries; at today's rate, that’s approximately $13,840. It's unclear if the purchaser could specify what type of entries they could acquire, as an SSN would certainly command more money than dates of birth on secondary markets.

The listing is very disconcerting. Until recently, we were aware of the breach's grand scale and some rough order of magnitude in terms of the number of records: 143 million in comparison to the Yahoo hack, which included more, but arguably less-sensitive, records. Seeing records — and the personal identifiable information of individuals — is sobering. For those engaged in threat modeling, the price points provide a marker by which to assess the value of such records in underground markets, although both wallets appeared to be empty at the time of writing.

Vulnerabilities Matter but Do Not Stop Business
We can elicit a number of lessons from this event. In response to Equifax's disclosure of the Struts2 bug, the Apache Software Foundation released some cogent guidance to those using any Web framework. As always, Brian Krebs has provided practical advice to those who may have been affected by the breach. Gartner's Strategic Planning Assumptions are also worth repeating here:

This incident highlights the importance of a multilayer application security strategy. Firstly, it is absolutely critical to patch systems in a timely fashion. Had Equifax had an effective, multilayered application security strategy that includes the underlying infrastructure, middleware, application, and edge, the company likely would have prevented the intrusion or caught it much sooner. Appropriate data governance also could have diminished the scale of exposure of sensitive data: an understanding of what kind of records are in their possession, their classification, how long they can be kept for, and the security that must be applied to safeguard them accordingly appears to have been elusive.

A mature security regime requires organizations to implement a combination of technical vulnerability management processes and the ability to deploy effective security controls — including compensating controls when patches cannot be deployed in a timely manner.

Web applications and services (like APIs) represent critical business drivers as well as an exposed attack surface for a growing number of organizations. That attack surface can be reduced by properly hardening infrastructure and middleware, using up-to-date frameworks, and defeating attacks at the edge of the network: a Web application firewall, a security control that proxies all Internet traffic while applying a security posture to block traffic deemed malicious or unauthorized, is a highly effective control when properly configured. This year's Verizon Data Breach Investigations Report confirms that Web application attacks lead the pack with respect to breaches, with botnet activity bolstering that number considerably.

Hackers tend to view the human user as a path of least resistance, but that calculus changes considerably when vulnerabilities are discovered in technologies. Today's time-to-exploit has become relatively shorter as security expertise proliferates, even if the number of publicly available exploits is dropping.

Don't give attackers a window of opportunity! Vulnerabilities don’t need to slow down or stop business operations. Deploying patches is absolutely imperative to maintain a strong security posture, but the process can be disruptive or complex, especially for legacy systems, making additional security measures — acting as compensating controls — necessary to provide suitable defenses to maintain exploitable systems while patches are deployed.

Related Content:

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.