Nächster Compass BeerTalk am Donnerstag 01.03.2012

Am 1. März 2012 ist es wieder so weit, wir führen den ersten BeerTalk im Jahr 2012 zum Thema Advanced Web Security durch.

Das weit verbreitete Struts Framework war im letzten halben Jahr immer wieder auf Remote Code Execution verwundbar, was Angreifern erlaubte, ganze Systeme zu kompromittieren. Philipp Oesch, Leiter Software Entwicklung bei der Compass Security, hat diese Schwachstellen untersucht und wird am BeerTalk vom 1. März zwei Live Hacking Demos durchführen. Dabei wird ein Applikations- und Datenbank-Server komplett übernommen.

Interessant zu wissen, dieser Angriff funktioniert noch immer bei vielen Anwendungen – Konkret, bei allen Struts 2 Anwendungen die seit dem 22.01.2012 noch nicht gepatcht wurden!

Inhalt des BeerTalks:

  • Aufzeigen von Bedrohungen in komplexen & heterogenen Infrastrukturen
  • Welche neuen Security Herausforderungen stellen sich für die Entwickler?
  • Welche Risiken werden oft vergessen?
  • Neue HTTP Headers
  • Welche Risiken bringen OpenSource und Frameworks (Struts, JSF, Spring, ..) mit sich?
  • Welche Massnahmen können getroffen werden um das Risiko einzudämmen?

1. Live Hacking Demonstration:

  • Übernahme eines Applikations-Servers durch eine Remote Code Execution Vulnerability
  • Der Angriff funktioniert bei allen Struts 2 Anwendungen die seit  dem 22.1.2012 nicht gepatched wurden (Struts 2.0.0 – Struts 2.3.1.1)!

2. Live Hacking Demonstration:

  • Übernahme eines Datenbank-Servers durch eine kombinierte Web-Attacke (XXE & MySQL UDF), inklusive Reverse Shell
  • Die Demo zeigt Step-by-Step wie ein Angreifer vorgeht um eine Reverse Shell zu erhalten

Kommen Sie vorbei, geniessen Sie den Vortrag und anschliessend ein Steak oder eine Wurst vom Grill mit einem kühlen Bier!

Wir freuen uns auf Ihre Anmeldung bis zum 29. Februar.

New Security Enhancing HTTP Headers

In the past few years, several new HTTP Headers have been proposed to increase the security of web applications. This is being done by providing additional instructions and information about the served application to the browser. Those can mitigate and avert various common web attacks, even if the underlying application contains vulnerabilities, therefore adding another layer of defense.
As time passes, more and more people do use a browser which support those measures. Compass Security has long been testing for these security enhancing features, and is actively advocate their implementation. Therefore we release an presentation which we used to educate employees and customers alike about this topic.

 

The presentation “New HTTP headers – and living in a POST-XSS world” aims to give quick overview, and answers to all of the questions below:
  • What are the new HTTP headers you can use to protect your web application?
  • Why should I force mode=block for the X-XSS-Protection header?
  • How tightly can I configure a X-Content-Security-Policy?
  • What is the purpose of the Strict-Transport-Security header?
  • How does Stefano Di Paola’s Firefox SeecurityHeaders extension look like?
  • Let’s dream of a world where browsers are smart enough to prevent execution of arbitrary JavaScript code via XSS – what options would be left?

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

Retrospective about cache snooping

As it is known since at least 2006, a website is able to identify the domains a user previously visited, with some simple CSS hacks. This had great privacy implications, and browsers took steps to eliminate this problem. But in December 2011, lcamtuf presented a new proof of concept based on cache timings, which basically does the same thing. This new technique uses JavaScript and the caching behavior of previously loaded resources to identify visited domains.

This vulnerability is not something a penetration test will identify, as it is purely a client side problem. Nevertheless it is a interesting topic as it exposes fundamental flaws in browser technology concerning privacy and which can’t be patched easily. It is similar to side-channel attacks in crypto systems, and the fix inherently reduces performance.

The attached presentation “CSS -visited – or now Browser Cache Timing” gives an overview of the history around this issue and how the proof of concept of 2006, respectively December 2011 work.