Apache Struts Hacked, leaving Equifax out to dry
There was a security flaw in the Apache Struts open-source framework that allowed hackers to take advantage of Apache Struts CVE-2017-5638. This security flaw was known since March 2017, and most have taken the proper steps to secure their Apache Struts framework, Yet in September of 2017, we are now learning that Equifax, a large company which collects and aggregates information on over 800 million individual consumers and 88 million businesses worldwide, has been compromised by this security flaw. Not only are we now learning about this security breach, but to find out it happened months ago and nothing was said; sort of makes you wonder how secure any of your information is.
First, let's talk a bit about Apache Struts, since that appears to be the "snake in the grass" if you will. We should start by figuring out exactly what Apache Struts is, and why it caused the issue. According to Apache:
Apache Struts is a free, open-source, MVC framework for creating elegant, modern Java web applications. It favors convention over configuration, is extensible using a plugin architecture, and ships with plugins to support REST, AJAX and JSON.
A framework is similar to building blocks, in that the code provided already has a lot of preset functions which you can use when calling repetitive tasks. Many frameworks exist for programming in general, and exist for the same reason of providing a simple code base which programmers can start with and jump off from. All of the popular programming languages have their own framework, such as Symphony, Laravel, CakePHP, Zend Framework, Spring MVC, Grails, Qt, etc. (yes most of those are PHP frameworks, but others exist for essentially every programming language out there).
Common Vulnerabilities and Exposures (CVE)
What is a CVE, and how can I better understand exactly what happened here? The National Institute of Standards and Technology, a branch of the US Department of Commerce, has a National Vulnerability Database (NVD) which describes in great detail security vulnerabilities in primarily open-source software, and allows for those that use the software to update in a timely manner. The particular CVE identifier for Apache Struts was issued on March 10, 2017, and the information about the CVE is a bit rattling.
First off, the description sums it up wonderfully:
The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 22.214.171.124 mishandles file upload, which allows remote attackers to execute arbitrary commands via a #cmd= string in a crafted Content-Type HTTP header, as exploited in the wild in March 2017
So we immediately know that the exploit hit in March of 2017, and we know what the exploit is. As with most CVE descriptions, they will tell you what the problem is, and how to resolve it. Typically, the resolution is a patch or an update, but it is usually a trivial update to fix the problem. So why did Equifax not apply this update? There's a piece to this that is a tad bit more scary than above:
Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
What this means is the exploit allows an unauthorized user (read: hacker, exploiter, etc) to gain access to information which they do not explicitly have permission to access, as well as modify that information. You also see the piece about "Allows disruption of service", which could mean anything from a simple disruption of services, all the way to a denial of service where the service stops working completely. So what happened to Equifax and why were they exploited and not others?
The reality is, there is a good chance other major companies were exploited, possibly seriously, and you are not aware of it yet. See, what happens when these CVE identifiers go out is the exploit which was previously unknown becomes instantly known, searchable, and exploitable. Until the CVE has been issued, only those who have already compromised systems know the exploit exists. Long story short, it's critical to update software which is running enterprise critical applications to keep from exploits such as this, which are highly documented. Because this CVE has been known for a while, as well as methods of accomplishing this exploit, every day that goes by this exploit becomes easier for hackers to take advantage of. More knowledge of the exploit, as well as a general lack of knowledge for the public on security issues, leads to giant security blunders such as the one Equifax left us with.
So what really happened?
Honestly, nobody will every really know what exactly happened here. Obviously Equifax would like to keep their chatter to a minimum as they smooth out the potential data breach issues they have to deal with now. From all the information out there, Equifax has identified that Apache Struts was the security issue. Further, Apache has issued an official response to the Equifax Breach. Through all of this, it does appear that nobody really knows exactly what happened, or they are trying to keep it hush hush until they know for sure and can fix it. From an official statement from Apache:
We are sorry to hear news that Equifax suffered from a security breach and information disclosure incident that was potentially carried out by exploiting a vulnerability in the Apache Struts Web Framework. At this point in time it is not clear which Struts vulnerability would have been utilized, if any. In an online article published on Quartz.com , the assumption was made that the breach could be related to CVE-2017-9805, which was publicly announced on 2017-09-04  along with new Struts Framework software releases to patch this and other vulnerabilities . However, the security breach was already detected in July , which means that the attackers either used an earlier announced vulnerability on an unpatched Equifax server or exploited a vulnerability not known at this point in time --a so-called Zero-Day-Exploit. If the breach was caused by exploiting CVE-2017-9805, it would have been a Zero-Day-Exploit by that time. The article also states that the CVE-2017-9805 vulnerability exists for nine years now.
This message leads us down a confusing road, in that they are not actually identifying the CVE which Equifax claims caused the issue. Instead, Apache references CVE-2017-9805 which was an exploit announced on September 4, 2017; potentially, this exploit was a zero-day-exploit instead of a known exploit from months ago. So was this issue something Equifax knew about for months, or was this an issue that has remained dormant for 9 years? Let us assume for a moment that it was a zero-day-exploit, and that the VCE-2017-9805 issue was in fact the issue that caused the exploit and data breach at Equifax. That exploit, while only issued a CVE on September 4, 2017, was an issue for nine years. This makes you wonder why, if Apache knew about this issue for nine years, the issue wasn't addressed. Well, Apache has an answer for that too!
Regarding the assertion that especially CVE-2017-9805 is a nine year old security flaw, one has to understand that there is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years. If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier. But this was actually not the case here --we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. What we saw here is common software engineering business --people write code for achieving a desired function, but may not be aware of undesired side-effects. Once this awareness is reached, we as well as hopefully all other library and framework maintainers put high efforts into removing the side-effects as soon as possible. It's probably fair to say that we met this goal pretty well in case of CVE-2017-9805.
With zero-day-exploits and known CVE issues, one could honestly sit back and wonder how one is to keep up with all of these issues. For starters, there are several points of information which will provide you with relevant information about security issues with the software you are using. For example:
Sophos covered the Apache Struts serialization vulnerability, what the problem is, and how to address it. ZDNet even covered it, stating that as many as 65% of the Fortune 500 companies are potentially affected by the vulnerability. Threatpost covered the patch being released. Did we mention that even major security companies such as Symantec know about the issue as well?
The troubling thought
While security vulnerabilities will be exploited all the time, what is a bit more scary about this is that Apache Struts is the backbone primarily for large enterprises dealing with financial information, as well as government agencies and large IT companies. Or in other words, it's used by big enterprise to achieve their end goals. Since this is a widely used framework used by big enterprises, one would think they would be a bit more concerned about privacy and security of data in general. Exploits in open-source software are published, not to make it easier to exploit the issues, but instead to make it quick to fix. Using that logic, quick fixes will make sure you are not subject to a vulnerability in the system you are using.
Some best practices for security would include:
- Make sure you are on the mailing list for security updates on any major software you use
- Make sure you apply any updates and patches (after reading what it's for) when prudent and needed
- Make sure you are monitoring your network traffic for unusual behavior
- Make sure your anti-virus / anti-exploit systems are updated at all times
We get it, it's not easy to keep your finger on the pulse of every single issue out there. BUT, these mailing lists for security issues exist for a reason, and it should be criminal negligence to ignore these security issues; especially when they can impact millions of citizens and their personal data. There is zero reason this exploit should have happened; instead it should have been issued (as it was) and patched by the people at Equifax using the software months ago. So for anyone pointing a finger at open-source, or in particular Apache, you have the wrong fingers pointed; security is the responsibility of the company using the software and features of that software.