I’m sitting on a plane waiting for my delayed flight to Boston listening to Adam Savage rant about Apple’s lack of ease of use (of which I totally agree). I figured it was the perfect time to finish this blog. Oh yeah, why am I on a plane? I’m heading to Red Hat Summit 2017. I might write about that later. In like a year or so. Yes, I back dated this if you realize the RH Summit is in May, but I’ve been meaning to write this post for over a month.
Recently, the Struts vulnerability hit in March and if you worked for a financial or other large company, and you didn’t have something to scan your source code auditing and inventory and catalog/inventory of applications and their libraries and versions in use, the appropriate response may have been to lose your minds and freak out. After about a minute of that, you should have been scrambling to find which apps have it, test apps for that vulnerability and jump down your less proactive development teams’ throat to get them to patch the version and release.
The vulnerability which has been covered in great technical detail in a wealth of other places allowed you to inject and run any command you wanted on a remote server that hosted an application running vulnerable versions of the Apache Struts 2 library. All one had to do was send a simple http request to a vulnerable and boom, server owned. To make it worse, it’s not immediately apparent what is vulnerable. Even if you think you know what’s vulnerable. A lot of scans for the vulnerable like Qualsys’s didn’t check for blind injection or work on applications that require authentication. So you can pass all Qualsys scans and still be completely vulnerable. To make it worse, vendors like IBM and Oracle were slow to disclose if they were vulnerable or not in WebSphere and WebLogic. Many vulnerable applications could be found online by searching for known extensions used in the Apache Struts framework.
If you need an example of exploitation you can go here: http://charlottehackers.com/rant/CVE-2017-5638.html
Suffice to say, the best known way was to try authenticate into the application and use a tool like Burp Suite with a plugin (you can write your own in Python or another language) that checks for the vulnerability that tries to run the exploit on every page visited or spider the site. The test exploit should both try to output something to the page that proves it’s working but also write something to disk or do some action on the system that can be logged so that it can be detected if a command ran but the output isn’t returned. That doesn’t mean a command wasn’t run and you need to detect a blind injection/exploitation.
I have friends who were in the thick of this, lessons hopefully were learned for developers that they need to start tracking library usage and do builds off one single standard version of a library and track which apps are using it. There are a litany of DevOps practices and solutions for doing this. It’s this or working 70+ hour weeks scrambling to find the holes and patch before you’re exploited if it isn’t actively happening already.
Some basic mitigation can be done at the front end load balancer by filtering what content types could be specified in that field.