Monday, October 3, 2011

'confused deputy' persistence mechanism: binary planting

so this is not a new idea really, but mb worth a little thought/exploration...

most of the recent-ish binary planting research seemed to focus on remote code execution attacks. but sometimes you don't need remote root.

some ppl say this attack is old news and lame, but then other people say 'whatever lands me shell'... binary planting came up in the adaptive pentest talk at DerbyCon, and maybe even Mitnick is using it (as also mentioned in a Derby talk). so whether or not you think it is lame, it appears ppl are using it.

a few weeks back i was digging around w/ binary planting in terms of priv escalation (which coincidentally got kicked around on FD recently)...

if you don't need CWD to win, then the set of potential DLL load attempts changes a bit. lots of apps run on boxen out in the world run w/ elevated privs, so maybe there's something to leverage there. specifically pretty much any DLL load attempt that doesn't find a target could be interesting. but even back on XP the default file perms and the landing place of most DLL loads limits the attack surface available to a non-admin user. so i kinda walked away from priv escalation w/o much success.

but maybe you've got root on a box. now you want your code to persist and exec through reboots. being tricky and hiding can be nifty, but hiding in plain sight can work too. home users don't pay a bunch of attention or have a ton of knowledge, and big environments are often resource constrained and no where near tracking detailed state on their endpoints (integrity checking, etc).

when you're digging for someone hiding under those conditions, sometimes you want to check machines for ways they automatically exec arbitrary code. so you dig through the registry and some folders, and look at core system files... and, well, it's kinda a lot of work...

so after i re-read some of Nick Harbour's thoughts on the issue, i think he already covered this pretty well, and really alluded to the potential magnitude and complexity of this situation...

but i guess i'll add a couple thoughts. first off, Nick seems to mostly consider the issue within the OS realm, but in IRL situations deployed apps give a much larger potential surface. and like the Acros peeps point out in some of their research, there are a number of DLL loads which are pure misses (ie: the DLL doesn't reside on the system, but the system is running fine). if you're search-order hijacking a core system DLL, an investigator can hone in on duplicate DLLs, or maybe where a stub is calling the other DLL to maintain required system functionality.

but a casual review on win7 and winXP found a number of 3rd party apps that miss on calls to non-existant DLLs during normal operation. if you're hiding on a box which is regularly used by a user, there are plenty of opportunities to maintain persistence (often) without going anywhere near System32, because the apps used by the user or loaded by system administrators will happily exec correctly named files in the right location (hence the confused deputy). since the system runs fine without the DLLs in the first place, it seems like lots of these apps produce no error messages or other obvious evidence when they call a DLL which doesn't do what it was hoping for... since it's DLL hell already, one wonders how much solid version and checksum information is really available...?

and to loop right back to the privilege escalation issue... in a more modern OS where privilege escalation isn't as easily accomplished, getting your code through a user-initiated MS Office load might get you a non-admin shell where a given priv escalation technique fails. but when exploiting a missed load from a modern commercial AV product and getting a non-admin shell, the same priv esc technique pulls root...? kinda want to research that more... the "Anti-Virus" product remained blissfully unaware that it had been co-opted and was now the persistence mechanism which maintained a compromised state on the victim machine... sloppy DLL loads and no tracking of it's own integrity... go figure.

not every DLL miss is a gem, but the attack surface seems pretty broad after some quick digging... browsers, media viewers, security/privacy apps, productivity apps, backup apps, etc...

the advantage to the attacker here is that the attack surface is broad and murky. app DLLs are generally not as well documented as OS components. there are more versions and less info.

plus if you change the way you look at it, maybe you don't need the code to exec on boot. if the code execs when the user performs an action, or once a week when a scan is run, the end result for the attacker is the same but now the defender has a whole lot more to look for. this isn't really a 'universal' attack method, b/c it is dependant on the app deployment posture of the environment being attacked, but even that becomes an attacker advantage b/c they aren't hiding the same place everytime. and then on the flip-side, in a given org maybe the vulnerable app is widely deployed.

anywho, check it out and see what you think :)

No comments: