ANI to the Extreme
A few days ago, we received yet another submission containing a strange Animated Cursor file. This vulnerability made quite some noise, and though we thought it was handled by now, this file was definitely not the usual ANI exploit…
An ANI file follows the RIFF standard, with a few exceptions. It is a collection of data chunks, all having the same format of "header | size | data". Therefore, spotting malicious files attempting to exploit the 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 affecting the ANI file itself, such chunks should not be encountered in cursor files, but the ANI parser just allows and skips them. Fair enough, our detections can handle that as well. Attackers, after a few days of ‘proper ANI files’ exploitation, realized that and started to write malicious 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 being exploited. Though chunks should be aligned on 2-byte boundaries, the size announced in a header – which should be an even number - can be less 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 word before moving to the next chunk. The detections were quickly updated to handle those not-so-invalid ANI files.
The file I’m talking about pushed the parser’s looseness to its extreme. Using a particular chunk, containing another chunk in its payload, the size field of the particular chunk can be highly modified, and the file will still be properly parsed by Windows! Where’s the logic?
Additionally, the ANI file itself did not exhibit a classic malicious structure: it did not contain any shellcode. It simply exploited the vulnerability and overwrote a ~460-byte area in memory. The exploitation was done by a malicious JavaScript code located in the HTML page that referenced the ANI file. Heap-spraying the memory in IE, triggering the vulnerability in ANI…an efficient combination. Though the heap-spraying part is not new, combined with this particular ANI file, it again demonstrates the ability attackers have to invent or find alternate ways to bypass usual detections. Not to mention the ANI parser itself, loose to a point that it facilitates the attackers’ job...once again, the trade-off between convenience, usability and security.
Links:
Microsoft MS07-017 - the official ANI vulnerability patch
Trojan.Exploit.131 – malicious ANI files detection
Posted by Nicolas Falliere on April 27, 2007 05:00 AM