Matousec: Proactive Security Challenge 64 (bits)

Discussion in 'other security issues & news' started by guest, Dec 11, 2011.

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

    MessageBoxA Registered Member

    Joined:
    Jun 20, 2011
    Posts:
    62
    Hi,

    The reason that the 64 bit version of Microsoft Windows is difficult to protect... is because of PatchGuard. The 64 bit version of Windows prevents SYSENTER hooks and hooking into various other parts of the kernel. This was added to make Microsoft Windows more secure... to prevent rootkits.

    However it makes it very hard for a security vendor to protect the user... because technically rootkits and security products essentially install the same types of hooks. Heh, we use to joke in the office how there was actually little difference between writing code for a rootkit and writing code that protects users.

    Ironically... rootkit authors could actually make very good security products if they would take off their black hat and leave the dark side. :)

    Or maybe they never leave the dark side? :ninja:

    Anyway... I think that Microsoft should allow some security vendors to bypass patchguard if they have their product go through a rigorous test and verification. They could release binaries that are code signed and WHQL approved.

    Best Wishes,
    -MessageBoxA
     
  2. EraserHW

    EraserHW Malware Expert

    Joined:
    Oct 19, 2005
    Posts:
    588
    Location:
    Italy
    Why the hell do you need to hook SYSENTER to give protection to the customer?

    Windows x64 can be actually hardened and secured if you know how to do that and it can be effectively done even if PatchGuard is active on the system
     
  3. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I still don't get why you would need kernel access. SYSENTER is a way to jump to 0. AM/AVs can't use it with patchguard but neither can malware.

    The idea of using kernel-level APIs is to block at the lowest level for reliability, because if you block at the application layer and the malware has kernel access it can go around it.

    But with patchguard you level the playing field - neither side has the ability to get to 0 so why not just block at a higher level?
     
  4. 1chaoticadult

    1chaoticadult Registered Member

    Joined:
    Oct 28, 2010
    Posts:
    2,318
    Location:
    USA
    Because AV vendors want what they want (ring 0) lol :p
     
  5. 3x0gR13N

    3x0gR13N Registered Member

    Joined:
    May 1, 2008
    Posts:
    802
    Malware will always have the upper hand because unlike AVs, they don't really need to make sure the infection will be stable across windows updates/kernel patches on 64bit for extended periods of time. After a windows patch is issued, rewrite parts of code, reinfect system again to achieve stability over a certain period and wait until it's broken by Windows update again. AVs need to play by MS' rules and provide stability/reliability.
    Also, VBR/MBR rootkits are common on 64bits.
     
  6. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I guess so. Having it would be nice since that way even if malware exploits and gets it the AVs are there to stop it... except it would likely be much more exploitable.

    IDK I don't know enough about it. I have no real-world programming experience.

    The nice thing about Linux is that you can just compile 3rd party security into the kernel with the LSM and you avoid the problem.
     
  7. EraserHW

    EraserHW Malware Expert

    Joined:
    Oct 19, 2005
    Posts:
    588
    Location:
    Italy
    False statement. It is actually possible to work at ring0 and you can even implement your own security solution which is PatchGuard-compliant
     
  8. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    How? Other than with undocumented APIs.
     
  9. EraserHW

    EraserHW Malware Expert

    Joined:
    Oct 19, 2005
    Posts:
    588
    Location:
    Italy
    - Kernel notification routines
    - FS filter drivers
    - WSK drivers

    These are just few examples. Everything is highly documented on the MSDN
     
  10. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    Good to know. Like I said, I have no real world programming experience. Something to read about I suppose.
     
  11. EraserHW

    EraserHW Malware Expert

    Joined:
    Oct 19, 2005
    Posts:
    588
    Location:
    Italy
    To be honest, more than PatchGuard, the real feature which allowed the OS to self-defense against kernel mode malware is the digital signature mandatory check.

    PatchGuard has been conceptually bypassed for years
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I have a few papers about bypassing PatchGuard bookmarked I just haven't really been too interested in reading them. I'll get around to it eventually.
     
  13. MessageBoxA

    MessageBoxA Registered Member

    Joined:
    Jun 20, 2011
    Posts:
    62
    As a security reseacher I don't personally hook SYSENTER as I generally use inline hooks. However I am simply stating the reason why 64 bit operating systems are less protected than older 32 bit operating systems without PatchGuard. The test suite over at Matousec demonstrates this fact.

    Over the past few years I have been working on an experimental sandbox similar to SandBoxie. I implemented a SYSCALL hook with what I guess what you could call 'A SYSENTER Access Mask' that would scan an application before it has been launched and use a deterministic algorithm that could detect which system calls the application required by disassembling the application and looking at the GDI,kernel32 and user32 calls (various other libraries too).

    Let me give an example:

    Windows calc.exe for example does not need to use over 90% of the system calls.

    Have a look: http://j00ru.vexillium.org/win32k_syscalls/

    As you probably aleady know... iexplorer.exe does not need to use the majority of those syscalls. However... iexplorer.exe has access to ALL of them. You can inject a DLL into iexplorer.exe and through the SYSENTER gateway call any system call in that list. Shellcode from exploitA can also access ALL system calls.

    Fact 1.) Most of the zero-day exploits that elevate to kernelmode will do this through a vulnerability in one of the system calls.

    I was successful in blocking a HUGE number of zero-day exploits by using this experimental SYCALL access mask technique. However as you correctly stated... hooking SYSCALL is a hack and should probably not be included in commercial products.

    However as a security researcher... I live, breathe and walk outside of the box and rules that bind security vendors.

    In conclusion... I firmly assert that Microsoft should add a SYSCALL access mask to the PE file specification. The operating system should enforce this access mask and the compiler/linker could easily populate this SYSCALL access mask.

    Then perhaps in the year 2020 when exploit1337 attempts to elevate to kernelmode through... lets say NtUserActivateKeyboardLayout or other system call... it would fail because the iexplorer.exe binary was compiled without a SYSCALL access mask that allowed access to that system call.

    Best Wishes,
    -MessageBoxA

    P.S.
    I do not disagree with you that commercial security products should never hook SYSENTER. However I correctly stated why 64 bit Windows is currently less secure. As everyone knows... most security products for the older 32 bit Windows XP was hooking deep into the kernel. This is exactly why Microsoft put a stop to the practice.
     
  14. EraserHW

    EraserHW Malware Expert

    Joined:
    Oct 19, 2005
    Posts:
    588
    Location:
    Italy
    It demonstrates that most security vendors decided to use undocumented and not recommented ways to work into the kernel mode. When Microsoft decided to stop this practice, everybody complained instead of trying to migrate their solutions to more documented ways
     
  15. MessageBoxA

    MessageBoxA Registered Member

    Joined:
    Jun 20, 2011
    Posts:
    62
    Are you prepared to publically state that PrevX has never used undocumented functions/techniques or hooked kernelmode functions in any of their 32 bit security products? You might want to reconsider your position on that.

    Anyway that really does not matter. Nearly all security vendors in the past had to go through extraordinary measures in an attempt to protect the operating system.

    Best Wishes,
    -MessageBoxA
     
  16. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    365
  17. EraserHW

    EraserHW Malware Expert

    Joined:
    Oct 19, 2005
    Posts:
    588
    Location:
    Italy

    1) Here I'm not speaking on behalf of Prevx, I'm expressing my personal opinion about this topic

    2) I never complained about PatchGuard (or let's call it using the official name, Kernel Patch Protection), I think it's great

    3) Prevx (WSA) is 64 bit compatible, even its security settings, using documented functions
     
  18. trismegistos

    trismegistos Registered Member

    Joined:
    Jan 29, 2009
    Posts:
    365
    Can't help but take a second look at your post which looks like a breakthrough.

    Microsoft should take note of your suggestion. Or most probably they know it all so well. Looks plain simple but why with their dedicated well-paid coders didn't see and implement that crucial step to stop a huge number of exploits as you have tested. Would that be so unprofitable and thus against their Business model as noone_particular would probably say?

    Some of us, the kernel hooks addicts, won't mind if your 'SYSENTER Access Mask' to harden the operating system is an Out of the Box method/tool/solution. Pls PM me how can I go about implementing this experimental Sandbox as you probably don't want this to go public and be the target of ire of the Corporation. jk :)
     
    Last edited: Feb 25, 2012
  19. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,148
    I'd originally assumed that certified applications could bypass patchguard lol
     
  20. guest

    guest Guest

    Perfect. :thumb:
     
  21. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    9,953
    The discussion around system calls, rings, and how userspace system calls are translated into kernel space and all that. Just found some of the discussion to be rather funny. And sad. And funny.
    Mrk
     
  22. MessageBoxA

    MessageBoxA Registered Member

    Joined:
    Jun 20, 2011
    Posts:
    62
    Hi,

    Which part of the discussion did you find funny and which was sad?

    Best Wishes,
    -MessageBoxA
     
  23. Cudni

    Cudni Global Moderator

    Joined:
    May 24, 2009
    Posts:
    6,955
    Location:
    Somethingshire
    ot post removed.
     
  24. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    9,953
    Well, there's the whole issue of what can do what. In theory, if you allow any driver to run in the kernel mode, then it can do anything. It is as simple as that. However, if the driver is not allowed to run there, then it will work partially or not at all. And if you have security products that want full access, but do not get it, then they will fail at their security mechanism, although the security itself, of the system as a whole, may remain untouched. So in a way, testing security that relies on security is a paradox.

    And the bigger question is, what for? Protect against what? Just by reading security advisories, you may assume that something sinister is happening all the time. But it's not. So the whole premise might be wrong or flawed.

    That's how I see it; of course, people who love funny code might be offended by my security boredom statement.

    Cheers,
    Mrk
     
  25. fax

    fax Registered Member

    Joined:
    May 30, 2005
    Posts:
    3,899
    Location:
    localhost
    New tests results....

    http://www.matousec.com/projects/proactive-security-challenge-64/
     
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.