Last week (9/7/2017), Equifax announced that on July 29 they discovered that an exploited web application vulnerability was being used to access a trove of consumer information for the previous 2 ½ months, until discovery. Various news outlets, such as the New York Post are starting to report that the web application vulnerability that was exploited is the recent Apache Struts Remote Code Execution Vulnerability, that has been designated as CVE-2017-9805.
In the NY Post Article, an analyst at RW Baird & Co named Jeffery Meuler is cited as the source of this information, based on a phone call that he had with an Equifax representative in preparation for a research bulletin that Baird Equity Research published the day of the Equifax announcement. This bulletin states that:
Our understanding is that data entered (and retained) through consumer portals/interactions (consumers inquiring about their credit reports, disputes, etc.) and data around it was breached via the Apache Struts flaw.
What is the Apache Struts Flaw?
Apache Struts (https://struts.apache.org/) is a framework for creating Java web Applications and REST application programming interfaces (API). An API is how various systems on the Internet communicate with each other. The data exchanged via an API is typically serialized into either JSON or XML.
When you think about the type of data that a company might collect about you, such as your current and previous addresses, employers, and credit card numbers, it is understandable that the data structure that gets flattened out into XML would be very complex. The security problem arises when the recipient system tries to deserialize the data stream so that it can process the data.
The word “deserialize” and its many technical descriptions are very intimidating, but it essentially means that the data stream needs to be parsed so that meaning can be assigned to the various data elements in the stream. The flexibility demanded of deserialization libraries are their undoing, because the stream can contain binary data as well as text and numbers. In the case of this vulnerability, a malicious manipulation of the XML results in the attacker being able to execute remote code on the victim server. The Sophos Naked Security blog has a very readable explanation of this vulnerability and serialization.
The Exploit is in the Wild
On September 5, at 15:30 BST (7:30 AM Pacific Time), the security researcher that publicized the Struts vulnerability did so on his company blog in concert with the release of the Struts update announcement regarding S2-052. One day later, a functional exploit was uploaded to the Exploit Database and has a Metasploit module.
This attack vector is referred to by OWASP as the “deserialization of untrusted data,” which explains that “[d]ata which is untrusted cannot be trusted to be well formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code, when deserialized.”
Roughly eighteen months ago, there was an uptick of security research on the topic, including a whitepaper published by an HPE security researcher named Alvaro Munoz, named “the perils of Java deserialization.” In the whitepaper, Munoz specifically called out XStream (the target of this Struts exploit) speculating how its protections could be bypassed.
Mitigating this Type of Vulnerability
The SANS Security Awareness Blog has published a helpful post for security awareness officers to communicate regarding the Equifax hack, reminding us to stick to the facts and that it is not the victim’s fault. I agree. However, this is also a tremendous opportunity to raise developer and executive awareness regarding application security best practices. Toward that end, here are some recommendations:
1. Do not deserialize untrusted data
But what does this really mean? In this sense, “trust” has a specific context, which essentially means that if you have not had complete control of the data since its original creation, you must assume that it is unsafe. It is often beneficial to think about how data crosses trust boundaries or put more simply, how does data get into your application?
2. Authenticate before deserialization
Don’t trust strangers. Authenticate the source of the data before deciding to trust it. This will prevent many of the automated types of attacks, such as the Metasploit exploit described above.
3. Limit the data types that can be deserialized
Do not deserialize binary data if you don’t need to serialize it. In his paper, Munoz noted that XStream supports blacklisting and whitelisting the classes that can be deserialized, but pointed out that many implementations do not use this feature.
4. Avoiding writing your own parsers
In general, parsing untrusted data is risky, and deserialization is a subset of parsing. Libraries such as Struts and Springs may have multiple published vulnerabilities, but they benefit from considerable public scrutiny. It is safer to use these libraries than to reinvent the wheel and make the same security mistakes in novel ways.
5. Scan your code
While these tools have their limitations, static and dynamic application scanners catch the vast majority of the known vulnerabilities and are updated rapidly after these types of vulnerabilities become public (and sometimes before, when the vulnerability is responsibly disclosed). Strive for full code coverage.
6. Inventory and authorize your code libraries
Right now, more than one CISO is losing sleep as to whether or not his or her organization is using Struts. This is compounded by the fact that much of the software that organizations use is not written by internal developers. Many scanning tools will flag vulnerabilities in the dependent libraries, but only if that code is scanned. Companies that require that all code is stored in approved code repositories and have a security review and authorization process for code libraries have an advantage when responding to critical security vulnerability notices.
7. Educate management
Vulnerability management is expensive. This includes commercial scanners, penetration testing, security management processes and auditing. However, breaches are more expensive. When bad things happen, like the Equifax breach, it opens a window of opportunity to inform management how and why the security infrastructure that they are investing in is designed to help manage security risks.
8. Learn from Others
This breach will generate lots of discussion in the months and years to come. I also predict that CVE-2017-9805 will plague many for quite some time. I expect that there will be considerably more research into deserialization vulnerabilities. In fact a second, brand new Struts vulnerability was announced yesterday (CVE-2017-12611, S2-53). To cope, our best response is to continue to learn, share, and adapt. An excellent example of this is Paypal’s January 2016 posting called, Lessons Learned from the Java Deserialization Bug.
The postings and views on this site are my own and do not necessarily reflect the positions, strategies, or opinions of any current or previous employer.