Circumventing SRP and AppLocker by design, with SANDBOX_INERT -> new process

Could this be related? http://twitter.com/msftsecresponse/statuses/30429733023907840

 

I wrote it myself. It was very easy considering I didn't know much VB before I started today. Of course all the credit goes to Didier, I just put the pieces together. POC is at http://www.mountknowledge.nl/2011/0...-applocker-using-vb-script-in-word-and-excel/

 

https://www.wilderssecurity.com/showthread.php?t=291886

Nice!

 

Didier,

Basically, can you confirm that a downloaded program using this "feature" (SANDBOX_INERT) will not be able to execute?

It needs to be executed from inside an already existing and running process. And it can only run within the context of the user (standard or admin - let's not talk of priviledge excalation). I understand that it makes your "office" shellcodes easier but doesn't create a new field of exploits.

Did I understand right?

 

@Lucy: for a downloaded program to bypass the AppLocker restrictions it needs to be started by an already whitelisted application using the SANDBOX_INERT flag. This could be Word or Excel using the VB code I published.

 

Thank you! Please keep us posted if/when you hear back from Microsoft.

 

Correct.

 

Thank you for this short, yet concise answer.

So I conclude that AppLoker, or srp? is a wonderful tool to stop drive-by downloads, is very efficient to enforce a company (or admin) IT policy.

But it is very weak in doing its job when it comes to patrol documents which have script or program-like capabilities. It means that a company (or an admin) which would rely on this tool for security purposes would need as well to have a document policy to avoid untrusted / alien documents (office, PDF...) to be read, or at least that the supported script features should be inactivated or activated for only signed scripts whenever possible. This can be powerful but is certainly difficult to follow up.

Anyway, this seems that such scenarri would be seen only in targetted attacks, instead of wide-spread contaminations.

 

No the VBA code is now available, any organisation having Office installed (practically everyone, except high secure systems) and using Applocker or SRP to enforce software policies needs to look into it. This is very serious.
What's probably limited to targeted attacks is shellcode using these functions.

 

Right.

I can't believe we will see much of it anyway, provided the huge number of people even in Wilders (supposedly security-aware) who run as admin their computers, while shutting down UAC for a so-called "ease of use".