Blog

Fixing vulnerabilities: the Struts example

When I started working in IT as a Java Developer in 2004, I was confronted with one of the first MVC frameworks called Struts. It was not always as easy because it could take you up to 4 hours to add a field to web form. Soon other technologies like JSF and later Spring appeared and Struts lost lots of popularity. Of course, there are still lots of applications that run on Struts and new versions are still released.

Struts has suffered some vulnerabilities in the past with peaks in 2012-2013 and 2016. But at the start of this month, a new one appeared with the highest CVE rating possible (10)!

You see on the graph that Code execution and XSS are the most common vulnerabilities found in the Struts framework.

The "Jakarta Multipart parser in Apache Struts" vulnerability is again a remode Code execution problem with complete takeover and no authentication required. Versions starting 2.3.5.x of the Struts framework are vulnerable and a MetaSploit module is available!

This is being exploited in the wild and we have seen alerts on SIEM systems of getting such requests each 15 minutes to all of their public IP's.

So how many applications still use the Struts framework?

Well that isn't clear. Struts was very popular around 2004 - 2008 and lots of those applications are still turning in production. If you look at the statistics of the used frameworks for 2016, you notice that Struts isn't the favorite choice for development (only 4%).

If you look below at the exploitation attempts, the peak came when the vulnerability was registered in the CVE database on March 10th. The Apache Struts Foundations released a fix on the 7th of March, but you see that the attempts are on the rise again (see below).

How to protect against it?

There are several mitigations:

  • Vulnerability management systems have detected that you have a vulnerable system
  • Your IPS/WAF blocks the malicious requests
  • Your application needs updating

Vulnerability management systems, like Qualys, scan your network/applications on a regular base, maybe even multiple times a day. Those systems have a resource database and from the moment a vulnerability is registered into a public database or by custom research, your system will be scanned for it. This way you get fast notifications if your system is a possible target. They can sometimes also block the malicious requests.

Your IPS / WAF systems like Incapsula, block the requests because in this case the header seems fishy. The IPS / WAF systems also use a resource database as the vulnerability management systems. Now the requests are blocked and your application is safe, for now...

Your application uses the vulnerable Struts version and needs to be updated. How can you know if it is vulnerable?

  1. The Struts website did an announcement on the security issue at the beginning of March (https://struts.apache.org/announce.html#a20170307-2), where you subscribed to the Struts announcement mailing list. Did you subscribe?
  2. Do you check your open-source libraries for vulnerabilities? See previous post "You may have gotten lucky this time...."
  3. Did your development team get a notification from operations or the security team about the IPS/WAF blocked requests or vulnerability management system alerts?

Struts has released patches for the vulnerability so you need to apply the patch and release a new version in production, even if your IPS blocks the malicious requests. Because when in time other vulnerabilities are found that apply to your system, all those unfixed issues will lead to a major break of your security. Security breaches are mostly multiple vulnerabilities that are combined to hack your system.

Conclusion

If we look at the complete picture, we see that your operational phase and your strategic phase of the Software development (SDLC) need to work together.

  1. Vulnerability management systems need to alert if a system becomes vulnerable asap
  2. Weird or large numbers of malicious requests should be reported and studied. This can be done by the operational team, but the security team should have an overview of which technology applications are running
  3. Applications should check the used open-source libraries for vulnerabilities and need to be subscribed to the announcement/security mailing list

References



Written by Koen Vanderloock & Cedric Viaene

Add comment