65

A colleague sent a .xml file to me earlier today, which was blocked by Outlook. As we were discussing the workaround (put it in a .zip), we got to wondering why .xml files are blocked.

My colleague reckons it's because the browser is the default renderer for .xml files and there's possibly an attack vector by passing a html file with an xml extension, but I tried this on Firefox and I am shown the document tree as a bare xml file.

Does anyone have any examples where an xml file could be added as an attachment to do something malicious (or at least, moreso than any other random attachment that isn't blocked)?

KidneyChris
  • 685
  • 1
  • 5
  • 7
  • As another attack vector I hadn't previously considered, I also tried using XLSTs embedded in an .xml file to try and trick the browser into rendering something that looks like a web page, but either I did something wrong or Firefox is too smart to fall for that these days ( http://webstersprodigy.net/2012/02/04/serving-back-xml-for-xss/ ) Presumably older browsers (the article is from 2012) would quite happily serve up a malicious page. – KidneyChris Oct 26 '15 at 14:02
  • 8
    In my experience many corporations block .ZIP attachments, which is even harder to explain. I think it's just paranoia. You can almost invariably get around these restrictions just by renaming the attachment. What happens to the attachment when you double-click on it depends of course on how your mail client is configured, and I would have thought that's where corporates would want to exercise control: just insist that the default application for ALL attachments is something that checks the attachment carefully before executing anything. – Michael Kay Oct 26 '15 at 16:08
  • 6
    Note that it may not be a blacklist: it may be a whitelist. Meaning XML files are not specifically blocked, they're simply not (explicitly) allowed. – Jon Story Oct 26 '15 at 16:18
  • In our company, the webmail client blocks files with the "xml" extension, but the desktop client does not. Go figure. – kojiro Oct 27 '15 at 10:51
  • 2
    @MichaelKay "which is even harder to explain" - I think there's a fairly simple explanation, which is that zip file attachments can be used to bypass all the other filters. If they wanted to allow the filters to be bypassed like that, they wouldn'tve bothered adding any filters in the first place. – user253751 Oct 28 '15 at 01:39

3 Answers3

75

Possible XML based attacks are:

  1. XML bomb (aka Billion LOLs attack). This is an XML file that uses a recursive custom entity type definition to attack a vulnerable XML parser. The XML bomb has a very small size on disk, but expands up to a huge size when parsed, potentially exhausting the available memory on the victims device.
  2. External entity type that may not return. In this case the XML document defines an external entity type at a URL that either does not respond, or responds slowly. This could cause a DoS on the victims device.
  3. External entity type that expose sensitive information. This is similar to point 2 (and is explained at the same link), but in this case the external entity type attempts to expose sensitive local files (e.g. file:///etc/passwd)

Whether any of these attacks could succeed depend on the installed XML parser on the local machine. I think applications like newer versions of IE, Firefox etc. protect against these, but older versions or some custom software might be vulnerable.

Mike Goodwin
  • 2,151
  • 1
  • 11
  • 13
  • 1
    Do browsers or other tools that process XML still actually allow/enable external entities? This misfeature should have been disabled/removed a long time ago. – R.. GitHub STOP HELPING ICE Oct 27 '15 at 03:54
  • 2
    As mentioned, I think most newer apps will have this disabled (maybe it can be optionally enabled). On platforms like .Net and Java etc. it is still possible although depending on the version it can be disabled by default. – Mike Goodwin Oct 27 '15 at 09:08
  • Similar to @R..'s comment, XML bomb is no longer a viable attack either - XML parsers typically do not allow DTD by default anymore, thus blocking all entity-based attacks... Thus, it seems your answer is basically "historical reasons which are no longer viable" – AviD Oct 27 '15 at 15:32
  • 1
    Well, without doing a broad survey of platforms, I can say that on .Net, System.Xml.XmlReader allows DTD processing by default. You have to explicitly prohibit it using one of the overrides of its factory method. This is true of .Net 3.5 and 4 at least. XDocument does prohibit DTDs by default. – Mike Goodwin Oct 27 '15 at 15:53
  • 2
    It would be great to have some survey of widely used XML parsers and whether they are insecure/broken by default. – R.. GitHub STOP HELPING ICE Oct 28 '15 at 00:22
  • 1
    @R..: On external entity vulnerabilities and whether they are current threat or not, check out this https://edgescan.com/assets/docs/reports/2015-edgescan-Stats-Report-(2015)-v5.pdf – Mike Goodwin Nov 09 '15 at 12:55
16

An attacker can use an XML file for nefarious reasons and, as you asked if anything like that occurred in the past, there have been examples of such malicious XML attached files in the past.

In fact, the attack I am going to mention is recent and done by the end of Februaru 2015 where companies are sent a spam with an attached malicious XML file:

enter image description here

This attachment is a Microsoft Word XML Document; Microsoft has a special handler for XML files that will choose the application to handle them based upon detection of the contents, as described here, so double clicking on it can lead MS Word to be executed and thus loading the malicious macros embedded within it. Here is diagram showing how the malicious document was stored:

enter image description here source

Community
  • 1
  • 4
    You should explain those attacks in your answer, in case the link stops working. – Arturo Torres Sánchez Oct 28 '15 at 04:17
  • 1
    "In reality, this attachment is a Microsoft Word 2003 document that was saved as an XML file so double clicking on it lead MS Word to be executed" - This sentence makes no sense. – Nye Oct 28 '15 at 13:46
  • @Nye thank you for the comment: what does not make a sens? It simply says if you double click on the XML file, the MS Word (software) will execute/open it –  Oct 28 '15 at 13:59
  • 1
    The second part of the sentence doesn't in any way follow from the first. Double-clicking an XML file will open Word if and only if you have set Word as the application that handles XML files, which is neither a default nor a common setting. It makes no difference how the file was generated. Thus, the first part of the sentence is irrelevant, and the second part is incorrect in most circumstances. – Nye Oct 28 '15 at 14:04
  • I'm sorry, I really do not understand what you mean. If you want to edit my answer, please feel free to do that and I will accept it if no harm is done. Actually the example I gave is not theoritical: it is a banking trojan spread as an XML attachment (i linked to the source) @Nye –  Oct 28 '15 at 14:10
  • Oh, I see - it's the source that's wrong. Unfortunately it's *so* wrong that it's hard to guess what they even *meant*, but the article at face value is just nonsense, I'm afraid. – Nye Oct 28 '15 at 14:17
  • @Nye Actually several resources linked to that source, for example [this one](http://www.securityweek.com/xml-files-used-distribute-dridex-banking-trojan) –  Oct 28 '15 at 14:19
  • Okay, I understand it now - when I tested it at first I was thrown by the bit about it being "the older 2003 binary format", and couldn't reproduce the stated behaviour. That bit is incorrect, as the 2003 binary format and the 2003 XML formats are separate, so saying "(the older 2003 binary format) that was saved as an XML file", as the source article does, is self contradictory and I couldn't work out where they were going from there. I will propose a re-wording shortly... – Nye Oct 28 '15 at 14:42
5

If they block HTML then it also makes sense to block XML because it can be transformed using XSLT into XHTML (the transformation is supported by all recent browsers passing the Acid3 test) which is pretty much (especially security-wise) like normal HTML.

phk
  • 374
  • 2
  • 10
  • 2
    The transformation to XHTML via XSLT didn't seem to work on my version of Firefox. In particular, – KidneyChris Oct 26 '15 at 18:23
  • I just looked at simple examples on the web and they still work (and other browsers are supported as well), so the transformation itself does still work. – phk Oct 26 '15 at 18:58
  • 2
    What you might be seeing are the differences between XHTML and HTML, e.g. you can't use ```document.write()``` (which nobody in his/her right mind should nowadays do) and the CSS rules for html/body are handled a bit differently. Best to start testing with an XHTML to begin with, don't forget to deliver it with the right MIME type (```application/xhtml+xml```). – phk Oct 26 '15 at 19:03
  • 1
    It works if XML and XSL have the same source but shouldn't work for local documents pointing to the web. That should be blocked by same origin policy. – Thomas Weller Oct 28 '15 at 15:31