XML External Entity (XXE) Injection during import of aggregated report

[pjlantz]

Background

XXE Injection is a type of attack against an application that parses XML input. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document. Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

Steps to reproduce

1) Using the XML file in the Gist, run the following to create a zip attachment

zip -r report.zip dmarc_report.xml && base64 report.zip 

Copy and paste the base64 encoding into one of the test reports, for example this one.

2) Import the aggregated report

cat report.eml | python manage.py import_aggregated_report --pipe

This will trigger XML processing of the document.

Impact

After running the commands above the database will be populated with the injected data. However, at the moment there is no way to view the injected data, for example via the web interface.

Another feasible attack is a denial of service against the DMARC reporting functionality. By substituting file://etc/hostname with file://dev/random in the XML document, will cause the import of the aggregated report to block while processing the XML document.

A remote attacker can send a number of such DMARC reports to the mail specified in the RUA attribute of the DNS records. This will block any legitimate DMARC reports to reach the RUA email and will be put in the mail queue. Eventually, it may reach, since postfix has a timeout mechanism that will abort the report import but depending on the postfix configuration and number of DoS mails sent it may take quite some time. Note that by default, postfix allows a maximum of 20 concurrent processes to parse the DMARC reports. This can be increased as described in the next attack.

Yet another possible attack is a variant of the previous one. This one can cause a DoS against the Modoboa application or even the hosting server. Given that an instance of Modoboa hosts several domains, an attacker could send DMARC reports to each RUA addresses for all of the domains and this way trigger more concurrent processes. This attack can be reproduced by creating a few domains in the web interface and adding an entry for each domain to /etc/postfix/dmarc_transport (one domain and email per line). Following this, send a number of emails to each RUA and observe that the number of processes increase, as shown in the figure

Soon after, the web application will become unresponsive, showing the following error message

The worst-case scenario is that the concurrent processes will consume all RAM on the hosting server. Attached is a portion of the mail.logs written during this attack.

Remediation

Use a XML parser with entity expansion disabled. Please refer to this guideline.

[tonioo]

@pjlantz Thank you for the report. I've just pushed a PR which should address this issue, would you mind testing it?

[pjlantz]

@tonioo I can confirm that defusedxml fixes this issue.

[tonioo]

@pjlantz Thank you.