Bypassing SRP

Here's a video I just made showing an Excel Macro disabling/bypassing SRP in a Limited User Account. I've also demonstrated some other information in the video:

Hello SSJ,

I'm on Dial-up right now, so can't watch the video. Does it also bypass AppLocker? If not, could it do that in theory?

Sadeghi85 wrote:Hello SSJ,

I'm on Dial-up right now, so can't watch the video. Does it also bypass AppLocker? If not, could it do that in theory?

Hey mate. I asked Didier Stevens the same question. He basically said that AppLocker is different because it works at the kernel level. As a Limited User, you don't have access to the kernel. Therefore, you would need to use a Privilege Escalation Exploit.

And we all should know by now that if a Privilege Escalation Exploit was able to be carried out, it would bypass SRP/AppLocker without any need of a separate POC such as this. So essentially, AppLocker is more secure than SRP because it operates at the kernel level. As far as I know, AppLocker has still not been bypassed by a POC/malware to this date.

EDIT: although keep in mind that the only genuine SRP bypass became publically available after about 7 years (Windows XP was released around 2001, and this Excel Macro was publically released around 2008). Windows 7 is only about 1-2 years old.

Thanks.

ssj100 wrote:Here's a video I just made showing an Excel Macro disabling/bypassing SRP in a Limited User Account. I've also demonstrated some other information in the video

I must assume you did this in admin mode? As far a I know, a limited user is not supposed to have write access to the VBA Trusted objects.
As soon as you start trusting macros, you're toast because that's how the 'Trusted Computing' principle works; you effectively take away a means for the system to protect itself. I think that even most HIPS programs will fail on this test, because loading a library and mapping a temporary file into memory is expected behavior.

Paul

p2u wrote:

ssj100 wrote:Here's a video I just made showing an Excel Macro disabling/bypassing SRP in a Limited User Account. I've also demonstrated some other information in the video

I must assume you did this in admin mode? As far a I know, a limited user is not supposed to have write access to the VBA Trusted objects.
As soon as you start trusting macros, you're toast because that's how the 'Trusted Computing' principle works; you effectively take away a means for the system to protect itself. I think that even most HIPS programs will fail on this test, because loading a library and mapping a temporary file into memory is expected behavior.

Paul

No, as I stated in the video, I'm using a Limited User Account. If you go to the youtube site to view the video, you'll note this reference:
http://blog.didierstevens.com/2008/06/25/bpmtk-bypassing-srp-with-dll-restrictions/

I'm not a programmer or computer whizz of any kind, so I don't really understand how it's exactly done. But perhaps you can enlighten us? All I know is that SRP is disabled with this Macro, even as a Limited User (on Windows XP Professional).

ssj100 wrote:No, as I stated in the video, I'm using a Limited User Account.

Sorry, missed that. It's early morning here and I haven't had coffee yet.
What version of Office is that? 2003? As I said, limited users should NOT be able to change the Trusted object policies. I believe the key is:
HKCU\Software\Microsoft\VBA\Trusted
Block write access and try again.

Paul

p2u wrote:

ssj100 wrote:No, as I stated in the video, I'm using a Limited User Account.

Sorry, missed that. It's early morning here and I haven't had coffee yet.
What version of Office is that? 2003? As I said, limited users should NOT be able to change the Trusted object policies. I believe the key is:
HKCU\Software\Microsoft\VBA\Trusted
Block write access and try again.

Paul

Yes, version 2003. Well, this is a default LUA + SRP installation of Windows XP. It is bypassed by this Excel Macro if you enable Macros. If you watched the video, you'd see that I had to reduce the default Macro security level to allow this bypass. I was able to do that as a Limited User. Obviously, there must be ways to prevent this. But that's not really the point of the video.

By the way, here's another good link:
http://hype-free.blogspot.com/2008/10/limitations-of-software-restriction.html

Conclusions about SRP:

