Security Advisories for SAP BusinessObjects Explorer and neuroML

Compass Security employees identify and report on a regular basis security vulnerabilities as part of their daily assessments (or just out curiosity).

Stefan Horlacher identified and reported back in June 2013 several flaws in SAP BusinessObjects Explorer. We’re happy to publish today the details as the flaws have been patched and a reasonable grace period given for their deployment:

Note that both the port scan as well as the XML External Entity (XXE) attack can be conducted anonymously without prior insider knowledge.

Philipp Promeuschel on his part identified multiple vulnerabilities in neuroML version 1.8.1 in May this year. The related advisory covers a wide range of vulnerabilities allowing a full compromise of the application:

Disabling Viewstate’s MAC: why you deserve having now a broken ASP.NET web application

Lots of things happened since my first (and unique) blog post about ASP.NET Viewstate and its related weakness. This blog post will not yet disclose all the details or contain tools to exploit applications, but give some ideas why it’s really mandatory to both correct your web applications and install the ASP.NET patch.

Back in September 2012 I reported an issue in the ASP.NET framework which could be used to potentially execute remote code in a typical SharePoint installation. Microsoft patched its flagship products SharePoint and Outlook Web Access. They also released guidance in security advisory 2905247 which contained an optional patch to download, removing the ASP.NET framework’s ability to alter setting “EnableViewStateMac”. It was also made clear that Microsoft will forbid this setting in upcoming ASP.NET versions. ASP.NET version 4.5.2, released in May 2014, was the first version of ASP.NET to have this setting disabled. Microsoft released as part of this month’s Patch Tuesday a patch to remove support for setting EnableViewStateMac for all ASP.NET versions.

While this patch may break ASP.NET applications, remember that without this patch you’re vulnerable to a much bigger threat. Fixing the web application is in the very vast majority of the cases easy from a technical perspective (e.g. set up dedicated machine keys within a given web farm). But as pointed out in the ASP.NET article, the management and distribution of these machine keys must follow a strict process to avoid being disclosed to unwanted parties. Think of machine keys being an essential element of your application. If these keys have ever been disclosed, you have to change them immediately. Ensure software purchased or downloaded from the Internet does not contain pre-defined keys in the application’s web.config.

If you want to know more but missed my Area41 talk about this flaw, come over to the AppSec Forum Western Switzerland on November 4th to 6th in Yverdon-les-Bains . I will be presenting an updated version of my “Why .NET needs MACs and other serial(-ization) tales” talk about the underlying flaws, their history and how to exploit them.

Advisories regarding Leed and Secure Entry Server (SES)

Today I’m happy to release the following security advisories:

I would take the opportunity to thanks Valentin CARRUESCO aka Idleman for the timely patches he implemented within Leed.

Of further interest is the vulnerability which affected the SES as it was due to a common mistake made when validating URLs. Let’s illustrate the issue with another occurrence of the same flaw, which affected LinkedIn and was reported back in November 2012.

Back then, attempts to visit a page reserved to LinkedIn members only triggered a redirect to the following login page:

https://www.linkedin.com/uas/login?session_redirect=%2F[original_page]

Variable session_redirect was used to keep track of the initially desired page. Once successfully logged in, the web application would redirect us straight to this page using the following AJAX response:

{"status":"ok","redirectUrl":"/[original_page]"}

Attempts to misuse this mechanism and inject a full URL in parameter session_redirect (e.g. session_redirect=https:%2F%2Fwww.csnc.ch) would fail, presumably because the developers ensured that the first character of value session_redirect had to be a slash (or its URL-encoded hex value %2F).

But what about partial URL //www.csnc.ch? Based on the aforementioned logic, such an URL would be considered as safe by the code, as it starts with a slash. But modern browsers don’t interpret a redirection to //www.csnc.ch as being http(s)://[victim]//www.csnc.ch, but in fact as a redirection to http(s)://www.csnc.ch. This behaviour is RFC conform and commonly used over the Internet to embed resources regardless of the URL scheme (http if the initial page was called over http, https if called over https).

