defensewall or Sandboxie versus LUA + SRP

Discussion in 'other anti-malware software' started by RealityCheck, Jan 7, 2009.

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

    RealityCheck Registered Member

    Joined:
    Jan 7, 2009
    Posts:
    1
    After reading some excellent threads on Wilders I have locked down my Windows XP with LUA + SRP + KAFU +DEP is there anything essential that Defensewall or Sandboxie can add to this setup?
     
  2. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    If they run OK in a LUA, i think they always add something. Besides with SBIE having the virtual sandbox, both apply a policy regarding programs' rights (trusted/untrusted), as opposed to user rights that the programs inherit.

    The marginal benefit would be less marginal and more evident when running a program with admin rights facing the internet.
    I can think of a game i played, which only ran with admin rights, and talking to a server admin one day where he said something like "i'm not in control of the server".. Someone was though.

    Otherwise, I'm not sure if this isn't a 'belt and suspenders' kind of situation. :)
     
  3. chris2busy

    chris2busy Registered Member

    Joined:
    Jun 14, 2007
    Posts:
    477
    yes,with sandboxie you can also be protected of malicious scripts and other browser,im,mail threats
     
  4. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    Malicious scripts are covered in SRP.
    Whatever SBIE adds is probably more about what could happen, like some sophisticated exploit, rather than what's likely to happen/ what does happen.

    I don't use anything else myself, other that what the OP states and SuRun.
     
  5. Lucy

    Lucy Registered Member

    Joined:
    Apr 25, 2006
    Posts:
    401
    Location:
    France
    SRP checking is not implemented at kernel level. It can be easily circumvented / bypassed.
    Even Microsoft says Software Restriction Policy and Group Policy are not meant to be complete security features. For full security, Microsoft recommends using ACLs to protect the appropriate resources in Windows.

    If you go on the site of GeSWall, and read the different papers there, you will understand that GeSWall is the exact apllication of microsoft advise, plus a bit more.

    DW and SBIE set their policy in the same philosophy, but with different means.

    In the same time, LUA+SRP is more than enough for 99.999% of the time I guess. I don't know about malware which would be forged to bypass it...

    Therefore... Make your choice...
     
    Last edited: Jan 7, 2009
  6. jmonge

    jmonge Registered Member

    Joined:
    Mar 20, 2008
    Posts:
    12,883
    Location:
    Canada
    very clear,makes sense:thumb: cool explanation;)
     
  7. zopzop

    zopzop Registered Member

    Joined:
    Apr 6, 2006
    Posts:
    632
    Wow this is the first time I'm hearing this. Is there an example of a PoC or real life malware that does this (especially SRP in default deny mode)?
     
  8. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    If this is the case, then what about DropMyRights? Or any other means of 'demotion' ? I also would be interested in finding out the specifics on why and how SRP would be deemed 'weak'. But, what about when SRP is combined with the restriction of 'Basic User' instead of disallow/allow as it's normal use?

    Just when you thought you might know a few things...

    Sul.
     
  9. Lucy

    Lucy Registered Member

    Joined:
    Apr 25, 2006
    Posts:
    401
    Location:
    France
    I
    Well I didn't mean it. SRP is a powerful tool I would use if I ever had Vista ultimate...

    Check this link and enjoy:

    http://hype-free.blogspot.com/2008/10/limitations-of-software-restriction.html

    What I meant is that SRP is a must have, when applicable, but it's always good to know the limitations of any tool one chooses to use!
     
  10. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Actually, I had seen that Mark Russinovich had shown that. May even have been here at Wilders.

    Good read for sure. I think that all goes back though to the same question many here have. Just what are my vectors of compromise? How many and how weak? I wonder though, that article eludes to the calling of the assignment of SRP, what about after SRP has already been implemented on a particular .exe. For instance, if I use SRP which forces IE to start as a Basic User, and then a piece of code (fictitous) were to run in the IE thread, that attempts to bypass SRP, could it do it? Could it circumvent an already demoted acl on that thread? Or could it promote another process it would want to start?

    Very interesting.

    Sul.
     
  11. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Hi,

    I run XP Pro as limited user with SRP (no execute allowed at recycler and temp directories, while data directories are marked as basic user).

    I have Malware defender configured to protect HKU registry startup, low level access to registry and keyboard, rights elevation and shutdown, hook setting, driver loading (this effectively blocks all keyloggers I could test) as a general extra protection level.

    I have also contained all my internet facing applications (no intrusion allowed, only specific processes allowed to start/call, reistriced directory access and access to registry limited to a few keys/values).

    It is not a policy or virtualisation sandbox, but an extra intrusion/access containment. It runs very light without pop-ups (no execution control)

    MD has the advantage that it also provides limited firewall functionality.
     
  12. zopzop

    zopzop Registered Member

    Joined:
    Apr 6, 2006
    Posts:
    632
    Thanks for that Lucy. I read the article and I'm sort of confused. He's bypassing SRP by writing scripts in programs such as Excel? Doesn't that require a user to be physically at the computer hacking away using Excel (or whatever program allows writing/executing scripts)? How would malware writers use driveby downloads or other methods that don't involve being physically in front of the PC to exploit these methods of bypassing SRP?
     
  13. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    This is basically a macro virus or exploit. You would have to be duped into executing the macro (using it). They are showing an example using VBA, which is a subset of VB. VB has lot's of calls available, so probably the easiest to implement without much research.

    I did not read anything that led to the likes of 'driveby' exploiting. Yet anyway.

    Sul.
     
  14. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    Guys, all sorts of data formats conatin embedded code, media files, xml files, html, ole, dcom, com, java, etcetera. Distributed computer processing drives on it. Also code can be executed by being evolked remotely.

    That is why I am looking at containment (GesWall and DefenseWall offer containment of files also!), not anti executable type of control.

    Cheesr
     
  15. zopzop

    zopzop Registered Member

    Joined:
    Apr 6, 2006
    Posts:
    632
    Hmm but doesn't SRP allow you to restrict .vb, .vbs, and other scripts from running? I set my SRP up to restrict things like .vbs, .js. etc...

    You would have to be tricked into running the macro in Excel or something similar no. Note : since I don't use macros EVER and restrict macros in my openoffice programs I don't really know much about Macros.
     
  16. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Right. The article referenced shows proof of concept though of macro's, like VBA. I am sure that any language that can hook deep enough with the right calls could do it as well.

    Good points though ZopZop. I don't really know if it could happen if those extentions are already protected. I would imagine it could, because as I understand it, the concept is to intercept the SRP before it takes hold, or after it takes hold but before it applies. Seems like it is chalked up to the registry holding the values. Intercepting and modifying.

    Honestly, does anyone think thier probable multi-layers would fail even if SRP did? Just wondering, as I am trying out full DEP and using Cyberhawk ATM. Somewhere I think I read you could download one of Mark's proof of concept files and test this yourself. But I cannot remember where I saw that at.

    Sul.
     
  17. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Last edited: Jan 7, 2009
  18. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    I saw that article recently. It all started with an old blog by Mark Russinovich, Circumventing Group Policy as a Limited User

    This is a excellent article, and I've often quoted him that the proper way to set up SRP is for white listing. With SRP configured properly, this application could not run, as Didier Stevens explains,

    bpmtk: How About SRP Whitelists?
    But, he continues:

    And so began the interesting journey of developing a script to do this.

    In the original blog cited, the author, cdman83, made this comment which I found rather curious:

    "Executable code" as far back as I can remember has always included scripts. It's just that for convenience sake, executable files are called "executables" when referring to code compiled in binary language (.exe, .dll, .sys), and "scripts" when code is compiled in ASCII (plain text) language (.vbs, .js). Both types can "execute" code.

    Back to the attack: he seems to be talking about multiple users on a group workstation:

    Also comments by Didier Stevens:

    He also points out the most likely type of attack:

    To demonstrate how a script can launch an executable from within the document. Note that no separate VBS or other script filetype is involved. The code is inside the document:

    Using MSWord, I create an AutoOpen macro to launch a non-white listed executable.
    I don't use SRP so I'll demonstrate with Anti-Executable, but the result would be the same:

    srpBypass-2.gif

    Stevens demonstrates how he can use code embedded in a document that would disable SRP
    which would then permit any executable to load:

    Excel Exercises in Style
    As they stand, these are demonstrations of vulnerabilities --Proofs of Concept (PoC). They are not exploits in the wild.

    Normally I don't get too excited about vulnerabilities. Hundreds are discovered each week and people love to post their PoC. I don't ignore them -- I look at them and think through what has to take place, and ways to prevent.

    Ask yourself what the liklihood is that this would become a widely distributed malware exploit where malware writers would take the time to target such a small group of people, compared with the millions of people out there just waiting for an e-card from "their friend" and who will gladly open the card and immediately become an honored guest in a botnet!

    From this standpoint, if I were an SRP user, I wouldn't lose any sleep over this. Note cdman83's final comment:

    To alleviate any concerns, however, you can follow advice from Kees1958 in his post above.

    Let's suppose you are a targeted individual:

    First, the perpetrator will have to get you to open a rogue file. Note as Kees1958 points out, many file types contain embedded code that can be used for malicious purposes.

    How will the file be delivered to you? Most common methods are

    • by opening an email attachment
    • by opening on a web page
    How do you presently decide about opening such a document?

    Finally how would a perpetrator know that *you* use SRP in the first place? Only you can answer that.

    ----
    rich
     
    Last edited: Jan 7, 2009
  19. wat0114

    wat0114 Guest

    Hi Rmus. Thank you for the post. As always, they are very informative.

    Just a quick question on this:

    I'm pretty sure you've elaborated on this as being a possible "codec" screensaver, wallpaper or ad, but I can't remember. Could you please verify. What is the most common/probable malicious object, so to speak, someone might open in a web page? Thanks!
     
  20. Cerxes

    Cerxes Registered Member

    Joined:
    Sep 6, 2005
    Posts:
    581
    Location:
    Northern Europe
    Yes, if you have deep skills in Win internals with knowledge about the policy configuration of the targeted system = a very hard nut to crack...

    AFAIK, one can protect the system against these attacks since blocking the attack vectors preceds the intercepting reads/calls by using SRP to block as much file extensions as possible (e.g. .vb*, .js*, .exe, .dll etc), in conjunction with blocking of the script engines (cscript.exe, wscript.exe, scrobj.dll). The execution of non-whitelisted processes in purpose of injecting other legitimate processes is also covered by this countermeasure. Therefore the malicious code can't conduct its intercepting reads/calls in purpose of returning false values.


    By running in a limited user account you effectively protect both the functionality of SRP, as well as the ownership and its permissions of objects: Applications that runs in a secure mode using standard user privileges doesn't protect the system at the same level as running in a restricted/limited user account.

    /C.
     
  21. zopzop

    zopzop Registered Member

    Joined:
    Apr 6, 2006
    Posts:
    632
    Some good info in this thread. I already added a bunch of script extensions to block to the SRP (i actually used a list of script extensions from Script Defender :D ). And I already added cscript and wscript to the blocked programs list.

    Now I do have one question though. What the heck is scrobj.dll. I've never even heard of it. What is it?

    EDIT :

    I still didn't find out what scrobj.dll does (even with googling around)... BUT.....

    I did find these odd .dll files : scrrun.dll, jscript.dll and vbscript.dll and experimented with blocking them using SRP.

    If I block scrrun.dll no scripts run (not even in my browsers! it's like a perma universal noscript!). This is too restrictive so I removed the rule.

    Next I tried blocking jscript.dll and again this blocked all javascript in all my browsers (and I'm assuming other programs too). Again this was too restrictive and I had to remove the rule.

    Finally I tried blocking vbscript.dll and as you would guess NO VB scripts ran (this also didn't interfere with my browsing). So I decided to keep this rule.

    So in conclusion wouldn't a default deny SRP with vbscript.dll blocked stop the trick used to bypass SRP in this thread?
     
    Last edited: Jan 8, 2009
  22. Reimer

    Reimer Registered Member

    Joined:
    Apr 6, 2008
    Posts:
    217
    I've read that malware such as Antivirus 2009 can be installed within a LUA. I've tried it myself within a virtual machine install and it did install... however, that was without closing off the 'unprotected' autorun folders/registry entries and without SRP.
     
  23. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Well, are you hogging them to yourself then? ;)

    Rmus, most excellent. If I would have tried to explain what you did, I would have probably needed a blog page to do it.

    Sul.
     
  24. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    You are welcome. I was referring in this case to a targeted attack, as mentioned in the blogs.

    In targeted attacks, the perpetrator knows the victim, or obtains the victim's name/email address. I'll give an example of each of the two common methods of infection: opening a document in email, and opening one on the web. (I hope we can eliminate the scenario where the perpetrator gains physical access to your computer!)

    An early example of using an email attachment. The attack occurred at a business:

    Alert Raised for MS Word Zero-Day Attack
    http://www.eweek.com/c/a/Security/Alert-Raised-for-MS-Word-ZeroDay-Attack/
    This exploit was just the normal extract-a-trojan type (binary executable), and would be blocked by Software Restriction Policies. But you can see how a person targeting someone with SRP could modify the exploit code to disable SRP, as demonstrated in those blogs. Also, a perpetrator might know that an entire organization has SRP configured on all workstations. I've asked many businesses in my area and have found none that do. Ask around -- see if you find any!

    Anyway, these types of targeted attacks have proven to be rare.

    Another method is to get the victim to go to a web site where the document is stored. This was quite popular with .swf (Flash) files. One survey found 800+ malicious .swf files stored on ImageShack.

    Spammed SWF URLs Abuse ImageShack, Lead to Rogue AV
    http://forums.pcpitstop.com/index.php?showtopic=160170
    I've not seen any exploits where Office documents were used in this manner, but it is a possible scenario. Whether other file types (.swf, .wmf, etc) could be used to contain the SRP exploit script code has not yet been demonstrated.

    To reiterate: the demonstrations in the blogs require that the user open the infected document. No remote code execution (such as a browser drive-by download) has yet been shown.


    ----
    rich
     
    Last edited: Jan 8, 2009
  25. Cerxes

    Cerxes Registered Member

    Joined:
    Sep 6, 2005
    Posts:
    581
    Location:
    Northern Europe
    There are two categories of user environments that can behave differently towards the use of scripts:

    1. Professional environments

    2. Non-professional environments

    For the home user, this isn't an issue since one can disable scripting rather easily (if you have the basic knowledge how to do this). It depends on the necessity the user have when it comes to the need of using scripts.

    For businesses it's another question. The heavy interlacing use of scripts between the actors/stakeholders is very deep-seated, if not impossible to change since it offers a lot of time saving, automatic routines that one can't ignore. The only way of minimizing this problem is trough SRP using whitelists as mentioned in the blog, in conjuction with education/guidelines of the users regarding how to behave towards unsolicited attachments, mailed links etc. But I agree that it is indeed a problem since I personally was involved in a project a couple of years ago with an administrative authority, whose intention was to change certain workroutines and third-part applications to "safer" alternatives. It was a slow, viscous process that in the end, more or less failured since its interrelated dependence with other actors made it impossible for a change and thereby undermined the work. The conclusion was that a broader change of the infrastructure of the network (actors/stakeholders) was a necessity for a similar project to succeed.

    /C.
     
Loading...
Thread Status:
Not open for further replies.