A few days ago, we received yet anothersubmission containing a strange Animated Cursor file. Thisvulnerability made quite some noise, and though we thought it washandled by now, this file was definitely not the usual ANI exploit…
An ANI file follows the RIFF standard, with a few exceptions. It isa collection of data chunks, all having the same format of "header |size | data". Therefore, spotting malicious files attempting to exploitthe vulnerability should be easy. But is it? For the human eye, it is.For a heuristic detection, in spite of what was said before, it is not.Despite the supposedly easy structure of the Animated Cursor file,Microsoft’s implementation of its parser is quite loose.
First, invalid chunks will get properly parsed. Though not affectingthe ANI file itself, such chunks should not be encountered in cursorfiles, but the ANI parser just allows and skips them. Fair enough, ourdetections can handle that as well. Attackers, after a few days of‘proper ANI files’ exploitation, realized that and started to writemalicious ANI files generators containing hundreds of invalid chunks,hoping to force heuristic detections to bail out. It didn’t work.
Another ‘weakness’ in the Windows ANI parser started beingexploited. Though chunks should be aligned on 2-byte boundaries, thesize announced in a header – which should be an even number - can beless than the actual amount of data residing in the payload. Of course,the parser understands this…and rounds the size field to a 2-byte wordbefore moving to the next chunk. The detections were quickly updated tohandle those not-so-invalid ANI files.
The file I’m talking about pushed the parser’s looseness to itsextreme. Using a particular chunk, containing another chunk in itspayload, the size field of the particular chunk can be highly modified,and the file will still be properly parsed by Windows! Where’s thelogic?
Additionally, the ANI file itself did not exhibit a classicmalicious structure: it did not contain any shellcode. It simplyexploited the vulnerability and overwrote a ~460-byte area in memory.The exploitation was done by a malicious JavaScript code located in theHTML page that referenced the ANI file. Heap-spraying the memory in IE,triggering the vulnerability in ANI…an efficient combination. Thoughthe heap-spraying part is not new, combined with this particular ANIfile, it again demonstrates the ability attackers have to invent orfind alternate ways to bypass usual detections. Not to mention the ANIparser itself, loose to a point that it facilitates the attackers’job...once again, the trade-off between convenience, usability andsecurity.
Links:
Microsoft MS07-017 - the official ANI vulnerability patch
Trojan.Exploit.131 – malicious ANI files detection