Was it possible to abuse LinkedIn and the SES with such a trick? Yes, here’s an illustration of it:

Attempt to login on LinkedIn using forged URL (note the double slash – %2F%2F) https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

2013-12-04 12_52_00-Clipboard

Pressing button “Sign In” would submit the entered credentials. An extract of the AJAX response is shown below:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
[removed various Set-Cookies directives]
X-LI-UUID: B[base64_stuff]nsg==
[removed various Set-Cookies directives]
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
Vary: Accept-Encoding
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Date: Sat, 10 Nov 2012 11:45:45 GMT
Age: 1
Connection: keep-alive
Content-Length: 52

{"status":"ok","redirectUrl":"//test/phishing.html"}

The browser would then interpret this redirection as being meant for [scheme]://test/phishing.html and perform the according request as seen below:

GET /phishing.html HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

2013-12-17 11_58_10-Clipboard

The issue was reported to LinkedIn in November 2012 and fixed without further acknowledgement.

As a conclusion, do not assume that a partial URL value starting with a slash will always represent a path on your website. It may as well be a valid URL representation pointing to another domain. Furthermore, always perform redirections using a full qualified domain name and don’t just rely on a partial URL representation.

Compass SSL/TLS recommendations

Mozilla created an extensive page [7] concerning the best current choice of SSL/TLS cipher suites, primarily for web servers. Compass Security agrees broadly with the article, but recommends some additional restrictions in order to provide the most resistance against active and passive attacks versus TLS secured connections:

  • Use 3DES cipher instead of RC4
  • Disable SSLv3 support

Compass Security recommends against using RC4, and favors 3DES for a transitional period. 3DES only provides 112 bit keys (and may therefore be more prone to brute force attacks on the key), but is otherwise regarded as not (yet) broken. RC4, on the other hand, is considered not secure anymore:

  • A “nearly practical” attack exists, as the first bytes of the stream cipher are biased (not perfectly random)[4]
  • Microsoft recommends to disable it, and warns developers to not use it anymore [1]
  • The NSA is suspected to be able to decrypt it in real-time [2][3]
  • RC4 was primarily used to thwart BEAST and Lucky13 attacks. But BEAST is fixed on current browsers. Exploiting Lucky13 is currently not practically feasible [6]

For additional security, it is possible to remove SSLv3 support altogether, as it contains several weaknesses:

  • Weaker key derivation process than TLS
  • Cannot be validated under FIPS 140-2
  • There have been various attacks on SSLv3 implementations
  • Vulnerable to certain protocol downgrade attacks

TLSv1.0, which was released in 1999, contains several additional security features in comparison to SSLv3. For example, it uses both SHA-1 and MD5 at the same time, making it less vulnerable if one of these hash functions becomes insecure.

All browsers, except IE6 on Windows XP (in its default configuration) support at least TLSv1.0. The default IE8 browser on an up-to-date Windows XP, happily connects to TLS-only web servers. Nevertheless, other software may not be compatible with such an restricted configuration yet.

Furthermore it is recommended to turn off TLS compression. This will fix the CRIME attack on TLS connections, even if vulnerable OpenSSL implementation on the server is being used, while an obsolete browsers which do not have this issue fixed is connected. If the server uses current OpenSSL library, and/or the client has the CRIME fix implemented, this attack is not feasiable anyway. Turning off TLS compression will not mitigate the BREACH attack, as it uses the compression feature of HTTP, not TLS. See [12] for further information about this issue.

This concludes the discussion about most of the currently known SSL/TLS attacks, and their mitigation.

Apache Configuration

The following chapter provides an Apache configuration example, which incorporates the discussion above. It is based on  https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses

The implemented cipher prioritization logic is as follows:

  1. Most secure TLS 1.2 ciphers first: AES-GCM
  2. AES with PFS: ECDHE (Elliptic Curves)
  3. AES with PFS: DHE (Traditional RSA)
  4. AES128
  5. AES256
  6. 3DES

