CVE-2017-5638 - Groundhog's Day

It's one of those weeks. A new, big impact-low effort CVE (CVE-2017-5638). This time it is in the Java Struts apps. Specifically, ones using the Jakarta Multi-Part parser. Again, it is one of those “malformed inputs that gives me powers, in ways no one expected, that no one wants me to have” types of vulnerabilities.

You have to rush to deal with it, as there are already reports of bots spreading by exploiting this CVE. The damage potential here is very real. Put simply, even though the vulnerability is in the File Upload functionality of parts of the struts framework, unauthenticated, remote attackers can execute any OS commands on the targeted system. There’s also a metasploit exploit for it.

Looking at the Struts Security Report, we see the following:

• First vulnerable version affected is Struts 2.3.5. That code was released 5 years ago.
• Even the newer Struts 2.5 series, that was released 10 months ago, had the vulnerability from the get go.
• We know that this CVE was assigned late January, and announced on Apache Struts on March 6th.
• Now, kudos to those involved, we know what the effort required is in finding such a vulnerability, to getting a CVE, and finally a patch. Now the rest of the world has to rush to get the fixes in.

Think about this for a second:

• The vulnerable code was written 5 years ago.
• It made its way into quite a few apps (Struts is still widely used).
• Perhaps people have been exploiting since day 1, perhaps not, we’ll never know.
• It was found and reported to MITRE, the Apache Struts team, and a patch and CVE were efficiently released.
• However, now you have to rebuild, retest, redeploy, and hope that it is not already too late.

This happens all the time (future blog post with stats on this). Vulnerabilities lurk for years, and then the whole world has to rush to patch and deploy until it has to do it again. In fact, I would argue that most of the time you would not know about bugs such as this one lurking in your code base - because they could be small libraries, or as quite often happens, the researcher simply does not want to go through the hassle of getting a CVE assigned.

Sure, some vendors will tell you about their smart dynamic rules that respond to 0-days, but even that’s not good enough; what about the first 5 years, before that vulnerability was public knowledge?

We always believed there was a better way.

That line of code that is vulnerable ran on your servers millions of times, and never once resulted in a system command, but it does when exploited. Our security instrumentation technology picks that anomaly up and alerts you (or blocks the exploits if you choose to). In fact, had you been running IMMUNIO, you would not be exploitable, and would not have to rush to get a new version out. Furthermore, you would not have been exploitable for those years prior to the disclosure of that vulnerability.

Finding all vulnerabilities and then fixing them is hard. Adding security smarts into applications is much easier.