Software Restrictions Policies provide a much lower assurance than I previously assumed. They can be easily bypassed by users, even with the lowest privilege level.

The bypass can be performed directly from x86 code (for example by exploiting a running process and executing shellcode in it) or from scripting languages which offer access to the Win32 API (such as the MS Office macros).

However SRP still provides a strong protection against non-targeted attacks. This is because 99.9999% of the attackers aren't expecting for it to be activated or necessarily know how to circumvent it. This is security by diversity. It is not 100% conceptually correct, however in practice it works very good.

p2u wrote:I believe the key is:
HKCU\Software\Microsoft\VBA\Trusted
Block write access and try again.

Paul

Out of curiosity, what exactly are the steps to achieve this? Thanks.

ssj100 wrote:I was able to do that as a Limited User. Obviously, there must be ways to prevent this. But that's not really the point of the video.

For me the point of the video is, that there are millions of override parameters in the registry for Trusted objects. How else are the 'authorities' going to launch a key logger on your computer if you have SRP on? (Joke, but not a very funny one, I agree). I mean: how sick do you have to be to create keys like NeverShowExt to hide certain executable extensions? That trick (also a bypass) works until now and for some unclear reason MS still applies it. Maybe now you can imagine that I have removed/disabled so much from MS and all its 'Trusted' partners? Not paranoia, but simple common sense. In a corporate evironment this should NEVER happen and the responsible system administrator should be fired right away.

I can imagine that this override may affect only the exe in that same folder or the current directory (remember binary planting), but not "disable" SRP system-wide. Did you check that?

In order to prevent this from happening, I think you should go into your admin account, find your limited user SID and locate the :
(HKCU)\Software\Microsoft\VBA\Trusted
key for it. Open the permissions and set 'Deny' for write access.

Paul

p2u wrote:For me the point of the video is, that there are millions of override parameters in the registry for Trusted objects. How else are the 'authorities' going to launch a key logger on your computer if you have SRP on? (Joke, but not a very funny one, I agree). I mean: how sick do you have to be to create keys like NeverShowExt to hide certain executable extensions? That trick (also a bypass) works until now and for some unclear reason MS still applies it. Maybe now you can imagine that I have removed/disabled so much from MS and all its 'Trusted' partners? Not paranoia, but simple common sense. In a corporate evironment this should NEVER happen and the responsible system administrator should be fired right away.

You make completely valid points, but again, it isn't really what my video is about (although sure, you can interpret it however you like haha). Also, a corporate environment is completely different to a home user's PC (which is my target audience). In saying that, I feel privileged to have someone like you here who is an expert in the corporate environment (as well as the home environment).

I think 99.99% of home users will not have tweaked their Windows systems as much as you have. I think for most home users who apply LUA + SRP, they simply follow this guide here:
http://mechbgon.com/srp/
And now to the main point of this video - if you applied LUA + SRP as that guide explains, Didier Stevens' Excel Macro can bypass it if you allow Macros to run, and who knows, perhaps some home users allow Macros to run by default because they use/need it frequently? I suppose in this case, it comes down to the balance between usability/convenience and security (and Sandboxie fits in perfectly there!).

p2u wrote:I can imagine that this override may affect only the exe in that same folder or the current directory (remember binary planting), but not "disable" SRP system-wide. Did you check that?

Yes, you are right. But that won't stop a targeted attack from succeeding.

p2u wrote:In order to prevent this from happening, I think you should go into your admin account, find your limited user SID and locate the :
(HKCU)\Software\Microsoft\VBA\Trusted
key for it. Open the permissions and set 'Deny' for write access.

Paul

Thanks, I'll try that out and post back. I personally won't use it, but others may be interested.

