The strength of SRP as an Anti-Executable

Does anyone know if SRP has been bypassed in default configuration? I'm finding it's probably the best Anti-Executable there is haha - in default mode, it prevents new command prompt (.bat) and scripting executions (eg. wscript.exe) too. I do have to exclude "shortcut executables" (LNK) from the SRP for greater usability/convenience. Could this be the exploitable aspect of it?

SRP seems to be an excellent option for an extra layer of protection for me in administrator mode and with a properly configured Sandboxie - when installing new programs, I'd simply disable SRP and then re-enable it afterwards. This is less inconvenience compared with running a classical HIPS and having to deal with all its associated "house-keeping" chores (and SRP is even lighter than any HIPS, since it's built into Windows).

Of course, in this context, SRP would only be useful in the event of "user error" - for example, I accidentally execute something new on my real system or I forget to open my forced sandboxed folder (which contains newly introduced files) with a sandboxed windows explorer.exe. I suppose SRP would also be useful when connecting to unknown/untrusted LAN networks (and thus I wouldn't have to rely on manually enabling Defense+ or any other classical HIPS).

Also, would SRP prevent malware infestation via opening imbedded malware in .jpg files etc as discussed in this thread (https://www.wilderssecurity.com/showthread.php?t=251875), particularly regarding the .wmf exploit?

Thanks for any comments and insights.

EDIT: one way I can think of SRP being bypassed is if an infected executable file is somehow written into the System Directory or Program Files Directory (that is, areas that SRP doesn't protect), and run from there. Is this realistically possible though in the real world? (and yes, LUA would prevent anything written to those directories, but I'm talking about running as administrator).

 

If you, as an administrator, understand the risk you take, and have the habits/knowledge to steer clear of any issues, SRP can be of use to only demote the rights of specific applications or to simply deny an object or container from any execution. While some POC exploits exist, I have yet to hear of any actual use of them. I personally have not messed with the RunAs exploit that was mentioned here recently, but that would be easy to mend so I don't consider it an issue if it is addressed.

You are correct though, if you run as admin, and you execute anything outside of SRP or SBIE or VM or whatever you method, you are completely wide open to whatever is about to happen. I would certainly advocate LUA for the majority, as this would remedy just such a situation. But there are those of us out there, who even though we know about LUA, cannot or will not use it. We take our own chances.

I have always been admin, for the most part, and have never had an issue. But I know some who should not be admin because they always seem to develop an infestation. SRP in admin mode is not for them. SRP in admin mode is really for someone who understands that it is providing a method to restrict to user the threats they understand and wish to control.

SRP will not help you if you connect to other computers and you are logged in as admin. If you start a program that connects to another computer, then that program will be safe. But if you have open ports or doing netbios, your admin account, especially those without passwords, opens you up to whatever is on the other computers.

One would think if the only used DMR to open windows explorer, they could browse another computer with a demote to user explorer window. However, this does not work. The only way, IMO, you could safely connect to another computer would be to kill explorer.exe and then restart it with DMR. Then your shell will be a user. I wrote a tool awhile ago to do just that. It works well, but honestly is not the best approach I don't believe. I would think just having a LUA account when you connect to foreign computers (like a lan party or dorm) would be the best way to go. Here is where you could use windows FW or IPSec rules to easily get to the router/internet, but still block all other LAN traffic while you used your admin account. Then when you wanted to browse/share files etc, you log into LUA and change your firewall/ipsec rules. You can also simply enable I believe port 139, but close 137 and 138, and you will become psuedo-invisible on the network. I use that a lot too.

SRP is a great tool in admin mode, but I really think people who rely soley on it to provide protection had best understand thier threats and not rely on SRP to be some sort of complete answer, because it is not.

Sul.

 

Interesting topic!

In the past, SpikeyB, tlu, and Lucy have tested exploits for me.

Internet

Trojan downloads in a drive-by exploit and copies itself as svchost.exe and attempts to execute:



USB
Autorun.inf file attempts to run an executable, astro.exe. Screen shot in German, but message similar to the above:



USB
Autorun.inf file starts a MSWord document with an AutoOpen macro that attempts to use rundll32.3xe to load a DLL: (screen shot in French)





USB
Autorun.inf file starts a MSWord document with embedded package exploit that attempts to run a trojan executable with file extension .scr: (screen shot in German)



NOTE that the alerts are Default-Deny.

SpikeyB runs as Administrator.
I'm not sure about the others.

----
rich

 

SRP is not avaliable for xp home only profesional

 

man the pro cost 199.99 at best buy

 

https://www.wilderssecurity.com/showthread.php?t=200772

HTH,

 

Hi, Rich! In all the testing that you or others have done against SRP, was it all in its default configuration and did it prevent everything?

 

The strange thing is Microsoft not enable SRP for all windows versions... with a nice/easy GUI for the normal home user configure the computer will be alot strenghtned and without buy anything. SRP permit deny, reduce rights and block autorun and without consume a bit of RAM/CPU. who not use professional/ultimate have PGS and if i remember right windows steadystate have a option to only allow executables from Windows/Program Files folder.

Windows steadystate can be used to implement something in a LUA+SRP enviroment? the unique option i remember that can be useful is deny right click (so no "Run as...)

 

Probably in truth, you could run lua + srp, alternative browser, limited services run at startup, netBIOS and file sharing disabled, and this would give as close to bullet proof as conceivable - no additional security software needed. Throw in a virtual guest to work from and you've just upgraded to near idiot proof. No need to sandbox the vm either, nor run a sandbox in it. Barring the vm, Sandboxie could be used to run Internet facing apps. I have a machine set up this way. Of course don't overlook the value of an image/restore program.

 

Those are the only tests I've asked them to run.

I think that blocking DLLs is not enabled by default, if I remember correctly from Lucy.

----
rich

 

I also thought it strange, up until a year or so ago when the very informative threads by Sully, tlu, and Lucy came along.

Also, what is "the normal home user?"

From those threads/tutorials, I realized the the normal users I knew about could not easily set up and maintain SRP.

A install-and-forget-Default-Deny solution is still preferable in these cases, IMO. Some of the programs in Stevios's thread are more suited for this group of users.

----
rich

 

Hi wat,

Whats netbios? How can it be exploited? What are its weaknesses? How can I disable it? Thanks.

 

What I would like to know is, can SuRun prevent privilege escalation in LUA? Thanks.

EDIT: Quote removed.

 

Applies if you're running XP or W2k. Explanation is here and one way to disable it is here.

It's not such a big deal if you block these ports with a firewall, but I like to disable it anyways because it's simply not required, so it's one more possible avenue of attack removed.

 

Thanks!

 

Understand, that when you boot as administrator, that some processes get owned by the system, which is its own group. Other processes get owned by the user, who is an admin thus those processes are capable of doing anything. It is these processes that if exploited from another computer, WAN or LAN, that can do the damage because once they are exploited they allow anything to happen.

When you start a process with SAFER, whether from SRP or DMR, the process might be owned by you, the admin, but itself is reduced to users rights. So in this case the process, if exploited, would presumably be capable only of doing things a user could do.

The key here is that when you connect to another computer as an admin, most likely it will be your services or some program running as a server which will be exploitable. These most likely also will not be started via SAFER.

Understand that there is a service or two that let you communicate with other computers in a LAN. Most noteably netbios, but also network connections and computer browser services perform LAN stuff, and if IPSec service is enabled it holds two ports open that should be blocked unless you are doing secure tunneling things like VPN. In the windows firewall, or most any firewall, you can choose to allow the so-called "File and Print Sharing" ports to be allowed. Ports 137,138 and 139 are the ones for netbios AFAIK. So you can, for example, disable ports 137 and 138, and your computer normally will not show as an available node on the network, like your LAN. Open port 138 and it will be visible. But with port 139 open, you can type in a run box RUN> \\192.168.1.X, where X is your computers IP Address, and another computer can open and view your files if you are sharing any. So while you might be considered semi-stealth to most who try to look for you, like if you have a wireless router open to public, only those who have a network scanner or are knowledgeable will find you.

Now consider that you have to have shares open and shared for anyone to look at your shares. There is a service called Server which is responisble for file sharing. I set mine to Manual, not auto. This way, when I boot up, even though I have some directories shared, they are not active until the server service is actually started. If I want another computer in the LAN to be able to access my shares, I use from the run box RUN> SC Start LanManServer, which starts the Server service in about 2 seconds. You can also use RUN> NET Start Server, which starts the service as well, but takes somewhere between 5-8 seconds. Either way, as far as netbios and filesharing goes, these two methods alone will cover your bases in a LAN where a less advanced user is looking for these things.

So yes, with only controlling your services and the windows firewall, you can create a fairly effective solution, although it may not be foolproof.

You are somewhat ambiguous here. SRP, if enabled, will only help you if it is either applied to the directory your new executable is in or the executable itself. When using SRP in admin, I have a directory that SRP is applied to, and everything that is downloaded goes in there. If I were to execute a new download then SRP would reduce it to user and protection occurs. If you place a new file somewhere else and execute it, SRP would not help at all.

Now in context to being LUA and using SRP to create a default-deny, then as you state, SRP would help you IF your new executable is not allowed in SRP or not in a directory that is allowed.

So your statement is true but not refined enough in definition to be correct. Simply enabling SRP is only effective and correct in your statment if it is employed correctly.

SRP is simple for those who understand how to use it. Cheap is true lol. Effective, yes again it can be very effective when understood and implemented properly. Implementation in LUA is much more effective overall because it creates default-deny. Implentation in admin is more what I would call supplementation. It is more prone in admin to have problems, but if you know what you are doing, it can be very effective.

The exploit is irrelevant to LAN perhaps, but worthwhile to note

Sul.

 

Starting with XP, and in Vista and 7, the CreateProcess method looks for SAFER values in the registry before creating a process, aka starting a program. All versions have it but only pro versions provide MMC snap-in for it. You can create the registry items yourself or use PGS to create them for you. Once the correct registry settings are in place, SAFER aka SRP can be used in any versions of XP/Vista/7. M$ created the routine in the CreateProcess method, all you need to do is have the registry settings to make it work.

The link provided which shows the workaround posted by tlu is not needed really. All you need are the registry values. The info in that post by Tlu applies to adding the GP to home, which allows you to do group policy things. If all you want is SRP you only need registry settings.

Sul.

 

thanks

 

1. So, have you created a rule to allow the "Downloads"-folder apart from default Windows and Program Files, or what do you do when you actually want to run an executable?

2. How does SandboxIE play a role in this setup with SRP in place?


When I asked my previous questions here, I ofc intended to use a similar folder to be excluded for desired executions.

Now comes the big problem... my file-drive...

 

I am curious, you say you are using a default-deny in admin mode? Why would you do that? For example, the two default rules in SRP state that the containers c:\windows and c:\program files have the rule 'Allow Unrestricted'. In admin mode, you have to use the rule 'Apply to all users INCLUDING admins' in order for SRP to work at all. Typically however you have the default rule set as 'Allow' so that you can execute what you please as admin, but only those items you strictly set to deny or restrict are affected by SRP.

However if I understand you correctly, you have set the default rule to 'disallowed' or is it 'basic user' ? And hence, since program files and windows directories are in an 'allowed' state, your normal OS and program executables are not effected, but all other directories are. I have played with this setup before. For me, I found that because of what I do TO my computer, I had to make a lot of exceptions to Allow execution.

But perhaps you are in a comfortable state of installing programs to program files, and running those and not having many other directories or drives that you need to make exceptions for.

But when I tried this, I wondered for myself, if I am allowing c:\windows and c:\program files to run unhindered, but shut down the entire other parts of the drive(s) to running as either disallow or as basic user, what is the point then of staying admin and not just using LUA? For me it seemed at that point I must make exclusions for so many things to either run at all or run as admin or basic user, that using RunAs or SuRun would have been easier.

But then, everyday I am doing things TO my computer usually with registry or file manipulations or coding something that needs admin rights to do its thing. So I find LUA to be very restrictive in the sense that I am always elevating something. Likewise, when configuring my admin in SRP as you describe, it was much work to keep going daily because of how dynamic I use all my stuff.

So which are you using then as default, deny I suspect on XP. Vista or 7 gave the option of using Basic User as the default if I recall correctly.

Maybe I should revisit this method with the mindset of using my computer to do things instead of doing things TO my computer.

Very interesting topic here for sure.

Sul.

 

@ssj100

You might find it easier to just use DMR in reverse, where you elevate a said executable to admin, in which case you can proactively keep SRP in default-deny yet still allow one single execution without the restrictions. I am not sure it works, as SRP might say no to execute, but it might be worth a try.

I assume that you have a registry setting to quickly merge that turns the default to allow or deny? Do you use the mmc snap-in or PGS or just registry settings?

Sul.

 

As far as i know SRP can by bypassed by loading dlls. I think AppLocker can prevent those attacks by restricting dlls too.

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

 

Not really, no. SRP allows DLL restrictions as well, and they're actually easy to do (just whitelist folders containing the DLLs, instead of whitelisting single DLLs one by one). But, there are some valid, working methods to bypass even a very tightly configured SRP, detailed in that blog for example, and SRP itself cannot be used to protect against those methods. Methods which have, as far as I know, never been used in a real attack, even a targeted one. And it's extremely unlikely we'll ever see a non-targeted attack that uses those methods, since SRP is rather rarely used. I haven't had time to really look into how AppLocker in Windows 7 works - hopefully, it has been improved enough to stop even those methods that could be used to bypass SRP on XP & Vista.

 

I am not sure but i think the publisher rules are quiet good aren't they?

 

I don't find them particularly useful, but some may find them just perfect for the job. Still, they can be bypassed by those methods I was referring to in my previous post, since those methods don't target the actual rules but bypass the entire SRP checking (this is possible even in non-privileged user accounts because SRP checking happens, unfortunately, in user mode in the security context of the currently logged in user, and not in kernel mode like file permission enforcement for example). And as for publisher rules, there's the caveat that some have experienced it breaking Windows Update if it's set to anything except the default End Users. But, as said before, I haven't seen those methods actually used by any attacker in the real world, and probably won't.