Idea for HIPS backend using native capabilities of WinXP and later

Discussion in 'other anti-malware software' started by Gullible Jones, Oct 30, 2014.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Hope that got your attention! Yes, this should apply to XP too, because XP also has job objects. It might be a little half-baked, but I think it could be made to work.

    See first:

    http://www.chromium.org/developers/design-documents/sandbox#TOC-Sandbox-restrictions
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms681949(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms684147(v=vs.85).aspx

    Job objects let you group processes together and put various controls on them. In this case the control we want is ActiveProcessLimit in the JOBOBJECT_BASIC_LIMIT_INFORMATION struct. This lets you set a maximum number of processes belonging to the job object. If:
    - The job object is set to make spawned processes also part of the job
    - A job process tries to spawn another process
    - ActiveProcessLimit is too low for that process to join the job
    then the process creation will fail, which is exactly what we want. There may be other restrictions possible but that's the main one.

    I think there are a couple ways of doing this...

    A) Create a job object with an ActiveProcessLimit of 1, for each and every process that should be restricted.

    This might be memory intensive or otherwise problematic. This might be better:

    B) Create one job object, and build a list of restricted programs. When an allowed program spawns, increment ActiveProcessLimit and assign it to the job. When it exits, decrement ActiveProcessLimit. This way processes associated with the job will be blocked from spawning anything.

    That's kind of complicated though, and also you have the issue of malware co-opting an allowed process. So I have a better idea, inspired by VoodooShield:

    C) User lockdown. When the user hits the Big Red Button (or otherwise triggers the HIPS, maybe by launching one of a list of Internet-facing apps...)
    - a new job object is created with the aforementioned restrictions
    - ActiveProcessLimit is set to however many processes are running in that user account
    - All the user's processes are added to the job object, and ActiveProcessLimit is decremented if any exit

    So, no new applications can spawn until the user hits the Big Green Button and the HIPS invokes CloseHandle on the job object.

    ...

    Is this workable? I think I might be reading the Windows API stuff wrong, but if not I hope this is useful to someone...

    Edit: tell you all what, I'll try to create a command line implementation later this evening. Might take me a while though, as I'll need to create a Windows VM for it...

    Edit2: obviously blocking process creation is not enough to avoid CreateRemoteProcess hijinks and stuff, but there are other access controls available too, even on WinXP.

    BTW, to anyone who's actually reading this: are there any SysInternals tools that can mess with job objects? ProcessExplorer can view jobs, but can't seem to change them.
     
    Last edited: Oct 30, 2014
  2. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    So awesomely enough, Didier Stevens did this back in 2010!

    http://blog.didierstevens.com/2010/09/13/runinsidelimitedjob/

    But I'm interested in how far I can push it, so I am going to try for my own implementation. Maybe with a simple GUI, if I can get it working with Python ctypes and Tkinter.

    Edit: wow, I didn't notice that the source code is public domain too. Reading it now, and it appears to work pretty much how I expected. It should indeed be doable in Python, or any other language that lets you import Win32 API functions.
     
    Last edited: Oct 30, 2014
  3. GJ,

    Ambitious project. What about this to trigger your thoughts

    - run process under a different user as basic LUA
    - that user is not allowed to change other users data
    - program runs as job object with process limit of 1
     
  4. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Thanks @Windows_Security.

    Different user as basic LUA, not allowed to change other users' data -> this is getting a little more like a chroot sandbox, or per-application user accounts. I believe there are ways of limiting access rights further without doing this, using a restricted process token like Chrome (but maybe not quite as restrictive). Also I haven't fully explored the capabilities of job objects. And for stuff like this it might be better to go whole hog and use integrity levels...

    Runs as job object with process limit of 1 -> I mentioned this in the OP, as the first possibility. Actually it looks like job objects are not expensive to keep around, so that is probably better than the others... However, there is the problem of a hijacked process invoking e.g. CreateRemoteThread on Explorer or something like that, and then spawning the nasty from there.

    Of course, once you bring in CreateRemoteThread, nothing is safe. So I'll eventually want to see if I can block that (and other debug stuff) too.

    For now though, I'm just going to try to get the anti-executable/user lockdown part working. One thing at a time...
     
  5. 142395

    142395 Guest

    Thank you for very educational post, though I don't have Xp.
    I'm curious about whether is is possible to block code injection or dll injection (combined with any of LoadLibrary functions) by CreateRemoteThread w/out help of integrity level, or of course w/out hooking.
    How about dll injection by SetHookWindowsEx?
    (Sorry I don't know Windows internals at all.)
     
  6. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Neither do I. :p I honestly don't know the answer to those questions. Will look more into it later; other stuff came up this evening.

    (I know, I know... vaporware. Sorry.)
     
  7. 142395

    142395 Guest

    Every new programs are at first vaporware, aren't they?;)
     
  8. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    So, other interesting stuff that can be done with job objects...

    - Blocking interaction with the clipboard: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684152(v=vs.85).aspx
    This might not be a good idea for GUI programs; not sure, as I don't know how the Windows clipboard works.

    [Edit: also you can forbit SetWindowsHookEx, for setting global hooks. That's good too.]

    ... And that looks like about it. Hmm. Let's see what else the Chrome sandbox uses...

    - One could create alternate desktop objects for sandboxed programs. This would block shatter attacks! It would use ~4 MB of memory per sandboxed program though, which could quickly get prohibitive. Also not sure how it would affect the clipboard. Maybe allow programs to be grouped into alternate desktops?

    - A restricted access token could be used too, with fewer restrictions than Chrome uses.
    http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx

    One thing that might be a good idea, is revoking SE_DEBUG_NAME. That should block CreateRemoteThread, I think? In fact all of those privileges look like they should be revoked.
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    To be honest, I don't really have a clue what you're talking about. Is this different than how most HIPS work?
     
  10. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Yes. Most HIPS I've seen use their own driver. This would use internal Windows mechanisms, as Chrome's sandbox does; but unlike integrity levels it would work on Windows XP, and probably even 2000.

    Not sure how much practical value that would have though, we're already starting to see HIPS-bypassing stuff in the wild.
     
  11. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    On Win XP, I'd just stick with kernel hooking. And even most HIPS on Win 7/8 are still using a driver, so where's the value?
     
  12. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    That I might be able to pull it off without being a kernel programming expert. :p

    Edit: also I think there are valid reasons not to be messing around in kernel space to intercept this stuff, when the facility to do so already exists without a third-party driver. I haven't seen many BSODs on Windows 7, but those I saw were all caused by security software.
     
    Last edited: Oct 31, 2014
  13. 142395

    142395 Guest

    So you can forbid SetWindowsHookEx and even CreateRemoteThread, that's great! though of course it will cause problems for some (rather, many) apps if applied.

    As long as I know, Chrome use restricted token, job object, Windows station isolation, and desktop separation.
    You may also have interest for ReHIPS as it is a HIPS which don't use hook but only use Windows security mechanism, though I don't know if it works in Xp as well.

    Its user manual is very educational for me, explain Windows security mechanism well.
     
  14. 142395

    142395 Guest

    Hooking is attractive for programmer because e.g. it allows him to control and expand other apps which he doesn't know its source code at all.
    However hook is very dangerous, any mistake can cause serious issue such as BSOD.
    Also kernel driver and hooking are the source of many conflicts so Microsoft itself recommends to use other solution if possible.

    Regarding security, history proved sometimes hooking can be bypassed and even make attack surface, and many vulnerability in security software involves it's driver.

    I personally think it's big benefit that such a talent people like GJ got interest about Windows'-security-based HIPS-like control.
    I hope more to come.

    One disadvantage for such HIPS I noticed from my experience about ReHIPS is, (I'm beta tester of ReHIPS) I can't get prompt or log when something is blocked. They're seeking solution but I don't know it's even really possible as it don't use hook.
     
  15. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Do keep in mind that I'm very very new to the Windows API (and anything that interacts with it), my day job involves writing shell scripts... So please don't expect too much.

    Yeah, that could be a problem. Though maybe it would appear in the Windows event logs? I don't know, I hardly know Windows at all at this point.
     
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Actually, there's a difference between hooking the kernel on Win XP, and hooking it on Win Vista/7/8. On XP, developers used to hook the kernel directly (modifying the SSDT) while this was not recommended by M$, and it could also be abused by rootkits. So they forbid this on Windows 64 bit systems. However, you can still hook the kernel via a "filter-driver". Almost all advanced HIPS like Sandboxie and SpyShelter use such a driver.

    I haven't actually tried it yet, but at first sight, ReHIPS looks way too complex. Also, Sandboxie does the same (in a simple way) and DOES use a driver, probably because you can then apply security in a more robust way.
     
  17. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    OK I see, and like 142395 said, it seems like the developers of reHIPS have already tried to do this, so you might want to check it out, to get some ideas.

    http://re-hips.com/en/
     
  18. 142395

    142395 Guest

    @Gullible Jones
    Even so, at least I (and I believe some other member too) can learn a lot from you & your posts.
    It's very interesting to learn new things and such knowledge consequently let me make more robust security.
    But please keep your own pace & interest.

    I only looked administration events that time and there's none. Next time when I test ReHIPS I'll look into more.
     
  19. 142395

    142395 Guest

    @Rasheed187
    orry if it gave you confusion but I mentioned about hook generaly.
    In Windows, there're many forms of hooks, you know dll injection is a kind of hook, and all of them potentially can cause issue as it's not expected by original developer, sometimes leads to serious one.

    As to filter driver and filter manager as it's subcomponent, while the idea of altitude mitigates likelihood of conflicts to some extent, there're still conflicts and MS still recommends that if there're other way use that.

    Also there're still bypass like this:
    http://rce.co/why-usermode-hooking-sucks-bypassing-comodo-internet-security/
    Such bypasses are why they now integrated hardware assistance for extended protection mode.
    And vulnerability too (you can search for that from any vulnerability database)

    So basically no change to my opinion, or I'll add hooking makes some perfomance delay.

    I agree, ReHIPS is currently too complex and this is why I'm keeping contact with the developer and sending bugs/suggestions via PM.
    Also agree SBIE does good job with OS security mechanism (for Vista+) and much more usable.

    About SBIE driver, I suppose in some case such as when user got admin priviledge it might give some protection, but as I mentioned in 'Sandboxie technical tests and other technical topics discussion thread', it's most likely for compatibility & usability.
     
  20. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Actually, you're wrong when it comes to this. M$ actually recommends to use a "filter driver", because on Win 64 bit, such a driver can not hook the kernel directly anymore. It was hooking of the kernel that made a lot of systems unstable. But M$ has worked together with security companies to give these type of drivers (almost) the same power as drivers had on Win 32 bit. So that's why tools like Sandboxie and SpyShelter make use of them. I don't believe that Sandboxie could offer the same strength of security without a driver.
     
  21. 142395

    142395 Guest

    What MS recommends is to use filter driver rather than developing a new file system driver, and to use mini filter rather than legacy filter.
    However they recommend if you have other choice that don't use filesystem filter driver, then use it and give an example that if you just want to monitor change in directory, use Win32 API.

    I have one apology that it is stated in MSDN Japanese blog and I couldn't find English resource about that.
    Google translation of that blog:
    https://translate.google.co.jp/tran.../filesystem-filesystem-filter.aspx&edit-text=
    Also related post (in English)
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff539271(v=vs.85).aspx

    SBIE could offer the same, or maybe more strong security w/out driver as their security mechanism relies on Windows own security mechanism (for Vista+, in ver 4.x).
    Just look at Chrome which don't use driver but almost bullet-proof against remote-code-execution type of exploits.
    I believe SBIE needs driver mainly for compatibility & usability.
    E.g. SBIE converts global hook into app-specific hook. When it comes to security, it is safer to forbid any hook. But if SBIE did this, most program won't work properly. So here kernel driver is needed for compatibility.

    The idea that hook by kernel driver gives more security is IMO just a myth.
    That hooking means more power and more control, but also means more risks and more attack surface.

    But I still prefer hook-based HIPS as they're much more user-friendly.:)
     
  22. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    If you limit a user account to 5 processes, and I compromise 1, I just have to kill another process before I launch my payload. Right?
     
  23. 142395

    142395 Guest

    So, maybe some kind of self-protection is needed?
     
    Last edited by a moderator: Nov 4, 2014
  24. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Not user account, job object. But yeah, to avoid timing attacks it would be better to assign a job object per process; job objects are small and cheap anyway.

    Edit: Oh N/M I see what you're saying. But yeah, the idea was to temporarily block all running programs from spawning anything, and remove the blocks later by closing the job object handles.

    With fileless malware installs getting more common though, I wonder about the usefulness of this.
     
  25. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Keep in mind, we're talking about advanced security tools. Of course there's no need for a word processor or file monitor to use a driver. But security tools (like HIPS/AV/anti-exploit) who need to monitor, inspect and restrict stuff, will always need filter drivers. You can not control certain things without a driver AFAIK. And IMO, more power and control means more security.
     
  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.