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
- OS under Java is written in C
- NUL terminates strings
- Cannot contain NUL
What about the JSP engine inside WAS. How does it handle NULs
- Locate and read file
- Translate .jsp to .java
- 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 <%
- Most Text files
What about directories… well you can read them to?
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
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
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.
This also works for META-INF
The Whole Truth
JSP Strikes back
- Locate and read file
- Translate .JSP to .JAVA
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
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 .:
- Get the directory listing first
- Uploads the JSP
- 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
- 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 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
- Disable runtime compilation and reloading of JSPs
- 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