The cipher prioritization list:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK

Virtual host SSL configuration:

<VirtualHost *:443>
    ...
    SSLProtocol             All -SSLv2 –SSLv3
    SSLCipherSuite          <recommended ciphersuite from above>
    SSLHonorCipherOrder     on
    SSLCompression          off # default off, except in 2.4.3 and 2.2.24 to 2.2.25
    SSLInsecureRenegotiation off # default
    ...
</VirtualHost>

This TLS- and AES/3DES-only configuration was successfully tested with current versions of IE8, Chrome and Firefox on Windows XP.

Windows IIS

Example configuration settings for Windows. This should act as a basic configuration skeleton. Before deployment, the configuration needs to be actively tested in an production environment. The cipher list has been extracted on a Windows 7, but is identical to that of a Windows 2012 Server.

Disabling SSLv2 and SSLv3:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server] 
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server] 
"DisabledByDefault"=dword:00000001

Cipher list:

  1. ECDHE ECDSA AES-GCM SHA2
  2. ECDHE ECDSA AES-CBC SHA2
  3. ECDHE RSA AES-CBC SHA2
  4. ECDHE RSA AES-CBC SHA
  5. ECDHE ECDSA AES-CBC SHA
  6. DHE DSS AES-CBC SHA2
  7. DHE DSS AES-CBC SHA
  8. DHE DSS 3DES SHA
  9. RSA AES SHA2
  10. RSA AES
  11. RSA 3DES
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA

Configure Schannel according to the recommendations above and these pages:

Further Recommendations

This renewal in favor of more secure SSL ciphers can be a good opportunity to kick-off further clarifications and investigations about SSL related topics in your company, e.g.:

  • Is all your web infrastructure (proxies, WAFs, web servers, …) ready to support TLSv1.1 and TLSv1.2?
  • Are the clients you manage use an adequate configuration for setting up SSL communication (e.g. Prioritizing Schannel Cipher Suites for Windows clients)
  • Have your SSL certificates a 2048 bit private key?
  • Have your CA SSL certificates a 4096 bit private key?
  • Does your internal PKI enforce best practices and is moving to SHA2 and ECC? [10][11]
  • Are you using the most current version of the webserver?
  • Are you using the most current version of OpenSSL?

References

  1. Microsoft recommends disabling RC4
  2. Article about suspicious that NSA is able to decrypt RC4
  3. Article about suspicious that NSA is able to decrypt RC4, german
  4. Bruce Schneier about attack on RC4 from spring 2013
  5. Discussion “RC4 is kind of broken in TLS”
  6. Qualys Discussion about retiring RC4
  7. Mozilla Article about SSL ciphers
  8. Qualys SSL Test
  9. Web Browser Support Matrix
  10. MS SHA1 deprecation policy
  11. Windows Root Certificate Program – Technical Requirements version 2.0
  12. Nginx SSL Module
  13. Qualys – Defending against the BREACH Attack

Thanks to Alexandre Herzog for research, review and discussions concerning this matter.

Bypass File Download Restrictions in Content Filters

Companies battle with users who download files from the Internet at work and then execute them. Unsuspicious files are often infected with malware. A common procedure to decrease the amount of infections is to block common bad file types (for example .exe, .scr or .zip), before the files can enter the internal network. The preconditions are that users are only able to communicate with the Internet through a HTTP proxy and the internal email server. A whitelist on the email- and web-content filter, which only allows .docx to go through, can greatly decrease the amount of malware infections. Attackers will have to use exploits (e.g. in the browser, a plugin or office exploits) to perform code execution on the clients.

Sadly, in the case of web content filters, they can all be circumvented. They usually work by looking for HTTP responses whose content types are not safe, for example “application/octet-stream”. Here an example of a typical file download:

cf-0

With HTML5, it is possible to create the file to download on-the-fly with JavaScript (by storing the binary as base64 encoded string). As no download request is generated when the download link is clicked, the content-filter can’t deny the download request. It is also possible to misuse Flash for the same purpose.

Example:

cf-1The initial request to retrive the page goes to a plain html file:

cf-2

The response is plain HTML (content type text/html) with javascript:

cf-3

The JavaScript code will extract the base64 encoded binary as a blob and provide a normal download dialog for the user.

There is no simple solution for this problem. Content filters may be able to catch certain pages which use this functionality, but this would break other pages like Google Docs.
The issue was identified at a discussion at the Compass Offsite Meeting 2013 in Berlin. The Proof-of-Concept code (as seen above) has been implemented first by Cyrill Bannwart and works for current versions of Chrome, Firefox and IE10.

Microsoft Security Bulletin MS13-067 – Critical

As part of today’s monthly patch day, Microsoft fixed an issue I reported in September 2012 around (ASP).NET and SharePoint.

The vulnerability opens a new type of attack surface on ASP.NET if a given precondition regarding the Viewstate field is met. The impact is at least a breach of data integrity on the server side resulting typically in a denial of service. Leveraging the flaw to achieve remote code execution cannot be excluded though. The default configuration settings of ASP.NET are safe and do not allow an exploitation of the flaw.

But before uncovering more technical details about the issue, we want to ensure everyone had enough time to patch their servers adequately. For this reason, we will withhold further details during a grace period agreed with Microsoft’s Security Response Center to ensure all involved parties have enough time to react. In the meantime, we encourage you to patch the relevant servers and ensure your web applications at least enforce the default protection of the Viewstate field.

Risks of DOM Based XSS due to “unsafe” JavaScript functions

Introduction

Several native JavaScript functions or properties like .eval() and .innerHTML as well as several jQuery functions like .html() and .append() are considered as “unsafe”, but why? The reason is that they allow DOM manipulation using strings containing HTML code (e.g.”<b>This text is bold</b>“), which can lead to DOM Based Cross-Site Scripting vulnerabilities. To be more specific: The usage of such functions is not a problem as long as no user input is directly embedded in an “unsafe” way. jQuery can help us to safely manipulate the DOM without executing XSS in user defined inputs. But do not by mistake assume jQuery is safe per se, it only provides us some helper function to manipulate the DOM more safely.

The subsequent sections show the difference between safe and unsafe usage of JavaScript and jQuery functions in the following scenarios:

Unsafe DOM manipulation using eval():

var txtField = "field1";
var txtUserInput = "'test@csnc.ch';alert(1);";
eval(
   "document.forms[0]." + txtField + ".value =" + txtUserInput
);

The last double quote causes the user input to be treated as JavaScript. This results in the following JavaScript code being executed by eval():

document.forms[0].field1.value = 'test@csnc.ch';alert(1);

Therefore the user input is executed:


Safe DOM manipulation using eval():

var txtField = "field1";
var txtUserInput = "'test@csnc.ch';alert(1);";
eval(
   "document.forms[0]." + txtField + ".value = txtUserInput"
);

The double quote at the end causes the user input NOT to be treated as JavaScript. This results in the following JavaScript code being executed by eval():

document.forms[0].field1.value = txtUserInput

Or in other words:

document.forms[0].field1.value = "'test@csnc.ch';alert(1);"

This results in the following HTML code:

<input type='text' id='field1' name='field1'
       value="'test@csnc.ch';alert(1);" />

Therefore the user input is not executed:

However, this snippet shows again how small the difference is between safe and unsafe usage of eval():

"document.forms[0]." + txtField + ".value =" + txtUserInput
"document.forms[0]." + txtField + ".value = txtUserInput"

Therefore it is recommended to completely ban this function from your JavaScript code.

Unsafe DOM manipulation using jQuery html():

var txtAlertMsg = "This is bold: ";
var txtUserInput = "test<script>alert(1)<\/script>";
$("#message").html(
   txtAlertMsg +"<b>" + txtUserInput + "</b>"
);

Or in other words:

$("#message").html(
   "This is bold: <b>test<script>alert(1)<\/script></b>"
);

This results in the following HTML code:

