How We Audited a High-Traffic C Enterprise Stack on OVH and Mitigated XML External Entity (XXE) injection in old SOAP integrations

Initial Triage: Identifying the Attack Surface

Our engagement began with a critical security audit of a high-traffic enterprise stack hosted on OVH. The primary concern was a potential vulnerability in legacy SOAP integrations, a common vector for XML External Entity (XXE) injection. The stack comprised several microservices, a central API gateway, and a complex data processing pipeline, all interacting via SOAP and RESTful APIs. The initial phase focused on pinpointing the exact SOAP endpoints and the underlying XML parsers responsible for handling external entity declarations.

The first step was to enumerate all SOAP endpoints. This involved analyzing the API gateway configuration, service discovery mechanisms, and direct inspection of deployed service codebases. We utilized tools like curl and Postman to probe endpoints, looking for WSDL (Web Services Description Language) files, which often reveal the structure and expected input formats for SOAP requests.

Deep Dive: XML Parsers and XXE Vulnerabilities

XXE vulnerabilities arise when an XML parser processes untrusted XML input that contains references to external entities. These entities can be used to access sensitive files on the server, perform Server-Side Request Forgery (SSRF) attacks, or even trigger denial-of-service conditions. In our case, the primary risk was the potential for attackers to read sensitive configuration files or internal network resources.

We identified that several older PHP services were using the built-in SimpleXML and DOMDocument extensions for parsing SOAP requests. While convenient, these parsers, by default, are susceptible to XXE if not configured securely. The critical vulnerability lies in the ability of these parsers to resolve external DTDs (Document Type Definitions) and entities defined within them.

Exploitation Proof-of-Concept: Reading Local Files

To demonstrate the severity of the XXE vulnerability, we crafted a proof-of-concept (PoC) payload. The goal was to read a common sensitive file, such as /etc/passwd, from the server hosting the vulnerable SOAP service. This requires defining an external entity in the XML payload that points to the local file using the file:// URI scheme.

Crafting the Malicious SOAP Request (PHP Example)

Consider a hypothetical vulnerable PHP SOAP service endpoint. An attacker could send a request like this:

POST /legacy/service.php HTTP/1.1
Host: vulnerable.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/ProcessOrder"

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:proc="http://example.com/">
   <soapenv:Header/>
   <soapenv:Body>
      <proc:ProcessOrder>
         <proc:orderId>&xxe;</proc:orderId>
         <proc:quantity>1</proc:quantity>
      </proc:ProcessOrder>
   </soapenv:Body>
</soapenv:Envelope>

In this payload:

• The <!DOCTYPE foo [...]> declaration defines an external entity named xxe.
• The SYSTEM "file:///etc/passwd" directive instructs the XML parser to fetch the content of /etc/passwd and make it available under the &xxe; entity.
• The &xxe; entity is then referenced within the SOAP request body (e.g., in the orderId element).

If the server’s XML parser is vulnerable and not configured to disable external entity resolution, the content of /etc/passwd would be returned in the SOAP response, potentially revealing user accounts and system information.

Mitigation Strategy: Securing XML Parsers

The most effective way to mitigate XXE vulnerabilities is to configure XML parsers to disable external entity resolution and DTD processing entirely. This is a standard security best practice for handling untrusted XML input.

PHP: Securing DOMDocument

For PHP’s DOMDocument, the following options should be set before loading XML:

<?php
$dom = new DOMDocument();
// Disable external entity loading
$dom->resolveExternals = false;
// Disable loading of external DTDs
$dom->substituteEntities = false; // This is crucial for preventing XXE

// Load XML from a string or file
if (!$dom->loadXML($xmlString)) {
    // Handle XML parsing errors
    error_log("XML parsing error: " . $dom->errors);
    // Return an error response
    return false;
}

// Proceed with processing the XML if loading was successful
// ...
?>

It’s important to note that $dom->resolveExternals = false; alone is not sufficient. The $dom->substituteEntities = false; setting is critical for preventing the substitution of external entities, which is the core of the XXE attack.

PHP: Securing SimpleXML

SimpleXML is generally considered safer by default in recent PHP versions, as it doesn’t load external entities by default. However, if you are using older PHP versions or specific configurations, it’s prudent to be aware of potential issues. The primary way to interact with SimpleXML in a way that might expose XXE is through its integration with libxml, which can be influenced by global settings or specific function calls. The recommended approach is to use DOMDocument with the secure settings described above, or to ensure that any libxml_disable_entity_loader(true); calls are active before parsing with SimpleXML if you must use it.

<?php
// Ensure entity loader is disabled globally for libxml
if (function_exists('libxml_disable_entity_loader')) {
    libxml_disable_entity_loader(true);
}

try {
    $xml = simplexml_load_string($xmlString);
    if ($xml === false) {
        // Handle parsing errors
        error_log("SimpleXML parsing error.");
        return false;
    }
    // Process $xml object
    // ...
} catch (Exception $e) {
    error_log("Exception during SimpleXML parsing: " . $e->getMessage());
    return false;
}
?>

The libxml_disable_entity_loader(true); function is a global setting that affects all libxml-based parsers, including SimpleXML and DOMDocument. It’s a robust defense-in-depth measure.

Implementation and Verification

The mitigation involved a phased rollout across the affected services. For each service, we:

• Identified the specific XML parsing code.
• Modified the code to include the secure parser configurations (e.g., setting resolveExternals and substituteEntities to false for DOMDocument, or ensuring libxml_disable_entity_loader(true); was active).
• Deployed the updated services to a staging environment.
• Re-ran the XXE PoC payloads against the staging environment to confirm that the vulnerability was successfully patched.
• Monitored logs for any unexpected parsing errors or denial-of-service conditions that might indicate an incomplete fix or a new issue.
• Gradually rolled out the changes to production, with continuous monitoring.

Post-Mitigation Monitoring and Auditing

Post-mitigation, continuous monitoring is crucial. We implemented enhanced logging for all XML parsing operations, specifically capturing any instances where external entities might have been attempted or resolved (though with the secure configuration, this should be prevented). Alerts were configured for malformed XML requests or unusual error patterns originating from SOAP endpoints.

Regular security audits, including automated vulnerability scanning and periodic manual penetration testing, were scheduled to ensure that no new XXE vulnerabilities were introduced and that the existing ones remained mitigated. This proactive approach is essential for maintaining the security posture of a high-traffic enterprise system.