66

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)?

5
  • 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 ( 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. Oct 26, 2015 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. Oct 26, 2015 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, 2015 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, 2015 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, 2015 at 1:39

3 Answers 3

76

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.

6
  • 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. Oct 27, 2015 at 3: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. Oct 27, 2015 at 9:08
  • 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. Oct 27, 2015 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. Oct 28, 2015 at 0:22
  • 1
    @R..: On external entity vulnerabilities and whether they are current threat or not, check out this edgescan.com/assets/docs/reports/… Nov 9, 2015 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

8
  • 4
    You should explain those attacks in your answer, in case the link stops working. Oct 28, 2015 at 4: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, 2015 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
    – user45139
    Oct 28, 2015 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, 2015 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
    – user45139
    Oct 28, 2015 at 14:10
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.

4
  • 2
    The transformation to XHTML via XSLT didn't seem to work on my version of Firefox. In particular, <script> and <a>nchor tags were ignored. Of course, I could have done the XSLT incorrectly. Seems to have been valid in the past though: webstersprodigy.net/2012/02/04/serving-back-xml-for-xss Oct 26, 2015 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, 2015 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, 2015 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. Oct 28, 2015 at 15:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .