Archives for July 2013

Apache Struts 2 Exploit – have you patched?

Apache Struts 2 Exploit – have you patched?

In early July and then in mid July, Apache Struts 2 released information on two new vulnerabilities.  These recent vulnerabilities for Struts 2 appear to have gone under the radar in terms of patching urgency and active exploitation is now happening in the wild. The vulnerabilities appear to have gone unnoticed because they have received little media attention and the vulnerability description perhaps doesn’t do justice to the potential scope of the vulnerability:

Apache Struts 2 before 2.3.14.1 allows remote attackers to execute arbitrary OGNL code

Of course, the vulnerabilities will have been dealt with through organisations’ patching programs, if they were picked up. But have you assessed the potential impact correctly and taken steps to remediate this issue?

So what’s the true potential impact of the vulnerability if it were exploited?

The vulnerability alone may not be hugely significant, but when put into the context of an attack it can have much greater consequences. The vulnerability allows for some post-exploitation techniques to be utilised, such as installing backdoors and JSP post-exploitation tool kits. This allows for more elaborate and complex attacks to occur.

The true impact of the exploitation of this vulnerability when combined with post-exploitation tool kits could be full compromise of a system with the ability for that system to be used for onward compromise of connected hosts.

How easy is it to use?

7 Elements has discovered an exploit kit designed to target Struts 2 vulnerabilities. Whilst the exploit code itself required reasonable skill to construct, the toolkit enables attackers with a low level of skill to use the toolkit to attack Struts 2 vulnerabilities. The Chinese built toolkit essentially allows an attacker to enter their target via copy and paste, press a button and view the results.

Struts2 exploit code

Struts2 exploit code

(It comes with instructions on how to use the tool in a blog post that can be easily translated via online translators. As such, this isn’t just available to Chinese speaking script kiddies!)

 

The exploit code makes use of the following arbitrary code execution vulnerabilities within Struts 2:

– 2010 S2-005: http://struts.apache.org/development/2.x/docs/s2-005.html (CVE-2010-1870)

– 2011 S2-009: http://struts.apache.org/development/2.x/docs/s2-009.html (CVE-2011-3923)

– 2013 S2-013: http://struts.apache.org/development/2.x/docs/s2-013.html (CVE-2013-1966)

– 2013 S2-016: http://struts.apache.org/development/2.x/docs/s2-016.html (CVE-2013-2251)

 

The vulnerabilities exists due to a lack of proper input validation. Input validation occurs where end user information is not validated before being used by a web application. If an attacker can embed malicious commands in these parameters, the system may execute those commands on behalf of the web application, resulting in the execution of remote code. A more detailed explanation on the inner workings of the exploit can be found here:

http://blog.o0o.nu/2012/01/cve-2011-3923-yet-another-struts2.html

The option to choose which of the four Struts 2 vulnerabilities to exploit indicates that all are still useful to an attacker, and show that vulnerabilities from three years ago are still to be found.

What can you do?

Confirm that your current patching process has identified the need to apply this patch and correctly triaged the effort and priority. If you are yet to deploy a patch, then Apache has “Strongly recommended” that Struts 2 users upgrade to Struts 2.3.15.1. Doing so will address the current vulnerabilities.

If historically your organisation has chosen to not patch and deploy other mitigation techniques such as filtering, revisit these controls to ensure that they are still effective and provide the desired protection from the current Apache Struts 2 Exploit.

Root Cause Analysis

Security Testing Root Cause Analysis:  A New Way of Reporting

At 7 Elements we have introduced an additional way of reporting on the findings from our security tests, Root Cause Analysis.  Whilst root cause analysis is not a new concept, it has not to date been readily applied to security testing output.  We feel it is time for a change.

Current Practice

At present it is standard practice across the industry to report on the findings from security tests individually.  This is of course necessary so that the extent of each vulnerability and the risk it poses can be understood and appropriate remediation applied. However, this only enables organisations to view one vulnerability at a time and thus results in organisations tackling vulnerabilities on a case by case basis.

What is Security Testing Root Cause Analysis?

The causes of vulnerabilities can often be attributed to a single technical cause, i.e. the root cause.  Frequently, vulnerabilities share the same root cause. 7 Elements has developed a new technique that enables us to identify the common technical root causes of vulnerabilities for both Application and Infrastructure findings.  In addition to reporting on individual vulnerabilities, 7 Elements also reports on the number of vulnerabilities attributed to common technical root causes, with individual narrative against each root cause.

RCA

Example of RCA

Why should we use Root Cause Analysis?

The identification of root causes of vulnerabilities enables organisations to take a more strategic view of their vulnerability management and information security practices.  It allows organisations to not only understand where they may have gaps but also why.  This enables organisations to take remediation action to tackle a root cause and thus remediating multiple vulnerabilities in a strategic approach.Through our root cause analysis, organisations frequently find that the majority of their vulnerabilities have only a couple of root causes.  As a result, by tackling one root cause an organisation is able to tackle multiple vulnerabilities with only one remediation action.

Prevention is better than cure though.  By tackling root causes, organisations are able to take preventative action to stop vulnerabilities from arising in the same way in the future and more importantly potentially remediate issues that have yet been identified.

If you would like to know more about how we approach testing and the additional value that we deliver, then please get in touch with our team.