XML: A New Vector For An Old Trick
October 2014 saw the beginning of an e-mail campaign spamming malicious Microsoft Office documents. Mostly Word documents using the “old” binary format, but sometimes Excel documents and sometimes the “new” ZIP/XML format. All with VBA macros that auto-execute when opened.
Yesterday, we started to see XML attachments. You might expect that these attachments open with Internet Explorer when you double-click them, but if you have Microsoft Office installed, they will open with Microsoft Word.
The XML file contains an element (w:binData) with a base64 string as content. Its attribute (w:name="editdata.mso") reveals it is a MSO file. Decoding the base64 string, we end up with a binary stream with header ActiveMime. 50 bytes into the stream (position 0x32), a ZLIB compression object starts. Inflating this object reveals an OLE file (header 0xD0CF1LE0) containing the VBA macros.
This OLE file can be analyzed with my oledump tool I mentioned in a previous diary entry [1], but I just released a new version [2] that handles XML files directly. And Philippe Lagadec already released a new version of his olevba tool yesterday [3].
Both tools are Python programs, giving you the means to analyze malicious Microsoft Office documents in any environment supporting Python, without Microsoft Office applications.
If you filter e-mail attachments that are Microsoft Office documents, you should check what your e-mail filter does with XML files. XML declaration identifies the XML file as a Word document, and attribute w:macrosPresent="yes" (of element w:wordDocument) indicates the presence of VBA macros. Remark that these strings are different for XML Excel documents.
Until now, we have only seen XML Word documents. Please post a comment if you received another format, like XML Excel documents, if possible with a link to the VirusTotal entry.
The MD5 of the sample discussed in this diary entry is 77739ab6c20e9dfbeffa3e2e6960e156.
1: https://isc.sans.edu/diary/oledump+analysis+of+Rocket+Kitten+-+Guest+Diary+by+Didier+Stevens/19137
2: http://blog.didierstevens.com/programs/oledump-py
3: http://www.decalage.info/python/oletools
Anybody Doing Anything About ANY Queries?
(in an earlier version of this story, I mixed up Firefox with Chrome. AFAIK, it was Firefox, not Chorme, that added DNS ANY queries recently)
Recently, Firefox caused some issues with it's use of ANY DNS queries [1]. "ANY" queries are different. For all other record types, we got specific entries in our zone file. Not so for ANY queries. RFC 1035 doesn't even assign them a name [2]. It just assigned the query code (QCODE) of 255 to a "request for all records". The name ANY is just what DNS tools typically call this query type.
The "ANY" record works a bit differently depending on whether the query is received by a recursive or authoritative name server. An authoritative name server will return all records that match, while a recursive name server will return all cached values. For example, try this:
1. Send a DNS "ANY" query for "evilexample.com" to the authoritative name server
dig evilexample.com ANY @ns1.dshield.org
I am getting 44 records back. Your number may be different.
2. Next, request a specific record using your normal recursive DNS server
dig evilexample.com
I am getting one answer and two authority records (YMMV)
3. Finally, send an "ANY" query for evilexample.com to your recursive name server
dig ANY evilexample.com
You should get essentially the same information as you got in step 2. The recursive name server will only return data that is already cached. UNLESS, there is no cached data, in which case the recursive name server will forward the query, and you will get the complete result.
So in short, if there is cached data, ANY queries are not that terrible, but if there is no cached data, then you can get a huge amplification. The "evilexample.com" result is close to 10kBytes in size. (Btw: never mind the bad DNSSEC configuration.. it is called "evilexample" for a reason).
So but how common are these "ANY" queries? I took a quick look at a recursive and an authoritative name server. The recursive name server had no ANY queries at all in its query log (I am not using the latest version of Chrome on Windows). The authoritative name server had 0.7% of ANY queries. (click on image for full size)
 |
|
| Authoritative Name Server | Recursive Name Server |
As expected, the recursive name server, which is only forwarding requests for a few internal hosts, is a lot "cleaner". The authoritative name server, which is exposed to "random" queries from external hosts, is a lot more "dirty" and with many networks still preferring the legacy IPv4 protocol, A queries outnumber AAAA queries. Any queries make up less then 1%, and they follow a typical scheme. For example:
| Time | Client IP |
|---|---|
| 16:23:37 | 212.113.164.135 |
| 16:23:38 | 212.113.164.133 |
| 16:23:38 | 212.113.164.131 |
| 16:23:39 | 212.113.164.128 |
| 16:23:39 | 212.113.164.131 |
| 16:23:40 | 212.113.164.132 |
| 16:23:41 | 212.113.188.75 |
| 16:23:43 | 212.113.164.132 |
| 16:23:43 | 212.113.164.133 |
| 16:43:31 | 212.113.164.132 |
| 16:43:33 | 212.113.164.135 |
| 16:43:33 | 212.113.188.75 |
| 16:43:33 | 212.113.164.129 |
| 16:43:35 | 212.113.164.131 |
| 16:43:35 | 212.113.164.131 |
Short "surges" of queries arriving for the same ANY record from the same /24. This is not "normal". All these hosts should probably use the same recursive name server, and we should only see one single ANY request that is then cached, if we see it at all. This is typical reflective DDoS traffic. In this case, 212.113.164.0/24 is under attack, and the attacker attempts to use my name server as an amplifier.
Is it safe to block all ANY requests from your authoritative name server? IMHO: yes. But you probably first want to run a simple check like above to see who and why is sending you ANY requests. Mozilla indicated that they will remove the ANY queries from future Firefox versions, so this will be a minor temporary inconvenience.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1093983
[2] https://www.ietf.org/rfc/rfc1035.txt
Comments