• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• IBM's flagship JEE Application Server¹
• One of the most popular commercial JEE Application Servers ²
• Heavily used in the financial and insurance sectors
• Not cheap
  • Time bombed free trial available from web site¹

• Web servers forward HTTP connections into WAS
• HTTP connection forwarding handled by WAS Web Server Plugin

• Plug-in is between the Internet and WAS
• WAS can access many back end resources
  • A vulnerability in a web application or the web container leaves little protection

• Extension module for web servers
  • Apache
  • IBM HTTP Server (IHS, Apache derivative)
  • IIS
  • ...

• Communicates with WAS via HTTP
• Load balancing
• Fail over
• Not security

• Not all requests forwarded to WAS
• Configuration based on URL mappings in web.xml and ibm-web-ext.xmi
  • Simple file globs
• Matched in sequence
  1. /ctxroot/myservlet
  2. /ctxroot/servlet_with_pathinfo/*
  3. *.jsp
  4. If file serving is enabled: *

• If a match occurs, the connection is forwarded to WAS
• Otherwise the request is handled by web server
  • Used to serve static content from the web server instead of WAS for optimization.
• The plugin's URL handling is frequently misunderstood by admins and developers
• See "Understanding the WebSphere Application Server Web server plug-in"⁴ for more details.

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• OS under Java written in C
  • NUL terminates string
  • Cannot contain NUL
• Java
  • Counted
  • NUL allowed in string
• What happens if you open the filetest.txt\0 in java?
• You gettest.txt⁷

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

• What happens in WAS if we request/ctxroot/test.txt%00.jsp
• It compiles test.txt as a JSP and runs it.
• Similar to what Jouko Pynnönen found in Tomcat⁸

• /ctxroot/path_to_file%00.jsp
• The file must be in the WAR
• We can't read files in META-INF or WEB-INF
• Must compile and run as a JSP
• Not too useful unless "file serving" is disabled in the application

• Basically anything that doesn't include<%
• HTML
• XML
• Most text files
• Some ZIP files
• Most CLASS files
• ...

• What about directories?
• For some reason, accessing directories in this manner gets a directory listing.
  • I'm not sure why...
• /ctxroot/dir/%00.jsp
• In some cases, like the context root, a '.' is needed as well
• /ctxroot/.%00.jsp
• '..' can can even list the EAR directory
• /ctxroot/..%00.jsp
• JSP & NUL just became much more useful

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• Though not intended for security
• It can interfere with insecurity

• %00works great connecting to WAS directly
• Plugin poses an issue
• Written in C
  • Doesn't like NUL
• /ctxroot/test.txt%00.jsp
• Becomes/ctxroot/test.txt
• How do we get NUL past the plugin?

• ASCII/ISO-8859-1/ISO-LATIN-1
  • Single byte
  • 0-255 or -128-127
  • Standard C
• UCS-16/UTF-16
  • Two bytes
  • 0-65,535
  • Java in memory
• UTF-8
  • 1-4 bytes
  • 0-1,114,111
  • Java reading and writing

• Multi byte encoding
• Single byte values can be encoded as multiple bytes
• Explicitly forbidden by the spec ⁹
  • Who follows specs?
• Quite a history of those that don't
  • MS IIS exploits ¹¹
  • Java

• Made known publicly by Simon Ryeo and William A. Rowe, Jr.¹²
• Fixed by Sun in 1.4.2 update 19, 5.0 update 13 and 6 update 11 (bug id 4486841)
• Fixed by IBM 1.4.2 SR13, 5.0 SR9 and 6 SR4
• IBM's fix didn't work
  • IBM fixed NIO but IBM's JVM doesn't use NIO by default
  • Testing security fixes is a good idea...
• Really fixed in 1.4.2 SR 13 FP5, 5 SR11 FP2 and 6 SR8
• Not yet in any WAS Fix Packs though

• The plugin is in C and doesn't understand UTF-8 (overly long or otherwise)
  • Just ASCII/ISO-8859-1/ISO-LATIN-1
• WAS is in Java using a JVM that accepts overly long UTF-8
• Instead of /ctxroot/test.txt%00.jsp
• Use /ctxroot/test.txt%C0%80.jsp
• The plugin is no longer an obstacle

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• Servlet specification says
  • Return 404⁵
• Checked many places in WAS
• They missed one
• File serving allowed /ctxroot/./WEB-INF/web.xml
  • Fixed in PK64302
  • "Potential security exposure with fileServing feature enabled."¹⁵
  • No details so other issues may have been fixed
• Surely they didn't just check file serving...

• Directly: /ctxroot/./WEB-INF/web.xml%00.jsp
• The plugin also normalizes paths
  • /./ becomes /
• Via plugin: /ctxroot/%C0%AE/WEB-INF/web.xml%C0%80.jsp
• Fixed with the %00.jsp issue in PK81387¹³
• "Possible application source file exposure"
• Also works with META-INF

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• The truth, the whole truth and nothing but the truth?
• "Possible application source file exposure" can be arbitrary remote code execution...

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

• We need to get a file into the exploded WAR

• /ctxroot/%C0%AE/WEB-INF/%C0%80.jsp

• What's theattachments directory?

• SOAP with attachments¹⁶
  • SOAP attachments implemented as multi part MIME
• Caches attachments larger than 32KB to disk
• /WEB-INF/attachments by default
• Directory is created if not present at startup
• Guess what WAS's JAX-RPC is based on...
  • Not to be confused with WAS's JAX-WS which is based on Apache Axis 2

• Axis bugs me
• Attachments aren't even read unless referenced by the service
• So we could get an attachment there if a SOAP service handles attachments
  • Not many do.
• Can we put a attachment before the SOAP body and force it to be read?
  • Yup...but...
  • Axis has a bug: attachments before the body are saved to java.io.tmpdir instead.
  • So you can DOS two filesystems instead of just one.

• Allows an href attribute that can reference attachments
• When used with Axis 1, Axis parses the attachments...
  • And caches large ones to disk
• Requires the application to have a web service with at least one parameter that uses SOAP encoding (RPC/encoded)
  • Can't be document/literal or RPC/literal

• It's not my fault!
• Axis 1 provides an interesting ...err... feature
  • It's not present in the WAS's JAX-RPC derivative.
• The client can send a fault to the server as the first request
  • Server responds with an error since the client shouldn't be sending faults
  • After it parses it...
• Faults use SOAP encoding
  • So we can send attachments with them...
• Does not require any web services to be configured
  • Exposure of the Axis 1 servlet is enough.

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• Attachment filenames are random
  1. Get the attachment's directory listing first
  2. Send up your attachment
  3. Get the new directory listing and find your file
• Request your file as a JSP
• Your file is translated to java
• Compiled
• Run

1. Baselines the attachments directory
2. Uploads trojan JSP with a SOAP fault
3. Finds new attachments in the attachments directory
4. Checks each until it finds the trojan JSP
5. JSP copies itself to a non-transient location
   • Attachments are purged after use
6. Proxies stdin and stdout to a arbitrary command over HTTP
7. Removes trojan JSP when done

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• WAS runs on many different platforms
• AIX and Linux tested and vulnerable
• Case insensitive file systems are not vulnerable to %00.jsp
  • An earlier security fix is likely the reason
  • Windows
• Overly long UTF-8 decoding depends on the JVM in use
  • Non-IBM JVM may have been fixed earlier
  • HPUX & Solaris

• WAS 6.0
  • 6.0.2.35
  • Fix Pack 35
• WAS 6.1
  • 6.1.0.23
  • Fix Pack 23
• WAS 7.0
  • 7.0.0.3
  • Fix Pack 3
• Other versions with the IFix for PK81387

• 15 platform variants x 4 maintained versions = 60 different variants
  • I may be off a bit here
  • On the low end
• The time from disclosure to publicly released fix:
  • 2 Weeks
  • I'm impressed!
• When reporting security issues to IBM
  • If possible
  • Always do it as a support request (PMR)

• Checks that the path it thinks it's opening is the same as the path it's really opening.
• Something like

  File jsp;
  
  if(!jsp.getAbsoluteFile().equals(
  	jsp.getCanonicalFile()))
  	throw new HTTP404();
  

• Make sure /WEB-INF/ doesn't appear anywhere in the path.
  • Not as elegant
  • But works

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• First:
  • You're more than a year behind on fixes!
  • I sure hope you're not running IIS as well...
• Disable runtime compilation and reloading of JSPs
  • See info center for disableJspRuntimeCompilation in the application
  • disableJspRuntimeCompilation seems to no longer be supported at the container level.
  • Precompile JSPs at or before deployment time
• Block access to *.jsp before WAS
  • Direct access to JSPs will not be possible
  • Perhaps your JSPs are only used for MVC view though
  • Blocking rules must consider more issues...

• What do the following byte sequences have in common?
  • 80 - C1 BF
  • E0 80 80 - E0 9F BF
  • F0 80 80 80 - F0 8F BF BF
• Invalid byte sequences for UTF-8
• How does the fixed IBM JVM handle them?
  • ""
  • AKA: the empty string
• The unfixed IBM JVM only does this for 80 - FF
• Useful?
  • IDS evasion
  • Bypassing blocking rules
  • If overly long wasn't enough...

• The JSP engine handles more than *.jsp by default:
  • *.jsv
  • *.jsw
• In some cases:
  • *.jspx

• JSP blocking rules must handle
  • UTF-8 overly long decoding
  • UTF-8 invalid code replacement with empty string
  • Multiple JSP extensions
• I would recommend the patch....

• Browsers normalize URLs before sending requests
  • /./ becomes /
• URL encoding usually resolves this
  • Except firefox on windows
  • /%2E/ becomes /

• You need to hit the same server for each request
• Server affinity is handled by the servlet session
  • Eg:JSESSION cookie
• JSPs default to creating a session if one does not exist
  • Getting a baseline on the attachments directory will create a session
  • Keep your cookie

• One text file with
  • A URL to a website
• Sorry...
  • I missed the deadline for the CD

• http://www.darkmist.net/~schallee/defcon18/
• Slides
• Tool to view unicode mappings for your JVM
• Sample application for WAS with both Axis 1 and Web Services for J2EE
• Exploit for Axis 1 faults
• Source to all of the above

• WebSphere Application Server (WAS) Architecture
• JSP & NUL
• Web Server Plugin & NUL
• WEB-INF & META-INF
• Apache Axis 1 & Attachments
• Demo
• Fixes
• Extras
• Conclusions

• Implementation variations at software component boundaries are a fertile ground for bugs.
  • Plugin <=> Java <=> OS
• Native applications are not the only one susceptible to such issues.
  • Java is not immune
• A series of small security issues can sometimes be used in concert to create a much bigger vulnerability.
  • encoding issues + null bytes + axis 1 => remote code execution

Switch to "handout" mode for bibliography.