Earlier this week we had an internal presentation on Attacking ActiveX Controls. The main reason we had it is because of the ridiculously high hit rate we have whenever we look at controls with a slight security bent.. When building the presentation i dug up an old advisory we never publicly released (obviously we reported it to the vendor who (kinda) promptly fixed the bug (without giving us any credit at all, but hey.. )) While the IEBlog promises updates to IE8 that will minimize the damage caused by owned controls in the future, the fundamental problems with ActiveX today are an attackers dream.

• Developers still write controls as if only they can invoke its methods (repurposing++),
• The fact that Skylined's HeapSpraying and Alex Sotirovs Heap Feng Shui makes the browser such a comfortable exploiting environment means that memory corruption bugs in a control == trivial to write client side exploits.

The Background:

The Juniper SSL-VPN products make use of an ActiveX Control on the client-side. Previously bugs had been found in the control by eEye and had been subsequently fixed by Juniper. This was a pretty garden variety stack smash and it would appear that Juniper did the right thing and hunted down other instances of these bugs within the control.

The Bug(s):

The ActiveX control included the functionality to upgrade itself if the server informed it of a new software version. By simply instantiating the control and passing it a high build number and a URL path to a downloadable file, we could cause the client to download our (possibly malicious) file.

The kicker though.. was that this file was not deleted, and was always downloaded to a predictable spot. (C:\predictable_location)

Interlude: Now.. the usual attack vectors dont really come through for us.. We cant over-write anything important with this file and simply filling the disk seems pointless.

Bug (Continues):

When instantiating the control, one of the parameters we can pass is the path to the control's .ini configuration file:

Now, in case you dont see it, the config file above has the winning line: UninstallString="calc.exe &&"

So.. the writing is on the wall and the full process is this:

1. Client with control visits malicious page.
2. Page instantiates control and offers an upgrade 
   
   (click to enlarge)
3. new-config.txt downloads to c:\predictable_location\new-config.txt
4. Malicious page re-instantiates control with ini file == c:\predictable_location\new-config.txt [new-config contains arbitrary commands as uninstall string]
5. We use the controls uninstall method:
   
   (click to enlarge)
6. The victims machine fires calc.exe && and the game is over..

Ok.. so the simple deal is.. that much like the eEye find, client visits page and client gets arb. code executed on his machine, but (and this was the point of this whole rant) bugs like this have always been considered "less sexy" than stack smashes. Whats far more important for me however, is that even if our static analysis tools get to the state where they match their marketing hype, they will never find a bug like this..

There are some things that computers are good at, and some things that humans are.. and just because we want this to be a problem thats solvable with technology doesnt mean that the technology to do it will ever exist. This obviously does not mean that such tools are useless, just that they will never be a silver bullet, and that its still difficult to beat a trained set of eyes with high criminal energy..

/mh