Another bug your tools won't find and your WAF won't prevent

First off, I want to apologize to our readers for not being here as much last week.  I had a rough week involving a random ear infection and the loss of an aunt to cancer, so it was not a week where I was very concerned about computer security or my blog.  In any case, I'm back, and excited to be posting again.

A short time ago Sensepost had a sexy blog article about ActiveX repurposing.  You know, before I get started, I thought I should mention that repurposing attacks are not unique to ActiveX, in fact, John Heasman of NGSSoftware has a great article on repurposing Java Applets.  I think fairly shortly here I'll do a whole series of blog posts about testing ActiveX for issues, but that's another post for another time.  For now, I just want to call attention to SensePost's very cool, I've paraphrased pieces for discussion:

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

Before I get into Sensepost article's detail, I wanted to comment on analysis tools, like source assessment tools and black box web application scanning tools, but I'm going to avoid naming names here.  I definitely feel Sensepost's pain when it comes to clients believing that running a scanning tool is all that is needed.  I don't want to take anything away from the tools, I like these tools, they're helpful, but they are not the end all be all of security.  I also feel for the clients... there looking for the cheapest solution to a complex problem, unfortunately, there's not always a cheap solution to complex problems.  This brings me back to web application firewalls (WAFs).  They're in the same boat.  Ok, so back to the article:

"The Background: The Juniper SSL-VPN products make use of an ActiveX Control on the client-side. Previously bugs had been foundin 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"

Interestingly enough, I consider this type of flaw far sexier than any simple stack smash flaw.  It's elegant, abusive, and slips by most tools and most researchers focused on those things which can be easily detected. -Nate