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