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

Initial Assessment: Uncovering the Attack Surface

Our engagement began with a deep dive into a legacy Perl enterprise stack hosted on DigitalOcean. The primary concern was a potential vulnerability in older SOAP integrations, a common vector for XML External Entity (XXE) injection. The stack, while functional, hadn’t undergone a comprehensive security audit in years, leaving it susceptible to known and emerging threats. The initial phase involved mapping out all external-facing SOAP endpoints, identifying the specific Perl modules responsible for XML parsing, and understanding the data flow for incoming requests.

The core of the problem often lies in how XML parsers are configured. By default, many older XML parsers, including those found in common Perl modules like XML::LibXML or XML::Parser, are configured to process external entities. This allows an attacker to craft malicious XML payloads that can reference external resources, leading to:

• Server-Side Request Forgery (SSRF): Forcing the server to make requests to internal or external systems.
• Information Disclosure: Reading sensitive files from the server’s filesystem.
• Denial of Service (DoS): Triggering recursive entity expansion (billion laughs attack).

Identifying Vulnerable XML Parsers in Perl

We started by examining the codebase for imports of common XML parsing libraries. The most prevalent ones in older Perl applications are:

• XML::LibXML
• XML::Parser
• XML::DOM

The critical step is to check how these modules are instantiated and configured. For XML::LibXML, the default parser context can be influenced by specific options. A vulnerable instantiation might look something like this:

Example of a Potentially Vulnerable XML Parsing Snippet

Consider this typical pattern for parsing an incoming SOAP request:

XML::LibXML – Unsafe Parsing

use XML::LibXML;

my $parser = XML::LibXML->new();
my $xml_string = <<'XML';
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<request>
  <data>&xxe;</data>
</request>
XML

my $dom = $parser->parse_string($xml_string);
# Further processing of $dom...

In this snippet, the XML::LibXML->new() call, without specific options to disable external entity loading, is inherently risky. The DOCTYPE declaration with the &xxe; entity would attempt to read /etc/passwd if the parser is configured to resolve external entities.

Mitigation Strategy: Disabling External Entity Resolution

The most effective mitigation for XXE is to disable the resolution of external entities at the parser level. For XML::LibXML, this is achieved by passing specific options during parser instantiation.

Securing XML::LibXML Parsing

use XML::LibXML;

# Create a parser object with security options
my $parser = XML::LibXML->new(
    no_network => 1,       # Disable network access for DTDs and entities
    no_ent => 1,           # Disable entity substitution
    recover => 2,          # Enable error recovery, but still safe
);

my $xml_string = <<'XML';
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<request>
  <data>&xxe;</data>
</request>
XML

# Attempting to parse the malicious XML
eval {
    my $dom = $parser->parse_string($xml_string);
    # If execution reaches here, it means the parser is configured to allow entities.
    # This should ideally not happen with the above options.
    print "WARNING: Malicious XML parsed successfully! This is unexpected.\n";
};
if ($@) {
    # This is the expected path for malicious XML with entity resolution disabled.
    # The error message will indicate that entities are not allowed.
    print "Successfully blocked XXE attempt: $@\n";
}

The key options here are no_network => 1 and no_ent => 1. no_network prevents the parser from fetching external DTDs or entities over the network, and no_ent explicitly disables entity substitution altogether. This effectively neutralizes most XXE attacks, including those that attempt to read local files or perform SSRF.

Securing XML::Parser

For applications using XML::Parser, the approach is similar. You need to configure the parser to disallow external entities. This is typically done by passing a hash of options to the constructor.

use XML::Parser;

my $parser = XML::Parser->new(
    ErrorContext => 2,
    NoNetwork => 1, # Disable network access
    NoEnt => 1,     # Disable entity resolution
);

my $xml_string = <<'XML';
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<request>
  <data>&xxe;</data>
</request>
XML

# The parser will throw an error when it encounters the DOCTYPE or entity.
eval {
    $parser->parse_string($xml_string);
};
if ($@) {
    print "Successfully blocked XXE attempt: $@\n";
} else {
    print "WARNING: Malicious XML parsed successfully! This is unexpected.\n";
}

The NoNetwork and NoEnt options serve the same purpose as in XML::LibXML, preventing the parser from resolving external entities and making network requests.

Implementation and Verification on DigitalOcean

The remediation involved a phased rollout across the DigitalOcean droplet fleet. We identified the specific services and applications that exposed SOAP endpoints and applied the secure parsing configurations. This was done by:

• Code Review and Patching: Pinpointing all instances of XML parsing and updating them with the secure configurations. This often required modifying core libraries or common utility modules used across multiple applications.
• Configuration Management: Utilizing Ansible playbooks to automate the deployment of code changes and ensure consistency across all servers.
• Testing: Developing a suite of test cases, including known XXE payloads, to verify that the mitigations were effective. These tests were run against staging environments before production deployment.

Automated Testing for XXE Vulnerabilities

To ensure ongoing protection, we integrated automated checks into our CI/CD pipeline. This involved creating scripts that would:

Example Python Script for XXE Payload Testing

import requests
import sys

def test_xxe_vulnerability(url):
    """
    Tests a given URL for XXE vulnerability using a file inclusion payload.
    """
    xxe_payload = """
    
     ]>
    
        &xxe;
    
    """
    headers = {'Content-Type': 'text/xml'}
    try:
        response = requests.post(url, data=xxe_payload, headers=headers, timeout=10)
        if "root:x:0:0" in response.text or "bin:x:1:1" in response.text:
            print(f"[+] Potential XXE vulnerability detected at {url}. Found sensitive data.")
            return True
        elif response.status_code == 500 and "entity" in response.text.lower():
            print(f"[*] XXE payload blocked at {url} with a 500 error (expected behavior if protected).")
            return False
        else:
            print(f"[-] No clear XXE vulnerability detected at {url}. Response status: {response.status_code}")
            return False
    except requests.exceptions.RequestException as e:
        print(f"[!] Error testing {url}: {e}")
        return False

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python test_xxe.py ")
        sys.exit(1)

    target_url = sys.argv[1]
    print(f"Testing {target_url} for XXE...")
    test_xxe_vulnerability(target_url)

This script, when executed against a vulnerable endpoint, would attempt to retrieve the contents of /etc/passwd. A successful detection would indicate that the server is vulnerable. Conversely, if the server returns an error related to entity processing or simply doesn’t return sensitive file content, it suggests the mitigation is in place.

Post-Mitigation Monitoring and Auditing

Following the implementation of the secure parsing configurations, continuous monitoring was established. This included:

• Log Analysis: Regularly reviewing web server logs (Nginx/Apache) and application logs for any suspicious patterns, such as repeated requests to internal resources or unusual error messages related to XML parsing.
• Intrusion Detection Systems (IDS): Ensuring that IDS/IPS signatures were up-to-date and configured to detect XXE-related attack vectors.
• Periodic Re-audits: Scheduling regular, in-depth security audits to catch any new vulnerabilities introduced by future code changes or evolving attack techniques.

By systematically identifying the vulnerable components, applying precise code-level mitigations, and implementing robust testing and monitoring, we successfully hardened the legacy Perl stack against XXE injection attacks, significantly reducing the enterprise’s attack surface on DigitalOcean.