Classical HIPS and policy based HIPS discussion

Discussion in 'other anti-malware software' started by BoerenkoolMetWorst, Jan 28, 2015.

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

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Sandboxie is a fine program. However, remember the at length discussion in the Sandboxie thread a while back pertaining to RMI? All malware has to do is perform RMI against an unsandboxed system process such as svchost.exe and its game over. The inflected svchost.exe can do whatever it wishes.

    Sandboxing is a file based containment strategy.
     
    Last edited: Apr 16, 2016
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Best example of that is the ransomware a few months back whose creator had "conscience pains," took it off the market, and published a decryption key. The payload laid dormant for months and then came alive via remote C&C server trigger.
     
  3. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    Honestly, I dont remember the discussion. But the problem is, for the malware that is, how to get out of the sandbox. Thats really the question, Can it get out? I doubt it. Why? ...Sandboxed programs cant make changes to processes outside the sandbox. They cant do it.

    Bo
     
  4. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    Malware that stays dormant like in your example or by design, cant hurt me. Remember, I don't trust any file or you can also say, I trust every file the same. And for as long as that file remains in my PC, the file its gonna run sandboxed. :)

    Bo
     
  5. FleischmannTV

    FleischmannTV Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    1,094
    Location:
    Germany
    I believe you don't understand the mechanics of Sandboxie, but that's no wonder since you've already confused escaping a restricted environment with fooling an analysis environment, which are two different things entirely. Please explain to me how a process with integrity level untrusted can alter the memory of a process with a higher integrity level, such as svchost. I'd be really surprised if Sandboxie was that permeable, though I bet my ******* on it that it isn't.
     
  6. :gack: Without taking position in whether or not itman understands the mechanics of Sandboxie, I have to say that FleischmanTV makes a point for Sandboxie to be discussed in this thread also: Sandboxie sets process integrity levels to LOW,(read) file access to Guest, redirects file (write/delete) access on kernel level and monitors user land inter process commnication, so it could easily qualify as a policy HIPS.
     
    Last edited by a moderator: Apr 16, 2016
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Someone over at malwaretips.com recently tested Sandboxie using live malware samples: https://malwaretips.com/threads/memory-injection-inside-sandbox.55059/

    For starters, I have issues with the way he did his testing:

    1. He didn't reference the malware, so I have no way of referencing or determining what each was supposed to perform in the way of injection activities.​

    2. He didn't separately list each test and the results thereof.​

    That said, I will post his comments with my own comments following.

    Recently I got eight malware samples that will directly inject into Explorer.exe. So I can continue my tests. I test them in WinXP running in a virtual machine. The latest version of Sandboxie Free is used in the tests. I also use Outpost Firewall Pro (OFP) to monitor the activities of the malware samples.

    In my tests, I found that, when the malware samples launched directly (not in the sandbox), ofp alerts that those samples trying to manipulate the memory of Explorer.exe. By contrast, when those samples launched inside the default sandbox of Sandboxie (with default settings), there is no such alert, and the samples simply collapse. So I think these eight malware sample, when they are launched inside the sandbox, fail to inject into Explorer.exe, which runs outside of Sandbox.:)


    I would say this was done using malware that is disk based. Most likely a .dll injection since Outpost's HIPS detected it whereas this was not the case in the following process hollowing test.

    I also test some malware samples that use the technique of Process Hollowing. When these samples launched inside the sandbox, their target processes, such as svchost.exe, will first be launched inside sandbox, then the malwares can successfully inject into the target processes. However, in my tests, since the target system processes also run in the sandbox (this is because their parent processes are sandboxed), they cannot influence the files not in the sandbox

    In these malware instances, neither Outpost nor Sandboxie detected the sandboxed target process manipulation or relfective memory injection from the malware sandboxed process.

    Conclusion

    Sandboxie will detect disk based process injection from sandboxed processes against non-sandboxed processes and I assume other sandboxed process.

    Sandboxie will not detect RMI from sandboxed processes against other sandboxed processes. As such, I concluded Sandboxie will also not detected like activity against non-sandboxed processes.
     
  8. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    OK, those results is what you can expect when malware runs in the sandbox. In the first example, the malware collapsed, perhaps on purpose to fool the tester or user of the infected program, so he runs it out of the sandbox.

    And in the second example, the malware runs, does it thing in the sandbox and nothing more. Cant escape.

    Bo
     
  9. syrinx

    syrinx Registered Member

    Joined:
    Apr 7, 2014
    Posts:
    427
    Sandboxie doesn't attempt to detect or change behavior between apps 'in the box'. Since the programs in a box run as anonymous user/untrusted anyhow windows integrity levels alone should take care of it by itself in most scenarios but even if not Sandboxie is designed to prevent anything from leaving. This includes any memory write attempts to outside processes so the dll injections would/should fail outright if used vs a program outside of the box. Thus baring an unknown exploit vs sandboxie & windows [or some poor choice of rules created by a user allowing memwrites to the targeted process, eg a user made hole] I find the last part of that conclusion hilarious.
     
    Last edited: Apr 16, 2016
  10. FleischmannTV

    FleischmannTV Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    1,094
    Location:
    Germany
    @itman He tested them in XP which doesn't have some of the security features which Windows provides (since Vista :confused:) and Sandboxie applies, foremost integrity levels. So once again: do you really think a process with integrity level untrusted can that easily modify the memory of processes with a higher integrity level?
     
  11. hjlbx

    hjlbx Guest

    Recrypt Malware Researcher & Developer:

    "Is my opinion, Sandboxie has nice concept especially when they moved to anonymous access token and untrusted integrity level (since version 4, if I remember correctly), but pretty much everything is blocked with these credentials so they have to allow a huge bunch of things. In other words they are reinventing Windows access control system trying to allow everything Windows allows. These are like hooks inside out, just a big list of allowing rules instead of denying ones with hooks. And unfortunately at the end of the day these big lists will start biting in the back. It's good if these are some usability issues biting, but worse when security ones."

    "Unlike Shadow Defender I don't think Sandboxie is vulnerable to BIOS, graphics memory or other driver-involving infections. It doesn't allow to load drivers (if enable Drop Rights). And things like these aren't possible without a driver or some privilege escalation exploit. Sandboxie's problem is in rules, there are too many of them, way too many. Sometimes they forget something, sometimes some things that look innocent alone will become dangerous combined. That's why they fixes like this "NtGetNextProcess can be used to alter processes outside the sandbox and will now be blocked" or this "A security hole with the Windows print spooler has been plugged" or this "A security problem reported by a user has been fixed: hard links could be created outside the sandbox". They're not single bugs that every software can have, they're implications of design."

    "I understand Shadow Defender concept, they don't detect anything, just something like take an HDD snapshot and then revert system back to it. The problem is they can't fight drivers with drivers. The problem can't be solved at the level it occurred, to solve it one should be one level higher. Some low-level HDD access will always bypass this isolation. Without even talking about persistent malware that doesn't involve HDD, i.e. resides in BIOS, video memory, etc."

    * * * * *

    Bottom line is Sandboxie ain't perfect; it has a tiny holes. The size of those tiny holes is directly proportional to what the user does inside the sandbox - some might be a bit bigger than others - but they are all relatively tiny. Plus, you have to have a combination of factors occurring all at once - which statistically speaking - isn't very likely.

    I have only seen Sandboxie fail one time on my system. I don't know why nor do I care. I don't worry about it...

    The only way to get tighter security is to use LUA (use it as your system sandbox) and rely upon Windows' built-in security mechanisms.

    There is only one program that I know that has stronger default-deny access rights for programs than the Windows LUA - and that is ReHIPS Isolated Environment.

    If you know the registry, file system, COMs, user profiles, etc very intimately, then you can configure program access rights running inside Sandboxie very tightly - but even most advanced users don't have the requisite knowledge. I know I don't nor am I inclined to spend weeks or months trying figure it all out.

    Always trying to find that needle-in-the haystack bypass of this or that is a complete waste of time - and breeds nothing but needless paranoia and user discontent.
     
    Last edited by a moderator: Apr 16, 2016
  12. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    Hi hjlbx, the guy who wrote that above is wrong, sandboxed programs are not allowed to load drivers, whether Drop rights is enabled or not, it doesn't matter.

    I think you should have posted the link for the long quote.
    Sometimes when users find traces in the real system of programs they run in the sandbox, they think something has escaped the sandbox. Thats so because they believe this records shouldn't be there. What I just wrote, happens very often, and the explanation is that Sandboxie doesn't prevent Windows from keeping records of what you do in the computer. You don't say much about your fail, I don't know, maybe this is the explanation. Here is a more about that.
    http://www.sandboxie.com/index.php?PrivacyConcerns

    And, every time you allow a compatibility setting or even allow something simple like bookmarks, you allowing more than that to get out of the sandbox. Like for example, if you allow bookmarks for Firefox, history also gets saved. Sometimes people say "History is escaping the sandbox, Why?" But really, nothing is escaping. The user is allowing it out but he doesn't know. Could something like this be your fail? :)

    Bo
     
  13. hjlbx

    hjlbx Guest

    Sandboxie failed; SBIE services were killed off and malicious processes were running on the system.

    It happened once in testing.
     
  14. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    If this processes were visible in Sandboxie control, they were sandboxed. What happened when you rebooted the PC....no malicious processes were running, Right?

    Bo
     
    Last edited: Apr 17, 2016
  15. hjlbx

    hjlbx Guest

    Unless a sandbox virtualizes firmware or further privilege restrictions (like Sandboxie), it will allow the installation of malcode to hardware other than the hard drive.
     
  16. hjlbx

    hjlbx Guest

    Malicious processes persisted on system; just clean installed OS to remove.

    Such things happen... it is rare, but it happens.
     
  17. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    I remember Tzuk saying that sandboxed processes can not stop Sandboxie services, I never seen it happen. And never seen any kind of process get out of the sandbox either.

    So, you did reboot, right. If you didn't, dont be certain that the "malicious" process would have being around after the reboot. In some cases, malware can appear to take over the system but once you reboot, the sandboxed infection is terminated and gone after deleting the sandbox.

    Bo
     
  18. To recap Sandboxie's mechanisms

    1. Disk access
    Sandboxies sets the Anonymyous group token (I thought it used Guest). Anonymous translates to Everyone disk Access Control Level which only allows read access to disk. The kernel driver redirectes write's and delete's to the sandbox. Redirecting disk access is a fairly simpel mechanism which requires little code (jus look at the size of Excubit's Pumpernickel's driver which monitors Write and Delete) and is a known and proven mechanism.

    2. Process access
    Sandboxie lowers sandboxed processes (on Vista and higher) to LOW integrity level (IL). Lower IL's are not allowed to modify higher IL's, they are only allowed to modify same level IL (e.g. medium level Firefox Browser is allowed to changed medium level Explorer) or lower integrity level's. That is why FleischmanTV keeps asking the question "do you really think a process with integrity level untrusted can that easily modify the memory of processes with a higher integrity level?" As HJLBX quotes Recrypt Malware Researcher & Developer "pretty much everything is blocked with these credentials so they have to allow a huge bunch of things".

    Thinking of SANDBOXIE BLOCKING things is INCORRECT, internal WINDOWS mechanisms BLOCK things, SANDBOXIE ALLOWS things to enable the process to run as it were running normally. As explained by Syrix this ALLOWING is only is applicable for interaction to processes running OUTSIDE the sandbox (since all USER processes in the Sandbox run with LOW IL/ANONYMOUS). So in terms of risk, it is not an automatic open door, it is a whitelist/condition based allow exception (which can partly be narrowed down through sandbox settings).


    Bottem line for SBIE-fans
    This ALLOW mechanism is the (theoretical) Achilles of Sandboxie which could bite it in the back as RECRYPT (malware researcher) explains, but risk is minimal as HJLBX posts. Starting to debate this (BO Elam) is as irrelevant as stating that water is wet or the earth is round. SBIE needs to ALLOW things which are BLOCKED by Windows mechanisms LOW IL/ANONYMOUS USER to run a program inside the sandbox.

    Bottem line for SBIE-critics
    We already have discussed SANDBOXIE versus APPCONTAINER so let's NOT repeat the Sandboxie "increase of attack surface" discussion thread over here. For MEDIUM IL processes like Firefox, Thunderbird or Windows Media Player to run in a SBIE sandbox with LOW IL, is an ENORMOUS REDUCTION of attack surface in the first place.
     
    Last edited by a moderator: Apr 17, 2016
  19. guest

    guest Guest

    Good explanation
     
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This might indeed be the case, since the malwaretips.com tester was running on XP. However, I have never seen any proof of this as applicable to RMI. I have posted a number of RMI tests in this thread that can be run by anyone wanting to prove that Sandboxie can protect against RMI. These tests are basic in nature and many 5+ years old.

    -EDIT- Another test that should be performed against any sandbox solution is detection of dropper malware that is encrypted, obfuscated, and de-cloaks in memory such as noted in reply #719. This technique is employed by advanced banking Trojans and usually employs RMI often coupled with process hollowing. Additionally note that the process hollowed target is almost always a process that runs with elevated privledges with svchost.exe being a favorite target. Additionally note that the hollowed process with elevated privileges could then perform RMI against another system process running outside of the sandbox.

    Note that regardless of what privilege de-escalation Sandboxie performs, if so, against a sandboxed hollowed process, it has to be able to detect the RMI activity from the said process against other processes outside of the sandbox.
     
    Last edited: Apr 17, 2016
  21. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    I'm not sure what you mean. It should be easy for HIPS to block malware from loading system processes like svchost.exe and explorer.exe. And if they can't load trusted system processes, it should be game over.

    It isn't about classical HIPS vs behavior blockers, these are just labels. It's about developers staying on top of the game. The SS developers should simply update SS in order to make it block stuff like RMI and process hollowing.
     
  22. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    What others have already tried to explain is that SBIE will simply block all process communication from processes inside the sandbox, to processes outside the sandbox. So what this means is that process hollow and RMI attacks can only happen inside the sandbox, but it will not be able to take over the system.

    That is what's so cool about sandboxing, especially when combined with a behavior blocker like Invincea Endpoint does. I've actually tested the process hollow tool running "sandboxed", and as mentioned it does open svchost.exe, but it's running with low privileges so it's difficult to do any serious damage.
     
  23. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Cool to know they both could block this. BTW, the test would not work inside the sandbox.

    The only way to escape sandboxes is by using kernel exploits, or malware has to exploit specific holes in tools like Sandboxie and Invincea Endpoint. The two examples that you gave will most likely not be able to escape the sandbox. But it's indeed possible for malware to at least run inside the sandbox, so you always need to combine sandboxing with HIPS/BB/anti-logger to stay on the safe side.
     
  24. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Again, proof needed that RMI performed by the sandboxed hollowed svchost.exe cannot be performed against a non-sandboxed process.
     
  25. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    It's not only about proof, it's about logical thinking. SBIE is designed to block code injection and interprocess communications into/with non-sandboxed processes. So as soon as malware runs sandboxed, it's restricted to manipulate the real system, no matter if they try to use advanced techniques like RMI and process hollowing. But perhaps someone can test it.
     
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.