This article is based on the Command Injection in XML Signatures and Encryption whitepaper authored by Bradley W. Hill from Information Security Partners.
XSLT is a simple language designed to facilitate cross platform content generation by selecting and merging datasets presented in an XML document. The vulnerability described in the whitepaper still exists in today’s XSLT processing engines, which are widely used in web service implementations. In this article, we will look into reproducing this attack on two of the common XSLT processing engines: Microsft’s MSXML and Xalan (Java’s XML processing library). In addition to an overview of reproducing the attack, this article also features video demonstrations of the exploit that we feature in our Training courses. In both these scenarios we are using the latest versions of the frameworks’ XSLT processing engine as of September 16, 2009.
MSXML implemented in a .NET Application:
MSXML, Microsoft’s XSLT processor, provides a scripting engine to allow for dynamic content generation. The tag, amongst other things, allows developers to define custom functions that can then be called from XSLT code. The engine also provides functions within blocks complete access to .NET classes and methods as long as they fully qualified (e.g. System.Console.WriteLine). This extensibility raises the possibility of remote command execution from the code within the blocks. For instance, in our demonstration video we add a call to System.Diagnostics.Process.Start() method, which enables the attacker to spawn a command prompt.
Xalan implemented in a Java Application:
Xalan, on the other hand provides versions of standard Java classes such as Java.lang.Runtime and Java.lang.Object that can be included with the XSLT signature. These classes can then be used in tags to invoke member methods. In our demonstration video we will be using Java.lang.Runtime.exec() method to spawn a new process that launches Windows Notepad.