@author Evan Saez
And it has nothing to do with the people that made it. (sort of)
I am so sorry if you work in IT or Software Engineer on Java web applications, because if you do chances are at some point in the past or present the organization you’re working for probably had a public facing application or server that was developed with Apache struts. Which if you haven’t heard by now is having a pretty bad week.
First off a Chinese hacker released a POC for a Remote Code Execution on Apache Struts 2 that potentially allowed a hacker to gain full root access to the machine.
When this started to make rounds on the Internet at places like this Thief.one.
Security researchers started noticing major up ticks of this vulnerability being exploited in the wild which the team over at ixiacom.com outlined very thoroughly.
Struts Exploit analysis
The Talos security team notified the maintainers of Struts who went public with the vulnerability and released a fix. Unfortunately once every script kiddie with motor function realized exploiting this vulnerability was less trivial than pouring cereal this started to happen
Followed by shortly with the news that a metasploit module had been quickly developed
By Saturday everyone in the industry basically looked like this
Lets take a step back from the hysteria for a second and put down our pitch forks. I’ve heard a lot of people start attacking the struts project as a pile of syphilis that needs to be killed with fire but that is not were the blame belongs. Struts was one of the most popular Java web development frameworks when it was first released. Since it came with pre-built features that previously had to be developed in house it was widely adopted and setup a lot of future projects down the road (Spring, Jsf, etc…). However, when you’re the first at something you’re going to be the first to make mistakes and Struts broke the cardinal rule of trusting user input. RCE vulnerabilities are some of the oldest in the book right next to buffer overflows & DDoS attacks but we’ve also had mitigations for years for these problems that should by now be common place(unfortunately this seems to only be the case in the candy land delusion I live in). What is interesting to me is how a trivially easy dated type of exploit brought IT staffs to their heels this week. Well struts is primary used for Java Enterprise Web applications and if you know anything about enterprise applications you probably know that most make tire fires look Eco friendly.
Chances are most developers at large organizations inherited an undocumented mess of an application. The person who built it left the company and the person who replaced that person also left. Now that developer is stuck with a ten year old java web application and an unrealistic deadline to implement new features. Updating or porting to a new code base could mean this critical business application could face serious down time or could break all together. Fast forward five more years you have a burnt out engineering department who is just trying to keep this Frankenstein set of features impersonating software alive just a little bit longer. Yet alone give anyone alone think about security controls. It could take weeks to properly patch or mitigate this issue with a good solution not including the two weeks of 12 hour a day meetings you’ll need to justify implementing security controls. Here’s hoping the senior manager who signs off on this isn’t on vacation until then try not to cry in the server room.