LUA+SRP limitations
3 posters
Page 1 of 1
LUA+SRP limitations
It is my current understanding that the only way to bypass LUA+SRP is for a pre-existing executable or program (that is already allowed to run) that also has access to the WIN32 API, to then be controlled to call WriteProcessMemory and thereby disable SRP for that running process. Things like Office Macros and such. What about CreateRestrictedToken, does it work the same way? Something must be pre-existing for a call to that function?
A list of applications that are easy to control:
Office
Adobe Reader
Adobe Flash player
Java Runtime
Given the recent mysql.com exploit ... I'm nervous about how to protect my system. I thought SRP was bullet proof, I mean if you can't execute something outside of Program Files and a LUA account can't write there it must be perfect no? Why has Microsoft disabled SRP effectiveness or am I incorrect in my assumptions?
If I visit a malicious website, all that website has to do is tell the Flash Plugin to WriteProcessMemory and it's game over?
A list of applications that are easy to control:
Office
Adobe Reader
Adobe Flash player
Java Runtime
Given the recent mysql.com exploit ... I'm nervous about how to protect my system. I thought SRP was bullet proof, I mean if you can't execute something outside of Program Files and a LUA account can't write there it must be perfect no? Why has Microsoft disabled SRP effectiveness or am I incorrect in my assumptions?
If I visit a malicious website, all that website has to do is tell the Flash Plugin to WriteProcessMemory and it's game over?
pcunite- New Member
- Posts : 4
Join date : 2010-12-13
Re: LUA+SRP limitations
Also it seems that hotfix KB370118 will address some of this.
pcunite- New Member
- Posts : 4
Join date : 2010-12-13
Re: LUA+SRP limitations
Sorry to keep asking questions ... but what if I programmatically create a white list of programs that were allowed to run and forge the whole PATH concept. This way, when a shell code exploited process occurs in the future and thus makes a new .exe somewhere, that .exe could not run. Also my username is running as a limited account so it could not grant itself additional permissions. But then again if it only needs to WriteProcessMemory it does not matter?
pcunite- New Member
- Posts : 4
Join date : 2010-12-13
Re: LUA+SRP limitations
No worries with asking questions. Unfortunately, I'm not sure if you'll get many answers on this forum! Too technical for me anyway.
All I know is that SRP certainly is not "100%" and can also be "bypassed" if executable code is made to run in memory.
All I know is that SRP certainly is not "100%" and can also be "bypassed" if executable code is made to run in memory.
Re: LUA+SRP limitations
It seems KB370118 was just an internal fix number. It has just been released as KB2532445 at http://support.microsoft.com/kb/2532445. The hotfix is available upon request (see link at top of the article).
RichieB- New Member
- Posts : 7
Join date : 2011-02-01
Re: LUA+SRP limitations
No, the hotfix is for Windows 7 and 2008 only.
RichieB- New Member
- Posts : 7
Join date : 2011-02-01
Re: LUA+SRP limitations
AppLocker only exists on Windows 7 Ultimate (and Enterprise I think). SRP can be applied on Windows 7 Professional and Ultimate. So I think my question remains unanswered.
Anyway, I've played enough with both SRP and AppLocker to know that they are not hard to bypass if specifically targeted (like with most things). However, it's good that Microsoft have recognised one of the "vulnerabilities" and are "fixing" it.
Anyway, I've played enough with both SRP and AppLocker to know that they are not hard to bypass if specifically targeted (like with most things). However, it's good that Microsoft have recognised one of the "vulnerabilities" and are "fixing" it.
Re: LUA+SRP limitations
Sorry, I forgot about SRP on Win7. This patch limits the use of the SANDBOX_INERT and LOAD_IGNORE_CODE_AUTHZ_LEVEL flags to their valid uses. IIRC that is during software install like DLLs executed from a temporary location while installing an msi. So the answer to your question should be yes, but please test it.
If you know of any ways to bypass AppLocker rules after this hotfix has been installed, please share the details. MS argues in memory execution is not really a bypass, since AppLocker only limits the loading of code from a file system.
If you know of any ways to bypass AppLocker rules after this hotfix has been installed, please share the details. MS argues in memory execution is not really a bypass, since AppLocker only limits the loading of code from a file system.
RichieB- New Member
- Posts : 7
Join date : 2011-02-01
Re: LUA+SRP limitations
Thanks for the information. Yes, would be good if someone could test these things after applying the fix.
It's arguable that memory execution is not a "bypass". The way I see it, SRP/AppLocker is supposed to (or should) block all unwanted execution. Anyway, that's besides the point.
Regardless, any privilege escalation exploit will bypass SRP/AppLocker in practical scenarios. Of course, the reality is that SRP/AppLocker is highly unlikely to be bypassed in-the-wild.
It's arguable that memory execution is not a "bypass". The way I see it, SRP/AppLocker is supposed to (or should) block all unwanted execution. Anyway, that's besides the point.
Regardless, any privilege escalation exploit will bypass SRP/AppLocker in practical scenarios. Of course, the reality is that SRP/AppLocker is highly unlikely to be bypassed in-the-wild.
Re: LUA+SRP limitations
Awesome, thanks MS ... now can we get the fix in a general way or do each of us have to ask?
pcunite- New Member
- Posts : 4
Join date : 2010-12-13
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|