7 minutes estimated reading time.

Equifax Missed Defense in Depth, Allowing a Massive Data Breach

Frank Rietta — 09/18/2017

Equifax has confirmed that the main vector that lead to the data breach was a remote code execution vulnerability in Apache Struts that had been known for months [1]. Equifax had not yet patched it within the production environment. This is not just a lesson in the importance of patch management but one of defense in depth. The weakness in Equifax’s design was set in motion years before when they failed to design with the assumption that the front-end web server would be compromised.

The attacker was able to obtain the massive trove of private data because the web application was the only gatekeeper. Once the remote code execution vulnerability was exploited, the attacker was able to access data unfettered by additional access controls. Equifax chose to use a typical web application architecture without defense in depth.

Defense in depth has to start as part of the development process. All developers should be aware of the OWASP Top 10 (#3) and their work should be audited against the OWASP Advanced Security Verification Standard (ASVS) [#3] for the level appropriate for the risk faced by an organization in the event of a security breach.

A Typical Web Application without Defense in Depth

In a typical web application, there is little or no defense in depth. The web application has full read and write access to the underlying data store. The web application code is the sole arbiter of access. This looks something like the illustration below.

Typical Web Application Data Security Model

One should note that there is no firewall depicted between the public Internet and the web application. Traditional firewalls provide no security benefit in this context as the public has direct access to the web application as a matter of design.

When everything is executing as the web developers assumed it would, things are fine. Subtle flaws in the application code or the framework code can shatter these assumptions and lead to an exploitable vulnerability where an adversary gains access to sensitive data to which he or she should never have access. Many web applications are built this way in every programming framework. Any flaw in in the web facing application puts all the data in the database at risk.

This is is the ordinary and easy way to build a web application where the business model basically presumes that the software can and should access all of the data. But if you’re going to put the data of millions of people online then this is not good enough. For that, you need defense in depth.

The software architecture may be enhanced by employing several technologies to implement a layered security approach. One of these would be utilizing the access controls built into the database server to specify that the website may write, but it may not read data.

What Defense in Depth Would Look Like

Building an app with security in mind takes a different process than just going with the framework defaults. Security starts with the business case and a process where product owners and developers consider security threats as software features are designed and implemented.

In a system designed with security in mind, the complete compromise of the web facing server would not enable the attacker to obtain unfettered access to the protected data because every component is designed with the principle of least privilege. One way to accomplish this is by architecting the front-end server to submit its requests to a more sensitive server. The system could be architecturally designed in a layered approach where the database permissions only allowed insert or events from the system could be encrypted in a way that the web server has no way to decrypt even if compromised. This could conceptually look something like this:

Some Defense in Depth by Segmentation and Write Only Public Access

The point is that the public web server is incapable, in this conceptual example, from reading any data at all. Rather it can only add new data to the database, such as a dispute from a person regarding his or her credit activity. There are many tools available to implement this form of least privilege ranging from SQL database permissions to public key encryption where the key to decrypt has never been present on the public web servers.

In practice, the business purpose of the application makes these scenarios more complicated because some data has to be read back from the database at the request of a remote Internet user. For example, in a dispute system a public user presumably needs to see the status of his or her dispute or its resolution.

Using an Event Queue with Encrypted Responses

One way to do this is to split the middle layer into a set of microservices and use event queues to communicate. Requests are published to be picked up by the backend. After processing the request, the backend publishes an expiring result back to the frontend. This result includes only the data that is authorized for the frontend use. For added security this response can even be encrypted to a asymmetric session key pair. Though not depicted in this diagram, it is presumed that all communication will be conducted over TLS encrypted connections.

Event Queue with Encrypted Responses

This drastically reduces the target area given an external exploit. A remote code execution on the web server will not be enough to dump the sensitive database.

The amount of security possible has to be dialed back a notch from the ideal of write only. An attacker may be able to obtain sensitive records for another, but will be forced into doing so one record at a time at considerable cost. The added complexity will also increase the chance that the organization can catch the breach through monitoring for anomalous usage.

Conclusion

Software security is really hard and its especially hard in situations where sensitive data on millions of individuals is put at risk. Also security is not, and has never been a feature in the software such that code written today is necessarily secure tomorrow after new attacks are discovered and flaws in the deployment environment come to light. So for example, the mythical most secure software in the world that has no flaws will be hacked if the username and password are permitted to be admin and admin (#4). At the same time the best network security, monitoring, and incident response in the world will be unable to stop a data breach where the web application’s code is long forgotten, un-patched, and was designed such that a single defect exploited is all that’s required for the attacker to gain complete control and to retrieve all protected data. An effective security program will require the involvement of those who develop the web application software and those who deploy it and those who monitor it. These teams must be in continual contact and none of them can be dismissed at any point in the useful life of the software, but rather must be able to respond rapidly it new information about emerging threats and discovered weaknesses in the software infrastructure.

References

Equifax Releases Details on Cybersecurity Incident, Announces Personnel Changes (equifax.com) Friday, September 15, 2017.
OWASP Top Ten Project (owasp.org)
OWASP Application Security Verification Standard Project (owasp.org)
Equifax had ‘admin’ as login and password in Argentina (bbc.com). Wednesday, September 13, 2017.