8

We have uncovered an XML External Entity vulnerability in our asp.net asmx web service.

We are testing an asp.net .asmx web service using burp suite, to check for XML External Entity Processing vulnerabilities. See: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

We see that when a DTD is included in the request like this:

<!DOCTYPE soapenv:envelope PUBLIC "-//B/A/EN" "http://1234565.cigitalcollaborator.com">

A DNS request is sent to for cigitalcollaborator.com. This indicates the asmx web service is processing the DTD in request.

We are using .net version 4.5.2.

According to this link, XXE vulnerabilities should be implicitly blocked for .net 4.5.2 and later: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#.NET_4.5.2_and_later

But it's not... We ge this DNS lookup.

The underlying .net framework is handling XML deserialization/serialization for this asmx web service, so there's no code for us to really fix here. We cannot alter the behavior right, because it's somewhere in the underlying framework?

How we can fix this XXE vulnerability for our ASMX web service?

Thank you

Jon Paugh

pseudorandomusername
  • 57
  • 7
user10102158
  • 81
  • 1
  • 3
  • Are you sure the code is doing a DNS request due to the DTD. I would use a sniffer like wireshark or fiddler to see why the code is actually doing a DNS lookup. – jdweng Jul 19 '18 at 17:36
  • Is the client that calls the web service on 4.5x? – Crowcoder Jul 19 '18 at 18:05
  • jdweng, the DTD has a very unique URI in it. There is no way it would get hit via DNS if it were not coming from the DTD. – user10102158 Jul 19 '18 at 19:01
  • Crowcoder - i corrected my question to make the example XML visible. We are sending the request to the asmx web service using SoapUI test tool (not using .net at all). The problem is caused by the presence of this DTD in the request. A malicious client can always send this to us, and we need to ignore it/not process it. – user10102158 Jul 19 '18 at 19:06
  • @user10102158 so you haven't tried it where you are actually using .Net as the client to call it? It is the implementation in .net 4.5 that blocks it, I wouldn't count on SOAP UI or Burp Suite to do that. – Crowcoder Jul 19 '18 at 19:38
  • 1
    @user10102158 - I think you are saying "use .net 4.5.2 in the client, and that will fix the vulnerability". But the vulnerability is in our service, where the XML is processed, not the client. So not seeing how the client is relevant. – user10102158 Jul 19 '18 at 20:04
  • `XmlReaderSettings.DtdProcessing` is set to `Prohibit` by default in .NET > 4, which should be safe. What classes do you use to process XML? – Markus Dresch Apr 11 '19 at 15:24

2 Answers2

3

I think that it is important to consider two different points here:

First - An automated scan designed to work across web applications using all manner of different technologies does not prove that a vulnerability is present. A DNS lookup is not the same as fully processing the Entity in question. If a subsequent request is made to the url in question, and data from that is processed then you have a vulnerability. You can configure your application use a proxy like Fiddler to verify if such a request is made.

Secondly, .NET has been secure since 4.5.2 by default. This is not the same as guaranteed secure. If an application requires DTD processing it can be enabled in the settings:

var xmlReaderSettings = new XmlReaderSettings();
xmlReaderSettings.DtdProcessing = DtdProcessing.Parse;
var xmlReader = XmlReader.Create(new StringReader("EvilXml", xmlReaderSettings));

Or

var xmlTextReader = new XmlTextReader(new StringReader("EvilXml");
xmlTextReader..DtdProcessing = DtdProcessing.Parse;

And with an XDocument resolver implementations process DTDs

var xmlDocument = new XmlDocument();
// Implementations of XmlResolver are probably  unsafe
xmlDocument.XmlResolver = new MyCustomResolver(); 
// xmlDocument.XmlResolver = null is safe - should be the default from 4.5.2 
xmlDocument.LoadXml("EvilXml");

I would probably search the source code for the two relevant text strings "DtdProcessing.Parse" and "XmlResolver" to rule this out.

ste-fu
  • 6,879
  • 3
  • 27
  • 46
  • Additionally the link from the [OWASP XML_External_Entity_Prevention_Cheat_Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md#net) which refers to [Security Briefs - XML Denial of Service Attacks and Defenses](https://msdn.microsoft.com/en-us/magazine/ee335713.aspx) – kapsiR Apr 15 '19 at 13:04
  • I would seriously consider nuancing your first point. A DNS lookup to an arbitrary domain is a red flag. Sensitive data can sometimes be exfiltrated via a DNS lookup (e.g. by base32-encoding the sensitive stuff and sticking that in a subdomain label of the attacker's domain). – jub0bs Dec 31 '20 at 16:35
2

ASXM web services are considered legacy and don't receive all bug fixes as they have limited extension points. You probably want to re-write this or at least put a facade in front of it using like WCF or WebAPI...

Sadly the connect articles referring to this have been taken down with connect retiring but there are references from people to linking to them:

"They are based on the old XML Serialization technology, which is not getting bug fixes. (see Microsoft comment on 1/11/2010)" https://johnwsaunders3.wordpress.com/

Milney
  • 6,253
  • 2
  • 19
  • 33