The strength of SRP as an Anti-Executable

Discussion in 'other anti-malware software' started by ssj100, Sep 5, 2009.

Thread Status:
Not open for further replies.
  1. arran

    arran Registered Member

    Joined:
    Feb 5, 2008
    Posts:
    1,156
    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.
     
  2. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    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
     
  3. Habakuck

    Habakuck Registered Member

    Joined:
    May 24, 2009
    Posts:
    544
    I think malware which was copied into the ProgramFiles or system folder will be able to execute. :doubt: Isn't that right?
     
  4. Habakuck

    Habakuck Registered Member

    Joined:
    May 24, 2009
    Posts:
    544
    OK. I thought that it can write to the program files folder..

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

    Habakuck Registered Member

    Joined:
    May 24, 2009
    Posts:
    544
    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...
     
  6. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    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.
     
    Last edited: Sep 28, 2009
  7. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    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
     
    Last edited: Sep 28, 2009
  8. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    @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
     
  9. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    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/
     
    Last edited: Sep 28, 2009
  10. Dregg Heda

    Dregg Heda Registered Member

    Joined:
    Dec 13, 2008
    Posts:
    830
    Wouldnt disabling vbscript prevent the exploit of SRP discovered by didier stevens?
     
  11. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571

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

    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?
     
  12. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    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).

    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.
     
  13. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    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

    It would block some, like buffer overflow type attacks.

    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

    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

    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.

    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
     
  14. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    @ 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 o_O 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.
     
    Last edited: Sep 28, 2009
  15. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    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

    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.

    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. :)
     
    Last edited: Sep 28, 2009
  16. wat0114

    wat0114 Guest

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

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    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
     
  18. wat0114

    wat0114 Guest

    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 :eek: :D So with this in mind, it is supposedly better to test malware on a non-virtual system.
     
    Last edited by a moderator: Sep 28, 2009
  19. wat0114

    wat0114 Guest

    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.
     
  20. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    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
     
  21. andyman35

    andyman35 Registered Member

    Joined:
    Nov 2, 2007
    Posts:
    2,336
    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.o_O
     
    Last edited: Sep 28, 2009
  22. andyman35

    andyman35 Registered Member

    Joined:
    Nov 2, 2007
    Posts:
    2,336
    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.
     
  23. wat0114

    wat0114 Guest

    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.
     
  24. andyman35

    andyman35 Registered Member

    Joined:
    Nov 2, 2007
    Posts:
    2,336
    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.
     
  25. andyman35

    andyman35 Registered Member

    Joined:
    Nov 2, 2007
    Posts:
    2,336
    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 o_O
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.