XXE with .NET in 2019
After the seminal blog post by James Jardine in 2016 on XXE exploitation in .NET applications back in 2016, Microsoft seems to have implemented some additional changes regarding the default behavior of XML parsers.
We work through the different XML methods provided and their corresponding vulnerable configurations. For all experiments, .NET framework 4.6 was chosen.
In order to create an XXE vulnerability for applications using .NET framework 4.6+, you have to instantiate a vulnerable
However, DTD parsing still is enabled by default for many readers, thus making them vulnerable to so-called billion-laugh attacks (see https://en.wikipedia.org/wiki/Billion_laughs_attack).
In order to allow the processing of external DTDs, both the
DtdProcessing and the
XmlResolver attributes have to be set accordingly.
DtdProcessing attribute alone will not suffice.
The official Microsoft documentation states the following:
XmlResolvertype is used to resolve external XML resources, such as entities, document type definitions (DTDs), or schemas. It is also used to process include and import elements found in Extensible Stylesheet Language (XSL) style sheets or XML Schema definition language (XSD) schemas. (see https://docs.microsoft.com/de-de/dotnet/api/system.xml.xmlresolver?view=netframework-4.8)
XmlResolveris used to access external documents. If set to null, an
XmlExceptionis thrown when the
XmlReadertries to access an external resource. The default is a new
XmlUrlResolverwith no credentials. Starting with the .NET Framework 4.5.2, this setting has a default value of null. (see https://docs.microsoft.com/de-de/dotnet/api/system.xml.xmlreadersettings.xmlresolver?view=netframework-4.8)
For this class, any DTD declarations will be automatically processed. However, for external entities there still is a corresponding
Likewise, DTD declarations will be automatically parsed for this class. In order to be able to resolve external entities, an XmlResolver object has to be created.
This class offers a variety of constructors, of which only the ones using XmlReader and XmlTextReader seem to be still vulnerable. Yet, these have to be configured in an insecure way as described above.
For newer versions of the .NET framework, the principle of secure defaults have been incorporated throughout for XML parsing. In a nutshell, you have to bend over backwards in order to create an XXE vulnerability.