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

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

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


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

Topics: CXO, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Nothing is secure

    It's always the simple things that work best.

    And do not even think this is limited MS, every system will fall prey to this or something like it.
  • The only totally secure system, is one not connected to the network.

    But of course the guy at the keyboard can still mess things up. So you need to keep the tower behind a locked door, with no connection to the network.
  • "the fundamental problems with ActiveX today are an attackers dream."

    ActiveX is so 90s.

    What else you got? ;)
    D T Schmitz
  • RE: Another bug your tools won't find and your WAF won't prevent

    Haha, is that sort of like buffer overflows are so '80s?

    Trust me man, ActiveX exploitation is back in action again. It's been forgoten, and it's making it's return... just like bellbottoms did not long ago.

    • I trust you don't take any delight in that

      At bellbottoms don't hold you hostage--you can hang them up in the closet and wait for them to come back into style. ;)

      ActiveX on the other hand, well I have my own ideas of what IT Folk and regular end-users can do.

      Stop by [url=]Linux IT Consultant[/url] and educate yourself to the options at your disposal.

      Be Safe.

      Dietrich T. Schmitz
      [i]Linux IT Consultant[/i]
      D T Schmitz
  • RE: Another bug your tools won't find and your WAF won't prevent

    So to comment on the automated tools (since that's something I know a little about... <right Nate?>) ...anyway - I always tell clients that automated tools find between 30% - 80% of a web application's flaws with about 75% consistency. It doesn't matter what the tool is, that's just a matter of life. What this means is this... say you use Tool X and you find only 30% of your vulns - but that 30% is the "low-hanging fruit" which can cause the garden variety h4x0r to give up once they're eliminated... the other 70% are left to the determined attacker. So now you can start to flesh out your risk equation. If it costs you $50 (say a tool costs that much for instance) to find 30% of the flaws (which we agree are the most likely to be explotied) about 75% of the time... while the data value is, say for instance, $10mm... have you done enough? Of course this is simplifying it too much but you get my point.

    Anyway - this isn't necessarily anything that a scanning tool is even *meant* to find... this is considered a logic flaw, right? By definition when automated tools start to find logic flaws I think I'll be hiding in a bunker expecting SkyNet to start eradicating humans.

    /my $0.02
    Rafal.Los (RX8volution)
  • Not at ActiveX Problem

    What's described here is not specific to ActiveX.

    The problem is that a client app will download and run something without proper checking. There's nothing in this that is specific to any particular OS, web browser or client technology. It's a programming bug pure and simple, and this bug could be implemented in Java, Javascript, Flash, or anything else that runs in the client.

    Anyway, gotta love the "programmer's error, Microsoft's fault" attitude!! ;-D

    Steve G.
  • RE: Another bug your tools won't find and your WAF won't prevent

    True that this is not Active X problem. However, most other programs will give you more information what application was called and what will be affected if you "allow" the program do what it supposed to do. If you ever got an Active X message pop-up you have no idea what application called it and what is it doing the word "vague" is best term for Active X message pop-up. Active X is pretty much a blind trust that the program is doing.
  • I'm really very sorry for your loss . . .

    I've lost loved ones myself and its tough; my hopes and prayers are with you and your family.

    Very good article and I truly enjoy your blog.

    Best regards,
    The p-smurf.