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

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

[Defcon] Exploiting WebSphere Application Server’s JSP Engine

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

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
Advertisement

2 responses to “[Defcon] Exploiting WebSphere Application Server’s JSP Engine

  1. Pingback: [Defcon] Exploiting WebSphere Application Server's JSP Engine … – jsp - dowiedz się więcej!

  2. Pingback: [Defcon] Exploiting WebSphere Application Server's JSP Engine …

%d bloggers like this: