• Introduction
• Supported version
• Command line
• Identification strings
• Special features
• Java properties disclosure
• Java environment disclosure
• Java code execution
  • Basic Java calls
  • Executing arbitrary classes
• OS command execution
  • Command without output
  • Reading stdout
• File creation
• JDBC connectivity
  • Simple connection
  • Credentials brute-forcing
• Anti XEE

Introduction

Xalan-J is a Java based XSLT engine by the Apache Project.

Supported version

1.0

Command line

$> java org.apache.xalan.xslt.Process -in foo.xml -xsl foo.xsl

Note : xml-apis.jar, xercesImpl.jar and xalan*.jar must be in the $CLASSPATH

Identification strings

Special features

• Java properties disclosure
• Java environment disclosure
• Java code execution
• OS command execution
• File creation
• JDBC connectivity

Java properties disclosure

The xsl:system-property() standard function can be called with non standard arguments, mapped to Java properties. In this example, the name of the Java properties is stored in a separate XML file (properties.xml). The XSLT code will, for each property, display its name and its value.

Java environment disclosure

The checkEnvironment() extension function (documented here) will display some information about the execution context (including available packages, paths, versions, ...).

Java code execution

Basic Java calls

The attached code will display the current date using a newly created "java.util.Date" object. This should be enough to demonstrate Java code execution.

Executing arbitrary classes

 It is afaik not possible to get a pure Java reverse-shell, as we can't create threads :-( 

Warning

TODO : javapayload => loading arbitrary byte code (aka classes) via reflection
$> java javapayload.builder.Builder Template XalanJ.xsl bind-jsh-4444.xsl BindTCP 127.0.0.1 4444 - - JSh
List supported payloads !
Check supported versions of Xalan !

OS command execution

Once Java code execution is possible, it is trivial to execute arbitrary OS commands using the java.lang.Runtime class.

Command without output

The attached PoC will not read the output of the executed command (because loops are hard in XSLT). But this is not a problem if a reverse-shell have already been started, isn't it ;-)

Note : as arrays are not a native type in XSLT, we create one in Java via split() before passing it as an argument to exec(String[] cmdarray).

Reading stdout

As the output have an unknown number of lines, we must use a loop construct like "while" ... which is not available in XSLT. This limitation is due to the functional programming paradigm but can be circumvented using templates and recursion. This way, we can also update some variables, but the syntax is awful and error prone.

It's far more efficient to 1) write loops using non-standard elements like <loop:while> and <loop:update> 2) convert them in stylesheets using only templates and recursion. This conversion can be done with a tool like the XSLT Loop Compiler (which is itself in XSLT).

The following PoC will fetch some commands from a XML file, execute them (with bash or cmd.exe depending on the detected OS), read the standard output and display it. The file with a "lxsl" extension uses the non-standard <loop:*> elements and is far more readable than the "xsl" one.

It is of course possible to include commands for multiples OS in one file and to execute only the relevant ones.

File creation

The "write" extension element allows to create files on the engine side. The content written to the file must be valid UTF-8 (so plain ASCII works too). Existing files can be overwritten. 

JDBC connectivity

It is possible to use XSLT to connect to any database having a corresponding installed JDBC driver.

Simple connection

The xalanj-jdbc-query.xsl PoC simply connects to a local MySQL database using some hard-coded credentials, executes a query and displays the result.

Credentials brute-forcing

The xalanj-jdbc-bruteforce.xsl file will read some tuples (JDBC driver, database URL, username, passsword) from a XML file (xalanj-jdbc-bruteforce.xml) and try to login with each one, effectively brute-forcing credentials from the engine side (usually on the backend ;-).

Here's the output when launched from the CLI :

$> java org.apache.xalan.xslt.Process -in xalanj-jdbc-bruteforce.xml -xsl xalanj-jdbc-bruteforce.xsl 2> /dev/null
Username : [root] / Password : [] :
Username : [root] / Password : [uberpasswd] :
Username : [root] / Password : [cnam] : OK !!
Username : [pma] / Password : [pma] : 

Anti XEE

DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
builderFactory.setExpandEntityReferences(false);            <<<<==[Here]==<<<<
DocumentBuilder builder = builderFactory.newDocumentBuilder();
DOMSource xmlSource = new DOMSource(builder.parse(new ByteArrayInputStream(myXmlString.getBytes())));

By default (cf. Xalan-j documentation), this value is set to True.