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.

This blog post is not about fuzzing the hell out of a control or even about comfortable memory corruption inside a modern browser.. Instead its about the bugs you will never find with static analysis (and statistically will never find with fuzzing). You occasionally have a customer asking if an application needs to be assessed if the customer has already used some sort of static analysis tool. Of course answering this is tricky since we do application assessments for a living and my honest answer must seem at least slightly tainted.. For me the attached bug we found in a Juniper ActiveX control covers my point of view perfectly..

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.

(click here to enlarge) This was a pretty obvious attack though, and the Control first checked the downloaded file to see if it was signed by Juniper. If it wasnt, then the file was not executed. Drat!

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:

(click to enlarge) Now..  We can drop an arb file to the victims machine && we can instantiate the control using any well formed config file on his machine.. hmmm..

(click to enlarge)

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..

Conclusion:

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

Then you probably should get on this one... [Problems with Random Number Generator]

While it looks like an arb openssl bug, 2 seconds of reading should get you to:

-snip-

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch.

&&

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. -snip-

Note that even if you upgraded the package, you probably need to regenerate your old keys..

/mh

PS.. Sorry about the loooooong blog silence.. theres been lots of coolness, but most of the guys have actually had their heads down on projects, and either havnt been blogging, or have blogged -> but we would get killed if we spake about it..