SRP easily bypassed :(

I've been running my XP system under a LUA with SRP for a while now, feeling nice and confident that nothing could run that hadn't been installed with my admin account.

Well it seems that was a false sense of security. You can completely bypass SRP with no password or anything.
If you have an executable that can't execute where it is because of SRP, simply using "runas /trustlevel:"Unrestricted"" will allow it to run. For example:

Code:

C:\Documents and Settings\crisp>c:\program.exe
The system cannot execute the specified program.

C:\Documents and Settings\crisp>runas /trustlevel:"Unrestricted" c:\program.exe

and up the program will come. You still have the protection of your LUA though so I guess thats something.
I even tried disabling the Secondary Login service, but just changing your trust level doesn't require that service and so it continues to work.

So do I need a fully fledged HIPS to achieve what I thought I had with SRP? I guess specifically blacklisting the runas program might work too.

 

Yeah, runas.exe does allow that mostly unknown trick. If you want to block it, the solution is quite simple: create rules that disallow runas.exe, and it can no longer be used to change trustlevel.

Still, nothing is perfect, and that applies to SRP, as well. But it's a pretty nice measure to take, and costs nothing.

 

Yeah, like wildchild said, it's nothing to worry about. You can easily add a disallow rule and the problem is solved. In fact, I had the following already blocked by SRP :

• cscript.exe
• wscript.exe
• command.com
• cmd.exe
• regedit.exe
• format.com
• runas.exe

 

Rename runas.exe also is simple solution.

Sul.

 

Its good to know it can be blocked; are there any other windows programs that work similar to runas that also need to be blocked?

It would be good if this was more widely known about though, seeing as not specifically adding a block rule for runas results in your SRP being easily bypassable. I can hardly find any mention of it anywhere, not even in the recommended srp guides like http://www.mechbgon.com/srp/

 

Easily bypassable, if they know about it. And a lot of people do not.

But, as far as I know, there isn't anything else that can be used to change trustlevel to bypass SRP. There are, though, other ways that might work to bypass SRP. Those range from simple things like checking to see if the limited user can write anywhere in "Unrestricted" paths (in XP, for example, Windows\Temp can be written to and one can then launch programs from there in spite of SRP, since the default rule allows everything in the Windows folder and subfolders) to more complex attack that require actually coding something.

 

I read this: http://blog.didierstevens.com/2008/06/05/bpmtk-how-about-srp-whitelists/

It appears that you can bypass SRP without using Runas. The depressing thing about that link is it shows running an executable from within a VBA script as the example. So it seems there's no way of relying on SRP to protect you from unknown executables being run. Bummer.

I'll have to look at some of the anti executables software that's recommended on these forums, like trust-no-exe or anti-executable.

 

If you read that article, you'll find that it assumes that SRP is set to apply only to EXE files, not DLL libraries as well. If you apply SRP to all executable files, including libraries, then this method is no longer possible - it doesn't work.

People, try to read carefully when you read something. Otherwise, there's no point in reading.

Now, like I said, there are still other ways SRP might be bypassed. For example: http://blog.didierstevens.com/2008/06/25/bpmtk-bypassing-srp-with-dll-restrictions/ Note that this method requires you to run an untrusted Office macro. Don't run untrusted macros. Problem solved. Nothing is perfect. But in real life, SRP works very well to protect you from unknown executables running. You can choose to use third party execution prevention products if you want, but they have their own problems.

 

It's a local bypass and requires that you:

1) how to run that command
2) actually run the command

So, it's really nothing to worry about unless you have untrusted local users, but then, someone with local access ... game over.

Mrk