Application Sandboxes: A pen-tester’s perspective

Discussion in 'sandboxing & virtualization' started by BoerenkoolMetWorst, Jul 25, 2013.

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

    guest Guest

    The problem with EMET is it loves to break things up in my computer. The only way to fix it is to find what mitigation technique(s) which caused the problems by disabling them one by one. It's just not worth the effort in my personal opinion.
     
  2. AlexC

    AlexC Registered Member

    Joined:
    Apr 4, 2009
    Posts:
    1,288
    So if everyone starts using Chrome under EMET, malware writers will never be able to come up with exploits? That's unreasonable, imo. But that's not the point.

    My point is that is more likely the appearance in the wild of malware that simply targets Chrome (that have a large user base), than the appearance in the wild of malware that targets Chrome and also is able to bypass a well configured Sandboxie (why bother? why the extra time and money invested for such a small percentage of computers? Like i said, is possible but highly unlikely). And the same is applicable to the use of EMET.

    I think that the larger attack surface factor have more importance in the circumstance where someone is under a targeted attack. For the majority, that's not under that circumstance, the use of Sandboxie, or EMET, or some other layer (instead of the use of Chrome alone), will almost always be a distinctive advantage, and therefore the better option, imo.
     
    Last edited: Nov 9, 2013
  3. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    I have the same problem, I still don't know why EMET doesn't like my computer.
     
  4. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    3,282
    Location:
    Canada
    I found using it to mitigate Chrome was a problem, but for a short time now, out of interest sake and experimentation because there are some who want to continue using the O/S (I'm migrating away form XP for good), I'm using all mitigations for Firefox with EMET 3.0 on XP Pro SP3 and so far no breakages, even with Firefox SBIE'd.

    The point is imho to understand the threat landscape and I truly believe script control in the browser is so very important, particularly for XP users. Drive-by downloads don't require social engineering, except for the ones deliverd via email. If one can tame EMET to afford even some mitigation of the browser and other Internet-facing apps, then that is huge as well. You don't want malicious shellcode getting a foothold in the browser's memory heap.
     
    Last edited: Nov 9, 2013
  5. Page42

    Page42 Registered Member

    Joined:
    Jun 18, 2007
    Posts:
    6,695
    Location:
    USA
    Hear, hear! :isay: :thumb:
     
  6. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    The main problem with these reasonings is that in SBIE4 it can be configured to block all of the exploits and all of the vunlerabilities (both user mode/user-level and kernel-mode/kernel-level exploits) if you know what to configure and what to block in the first place, so even though, by default SBIE is vulnerable is not vulnerable anymore once you block access to those bugs/holes-and there is nothing that can bypass this.
    Also, like Peter said these are only POCs and that's about it-they are not real, one thing is to hypothesize it/theorize it and one thing is something that is 100% real and in everyday practice.
     
    Last edited: Nov 9, 2013
  7. Ilya Rabinovich

    Ilya Rabinovich Developer

    Joined:
    Sep 13, 2005
    Posts:
    1,543
    That's a good challenge to check it out. Isn't it?
     
  8. Jryder54

    Jryder54 Registered Member

    Joined:
    Sep 3, 2013
    Posts:
    214
    That wasn't the point.. they were examples.
     
  9. guest

    guest Guest

    Say, you have a beef. But you're not allowed to:
    - fry it
    - boil it
    - grill it
    - put it on fire
    - put it between two layers of breads
    - eat it raw
    - give it to someone or something else

    If you do one or more of the above, a secret government agent will shoot you down with a handgun until you're dead. Of course, you can think of any new method of how to cook the beef that is not forbidden. But you'll have to be very creative. It doesn't matter if such restrictions are only applied to your town or to the whole country. You still will have to come up with something new, which isn't easy. And that new method might be forbidden as well within an update to the laws. Not to mention you have to cook the beef ASAP or it will get rotten.

    And vulnerabilities in Chrome and other popular browsers will get patched quickly. The advantage of popular software being targeted is the developers usually know how to deal with attacks which might compromise their products.

    Or may weaken the security features of the programs and OSes themselves.
    hxxp://support.emsisoft.com/topic/12668-oa-blocks-acrobat-reader-in-runsafer-mode/
    hxxp://support.emsisoft.com/topic/11574-online-armor-run-safer-help/

    Anything you've added to your computer will increase security risks, even applicable to non security software. For example, if you don't install Java, then you're practically immune to Java-based exploits. What matters most is if the increased security risks are worth to take.
     
  10. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    4,538
    Location:
    Outer space
    I wonder if this will really work against drive-by-attacks and exploits, they don't use the normal download method and Public Fox seems more aimed at stopping other users from messing with FF and downloading all kinds of stuff.
     
  11. AlexC

    AlexC Registered Member

    Joined:
    Apr 4, 2009
    Posts:
    1,288
    The problem is that Malware writers have the advantage here, because it's typical "cat and rat" game. Vulnerabilities may be patched quickly, as long as they are known to the developers.

    Check this link about Chrome hacking contest: http://arstechnica.com/business/2012/03/googles-chrome-browser-on-friday/

    For sure Google was fast patching the vulnerabilities. But the hackers who discovered those, could have sold them instead of participate in the contest and that way make them known to the developers.


    I agree, what matters most is if the increased security risks are worth to take. So, once again, but slightly modified to answer your reasoning, what is more likely to emerge in the wild?

    - A exploit that affects Chrome?

    - A exploit that affects Chrome through security software like Sandboxie or Defensewall?


    Is the security increase brought by Sandboxie worth against the risk of the appearance in the wild of malware that target's Chrome through Sandboxie?

    Or is more likely that a properly configured Sandboxie is able to stop an exploit that targets Chrome (huge user base), or Java (huge user base), or some other widely used browser plugin?

    IMO, the first is highly unlikely, and the second is much more likely. That's why i think that using Sandboxie together with Chrome is still the better option.
     
    Last edited: Nov 9, 2013
  12. guest

    guest Guest

    It's always like that. Otherwise we won't need to update everything. But big players have many ways to make their products as secure as possible, like bug bounty programs as an example. Chrome/Chromium's security is well documented and actively developed. At least it's much better than using a web browser that most people have never heard of it and last updated in 2007.

    Well, your decision is yours, so is mine. I don't consider using another kind of sandbox on top of Chrome is worth the risks and efforts. :)
     
  13. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Mandatory: https://www.cr0.org/paper/to-jt-party-at-ring0.pdf Local kernel exploits are pretty common, on Windows and other platforms.

    But I'd also point out that application sandboxes don't matter much if we're talking about browser based attacks and data theft. Files accessible in the browser sandbox can be grabbed, input can be monitored, etc.

    Ideally you want an attack to not succeed in the first place. EMET helps, as does Javascript and plugin whitelisting, and just staying up to date with patches; but when you think about it, pretty much every desktop OS is sadly weak on this front.
     
  14. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    3,282
    Location:
    Canada
    Agreed!

    Yes, the O/S itself is weak in this area, but there are some options available in some browsers and there are some nice browser plugins/extensions for this purpose too.
     
  15. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    This post brings out some significant points. First and foremost it is only a POC, and there are probably a lot of reasons for not concerning oneself to much.

    But since this thread is about that POC and it's effects and is it a potential threat. And it that context the first statement is completely incorrect. Heck even Tzuk stated that.

    I went back and re read what I got from BlueRidge(no, Unfortunately I can't post it), and a very interesting theoretical scenario was described. You have a graphics rendering API which has a flaw in it. When the graphics API is called with a certain value, it passes code into the kernel process, which at that point does nothing. Then at some point later a browser, and browser, pass a perfectly legitimate call to the graphic renderer and bingo depending what the code does it could be game over. There is no way SBIE or anything for that fact that can stop it.

    The best defense against this theoretical threat is keep the OS fully patched.

    Pete
     
  16. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    There's some interesting stuff with how the system will cache API responses. I don't know the details of it on Windows, unfortunately, but it seems relevant to that attack.

    @GJ,

    Classic paper. One of my favorites.
     
  17. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    Some people seems to have already forgotten the redundancy of using Chrome and Sandboxie together, since they implement the same sandbox (with Google's being superiorly configured without need for compatibility) under Vista+.

    Sandboxie hardening is nothing special and can be implemented through other means. It has been discussed before, but the real life difference is virtually non-existent.

    I prefer tools like EMET, HMP.A, MBAE, and WSA to protect Chrome, because they're much more usable and stronger for it and probably IE imo. Also, some of them have compatibility problems with Sandboxie, so obviously I choose the different kind of layer.
     
  18. guest

    guest Guest

    Same sandbox? I thought they were different (type A and type B)? o_O

    Since I have my eyes on AppGuard, based on your point of view, would you say that it's a good tool to protect Chrome or any other high risk apps, or redundant instead? Thanks.
     
  19. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    Sandboxie 4+ uses lower integrity levels just like Chrome, unlike the kernel hooks it uses in previous versions (which works better on XP). You can search this thread for a lot of posts on this subject.

    Probably a good tool for the system including Chrome, but I have no experience with that software.
     
  20. guest

    guest Guest

    Oh... you were talking about that one. Back in the days when I was still using Sandboxie I read some discussions which said version 4 will be a massive change. I didn't really keep up with the discussions. So that's what was being discussed.

    From what I've known so far, it doesn't seem like a sandboxing tool. Not even partial virtualization. It blocks guarded programs from doing certain things based on policies. No idea if it's comparable with IL restrictions. :doubt:
     
  21. AppGuard implements
    1. Memory protection of guarded aps
    2. UAC/LUA like protection of windows & programs file and HKLM
    3. Privacy limitations (reading updating folders marked as private) to guarded aps
    4. Deny execute in user folders for all processes (anything outside Windows & Program Files).

    Pretty hard to bypass since this are typical starting points of most intrusions. When you test it with Comodo tools it does not look strong, but AppGuard has a simple but effective strategy: intercepting the first steps in the chain of events of all (known) intrusion by exploits. Nice side effect it is very quiet, so it is obe of the few HIPS which could be used by larger audience.
     
  22. guest

    guest Guest

    I'm just afraid that AppGuard will be redundant if used with Chrome's security features. :doubt:

    I agree, although silent security feels pretty boring sometimes. :D
     
  23. Jryder54

    Jryder54 Registered Member

    Joined:
    Sep 3, 2013
    Posts:
    214
    What is redundant? Which security features? Most of the things he listed can't be implemented by chrome alone. o_O
     
  24. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    5,981
    Location:
    Nicaragua
    If you are gonna talk about Sandboxie and integrity levels, perhaps you should read what Tzuk has to say about it.
    http://www.sandboxie.com/phpbb/viewtopic.php?t=16967&highlight

    Bo
     
  25. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    From the testing I've done, Appguard really appears to be very strong indeed. And since I won't use chrome, redundancy isn't an issue.

    Pete

    PS. But going back to the point of this thread, which is the pen-testers perspective, neither Appguard nor Sandboxie, will stop the class of exploits discussed.
     
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.