<div id='message'><b>test<script>alert(1)</script></b></div>

Therefore the user input is executed:


Safe DOM manipulation using jQuery html() and text():

var txtAlertMsg = "This is bold: ";
var txtUserInput = "test<script>alert(1)<\/script>";
$("#message").html(
   txtAlertMsg +"<b><div id='userInput'></div></b>"
);
$("#userInput").text(
   txtUserInput
);

Or in other words:

$("#userInput").text(
   "test<script>alert(1)<\/script>"
);

This results in the following HTML code:

<div id='message'>This is bold: <b>
   <div id='userInput'>test&lt;script&gt;alert(1)&lt;/script&gt;</div>
</b></div>

Therefore the user input is not executed:

Conclusion

  • eval() is evil
  • jQuery does not solve all your problems
  • When using JavaScript or jQuery functions to manipulate your DOM you always need to know if your content may contain user input. If yes you must only use functions which encode HTML / JavaScript strings like jQuery text().

Resources

Samba Exploit Development Presentation

As penetration testers, our main goal is to identify as many vulnerabilities as possible. This allows our customers to more objectifly assess their security level and to shut as many doors as possible which an intruder could use to break in. This process needs to be based in respect of cost-benefit, depending on risk probabily and impact. Exploitation is only a secondary objective, mostly used to facility the first one. Also – the fix for most software vulnerabilities is the same: Always update all your software everywhere as soon as possible.

In my spare time, I like to get low-level and study the art of exploitation. From time to time I try to shed some light on the dark art of exploitation, by giving a little presentation to my work colleagues about my findings.

In my presentation I talk about CVE-2012-1182 (“root” credential remote code execution in Samba). First I show a small analysis of the vulnerability itself. After that I outline the inner workings of the Samba heap allocator. Based on this knowledge, I describe how to develop a working exploit which circumvents typical anti-exploitation securiy features like NX, ASLR and PIE.

 I close the presentation with a short analysis of the randomness of libc function addresses of common linux distributions. To summarize, ASLR/PIE implementations in 32 bit Linux distributions do not provide adequate randomness against brute forcing of ret2libc function addresses, as they provide less than 12 bit of entropy. OpenBSD-32bit provides 16 bit, and 64 bit linux distributions more than 20 bit of entropy, which considerably slows brute-force exploiting attempts.

Here are the results of my short evaluation. I generated around 1 million processes, each printing the address of system(), collected them in a file and did some analysis. In the following table, the second row shows the number of unique addresses collected. The third row shows how many times the most common address is being used, in respect to the least common.

It is not really a problem to brute force around <2000 addresses in a suitable timeframe, so the 32 Bit Linux distributions receive a FAIL rating. OpenBSD does a much better job on randomizing LIBC function addresses (as expected). 64 Bit operating systems are the hardest to brute force.

More details in my presentation: sambaexploit_v1.0.pdf

nevisProxy Advisory Release

Today, Compass Security published a public advisory regarding nevisProxy, a product from AdNovum, used by several Swiss financial institutions.

nevisProxy is a secure reverse proxy with an integrated web application firewall (WAF). It acts as a central upstream entry point for web traffic to integrated online applications. nevisProxy controls user access and protects sensitive data, applications, services, and systems from internal and external threats. nevisProxy is a component of AdNovum’s security framework Nevis (source).

Instead of focusing this post on the issue itself, I would like to take the opportunity to show how well the vendor AdNovum handled the vulnerability we identified. In less than a few hours after the disclosure, our initial mail was acknowledged and their team was already working towards a resolution. On the following morning, the vendor informed all its customers by releasing a security bulletin and a blog entry (AdNovum Security Bulletin 2012-03 – only accessible via their customer portal), containing a mitigation proposal. A concrete date for a patch release (March 14, 2012) was communicated at this occasion as well. Only two working days later, AdNovum has sent an email reminder about this issue, ensuring all customers were aware of the issue and could take adequate steps to safeguard themselves.

