In this article I will outline the stages involved in the full exploitation of the recent DirectShow vulnerability. In particular I will discuss a specific example of how this exploit was used in the wild. The recent DirectShow vulnerability was interesting for a number of reasons and to explore each of those reasons in detail I will first give an overview of the entire exploitation flow, and then explore individual portions in more detail.
Some of the first pages to use this exploit for this vulnerability in the wild were linked from phishing pages. The phishing pages in question not only attempted to steal the visitors’ login credentials, but also silently redirected users to a malicious Web page hosting an exploit for the DirectShow vulnerability (CVE-2009-1537). This malicious Web page loads a corrupt .avi file that exploits the vulnerability and also loads some additional malicious .dlls to facilitate reliable exploitation of the user’s machine (this will be discussed in more detail later).
The malicious .dlls in turn download an encoded .exe payload that, in this case, ultimately leads to Trojan.Cipevas being loaded on to the victim’s machine. Trojan.Cipevas then connects back to the attackers’ website (the same one where the exploit page is hosted), sends some minimal user information to the attacker and then waits for further commands from the attacker.
The actions that Trojan.Cipevas can conduct on the victim’s machine include downloading additional files, adding/deleting files and registry values, stopping/starting services and processes, gathering user information, and opening up ports for the attacker to take further control of the machine. (A side note: Trojan.Cipevas was named by reversing the name of the page that it connects to when announcing its presence to the attacker: http://[attackers ip]/savepic.asp.)
The phishing page observed in this case was for a well-known webmail login page (as shown below). The attackers were hosting the fake login page on their own servers, so the URL displayed in the location bar was obviously not the real URL you would expect to see:
Reviewing the source code of the page shows that although the main purpose of this fake login page is to steal user credentials, the page also contains an iframe that redirects to the DirectShow exploit page. As usual in these types of attacks, the width and height of the iframe are set to zero to hide it from the user:
The Exploit and Trojan
The exploit is interesting for several reasons. Firstly, it is not a typical buffer overflow/heap corruption vulnerability; rather, the vulnerability only allows one byte in memory to be overwritten. This means that the creator of the exploit code had to think outside the box to get this vulnerability to be exploitable, which leads to the second interesting point. This is one of the first exploits we have seen that uses the techniques described by Alex Sotirov and Mark Dowd in their paper “Bypassing Browser Memory Protections.“ In fact, using these techniques makes the typical heap-spraying code that we normally see in these exploit pages redundant here, which leads to the third interesting point. If heap spraying is not needed, why is it included in the exploit pages?
There will be a follow up blog about the exploit and Trojan.Cipevas in more detail tomorrow. For our DeepSight customers there is already a detailed technical report available on our DeepSight portal.