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

Auditing a High-Traffic Perl Stack on AWS

Our recent engagement involved a critical, high-traffic enterprise application stack running on AWS, primarily built with Perl and relying heavily on legacy SOAP integrations. The primary objective was to conduct a thorough security audit, with a specific focus on identifying and mitigating vulnerabilities, particularly XML External Entity (XXE) injection, which had been flagged as a potential risk in older SOAP services.

The stack comprised several interconnected Perl services, a MySQL database, and various AWS components including EC2 instances, ELB (Elastic Load Balancer), and S3. The SOAP integrations, in particular, were a point of concern due to their age and the inherent complexities of XML parsing in older libraries.

Deep Dive into XML Parsing Libraries and SOAP Handlers

The core of the XXE vulnerability lies in how XML parsers handle external entities. In older Perl SOAP implementations, it was common to use libraries that, by default, would attempt to resolve external DTDs and entities. This behavior, while sometimes useful for including external data, opens the door to attackers who can craft malicious XML payloads to:

• Read arbitrary files from the server (e.g., /etc/passwd).
• Perform Server-Side Request Forgery (SSRF) by making the server send requests to internal or external resources.
• Cause Denial of Service (DoS) through recursive entity expansion (Billion Laughs attack).

We began by identifying all SOAP endpoints and the specific Perl modules used for XML parsing and SOAP handling. Common culprits in older Perl environments include:

• XML::LibXML
• XML::Parser
• SOAP::Lite (which often uses one of the above internally)

Our initial audit focused on the configuration of these parsers. Many of these libraries offer options to disable external entity resolution. For instance, with XML::LibXML, the key is to ensure that the parser context is configured correctly.

Mitigating XXE in Perl SOAP Services

The most effective mitigation is to disable external entity processing at the parser level. For XML::LibXML, this is achieved by setting the no_network and no_ent options when creating the parser context or loading the XML document.

Example: Securing XML::LibXML Parsing

Consider a typical SOAP request handler that parses incoming XML. An insecure version might look like this:

Insecure Parsing Example

use XML::LibXML;

sub parse_soap_request {
    my ($xml_string) = @_;
    my $parser = XML::LibXML->new();
    my $doc = $parser->parse_string($xml_string);
    # ... process $doc ...
    return $doc;
}

To mitigate XXE, we modify the parser instantiation and document loading:

Secure Parsing Example with XML::LibXML

use XML::LibXML;

sub parse_soap_request_secure {
    my ($xml_string) = @_;

    # Create a parser context with security options
    my $parser = XML::LibXML->new(
        no_network => 1,  # Disables network access for DTDs and entities
        no_ent     => 1   # Disables entity substitution
    );

    # Load the XML string with the secure parser context
    my $doc = $parser->parse_string($xml_string);

    # Alternatively, if loading from a file or string reference:
    # my $doc = $parser->parse_fh(\*STDIN); # Example for STDIN
    # my $doc = $parser->parse_file('request.xml'); # Example for file

    # ... process $doc ...
    return $doc;
}

For XML::Parser, the approach is similar, involving the no_network and noent options passed to the parser constructor.

Securing SOAP::Lite Integrations

SOAP::Lite, being a higher-level framework, often abstracts away the direct XML parsing. However, it typically allows configuration of the underlying parser. If SOAP::Lite is configured to use a vulnerable parser or if custom XML processing is injected, XXE can still occur. The best practice is to ensure that any custom XML handlers or parser configurations within SOAP::Lite adhere to the secure parsing principles outlined above.

In many cases, updating SOAP::Lite to a recent version and ensuring it uses a modern, secure XML parser backend is sufficient. If custom XML processing is unavoidable, it must be rigorously audited.

AWS-Specific Security Considerations

While the XXE vulnerability is application-level, the AWS environment provides layers of defense and specific considerations for auditing and mitigation.

Network Access Control (Security Groups & NACLs)

Even if an XXE attack attempts to exfiltrate data via SSRF, AWS Security Groups and Network Access Control Lists (NACLs) can block outbound connections to unexpected destinations. We reviewed the outbound rules for the EC2 instances hosting the SOAP services. Ideally, outbound traffic should be restricted to only necessary ports and IP ranges (e.g., database servers, external APIs). For example, restricting outbound HTTP/HTTPS traffic to only known API endpoints significantly limits the impact of an SSRF attack.

IAM Roles and Least Privilege

The IAM roles attached to the EC2 instances were audited to ensure they followed the principle of least privilege. If an attacker could exploit an XXE to gain access to AWS metadata endpoints (http://169.254.169.254/latest/meta-data/), a role with excessive permissions could lead to a catastrophic compromise. We verified that roles only had permissions necessary for the application’s operation, such as read-only access to specific S3 buckets or permissions to interact with the RDS instance.

WAF (Web Application Firewall) Integration

For high-traffic applications, integrating AWS WAF with the Elastic Load Balancer (ELB) is a standard practice. We analyzed the WAF rulesets to identify if any were configured to detect and block common XXE patterns. While WAF is not a silver bullet for all XXE variants (especially those with complex encoding or obfuscation), it can provide a valuable first line of defense against known attack vectors.

A basic WAF rule to block requests containing common XXE indicators like or SYSTEM within XML payloads could be implemented. However, care must be taken to avoid false positives on legitimate XML content.

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