Fri, 23 May 2008
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:
- Client with control visits malicious page.
- Page instantiates control and offers an upgrade (click to enlarge)
- new-config.txt downloads to c:\predictable_location\new-config.txt
- Malicious page re-instantiates control with ini file == c:\predictable_location\new-config.txt [new-config contains arbitrary commands as uninstall string]
- We use the controls uninstall method:
(click to enlarge)
- 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
Categoriers
.ac.za (1).za (2)
44con (4)
about:us (42)
analysis (7)
auctions (1)
auditors (1)
b-sides (2)
blackhat (23)
blog (10)
broadview (4)
build-it (1)
ccdcoe (1)
cloud (12)
community (21)
conferences (75)
consulting (1)
crypto (6)
estonia (1)
fail (3)
foos (1)
footprinting (2)
fun (52)
goodbye (1)
hackathon (1)
hackrack (2)
Hope? (2)
howto (14)
imsojaded (2)
infosec-soapies (25)
infrastructure (3)
interns (1)
ios (1)
jobs (3)
local (7)
mac (15)
management (12)
materials (4)
memcached (2)
memory (1)
metasploit (3)
metricon (2)
metrics (3)
mindless-politics (4)
mindmaps (1)
mobile (5)
modelling (5)
PCI (2)
penny (1)
pentest (4)
phone (1)
pickle (4)
policy (1)
post-exploitation (1)
post-it (1)
presentations (3)
Press (3)
privacy (7)
product (2)
programming (14)
public (360)
python (7)
qo[w|m|?] (5)
rambling (2)
README (1)
real-world (17)
Release (3)
report-info (1)
research (55)
reversing (12)
risk (2)
SAP (2)
security-fyi (8)
security-news (6)
shells (1)
silly-yammerings (20)
skype (2)
solution (1)
suru (1)
tech-toys (3)
threat (5)
time-waster (6)
tin-foil-hat (6)
tools (50)
training (38)
travel (2)
tricks (3)
UK (2)
Uncategorized (3)
uncon (2)
vendors (7)
videos (6)
vulnerability (10)
wasc (1)
webapps (6)
web_x.0 (2)
wifi (1)
windows (1)
writing-advice (1)
zaprize (2)
zen-hacking (6)
Archives
May 2013 (3)April 2013 (2)
March 2013 (4)
Feburary 2013 (2)
January 2013 (1)
December 2012 (3)
November 2012 (6)
October 2012 (1)
September 2012 (3)
August 2012 (3)
July 2012 (1)
June 2012 (2)
May 2012 (5)
April 2012 (1)
March 2012 (3)
Feburary 2012 (1)
December 2011 (3)
November 2011 (2)
October 2011 (6)
September 2011 (3)
August 2011 (3)
July 2011 (3)
June 2011 (2)
May 2011 (6)
March 2011 (3)
Feburary 2011 (3)
January 2011 (1)
December 2010 (2)
November 2010 (4)
October 2010 (3)
August 2010 (4)
July 2010 (1)
June 2010 (4)
May 2010 (3)
April 2010 (3)
March 2010 (7)
Feburary 2010 (2)
January 2010 (3)
December 2009 (4)
November 2009 (4)
October 2009 (3)
September 2009 (5)
August 2009 (9)
July 2009 (1)
June 2009 (5)
May 2009 (4)
April 2009 (10)
March 2009 (13)
Feburary 2009 (12)
January 2009 (11)
December 2008 (9)
November 2008 (8)
October 2008 (5)
September 2008 (5)
August 2008 (6)
July 2008 (6)
June 2008 (6)
May 2008 (2)
April 2008 (3)
March 2008 (7)
Feburary 2008 (12)
January 2008 (9)
December 2007 (8)
November 2007 (4)
October 2007 (9)
September 2007 (14)
August 2007 (18)
July 2007 (13)
June 2007 (17)
May 2007 (2)
July 2006 (1)
April 2006 (1)
August 2005 (1)
June 2005 (1)
May 2005 (2)
- Social:
- E-mail: info@sensepost.com
- Tel (South Africa): +27 (0)12 460 0880
- Tel (United Kingdom): +44 (0)20 7956 8826
- Accreditations: PCI ASV, CREST
United Kingdom
- 37th Floor
- 1 Canada Square
- Canary Wharf
- London
- E14 5AA
- United Kingdom
South Africa
- Lakeview 2
- 138 Middel street
- Nieuw Muckleneuk
- Pretoria
- South Africa
It's because it's not a man vs. machine problem, but a man vs. man problem :)
http://www.microsoft.com/downloads/details.aspx?FamilyID=43cd7e1e-5719-45c0-88d9-ec9ea7fefbcb&displaylang=en
"If you think that technology can solve your problems, you do not understand the problem and you do not understand the technology".
Carbon Units still have the edge.
which happens to look like their company's corporate web site, there are about 10 thousand other things you could do, like prompt them to download "Upgrades" to any of the hundreds of binaries installed on their machines, and backdoor them in countless ways. The only difference here being the VPN client appears to need a real upgrade, and so it appears more _plausible_ to the end user. Reality check: if you've got this far along in your attack (you're mitm-ing someone or !
they click on your link) where you'd consider using this "vulnerability", don't. Shoot yourself in the face. As a bad guy, this vuln makes you work HARDER to own the victim's box: Say you use this vuln. Now what? Do you think Sally in HR has nc.exe on her box? What are you going to do? "del *.* /s"? At least if you convince someone to simply download your "Adobe Acrobat" upgrade you can outright own their box in a single HTTP GET/double click. Haroon, you're an intelligent person and much better t
han this.
Maybe my explanation was not clear enough (for this i apologize).
a) i can download _any_ file to your machine
b) i download malware nc.exe, nc2.exe and nc3.exe for good measure
c) i download bad config file
d) then i use config file to do what i want..
Three more things..
a) All of this happens behind the scenes.. so the user doesnt have to click on anything / accept anything or be fooled by anything.. i.e. this can be an iframe within a popular reddit article to be mass owning people..
b) i think u underplay the value of being able to run a single command on Sallys box.. even just a net use \\me will be useful to steal her hash, that might prove useful elsewhere..
c) i never said this was a libtiff / slidingwindow style broken internet vulnerability.. i just thought it was cute..
Thanks for the comments though, and for not thinking me a complete monkey like my wife does :>
yeah.. the downloads are not done regular download style.. its the control fetching it and storing it on ur machine without u noticing anything at all.. thanks for writing in.. the feedback is always cool..
The same goes for SSL - the activex can make sure a site invoking it has a valid SSL cert, but hard coding a specific SSL cert would not be scalable (every customer has their own).
Microsoft IAG makes their SSL VPN users white-list the site instantiating the ActiveX upon first use. Seems like the best solution I've seen so far...
further reading: <a href="http://blog.phishme.com/2008/05/owning-the-mobile-workforce-blackhat-2008/" rel="nofollow">http://blog.phishme.com/2008/05/owning-the-mobile-workforce-blackhat-2008/</a>.
-schmoilito
A command is being executed based on tainted data (data from a file who's name is attacker controlled). There is nothing particularly special here that would stop static analysis from finding it. The challenge for static analysis would not be to find this bug, but to weed out false positives related to sanitisation of your tainted data, which is the problem static analysis faces for all bug classes that are considered identifiable by static anlysis.
I confess to not following the latest techniques in static analysis and so will likely have missed something. The point Haroon was making is that proof of exploitability for this bug would be hard to produce for static analysis rather than whether any single contributing factor could be identified. There are three contributing features/bugs that makeup the exploit:
1. Arbitrary download to a predictable location
2. Instantiation with an attacker-specified .ini
3. Uninstall feature in .ini
Static analysis should (would?) discover at least 3, and possibly 2 or even 1, however piecing them together to prove remote code exec seems unlikely. If the above are flagged then, as you point out, there is a good chance they're flagged as low or get lost in the noise as, for example, issue 2 is a pure feature and any check that flags this would also flag every other input point into the control.
However, as mentioned, static analysis is not my strong point. What would you consider to be the state of the art in terms of static analysis, so we can test this?
a) SMB means we always have files at predictable locations on a user's machine - you have be abel to specify the full path, but this is often possible
b) The browser environment has tonnes of ways to drop files at predictable locations
So being able to control files at predictable locations should be in your attack model even without a vulnerability in the specific control.
.: static analysis does not need to find issue #1
In my mind, Issues 2 and 3 are not the actual bugs, the existance of an uninstall feature is not the bug (but could be a DoS bug that static analysis cannot find), the real bug is that you can control the data in a call to system() or similar.
However, I don't know anything about the product space for static analysis, I can simply see that this bug doesn't hit any of the real limitations of static analysis.
A simple thought exercise is, could you write an algorithm that identified a bug in some code like this:
a=open(user data)
b=read(a, some location, some length)
system(b)
And I think your answer would be an easy yes. And that pseudocode snippet is the essence of the bug.
Of course the real bug might not be found by static analysis due to there being other issues that static analysis cannot really grapple with well atm (eg self modifying code, lol), but I just wanted to say that theoretically the bug in this post is not outside the realm of what static analysis can find
While it is reasonable for a static analyser to assume that files can be predictably placed when considering a generic attack model, having this "feature" as part of the exploit undeniably raises the immediacy of the exploit. But I take your point about introducing assumptions into the attack model. Of course, this implies that any application that calls execv(/some/path) is also flagged (consider a standalone client or some ActiveX control that launch apps). At this point one might reply with "file dropping is a specific issue in browsers and hence ActiveX, and can be ignored for standalone apps", but suddenly the attack model isn't so clear and we'd need to provide hints to the static analyser. And hints suggest the process is not so straightforward.
Agreed, issues 2 and 3 aren't strict bugs which is why I refer to "features/bugs". However they are needed for the full exploit to work, and therein lies the difficulty for static analysis since they're not clear faults in the application. Consider the sample code in your thought exercise. "user data" could refer not only to file contents, but registry entries, DOM elements (since we have to include XSS in our attack models due to its prevalence) or RPC calls (mitm is an ever present threat). At the same time, system() is not the only dangerous call we need to protect against. Unfortunately my static analysis knowledge falls down here and I can't estimate the number of calls considered dangerous, however I'm going to assume it's a bunch. The Cartesian product of multiple srcs of user input and unsafe functions means many many potential findings. Lot's of user-originated data winds up in unsafe calls; the trick is determining whether it's been sanitised and that's non-trivial for static analysis. If you assume all data is unsanitised, then you get flooded with false positives and the actual issues get lost in the noise. The theory of taint analysis is simple, but its implementation is devilishly difficult.
Returning to the exploit above, I have no doubt that an analyser could be written that looks for this specific issue. However, like many algorithms, the problem is in generalising and not optimising on individual cases too early. Static analysis should detect the above issue in such a way that it's useful; I'd argue that flagging the issue in a sea of false positives is equivalent to a false negative, from a user's perspective.
(I'm hoping Haroon will drop into the discussion shortly, he's aware of it and can provide more insight)
I agree that theoretically the bug is findable, if we agree that theoretically all bugs are findable.
kuza55 said:
> However, I don't know anything about the product space for static analysis, I can simply see that this bug doesn't hit any of the real limitations of static analysis.
I think a fundamental limit of static analysis has been identified in previous posts: If we manage to generalize a check for some issues, we drown in false positives.
For taint tracking to have a chance, the dev/tester will need a good understanding of what truly is tainted to begin with. In this case, i always got the feeling that they never considered we would be able to pass it a controlled ini to begin with. (i certainly dont think they thought it could be done remotely)
Having said all of this, i guess the topic would have been better written as "bugs your static analyzer are unlikely to find" instead of "bugs your static analyzer will never find"
/mh