Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: java

ShmooCon 2012: Java backdoors and Cross Framework Abuse

3 Comments Posted by on January 28, 2012

Java backdoors and Cross Framework Abuse

– Nicholas (aricon) Berthaume

Adding backdoor(s)

Java has a number of different archive formats. This talk covers the J2SE / J2EE type archives. The goal here is to show how simple it is to add potentially malicious software to three of the most common format.

JAR – Java ARchive

Typical run in Java Virtual Machines on client system

ZIP files with manifests, metadata and Java byte-code

Can be digitally signed

WARs – Web application Archives

Typical run on Java application servers such as Tomcat

Run as the remote server user.

Can be digitally signed

EAR – Enterprise application ARchive

Very similar to WAR, but with extended enterprise features.

All three file formats when allowed to run can create sockets, interact with the filesystem outside of the respective virtual machines and execute commands there. This makes then perfectly suited for exploitation.

Run typical with full permissions of the user and display very few warnings. At most you receive a “run or don’t run” style prompt. Signing, even with a self-signed certificate, reduces these warnings.

AV engines rarely do effective heuristic analysis on known malicious code when it’s inserted into a Java Archive format.

JAR backdoor payloads

File droppers that execute arbitrary code.

WAR backdoor payloads

Completely malicious additions to existing WAR files content, JavaScript and so on.

All of the same features of JAR files, but run on the remote server.

EAR backdoor payloads

Similar abuse to WAR, but also allow for greater reuse of classes and scaling across multiple servers and additional security roles.

Adding content to WAR files is often as simple as editing the manifest and adding the required backdoor code. EAR is however a little more complex due to the additional features. However it’s possible to set the security context used to run your backdoor code.

JAR is more complex however. The process involves extracting a JAR to use as the host, add files into the correct paths and edit the MANIFEST as required.

Enter RAWJAR

Tool designed to automate this functionality. Written in Python.

When combined with the JDK, this tools will give you the ability to add arbitrary Java to existing files.

Currently tested with EAR, WAR, JAR files using the JAVA meterpreter as the standard backdoor. However other can be used with minor modifications.

Due to the way code is run, closing the browser after infection leaves the code active on the system.

Cross-framework Injection

In additions to pure Java there are a number of extension APIs that are either included or installable.

Java Native Access (JNA)

Open-source utility for calling native and managed libraries/assemblies on nearly every platform that the JVM runs on.

.NET from the JNA

By using assembled code in .NET (using jython) it was possible to implement simple calls outside the framework without needing to recompile the classes due to the reasonable support found in the JNA.

From here the goal is to inject processes, hopefully using standard injection techniques to inject into .NET or inject a DLL into memory.

Links:

  • Talk abstract –> HERE
  • RAWJAR project –> HERE
Conference, Security , ,

[Defcon] Exploiting WebSphere Application Server’s JSP Engine

2 Comments Posted by on July 31, 2010

Exploiting WebSphere Application Server’s JSP Engine – Ed Schaller

Note: Apologies for the notes…. Ed talks REALLY fast!

WebSphere Application Server

IBM’s JEE Application Server

One of the top 3

Not cheap –> free trial available

Common Network Architecture

Client Browser –> Web Servers –> WebSphere AS

Web server plugin –> Extension module for common HTTP servers (IIS, Apache, etc…)

  • Communicates with WAS via HTTP
  • Load Balancing
  • Fail over
  • Not Security!

Plugin URL Handling

Not all requests get forwarded back to the WAS.

  • Based on URL mappings in web.xml and ibm-web-ext.xmi (simple file globs)

If a match occurs the request is forwarded, if not its handled by the local HTTP Server

JSP & NUL

Strings

  • OS under Java is written in C
    • NUL terminates strings
    • Cannot contain NUL
  • Java
    • Counted
    • NUL Allowed

What about the JSP engine inside WAS. How does it handle NULs

  1. Locate and read file
  2. Translate .jsp to .java
  3. Compile
  4. Run as servlet

This means you can reading (some) specific files through the JSP engine. As long as it’s a valid JSP

What’s a valid JSP?

  • Anything starting with <%
  • HTML
  • XML
  • Most Text files
  • ….

What about directories… well you can read them to?

  • /root/dir/%00.jsp
  • /root/dir/.%00.jsp
    • Sometimes you need “..”

Web Server Plugin & NUL

Although not intended for security, it can get in the way of insecurity!

%00 works great on WAS, but getting it through the C compiled plugin isn’t

The next challenge is how to get %00 past the plugin

Character Encodings

UTF-8 is how Java reads strings natively

  • Multi-byte character encoding
  • Single byte values can be encoded as multiple bytes
  • Explicitly forbidden in the spec
    • Nobody follows the spec!

A fix for this issue was implemented… but the fix didn’t work!

It is however fixed in the latest JVM release (no direct patch from IBM as yet)

Encoding to bypass the plugin and get a NUL to the WAS –> %C0%80.jsp instead of %00.jsp

Web-INF & META-INF

Servlet specification says Return 404

Checked many places in WAS… but the missed one!

Fixed by IBM… but badly.

To bypass…

  • /ctxroot/%C0%AE/WEB-INF/web.xml

This also works for META-INF

The Whole Truth

JSP Strikes back

  1. Locate and read file
  2. Translate .JSP to .JAVA
  3. Compile
  4. Run

Doesn’t this mean we can get remote code-exec?

SOAP With attachments lets us read a file that we what to compile and execute

Anything over 32KB gets cached to a location readable….

Not many SOAP services however, handle attachments!

This makes it a lot less useable

SOAP Encoding

This allows you to reference attachments through the href in a SOAP message

When used with AXIS 1, it parses the attachment and caches the larger ones to the disk

AXIS 1 provides an interesting feature, A client can send a fault to the server as the first request… which is parsed

Faults use SOAP encoding and can therefore can be used to send an attachment

Putting it all together

Attachment filenames are random.

To bypass this .:

  1. Get the directory listing first
  2. Uploads the JSP
  3. Get another directory listing to find the filename
  4. …

This process however is pretty noisy and can cause a large amount of logs.

An example exploit code that performs this will be made available

Affected platforms

  • WAS runs on a lot of platforms
  • AIX and Linux tested and vulnerable
  • Case insensitive file systems are not vulnerable to %00.jsp –> e.g Windows
  • …

Fixes

Fixes are out for 6.x, and 7.x

Took IBM 2 weeks to fix this flaw (16 different variants)

Providing security reports as a PMR works!

Fix from IBM is very elegant

  • Double checks the file being opened to make sure it’s really the end file being opened
  • WEB-INF doesn’t appear in the patch –> Not so elegant

Workarounds

  • Disable runtime compilation and reloading of JSPs
    • disableJspRuntimeCompilation
  • Block access to .jsp before WAS
    • Not always possible
    • JSP Extensions such as jsv, jsw, etc….

A Note on Browsers

  • Browsers may normalize the characters
  • Could cause issues with exploitation

Links:

  • Talk Information –> LINK
  • Slides –> LINK
Conference, Security , , , , , ,