ssj100 wrote:[You make completely valid points, but again, it isn't really what my video is about

I know what point you like to make. Sandboxie *IS* excellent protection, but I always like to make reservations for programs that protect "too well". With time they are either:
forced to change their policies (AE3, for example, which used to block dlls [version 2], but for some strange reason doesn't do that anymore)
OR
are bought out (Sygate Firewall, Kerio Firewall)
OR
may be blacklisted in the future (in repressive countries, for example, where it would just hamper the authorities in doing their thing)
OR
may become 'untrusted' in certain competitors' cloud-based reputation systems, for example.
That's why understanding the root of the problem is indispensible.

Paul

Actually, Sandboxie being good was more of a side point. The point is a simple one (I just couldn't help throwing in the power of Sandboxie before haha) and is simply that LUA + SRP can be completely bypassed in the right circumstances and there is currently no direct workaround for it. Disabling Macros (or preventing them from being enabled) is NOT a direct workaround (not to me anyway).

Of course, the direct workaround would be to use AppLocker, which functions at the kernel level (as opposed to user space). However, there's no "AppLocker" on Windows XP/Vista/non-ultimate/enterprise versions of 7.

And with regards to the implication of Sandboxie being too good to be true, well, I can't argue with that one haha - I often get that feeling myself! However, Sandboxie has been around since 2004, and development doesn't appear to be stopping. It will eventually, but then why worry about that now? Fact is, Sandboxie is still going strong (probably stronger than ever). There are many possibilities in life - tzuk could fall ill or simply disappear (look at what happened to "Tony" and Shadow Defender) - I personally feel that this is more likely than what you've suggested above. But other possibilities such as Windows 8 may also arise...and then what?

I think in every age, there will always be good "security software" - if you look hard enough, you will find the best one for yourself.

However, at the end of the day, I completely agree that understanding the root of the problem is good advice.

p2u wrote:In order to prevent this from happening, I think you should go into your admin account, find your limited user SID and locate the :
(HKCU)\Software\Microsoft\VBA\Trusted
key for it. Open the permissions and set 'Deny' for write access.

Paul

By the way, I can't seem to get that to work:



Even when I tried denying everything, I found I could still change the Macro security level in my Limited User Account. Any ideas?

ssj100 wrote:LUA + SRP can be completely bypassed in the right circumstances and there is currently no direct workaround for it.

I would like to modify that statement a bit: the uneducated user may be lured into doing things he doesn't understand the consequences of. If he/she ads this Macro to the Trusted Group in DefenseWall or KIS, the result will probably be the same, won' it?

ssj100 wrote:Disabling Macros (or preventing them from being enabled) is NOT a direct workaround (not to me anyway).

Disabling Macros is not exactly what I suggested. I suggest denying limited users adding UNSIGNED macros into the Trusted Macros group. If he/she can't do that, the exploit will fail, which you actually proved yourself.

Paul

p2u wrote:

ssj100 wrote:LUA + SRP can be completely bypassed in the right circumstances and there is currently no direct workaround for it.

I would like to modify that statement a bit: the uneducated user may be lured into doing things he doesn't understand the consequences of. If he/she ads this Macro to the Trusted Group in DefenseWall or KIS, the result will probably be the same, won' it?

Keep in mind that it's not just macros we're talking about (not that I completely understand the alternative methods). For example, "cdman83" suggests this:

The bypass can be performed directly from x86 code (for example by exploiting a running process and executing shellcode in it) or from scripting languages which offer access to the Win32 API (such as the MS Office macros).

Office Macros are simply just one specifc example. He goes on to add:

the main point is that any kind of executable code of any privilege level (ie. even limited user) can bypass the SRP. As for limiting the possible exploitation paths - they are quite a few (and these are only the ones which come to mind):

- other applications might have macro capabilities installed which don't have an option to disable it or the option isn't set (relying on non-default settings being set is not a very good method). Example: OpenOffice, CorelDraw, etc

- the same patching is most likely possible from PowerShell (which nowadays gets installed by Windows Update)

- there are a lot of exploits in widely-used third-party products (like Flash, Acrobat Reader, etc) which result in arbitrary code execution

- just these days a new arbitrary code execution vulnerability for some MS ActiveX component has been disclosed

My point is: there are numerous ways to get executable code on your system, and it is very hard to guarantee that none of those apply to your environment (unless you run Linux :-p).

Furthermore, and no disrespect intended, but your example of adding the macro into eg. the "Trusted" group of DefenseWall is not a very good one (although you can argue anything in life). In this case, it's not a DefenseWall bypass at all - you've simply taken it out of DefenseWall's protection zone (anything would "bypass" it in this case, even a simple malicious ".exe" file). However, this Excel Macro directly bypasses SRP if unsigned Macros are allowed to run. And perhaps a home user may have allowed unsigned Macros to run for usability's/convenience's sake.

Also, another reason why your example doesn't quite work is that this Excel Macro is directly disabling SRP (in a Limited User Account). DefenseWall doesn't get disabled (it's probably got good self-protection).

As I've already said, the direct workaround would be to have SRP operating at the kernel level (like AppLocker). If it did, this thread wouldn't exist haha.

p2u wrote:Disabling Macros is not exactly what I suggested. I suggest denying limited users adding UNSIGNED macros into the Trusted Macros group. If he/she can't do that, the exploit will fail, which you actually proved yourself.

Yes, and in the video, I purposefully showed that Macros needed to be enabled because I wanted everyone to understand this point - I mean come on, I use LUA + SRP myself and I get very sensitive when people talk about how it's easily bypassed haha.

ssj100 wrote:My point is: there are numerous ways to get executable code on your system, and it is very hard to guarantee that none of those apply to your environment (unless you run Linux :-p).

That's the same point I was trying to make actually. We differ in our approach, but the outcome is the same. Using ANY security solution assumes a lot, and as we know from Under Siege II ("Dark Territory"): assumption is the mother of all [censored]...
P.S.: Linux is not to safe as it made out to be, but that's a bit out of scope.

ssj100 wrote:In this case, it's not a DefenseWall bypass at all - you've simply taken it out of DefenseWall's protection zone

Same goes for SRP: by changing the principles on which it SRP based, you may modify the protection zone. The problem is, that nobody knows exactly what the principles are, but I guess replacing any standard applications (especially those by MS and 'Trusted partners') with other ones would be good 'security by diversity' until proven otherwise.

ssj100 wrote:Also, another reason why your example doesn't quite work is that this Excel Macro is directly disabling SRP (in a Limited User Account). DefenseWall doesn't get disabled (it's probably got good self-protection).

That's an assumption, which does not necessarily hold. I think this exploit takes your desktop and all its executables out of the protection zone but doesn't hurt SRP in any way.

ssj100 wrote:As I've already said, the direct workaround would be to have SRP operating at the kernel level (like AppLocker). If it did, this thread wouldn't exist haha.

That's an assumption. LockExe or whatever it is called works on the kernel level, but I was able to launch executables from a folder with Cyrillic characters, whereas those same executables were not allowed to run in folders with Latin alphabet.

Paul

p2u wrote:Same goes for SRP: by changing the principles on which it SRP based, you may modify the protection zone. The problem is, that nobody knows exactly what the principles are, but I guess replacing any standard applications (especially those by MS and 'Trusted partners') with other ones would be good 'security by diversity' until proven otherwise.

Haha, if you're going to argue like that, I could also argue that Antivirus software are in fact never "bypassed" because anything not included in their signature databases are "out of their protection zones". And whatever the principles, these issues would be solved by operating SRP at the kernel level (see below).

p2u wrote:That's an assumption, which does not necessarily hold. I think this exploit takes your desktop and all its executables out of the protection zone but doesn't hurt SRP in any way.

Yes, you're probably right there actually. But it doesn't mean I agree that your example is a good one haha.

p2u wrote:That's an assumption. LockExe or whatever it is called works on the kernel level, but I was able to launch executables from a folder with Cyrillic characters, whereas those same executables were not allowed to run in folders with Latin alphabet.

Well, it's not my "assumption" - it's what the guy (Didier Stevens) who created the Excel Macro "bypass" told me haha. Not sure if you caught what I wrote about AppLocker - because it operates at the kernel level, these methods to bypass SRP won't work, as you would then need access to the kernel to patch "advapi32.dll" in order to bypass SRP (and limited users don't have such access).

ssj100 wrote:Not sure if you caught what I wrote about AppLocker - because it operates at the kernel level, these methods to bypass SRP won't work, as you would then need access to the kernel to patch "advapi32.dll" in order to bypass SRP (and limited users don't have such access).

Your idea about Applocker working on the kernel level ASSUMES, that MS wants to protect you any better from this in similar cases. I'm almost sure they won't, since this 'override for trusted'-principle is by design. You may say: "Hey MS, we have a bug here" and they will tell you (kindly if you're lucky): "That's not a bug, Sir; it's a feature".

Paul

p2u wrote:Your idea about Applocker working on the kernel level ASSUMES, that MS wants to protect you any better from this in similar cases. I'm almost sure they won't, since this 'override for trusted'-principle is by design. You may say: "Hey MS, we have a bug here" and they will tell you (kindly if you're lucky): "That's not a bug, Sir; it's a feature".

It seems convenient that Microsoft has released AppLocker which operates at the kernel level and therefore blocks the only known (public) method to "bypass" SRP.

Also remember:

the main point is that any kind of executable code of any privilege level (ie. even limited user) can bypass the SRP

Therefore the 'override for trusted'-principle is flawed from a security point of view. But then perhaps you're arguing that SRP was never really meant for "security", but rather to stop the average "honest" corporate user from "installing and playing World of Warcraft" when he should be working haha.

Regardless, surely you'd have to agree that if SRP operated at the kernel level, it would provide stronger protection from a security point of view? I'm not saying that this Excel Macro demonstrates an SRP "bug", but rather shows that SRP should never have operated from "user space" (from a security point of view). With AppLocker, Microsoft have got it (more) right from a security perspective, regardless of whether they wanted to protect users from similar cases or not.

ssj100 wrote:Regardless, surely you'd have to agree that if SRP operated at the kernel level, it would provide stronger protection from a security point of view?

No, not necessarily if there are structural and/or intended bypass mechanisms planted in the system for whatever reason. An exclusion is an exclusion, whether you are in user land or in the kernel; doesn't make a difference.

P.S.: I think SRP (and Applocker and Parental Controls) were never really meant as security solutions. They are rather tools for implementing Compliance (keeping users from running pirated programs, for example). Too many backdoors in there for real security if you ask me. But SRP *can* be used for security if you know how the system works and practice reasonably safe computing.

Paul

p2u wrote:No, not necessarily if there are structural and/or intended bypass mechanisms planted in the system for whatever reason. An exclusion is an exclusion, whether you are in user land or in the kernel; doesn't make a difference.

I'm really starting to feel that you're simply disagreeing with whatever I say haha. Would you agree that 1+1=2? Not really, depending on which dimension you're in?

Jokes aside (and apologies for such a bad one!), the fact that AppLocker wouldn't be "bypassed" by the Excel Macro (or similar "exploit") already shows that right now, it's more secure from a security point of view. That's what I think anyway. I mean, sure, you can block unsigned Excel Macros from running, but what about the other exploit paths cdman83 suggested? Also, we've heard of Trusted Digital Signatures being leaked - what if a malicious signed Macro was created?

Also, it seems that you're now admitting that SRP is "bypassed", but you're saying that it is intentional - it seems to me that you're assuming that it's intentional?

Let me ask my question another way:
Is AppLocker generally stronger than SRP against zero-day exploits?

p2u wrote:P.S.: I think SRP (and Applocker and Parental Controls) were never really meant as security solutions. They are rather tools for implementing Compliance (keeping users from running pirated programs, for example). Too many backdoors in there for real security if you ask me. But SRP *can* be used for security if you know how the system works and practice reasonably safe computing.

I think you've finally agreed with me on something haha.

By the way, thanks for participating in this thread. It's certainly got me thinking a lot - there's a lot more "Windows Hardening" available that I didn't know about.

Did you manage to find out how to block Limited Users from changing the Macro security level? I still can't figure it out.

ssj100 wrote:I'm really starting to feel that you're simply disagreeing with whatever I say

I'm really sorry if I gave you that impression. For good security, you *have to* assume the worst. I think I will leave it at that since we seem to have communication problems here. Let me recap what I was trying to say:

1) it's bypassing SRP (by disabling another security mechanism), it's not disabling it.
2) it's not the only possible mechanism and it's by design, not necessarily with bad intent (maybe for convenience).

Subject closed on my part and no hard feelings.

Paul

p2u wrote:

ssj100 wrote:I'm really starting to feel that you're simply disagreeing with whatever I say

I'm really sorry if I gave you that impression. For good security, you *have to* assume the worst. I think I will leave it at that since we seem to have communication problems here. Let me recap what I was trying to say:

1) it's bypassing SRP, it's not disabling it.
2) it's not the only possible mechanism and it's by design, not necessarily with bad intent (maybe for convenience).

Subject closed on my part and no hard feelings.

Hey, I've got no hard feelings here either - as I said, I was merely joking mate. I don't like using smiley faces, so perhaps you got the wrong idea (and missed the bad joke).

Yes, completely agree with assuming the worse - that's what I did for most of 2009 before I finally settled with my Sandboxie + LUA + SRP combination.

Also, I don't think we've really been completely disagreeing with each other - we're just wording things differently at times. I do understand your arguments and I feel they are correct from certain perspectives. I think essentially you're saying that SRP doesn't cover Office Macros, so it's not unexpected that it can be "bypassed" by one. However, it doesn't excuse it from not operating at the kernel level to prevent the exploit paths "cdman83" suggested (see here I'm assuming the worse too haha).