We often hear and read rants about vendors giving bad examples on how to (not) handle security issues. Hopefully this example of AdNovum will show that some vendors know how to manage security issues quickly and professionally, in the best interest of their customers – and their own reputation.

Our advisory can be found on http://www.csnc.ch/misc/files/advisories/CSNC-2012-004_Nevis_XSS_within_302_Redirections_publicVersion.txt

BeanShell puts Java Application Servers at Risk

Developers increasingly integrate BeanShell support into web applications to provide end users and administrators with a simple extension framework. But be warned! BeanShell support without appropriate access control will put the hosting web server at severe risk. An attacker could easily execute operating system calls and without appropriate system hardening such an attack will immediately result in full system compromise.

The BeanShell[1] is an environment that provides execution of Java code snippets in the web application context. The shell supports full Java language syntax and some loose structures for convenience. Be aware, to run code within an Java Virtual Machine (JVM) means to run code on the server. The following screenshot shows BeanShell enabled web application that just run a hello world command.

However, to be able to do some meaningful attacks one must first overcome and understand some limitations of the Java Runtime.getRuntime().exec() method. Simply putting a whole command into the exec method will not run properly since Java will internally tokenize the String and redirect IO streams. The first argument will be taken as executable. All remaining tokens will be passed as parameters to the executable. Thus, the below statement will not work as intended because the “-c” parameter awaits a single argument.

Runtime.getRuntime().exec("/bin/sh -c /bin/echo pwned > /tmp/poc"};

Following that, command injection in Java is a difficult thing to do since the attacker mostly just gains control over the parameters. However, in BeanShell we are pretty free to choose from the whole arsenal of Java API classes and methods. Finally, a correct call would look like:

String[] cmd = {"/bin/sh", "-c", "/bin/echo pwned > /tmp/poc"};
Runtime.getRuntime().exec(cmd);

That way, Java will pass “/bin/echo pwned > /tmp/poc” correctly. Unfortunately, there is another limitation on the IO streams. Thus, to read and process the output of a command the InputStream classes will be needed. The following snippet is a working example with the Unix list directory (ls) command.

import java.io.*;
try {
Process ls_proc = Runtime.getRuntime().exec("/bin/ls -lah");
DataInputStream ls_in = new DataInputStream(ls_proc.getInputStream());
String ls_str;
while ((ls_str = ls_in.readLine()) != null)
print(ls_str + " ");
} catch (IOException e) {
}

So, you might be asking yourself how this ex-course on the Runtime class’s exec method is related to BeanShell support in web applications?

I have published an advisory[3] on insufficient access control of an integrated BeanShell in an Enterprise Java (J2EE) based document management system software (OpenKM). An attacker could prepare en evil e-mail or website that runs a malicious command on the server if the OpenKM administrator clicks on the link or visits the prepared website.

For example, an attacker would simply embed the below JavaScript exploit code into a web page to cause writing a proof of concept file into the /tmp folder.

img = new Image();
img.src="http://example.com/OpenKM/admin/scripting.jsp?script=String%5B%5D+cmd+%3D+%7B%22%2Fbin%2Fsh%22%2C+%22-c%22%2C+%22%2Fbin%2Fecho+pwned+%3E+%2Ftmp%2Fpoc%22%7D%3B%0D%0ARuntime.getRuntime%28%29.exec%28cmd%29%3B"

Related vulnerabilities are often seen in administrative interfaces of web apps. The attack scheme is also known as Cross-site Request Forgery or XSRF[4]. There are several ways to approach the issue. Either ensure proper access controls[5] or lock down the JVM using Java security policies and the Security Manager[6]. In the end, system hardening may help limiting collateral damage in case of successful attacks.

References
[1] http://www.beanshell.org/
[2] http://www.ensta-paristech.fr/~diam/java/online/io/javazine.html
[3] http://www.csnc.ch/misc/files/advisories/COMPASS-2012-002_openkm_xsrf_os_command_execution.txt
[4] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
[5] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
[6] http://docs.oracle.com/javase/7/docs/api/java/lang/RuntimePermission.html