Since Thursday when Equifax released some of the details of their security breach, it has been visiting my curiosities quite often. Like many things I’ve seen in print lately, the story seems to be only partly accurate because of the nature of the exploited vulnerability cited, Apache Struts CVE-2017-5638:

This particular vulnerability is in the Apache Struts, Jakarta Multipart parser that allows unauthenticated code to be remotely executed on a webserver. According to the Apache project, the specific vulnerability is in the handling of errors in the content-type http header. If there is something in the content-type header that the multipart parser doesn’t understand, instead of terminating in an error, it would try to execute it.

A general architectural best practice for web servers that have an interface to the internet is to have them exist on a special network called a DMZ that is behind locked down firewalls that only let specific traffic on specific ports into that network. These servers are generally locked down, as in default accounts such as root and administrator disabled, obscured or removed, remote shell and auth requests not allowed through the server’s interface that leads to the internet. Then there is another set of firewalls between the DMZ and the network on which the backend application servers reside, and these firewalls only allow the DMZ hosts to send packets through to the backend, and remote display, remote shell, and authentication requests are only allowed to the DMZ from the inner DMZ firewalls. It is even better if locked down Brocade load balancers that proxy web traffic to the front end webservers are placed in front of them within the DMZ. These provide a front-line layer that would need to be hacked before having any hope of getting to anything important; and they do, of course, have an entirely different set of vulnerabilities than the web servers themselves.

In thinking about my example general best-practice architecture for reference, it is difficult for me to understand how the particular vulnerability cited would be the cause of the data breach by itself because the content-type header is involved mostly in telling a client how to process information it receives via http, and a front-end webserver would likely do far more serving out content-type headers, while reading them would occur in the course of conversing with a backend on the other side of the DMZ.

So the very peak of my curiosity about this breach is how the front-end could receive and process a malicious content-type header from the outside without having been directed to it from something on the inside, or without having also had other vulnerabilities that would allow it to be directed to it from the outside if the thing on the outside could get through the brocades.

My guess is that we haven’t been told everything there is to know about the Equifax hack because what we have been told does not logically fit unless there were also other security problems with the front-end servers that allowed the vulnerability to be exploited.

I truly believe that this back of the envelope assessment is far more charitable the firm appears to deserve considering the kinds of data that it stores, data that the majority of its subjects have no business relationship with this firm and have never been provided the opportunity to give consent to the firms storage and use of.