Hot Knives Through Butter: Bypassing File-based Sandboxes

From http://www.fireeye.com/blog/technic...gh-butter-bypassing-file-based-sandboxes.html:

Paper (direct pdf): hxxp://www.fireeye.com/resources/pdfs/fireeye-hot-knives-through-butter.pdf

 

You know what this reminds me of?: https://www.wilderssecurity.com/showthread.php?t=350960

But I predict a much shorter thread, since some specific programs weren't mentioned.

 

From http://www.itpro.co.uk/malware/20718/tricks-malware-trade:

 

MrBrian I agree with this quoted statement. Sandboxes are not bulletproof but they can be used as additional (and very effective) security layer.

hqsec

 

This is about evading detection in malware analysis sandboxes, not breaking out of mandatory access control. Though some of the techniques might be applicable in the latter situation.

 

Anyone notice this?

It begs the question, how many undocumented API functions are there, including ones we don't know about and are not monitored by any security apps?

 

Finding undocumented APIs in Windows

 

There are tons. One more reason why HIPS on Windows sucks.

 

Seems to be that such APIs would be able to bypass or compromise all security apps on Windows, not just HIPS. You can't expect a sandbox to contain system calls it doesn't know exist.

 

HIPS and policy sandbox are basically the same thing on a software level... So, yes.

That said I'd be surprised if many HIPS/sandboxes did not cover at least some of the undocumented API functions. Undocumented doesn't mean invisible; you can see them in Dependency Walker for instance.

Also, some of them may be wrappers for more primitive functions, which could be intercepted.

Edit: IOW the situation may not be quite as grim as it sounds. But I would not bet on that.

 

What GJ said.

 

The problem here is just how much there is to look through. Compared to the old system I use, a new version of Windows is 30 to 50 times larger. That's a lot of files to search. I'd also wonder how many of them can bypass Windows built in security as easily as they'd bypass 3rd party software. Just finding and trying all of them with the all the possible parameters would be a career in itself.

 

A standard user account is considered a security boundary by Microsoft. Microsoft fixes bypasses of security boundaries when they're found.

UAC is not considered a security boundary by Microsoft.

 

I'm thinking in terms of undocumented APIs that work like LoadLibraryEx did.

 

In related news, I'll be setting up a Windows 7 VM today for some legacy software, so I figure I'll take a screenshot of Dependency Walker pointed at the kernel.

For comparison, current(ish) Linux kernels a little short of 500 system calls, all of which are documented in the 'syscalls' man page.

 

Can someone give me a legitimate reason why such an API would exist on a system and not be documented? Something besides a deliberate vulnerability.

 

We're talking mostly about kernel APIs, which are just a few DLLs.

You have a good point though. Especially about the parameters, which most Windows system calls take a lot of.

Huh? You mean undocumented API functions? IIRC there is only one undocumented API (the native API). Not sure though.

You mean UAC limitation of admin accounts? Isn't that the same mechanism as for limited accounts, just with different default settings?

 

Yes, and no, respectively. See http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx.

 

I'm not referring to this API in particular. I'm referring to its ability to bypass Applocker and Software Restriction Policies by design. I wonder how many of the undocumented APIs can also do this? Also consider that these can be changed with each patch or update.

And subsystems with direct or near direct access to the kernel. The graphics system also comes to mind.

 

Yes: backwards compatibility. Also, lack of forethought.

Basically the Windows API has two layers, as I understand it: the Win32 API, and the native API. Both are exported to userspace, and can be used by userspace programs. But the Win32 API functions are mostly just wrappers around the native API functions. Third-party developers are encouraged to use the Win32 API and never the native one. The idea from what I've heard is that the native API is for Microsoft to use in their own software, and may change unpredictably. The Win32 API on the other hand does not change very much. Stuff is added to it at times, but rarely removed. (This is why you have functions named BlahBlahBlah, BlahBlahBlahA, BlahBlahBlahEx, etc.)

There is a reason that encapsulation is such a huge deal in programming. One should not export functions that other people aren't supposed to use... And IMO Microsoft did exactly that with the native API. And now app developers use it because it's cool, malware developers use it because it works, and security professionals use it because they have to. So it is here to stay, at least for a while.

(And that is probably the reason behind WinRT in Windows 8. Sometimes it's best to make a fresh start.)

 

I think I'm not understanding something here. Undocumented APIs, not API functions? APIs, plural?

Right, IIRC that is part of the Win32 API. Not sure what native API functions if any would be involved there.

 

I don't understand this as well as I'd like to. I'm probably using the wrong terms. I just have to wonder how many more bypasses there are like that, documented or otherwise.

 

See pp. 159-161 at http://books.google.com/books?id=FQC8EPYy834C&printsec=frontcover#v=onepage&q&f=false.

 

Oh hey I have a copy of that book! I'd put it down around page 108, hoping to get back to it at some point when I have the time. Thanks.

Anyway, it looks like all the undocumented stuff is very low-level (no wrappers) and should really not have been exposed.

 

The best thing is not to download anything such, and then it's ok.
Mrk