I suppose the question is if Microsoft "could go back to the start" (and had already developed AppLocker), would they have released AppLocker instead of SRP (eg. on Windows XP)? From my readings, I don't see Microsoft admitting that AppLocker is stronger than SRP security-wise, but I see respected and highly knowledgeable people like Didier Stevens strongly implying that it is. I suppose I was expecting you to say the same, and I still don't quite understand why you have not done so (hence why I keep posting haha).

Surely any security software/mechanism operating from the kernel is more secure than operating from user space (note I'm not saying that if it operated from the kernel, it would be 100% bullet-proof. I'm talking relatively here)? I mean, why do software like Sandboxie, DefenseWall, Malware Defender, Online Armor etc all hook into the kernel? Why does tzuk admit that "the 64-bit edition of Sandboxie provides a reduced level of protection compared to the 32-bit edition of Sandboxie"?

Sure, Microsoft may not have intended AppLocker to operate at kernel level specifically to prevent a malicious Office macro bypassing it, but lo and behold it does! Didier Stevens claims that AppLocker can't be bypassed from a Limited User Account without a Privilege Escalation Exploit, while SRP can be bypassed.

Finally, to drive home my point, what if the video I showed used a "arbitrary code execution vulnerability for some MS ActiveX component" which was able to bypass SRP and execute a malicious file, and then I posted another video showing that AppLocker successfully prevented this malicious file from being executed? This situation would have nothing to do with Macro protection or lack of. It would basically show that SRP is bypassed, while AppLocker is not. 1-0 to AppLocker.

Also just to clarify to readers, Limited Users can change the Macro security level by default - you'll need to tweak the Registry Key that p2u suggested - unfortunately, it doesn't seem to work for me. Can anyone work it out?