The strength of SRP as an Anti-Executable

[ssj100]

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 (http://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).

[Sully]

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.

[Rmus]

{QUOTE-> I'm talking about malware attack vectors from the outside (eg. internet, USB/DVD). <-QUOTE}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:

http://www.wilderssecurity.com/attachment.php?attachmentid=201068

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

211874

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)

http://www.wilderssecurity.com/attachment.php?attachmentid=206539&thumb=1&d=1235325019



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)

211875

NOTE that the alerts are Default-Deny.

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

----
rich

[jmonge]

{QUOTE-> Exactly mate. That's exactly what I'm talking about. SRP is basically the most powerful Anti-Executable there is, and it's completely free, incredibly light, and very easy to use.

With SRP in place, I think I can ease off with recovering new files into a sandboxed folder - I simply don't see the need given this powerful Anti-Executable is in place. <-QUOTE}
SRP is not avaliable for xp home only profesional>:(

[jmonge]

{QUOTE-> Yes indeed. Time for an upgrade maybe? <-QUOTE}man the pro cost 199.99 at best buy;D

[Creer]

{QUOTE-> SRP is not avaliable for xp home only profesional>:( <-QUOTE}
http://www.wilderssecurity.com/showthread.php?t=200772

HTH,

[raven211]

{QUOTE-> Interesting topic! <-QUOTE}

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?

[s23]

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...)

[wat0114]

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.

[Rmus]

{QUOTE-> 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? <-QUOTE}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

[Rmus]

{QUOTE-> 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. <-QUOTE}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

[Dregg Heda]

{QUOTE-> 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. <-QUOTE}
Hi wat,

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

[Dregg Heda]

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

EDIT: Quote removed.

[wat0114]

{QUOTE-> Hi wat,

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

Applies if you're running XP or W2k. Explanation is here (http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/Network/NETBIOSLeaveOnorTurnOff.html) and one way to disable it is here (http://www.petri.co.il/disable_netbios_in_w2k_xp_2003.htm).

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.

[Dregg Heda]

Thanks! :thumb:

[Sully]

{QUOTE-> Thanks for your insight. I've got a few questions if you have time.

You say "SRP will not help you if you connect to other computers and you are logged in as admin". I am guessing that the potential attack vector is not covered because the malicious executable/process that runs is not executed on your system, and hence your SRP would not cover you? I would presume here that a classical HIPS would cover you here (especially if you configure it so that no new files can be created on your system), or would the classical HIPS also be bypassed given the executable is run on another computer and your LAN is trusted? I just can't see how malware can infect you if no files are allowed to be written on your system though. Sorry for this tangent, but I'm brain-storming here. <-QUOTE}

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.

{QUOTE-> I'm not clearly understanding all that firewall stuff that you talked about, but thanks anyway. I guess configuring a firewall for the LAN network may be all that is required to prevent malware attacks, rather than relying on a classical HIPS? <-QUOTE}

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.

{QUOTE-> Anyway, apart from LAN networks, I am thinking that SRP should cover everything else right? If I run my internet facing applications sandboxed etc, the only way I can realistically get infected is if I recover a new (untrusted/unknown) file on to my real system (and not into my forced sandboxed folder). Then, I need to make the further mistake of executing this new file manually (although there are exceptions like that .wmf exploit). If I had SRP enabled, this file would be unable to execute. <-QUOTE}

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.

{QUOTE-> So it seems SRP is the simplest, cheapest, and most effective approach for me to cover any "user error" issues. In fact, it's probably not necessary to recover new (untrusted/unknown) files into a forced sandboxed folder anymore, since SRP will deny anything from running anyway. <-QUOTE}

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.

{QUOTE-> EDIT: by the way, the Runas exploit is irrelevant here - I'm talking about malware attack vectors from the outside (eg. internet, USB/DVD). If someone malicious has physical access to my computer, it's all over anyway. <-QUOTE}

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

Sul.

[Sully]

{QUOTE-> SRP is not avaliable for xp home only profesional>:( <-QUOTE}
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.

[jmonge]

thanks:thumb:

[raven211]

{QUOTE-> Yes mate, even in administrator mode, SRP is default-deny for any area of the computer except C:\program files and C:\windows etc. Since I always recover my files to a "Downloads" folder on my desktop, SRP will cover that area and much more. SRP is good stuff. The key advantage of running LUA here is that nothing is able to be written to C:\programs files and C:\windows, so it's an added measure of protection and a good complement to SRP. However, I don't want to use LUA, and I personally don't see the advantage to (especially when balancing out the disadvantages).

I've done a lot of testing now with drive-by downloads via IE with SRP enabled. SRP has blocked everything, and I'm running in administrator mode.

Anyway, thanks a lot mate. Well, I'll probably never be connecting my computer to a network or LAN anyway. If I end up doing so in the next few decades, I might be asking you more questions mate haha. I'm sure computer security would have changed by then though haha. <-QUOTE}

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... :P ::)

[Sully]

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.

[Sully]

@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.

[Habakuck]

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/

[Windchild]

{QUOTE-> As far as i know SRP can by bypassed by loading dlls.

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

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.

[Habakuck]

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

[Windchild]

{QUOTE-> I am not sure but i think the publisher rules are quiet good aren't they? <-QUOTE}

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.

[arran]

{QUOTE->

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).

<-QUOTE}

more convenient maybe, but a lot less secure. while you disable SPR to install new software it gives the chance for any malware you may have to also execute and run.

[Windchild]

{QUOTE-> more convenient maybe, but a lot less secure. while you disable SPR to install new software it gives the chance for any malware you may have to also execute and run. <-QUOTE}

One normally wouldn't disable SRP to install software. One would just execute the software as admin if SRP is applied to everyone except admins, or just execute the software from an unrestricted folder if SRP is applied to admins as well.

As for "any malware you may have" also being able to execute, I'm not quite clear on what that means. If you disable SRP, then of course SRP does not prevent anything from executing. But "anything" still can't magically execute all by itself - something has to execute it, and most often it's you, unless you regularly browse exploit sites in a vulnerable browser while installing software and get hit by drive-by download exploits. ;D So, if there's some malware file sitting in some folder when you disable SRP, it won't magically execute. It'll just continue sitting there, doing nothing. The only cases in which a malware would execute are 1) the software you are installing is or contains malware and 2) if you run into some drive-by exploit that your configuration is vulnerable to while having SRP disabled or logged in as admin if SRP only applies to non-admins. But sure, if you allow some installer to execute and the installer contains malware, then SRP won't stop that. It's not a HIPS type thing that monitors everything and pesters you about it or alternatively makes its own choices silently, it just either allows or blocks execution according to the rules. So, no, SRP won't save you or stop you from installing malware yourself when you purposefully execute a file in an environment where SRP is not enforced or is disabled. But then, it's not supposed to. It isn't a HIPS, and that's one of the good things about SRP. Of course, to some, it's a bad thing, but to others, not. ;D

In any case it's certainly true that SRP doesn't provide you with HIPS like detailed control over things like "Can process XYZ write a registry Run key?" It isn't supposed to. It's just a simple "execute or don't execute" kind of tool, but does that pretty nicely. In that sense, it certainly provides less "protection" than HIPS. On the other hand, it would be foolish to believe that a HIPS will always warn you if a process you trusted (like the installer of something that you wanted to install and allowed) is actually doing something malicious that you don't want done. If the malware is even remotely cleverly disguised, it's easy to fool the user into saying yes, at which point the HIPS is helpless. For example, let's take a malware that's pretending to be a CPU temp monitor tool that obviously needs to load a driver to do what it does. Let's assume our user wants to install this software, thinking that it is a CPU temp monitor. Their HIPS product then warns that the installer process is trying to load a driver called "cputempm.sys". What's the user going to do? Say no? If they do that, the malware does nothing and cleverly says: "Sorry, the temperature monitor driver could not be loaded. This requires administrator privileges and may be blocked by some security software." The user tries again, and this time allows the driver when the HIPS asks about it. And at that point, the malware is in kernel mode and can utterly savage the HIPS product and the system, if the malware author did his homework.

Basically, SRP is a pretty nice, free anti-executable. Certainly not invincible, but strong enough against any currently known threat. It can't beat social engineering, but then nothing can. Except a wonderful thing called thinking, which is available to everyone at no extra cost. ;D

[Habakuck]

I think malware which was copied into the ProgramFiles or system folder will be able to execute. :doubt: Isn't that right?

[Habakuck]

OK. I thought that it can write to the program files folder..

Is the Admin Acc with UAC enabled the same as full LUA?

[Habakuck]

Yes, now i can see what you mean.

I just wonder if it is the same on Vista/Win7 with UAC turned on. It should be...

[Kees1958]

{QUOTE-> Sorry, I don't understand anything you wrote there - could you please clarify if you get time?

By the way, this is how I use my SRP:
http://www.wilderssecurity.com/showpost.php?p=1536622&postcount=5564 <-QUOTE}

See http://technet.microsoft.com/en-us/library/bb457006.aspx

For educational purpose only offcourse


Try this http://requinix.blogspot.com/2009/08/bypass-software-restriction-policy.html

and this http://requinix.blogspot.com/2009/01/bypass-software-restriction-policy.html



It works for portable aps and since Kafu does not protect all vulnarable HKEY_CURRENT_USER keys, a protable app could set this key:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\Currentversion\winlogon\shell (like this one does http://spywarefiles.prevx.com/RRGFDJ22792349/BASESRV.EXE.html) or . . .

Without Surun warning your


But again what ever works for you mate.

[Kees1958]

{QUOTE-> Haha, that looks pretty cool. I'll give it a try when I get home. It probably wouldn't run the program with administrator privileges though - SuRun is the way to go!

EDIT: Kees, it seems like you are trying to tell me that SRP can be bypassed easily. I've got a much easier method mate - log out of my LUA, and log into my administrator account! And even easier - use SuRun! What's the big deal haha. If you're silly enough to run an untrusted application (not to say purposefully dragging the "untrusted" portable application into Microsoft Word and executing it from there, or purposefully zipping an "untrusted" application and executing it from within the archive), then it's all over anyway. I could also purposefully put a pipe bomb in my room and blow up my computer haha!
EDIT2: Furthermore, as I've said time and time again, a good "security setup" alone is not enough. You need a good "security approach". So in my case, if I recovered a portable application out of my sandbox, I would go through the usual process of testing it in a VM, as well as running on-demand scanners, uploading it to virustotal etc, before I would even consider running it on my real system. And now perhaps with Comodo Time Machine being released, I would run it on a snapshot and simply rollback if there were any problems! <-QUOTE}

No SRP can not be bypassed easily. Better to use 7-zip in stead of windows Xp own. Also Surun and Kafu won't help you, see changed post. There is a difference between a digital fort knox strength security and a strong security which in real life will be sufficient.

Advantage of Surun/PGS/FajoXPSE is that you can utilise the strength of LUA, SRP and ACL with near zero CPU cycle loss, so I would encourage everyone to use those freebies.


Cheers :P Kees

[Kees1958]

@SSJ

There is another policy based freebie in which you can add 7-zip (or win-rar) and word/excel/outlook etc. EdgeGuardSolo. I still have a copy of it (PM when you want it). Works on a differenct level (also eats practicably no CPU cycles) as SRP.

I always use PGS to run internet faced applications as LUA (I use the name feature) plus enforce deny Execute of user space and use EdgeGuardSolo for 7-zip, Office and PDF reader Foxit.

When CTM is out of beta, it will be very easily to setup a free security configuration which eats minimal CPU cycles or does a lot of I/O

Cheers

[Windchild]

{QUOTE-> For educational purpose only offcourse


Try this http://requinix.blogspot.com/2009/08/bypass-software-restriction-policy.html

and this http://requinix.blogspot.com/2009/01/bypass-software-restriction-policy.html
<-QUOTE}

Fellow users, remember one thing. The "bypasses" in that blog are not real bypasses at all. It's just the natural result of a SRP that is too lax. If you use rules that allow you to execute anything from temporary folders, then obviously you can "bypass" SRP by copying files to those temporary folders and then executing them. And if you want to block that sort of thing, just make SRP rules that disallow execution in such folders. Very, very simple and logical, and there is no vulnerability or design defect or bypass involved.

It seems whoever made those "guides" to "bypass" SRP either didn't know why doing what he did could "bypass" some software restriction policies or just didn't want to explain it. The reason of course is that if you ZIP some exe, and then try to execute it while it's still compressed inside the zip, Windows (or an archiver software like WinZip) will extract the file into the TEMP directory, which will usually be either Windows\Temp or UserProfile\Local Settings\Temp, and then will execute the file from that directory. If there is no SRP rule that denies execution from that directory, the exe will be allowed to run, of course, and that's how it should be. On the other hand, if there is a rule that denies it, then it won't run. The same is true for dragging some exe to MS Word and then trying to execute it - again the file is dropped in a temp folder and executed from there, if SRP rules allow execution from temp folders.

So, these aren't real bypasses at all. If you want a real bypass, try this, for example: http://blog.didierstevens.com/2008/06/25/bpmtk-bypassing-srp-with-dll-restrictions/

[Dregg Heda]

Wouldnt disabling vbscript prevent the exploit of SRP discovered by didier stevens?

[Windchild]

{QUOTE-> Thanks for the explanation Windchild. No wonder it's not bypassing my SRP.

Here's my attempt at bypassing SRP using that zipping method:

212606 <-QUOTE}


And as we can see, the screenshot shows that the file is being executed from Local Settings\Temp, and your software restriction policy wisely does not allow that and therefore the file cannot be executed. :)

{QUOTE-> Wouldnt disabling vbscript prevent the exploit of SRP discovered by didier stevens? <-QUOTE}

If you disabled Office macros completely, then you couldn't use the exact same method he used to bypass SRP by writing a macro in Excel to do it. Macro protection set to high would prevent this from happening automatically when you open some malicious Office file (keep that macro protection enabled anyway, since you're much more likely to run into macro viruses than this). But that would still leave other ways to do the same thing. And macro protection would not prevent a local user from writing a macro and running it to do this.

But, should you worry about this stuff? No, unless you plan to be the most unlucky man in the world. ;D As I said before, these attacks have never been reported in the wild. And no wonder, since there's really no reason to go through all that trouble, when there are millions of systems being run as admin, unpatched since 2004 or something. Why go through the trouble of trying to bypass rarely used security features when you can just own those who don't resist at all?

[Windchild]

{QUOTE-> What other ways would there be in a LUA + SRP environment (and that has all threat-gates forced sandboxed in my case haha)? It would have to take some amazing exploit of a non-executable file that I've recovered from the sandbox to break through. I doubt that is possible. But then again, perhaps the .wmf exploit or the more recent .pdf exploits could be used? Regardless, I don't think anything could protect you from such amazingly crafted malware. <-QUOTE}

Anything that allows you to execute enough code works. It can be an exploit, but doesn't have to be. If you can fool the user to execute PowerShell script for example, even in a non-privileged account, that will do it. On the other hand, to keep things in perspective: the malware, once executed, would still only have LUA privileges, meaning it can be easily detected and removed, and there's no reason to expect we'll ever see any widespread malware using these techniques (it would be a waste of time for the malware author).

{QUOTE-> If a malicious person with malicious intentions has direct physical access to your computer, then you'd better hope you took out the hard-drive with you haha. <-QUOTE}

It's certainly always a bad idea to let a malicious/untrusted user have physical access to the system. On the other hand, if physical access means only access to keyboard, mouse and display but not the actual rig, then it's not necessarily a problem at all. If you have to make do with just software, there's only so much you can do to try to break into a system.

[Windchild]

{QUOTE-> Interesting stuff. What would PowerShell scripts come in the form of? Do they exist as individual files that need to be executed manually by the user or are they integrated some other way? <-QUOTE}

Files normally with the .PS1 extension. We can obviously execute them manually (after a bit of messing with the default security settings in PowerShell) or like with other scripting engines, we can call the executable responsible for the script engine and feed the script file we want to execute to it as a command line argument. There's a nice little guide to get started with PowerShell here: http://www.microsoft.com/technet/scriptcenter/topics/winpsh/manual/run.mspx

{QUOTE-> Also with regards to other methods, would hardware DEP block a lot of them? <-QUOTE}

It would block some, like buffer overflow type attacks.

{QUOTE-> Anyway, in my case, this theoretical (and probably extremely rare) malware attack vector only exists for any file I recover outside of the sandbox. <-QUOTE}

Or for a malicious file that exploits some vulnerability or design defect in Sandboxie to bypass its protection. Unlikely to be sure, but not impossible (and it's been done before by actual real malware ITW even very recently, although I don't think it was so much targeting Sandboxie as trying to do something in a relatively unknown way to fool most security products in general). But then, for that malware to both bypass Sandboxie and then attempt to bypass also SRP, it would have to be pretty complex compared to what we usually see, and such a malware is about as likely as being hit twice by lightning the same day. ;D

{QUOTE-> From there, the file would have to contain directly exploited code which somehow bypasses (or switches off) my SRP configuration. Then it would have to execute, and as you said, it would be executing in a LUA, which automatically limits how much damage it can do anyway. <-QUOTE}

Exactly. Unless we get further in the theoretical and assume the malware author has also found an unpatched privilege escalation vulnerability and exploits that to get out of LUA. While that's not impossible, we'd be dealing with an attack so complex that... well, if you ever met something like that, it would be a good idea to start playing the lottery because with luck like that you should definitely win the whole big jackpot. ;D

{QUOTE-> I'm trying to look for such a POC that was created by Didier Stevens, but I'm unable to find any download links to his files. Have you had any luck? <-QUOTE}

He provides a download link to a new version of his tool in this blog post http://blog.didierstevens.com/2009/06/25/bpmtk-injecting-vbscript/ But I've not played with that and I'm not sure if it contains the script he used to bypass SRP.

But when even POCs are so hard to find out there, that's a pretty good indicator that the attack isn't really very interesting to folks. And again, it's no wonder, since SRP is rather obscure and unknown even to many professionals. This can be seen by the kind of thing that is usually claimed to be a way to bypass SRP - simple things that are prevented by any reasonable SRP policy.

{QUOTE-> "100%" is still achievable thanks to Sandboxie haha. <-QUOTE}

You know what I say about 100 %. ;D "Close enough to 100 %" is certainly possible and not even hard. "Absolutely, positively, fully 100 %" is impossible, with any system made by humans.

But certainly, a common sense approach to doing things is likely to thwart most of even sophisticated attacks. And really, worrying over POCs and such would be a waste of time unless you do that for a living or a hobby. It's enough to understand that practically everything will have vulnerabilities and therefore practically nothing is truly 100 % safe and secure. That should keep one from falling into too much of a false sense of security, and would encourage one to continue to practice the common sense approach to doing things safely. :)

Me? I usually only post in these threads to point out what is known to be possible and what is not, and why. Information seldom hurts, as long as it's correct. :D

[Kees1958]

@ Windchild
Have a look at SSJ's secuirity arsenal, he is definitely planning to be the most unlucky man in the world, SSJ is on a quest (for 100% protection).
Thanks for scaring him with PowerShell Script ;D I always thought you had to download the PowerShell from MicroSoft first to run the scripts.


Real world risk = likelyhood of happening x possible impact. For instance how high/solid should the water works protection of the Netherlands be?

For conditions which are thought to be happening once in a ??? years (spring tide, westerwind storm, high water of Rhine and or Maas, rise of Ocean waterlevel due to global warming, weakening of waterworks by rats, rabbits and other mamols living in those area's, sinking of the western European continental plate and other circumstances colliding)

As said: There is a difference between a digital fort knox strength security and a strong security which in real life will be sufficient. No SRP can not be bypassed easily. Advantage of Surun/PGS/FajoXPSE is that you can utilise the strength of LUA, SRP and ACL with near zero CPU cycle loss, so I would encourage everyone to use those freebies.

[Windchild]

{QUOTE-> Hey Windchild, thanks for your explanations. Not sure how that would bypass SRP (since SRP blocks script executables from running I thought). Thanks for any clarification. <-QUOTE}

SRP will only block the script executables one has told it to block. If I have PowerShell installed because I want to use it, then I can't block it with SRP because then I could no longer use it. ;) But then, to people who don't use PowerShell that's not a problem, but they may not have it installed either - it only came out in, what, 2005 or so? But as said, PowerShell scripts are just one way - any application that allows some decently complex scripting can be used, and some code execution vulnerabilities may be available for use as well. The bypass would happen the same way it happens when using an Office macro as Didier Stevens explained in his blog: if you can execute a PowerShell script, you can simply use the script to patch SRP checking off, since you have full write access to any process running in your own security context and SRP checking is done in the user's security context, instead of happening in kernel mode where non-privileged users wouldn't be able to do anything about it. Well, that sounded rather cumbersome, but that's the best I can do at this hour. ;D

{QUOTE-> Haha, now you're going from the incredibly rare (and purely theoretical) to stuff of fantasy! I think the most that Sandboxie has had to deal with in the last 4-5 years or so are theoretical POCs that don't even truly bypass Sandboxie (but seem to come out about once a year haha). <-QUOTE}

I wouldn't call it fantasy, just rare. There are real cases of actual, real ITW malware bypassing Sandboxie, even very recent ones, and those then tend to result in the author releasing a new Sandboxie version with some new protections. But then, many if not most of those bypasses would probably fail to work if the user was LUA, as in your config, so... yes, very rare, but not so impossible it deserves to be called fantasy, IMHO.

{QUOTE-> Your information is generally good stuff. However, you seem to enjoy talking about the (near) impossible too haha. <-QUOTE}

Not so much enjoy as feel it's kind of my responsibility. Think of it like this: If I tell someone that the new Honda Accord is very safe, much safer than earlier Accord models in crashes, what should I do if someone then seems to get all excited and says that it's so safe they're now 100 % safe from fatal car crashes? Me, I'd tell them that while it is indeed a pretty safe car, you can still get killed in an accident, so don't go thinking it's 100 % safe when it's not. It may be close enough, but not more than that, so it's best to be aware there's always the chance. It may feel like a little thing, but it's the little things that tend to make a big difference in nasty situations. :)

I'd contrast it like this: instead of worrying over obscure theoretical attacks or POCs, simply be aware of the possibility of such attacks, and find a security policy with a reasonably small level of risk that is acceptable to you. That is to say, find a setup with small risk, but remember that there is still risk - in other words, that the risk is not 0 % and you are not "100 % safe" or bullet proof to use that term. ;) Don't get all scared and worried, but don't get too cocky and think one is fully invincible, either. Or in just one word: awareness. It'll get people far. :)

[wat0114]

{QUOTE-> What is so "over-kill" about my security setup? <-QUOTE}

Kees didn't state your setup was "over-kill" ;)

[Kees1958]

{QUOTE-> Kees didn't state your setup was "over-kill" ;) <-QUOTE}

Yep,

At least I assume you use VM to play with malware. Playing/testing with malware under VM/sandboxie is sort of planning to be the most unlucky man

Cheers

[wat0114]

The few samples I've tested under VM were not even sandboxed, only that the vm is run on the host's limited account which is running a software firewall with hips functionality enabled, so I'd say there were no plans on being an unlucky man :) I guess there is some malware that detects it's in a virtual environment so it won't run in this case or, evidently so, it can leap Ninja-like out of the virtual guest and into the host to unleash its wrath upon it :o ;D So with this in mind, it is supposedly better to test malware on a non-virtual system.

[wat0114]

{QUOTE-> Purposefully testing malware on the real system is probably not a good idea, even if you have rollback software installed. <-QUOTE}

Absolutely, unless it's a dedicated malware-testing-only system, void of any and all personal info, where one can spare no expense in hardware/software. However, I don't test malware as a hobby or habit, so this is reallly irrelevant for me anyways :) And as for my applications, they are always at least 99% trusted, and those that may not be are tested appropriately (the need is rare) before I consider deploying them on my production system.

[Kees1958]

{QUOTE-> How do you test malware Kees? <-QUOTE}

Ah well, very old fashioned, also the reason why I am not testing a lot.

A seperate play PC

Phyiscally disengage the data disk

Load a test image

Test

Make a new image of test result

restore to working image

Bit by bit compare of clean image versus test image

Once some unused bits were changed in the master boot record, although everything seemed to work normally, I did mount that image regurly for a year, but it was not a time bomb either.

After some years of playing with malware and general usage on two PC's, we had one virus interception on my son's PC. I on the other hand had managed to destroy our home PC two times and my Son's once. Therefore my wife wanted a laptop, with only one security application (you guess what).

So I was more or less banned to an old PC ;D and am not allowed to touch the other PC's anymore. :D

[andyman35]

I'm just wondering here about this idea of running a VM within Sandboxie.If used on a system with a CPU that supports Intel VT/AMD-V wouldn't running Virtualbox Sandboxed actually lessen the level of protection at least theoretically.???

[andyman35]

{QUOTE-> Hmm, interesting question, and I don't have a definitive answer for that. However, what makes you think that the level of protection would be lessened?

From my logic and if it's possible, anything that escapes the VM (that is, jumps out of virtualbox.exe and other processes which I can't recall at the moment) would escape into yet another sandbox which has the restriction that only virtualbox.exe and some other processes can start/run and access the internet etc.

Unfortunately, it would be very difficult to test this out, since I'm not even sure if there are genuine malware or even POCs we can access that can bypass an unsandboxed VirtualBox. <-QUOTE}
Well I'm only speculating and talking theoretically but my thinking is that virtualization locked at the hardware level has to be more secure than any software layer,even one as awesome as SBIE.

[wat0114]

{QUOTE-> Well I'm only speculating and talking theoretically but my thinking is that virtualization locked at the hardware level has to be more secure than any software layer,even one as awesome as SBIE. <-QUOTE}

Good point and I think you may be right. My thoughts on using SB in concert with a vm is to run it within the vm rather than running the vm within SB, although I certainly see merit in the latter setup.

[andyman35]

{QUOTE-> Good point and I think you may be right. My thoughts on using SB in concert with a vm is to run it within the vm rather than running the vm within SB, although I certainly see merit in the latter setup. <-QUOTE}
Well for systems with unsupported CPUs running Virtualbox sandboxed is a sensible precaution against anything escaping the VM through an exploitable hole in Virtualbox,however unlikely that is.

[andyman35]

{QUOTE-> Not too sure mate. I thought that running VirtualBox sandboxed merely gave an extra layer of virtualisation. I didn't think it would erase any virtualisation provided by Virtualbox? <-QUOTE}
Well Sandboxie would block Virtualbox from interracting with the CPU's virtualization layer to my thinking instead redirecting to a virtual emulator...but this is way too much for my brain at 3am :wacko:

[andyman35]

{QUOTE-> Agreed. I'm completely lost haha. But I think I can see where you're coming from. Perhaps Tzuk will know the answer to this. <-QUOTE}
I'd be fairly certain that Tzuk could clear it up yes.

[wat0114]

{QUOTE-> Ah well, very old fashioned, also the reason why I am not testing a lot.

A seperate play PC

Phyiscally disengage the data disk

Load a test image

Test

Make a new image of test result

restore to working image

Bit by bit compare of clean image versus test image

Once some unused bits were changed in the master boot record, although everything seemed to work normally, I did mount that image regurly for a year, but it was not a time bomb either.

After some years of playing with malware and general usage on two PC's, we had one virus interception on my son's PC. I on the other hand had managed to destroy our home PC two times and my Son's once. Therefore my wife wanted a laptop, with only one security application (you guess what).

So I was more or less banned to an old PC ;D and am not allowed to touch the other PC's anymore. :D <-QUOTE}

Okay Kees, you had to be getting paid for this :D This procedure seems way too labour-intensive to me, although I'll admit it probably by far results in the most accurate representation of what the virus does to the system. But at least now I think I understand what you meant in your "most unlucky man" suggestion ;D

[Kees1958]

@ Watt and Andyman

Brilliant Wilders community reaction :thumb: :thumb: :thumb:

[Windchild]

{QUOTE->
By the way, what real-world malware are you talking about that has been proven to genuinely bypass Sandboxie? The only one I can think of in recent memory is that print spooler service vulnerability that Buster discovered. Have there been others in the last few years? Please enlighten me. <-QUOTE}

The spooler service one was the first that came to mind as it was so recent. As I suspected when it was first reported, it wasn't a vulnerability in the spooler service at all, but rather a Windows feature that had been overlooked in Sandboxie design and could be used to get out of the sandbox if the user was logged in as admin. (So, your setup, as far as I know, would have easily prevented that bypass.) There have been others, too, but fat chance that I could remember then now that it would be useful. :gack:

{QUOTE-> You might have noticed - I've tried quite hard to emphasise the importance of having a good "security approach" here on Wilders. <-QUOTE}

Yeah, I've noticed. It's a very good thing to emphasize that security is much more than a bunch of apps or settings. Even most quite sophisticated attacks and attempts to bypass security software can be thwarted simply by using one's head and of course social engineering attacks can be only by reliably defended against that way. :thumb: