HIPS with Kernel Patch Protection?

I´ve been reading about Kernel Patch Protection (also known as PatchGuard) and I´ve always wondered why HIPS don´t have the same ability?

Should it be possible for HIPS to protect the Windows kernel?

Stuff that PatchGuard protect against:

 

I got a little bit of feedback from Gullible Jones:

To clarify, I´ve read that PatchGuard is in fact nothing else but a driver (all or most HIPS use drivers), so that´s why I came up with this question.

I do know that HIPS who are running on top of the OS (as hypervisor), have the ability to protect the OS kernel.

Example: Hypersight Rootkit Detector

 

Well, without PatchGuard a HIPS could do all of those things. But PatchGuard is a kernel feature that, by definition, stops programs from being able to just tell the kernel what to do. So all the ways a HIPS would normally do those things are prevented by PatchGuard - except through the APIs provided by Microsoft.

 

Well yes, but that´s not exactly what I meant.

I know that PatchGuard denies the ability to modify the kernel, bad for rootkits, and also a bit bad for HIPS on 64 bit (the good guys).

But I´ve never really seen a HIPS (32 or 64 bit) with the same abilities as PatchGuard. I wonder why?

So if you look at it from a technical point of view, is it even possible for HIPS to stop a rootkit (loading a malicious driver) from modifying for example the SSDT?

 

I can't comment on more recent HIPS but earlier ones like SSM hooked hundreds of addresses and functions in the SSDT. A report generated by RootKit Unhooker on an XP-SP2 unit running the free version of SSM shows over 280 hooks. Here's the first 50 items from such a report, which includes a few from the firewall.

Code:

> SSDT State
NtAccessCheck
Actual Address 0xF86357AA
Hooked by: safemon.sys
NtAccessCheckAndAuditAlarm
Actual Address 0xF86357B4
Hooked by: safemon.sys
NtAccessCheckByType
Actual Address 0xF86357BE
Hooked by: safemon.sys
NtAccessCheckByTypeAndAuditAlarm
Actual Address 0xF86357C8
Hooked by: safemon.sys
NtAccessCheckByTypeResultList
Actual Address 0xF86357D2
Hooked by: safemon.sys
NtAccessCheckByTypeResultListAndAuditAlarm
Actual Address 0xF86357DC
Hooked by: safemon.sys
NtAccessCheckByTypeResultListAndAuditAlarmByHandle
Actual Address 0xF86357E6
Hooked by: safemon.sys
NtAddBootEntry
Actual Address 0xF86357FA
Hooked by: safemon.sys
NtAdjustGroupsToken
Actual Address 0xF8635804
Hooked by: safemon.sys
NtAdjustPrivilegesToken
Actual Address 0xF863580E
Hooked by: safemon.sys
NtAlertResumeThread
Actual Address 0xF8635818
Hooked by: safemon.sys
NtAlertThread
Actual Address 0xF8635822
Hooked by: safemon.sys
NtAllocateLocallyUniqueId
Actual Address 0xF863582C
Hooked by: safemon.sys
NtAllocateUserPhysicalPages
Actual Address 0xF8635836
Hooked by: safemon.sys
NtAllocateUuids
Actual Address 0xF8635840
Hooked by: safemon.sys
NtAllocateVirtualMemory
Actual Address 0xF863584A
Hooked by: safemon.sys
NtAreMappedFilesTheSame
Actual Address 0xF8635854
Hooked by: safemon.sys
NtAssignProcessToJobObject
Actual Address 0xF863585E
Hooked by: safemon.sys
NtCallbackReturn
Actual Address 0xF8635868
Hooked by: safemon.sys
NtCancelDeviceWakeupRequest
Actual Address 0xF8635872
Hooked by: safemon.sys
NtCancelIoFile
Actual Address 0xF863587C
Hooked by: safemon.sys
NtCancelTimer
Actual Address 0xF8635886
Hooked by: safemon.sys
NtClearEvent
Actual Address 0xF8635890
Hooked by: safemon.sys
NtClose
Actual Address 0xF2CFDD1E
Hooked by: C:\WINDOWS\system32\Drivers\fwdrv.sys
NtCloseObjectAuditAlarm
Actual Address 0xF86358A4
Hooked by: safemon.sys
NtCompactKeys
Actual Address 0xF86358AE
Hooked by: safemon.sys
NtCompareTokens
Actual Address 0xF86358B8
Hooked by: safemon.sys
NtCompleteConnectPort
Actual Address 0xF86358C2
Hooked by: safemon.sys
NtCompressKey
Actual Address 0xF86358CC
Hooked by: safemon.sys
NtConnectPort
Actual Address 0xF86358D6
Hooked by: safemon.sys
NtContinue
Actual Address 0xF86358E0
Hooked by: safemon.sys
NtCreateDebugObject
Actual Address 0xF86358EA
Hooked by: safemon.sys
NtCreateDirectoryObject
Actual Address 0xF86358F4
Hooked by: safemon.sys
NtCreateEvent
Actual Address 0xF86358FE
Hooked by: safemon.sys
NtCreateEventPair
Actual Address 0xF8635908
Hooked by: safemon.sys
NtCreateFile
Actual Address 0xF2CFD62B
Hooked by: C:\WINDOWS\system32\Drivers\fwdrv.sys
NtCreateIoCompletion
Actual Address 0xF863591C
Hooked by: safemon.sys
NtCreateJobObject
Actual Address 0xF8635926
Hooked by: safemon.sys
NtCreateJobSet
Actual Address 0xF8635930
Hooked by: safemon.sys
NtCreateKey
Actual Address 0xF863593A
Hooked by: safemon.sys
NtCreateMailslotFile
Actual Address 0xF8635944
Hooked by: safemon.sys
NtCreateMutant
Actual Address 0xF863594E
Hooked by: safemon.sys
NtCreateNamedPipeFile
Actual Address 0xF8635958
Hooked by: safemon.sys
NtCreatePagingFile
Actual Address 0xF8635962
Hooked by: safemon.sys
NtCreatePort
Actual Address 0xF863596C
Hooked by: safemon.sys
NtCreateProcess
Actual Address 0xF2CFDC92
Hooked by: C:\WINDOWS\system32\Drivers\fwdrv.sys
NtCreateProcessEx
Actual Address 0xF2CFDC17
Hooked by: C:\WINDOWS\system32\Drivers\fwdrv.sys
NtCreateProfile
Actual Address 0xF863598A
Hooked by: safemon.sys
NtCreateSection
Actual Address 0xF2CFD713
Hooked by: C:\WINDOWS\system32\Drivers\fwdrv.sys
NtCreateSemaphore
Actual Address 0xF863599E
Hooked by: safemon.sys

I'm not sure how one would compare the abilities of Patch Guard and a classic HIPS without analyzing each function and comparing that to what each allows or prevents, and for what processes/services.

 

Why none for x64? That would require changing the kernel, and that's stopped by you-know-what.

Why none for x86? See PatchGuard and Vista x86.

 

@ noone_particular and MrBrian

Don´t take this the wrong way, but I believe you´re misunderstanding the question.

Let´s say KPP (PatchGuard) didn´t even exist. Why has no one ever implemented KPP into a security product (HIPS)? Perhaps because it isn´t possible because of the design of Windows? Or perhaps it´s too difficult too implement? That´s the question.

 

But I´ve done some more reading about KPP and apparently not even Microsoft could make it work as a real-time HIPS. So I think that the only way to protect to OS is by running on-top of the OS (as hypervisor), instead of inside the OS. And this kinda tech is currently only available for the enterprise.

Examples:

McAfee Deep Defender (Almost the same as KPP, but even better)
Bromium vSentry (not the same as KPP, but does run on top of the OS, it´s basically a sandbox)

 

Interesting; polling like that is not particularly useful, I'd think.. Especially at such long intervals! By the time it kicked in, the patch protection components themselves could be subverted.

Re doing this stuff on an enterprise level using a hypervisor, I'm actually not sure I see the point. If a VM appears to be compromised, you want to roll it back (or replace it with a new one) immediately, IMO.

(Could be my bias showing though. I tend towards immediate distrust of anything from McAfee.)

 

Agreed. The early versions of SSM used polling on its registry, services, and other modules. Repeatedly checking the same objects, be it the registry or sevices was very processor intensive. Polling is a reactive solution, not a proactive one. If malicious code can subvert the SSDT, what prevents it from subverting the OS components that poll it or changing the polling frequency from 5 or 10 minutes to 5 years?

 

Yes, I was thinking the same, but it´s probably because of the way Windows is designed. It´s simply impossible to do this in real time.

KPP is working on the same level as all other drivers, so that´s why everybody is saying that it´s not perfect, as seen above.

But at least KPP is trying to protect the OS kernel, while HIPS have never been able to do this.

So perhaps security companies shouldn´t have wined about KPP that much. Of course I understand why they did complain, that´s not the point.

 

I think you´re looking at it the wrong way, this is not about protecting VM´s, it´s about protecting the OS against advanced attacks that normal HIPS (that we´re all using) can´t protect against.

Just to give an example: Currently, HIPS can´t fully protect against a malicious driver (rootkit) that´s already loaded. This has always bothered me. However, HIPS that run as hypervisor are easily able to stop these kind of attacks. That´s because they´re running in a more privileged mode than rootkits (and other malware).

That´s why I´m very excited about a tool like McAfee Deep Defender. I wonder how long it will take before this will be available for home PC´s.
Perhaps Microsoft will make KPP act like a hypervisor in Windows 9?

 

I'm at a loss as to how one would end up in the scenario you describe with your example. The only ways I can think of that a malicious driver would get past a classic HIPS are:
1, It was part of the OS to start with.
2, It was installed before the HIPS.
3, The user specifically allowed it to be installed.
None of these point to a failure of the HIPS.

 

HIPS are not designed to protect you against something that you allow to load on your system. A good HIPS may still prompt you as the infection begins to spread, and spawns new processes if the malware does not kill the HIPS. The HIPS may also still prompt you if the malware begins to download additional malicious threats upon them executing. Once you allow something like that to load on your system you will have to rely on a black list method security approach that uses signatures to try to remove the threat. The only other option you have is trying to minimize the damage by containing the threat to certain areas of the OS. Appguard would do this if you was already infected by using policy to contain the infection. This would only restrict the infection from further spreading to an extent.

 

Re Deep Defender, I meant in enterprise environments where VMs are pretty much expendable. It might be more useful for end users though. (But again, I instinctively distrust anything from McAfee for various reasons.)

Anyway, the mistake I think some of you people are making is to think of computers as having/needing immune systems. This is a really flawed analogy; software is not resilient like a biological organism. Once software is compromised, that's it, it's compromised - you can't (reliably) erase the malicious code from the compromised program's memory space.

http://technet.microsoft.com/en-us/security/bulletin/ms13-081

^^^ A vulnerability such as the above can bypass a HIPS, since it jumps straight to the kernel level before the payload executes.

Come to think of it the same could probably happen with the infamous "shatter attacks" on Windows XP. If the HIPS doesn't confine a privileged service (i.e. one that runs as SYSTEM user), and that service gets exploited, then it could unload the HIPS driver and run a payload.

 

hi
The limit is on the terminology itself, HIPS, and H as host.
An HIPS is a third party software designed to add another security layer in order to protect the system, but it can not be a substitute to the OS itself.
Kernel patch are for the OS http://msdn.microsoft.com/en-us/windows/hardware/gg487353.aspx

More over, it is important to remember that what is possible with Open Source code is not always possible with proprietary code like Windows.
Kernel patch are more used in Linux, from system hardening, like Grsecurity to the Hytux hypervisor project http://www.laas.fr/TSF/20-29916-Operating-system-kernel-protection.php
Regarding Windows, there is, as far as a know, no kind of desktop HIPS that can provide the same value as OS/Ring 0 patching.
There is risk management and assessment services, as for instance Vupen, that helps organizations to be patched before the zero day is published.
http://www.vupen.com/english/services/tpp-index.php

There is of course hardening HIPSs, available for the desktop environment, that mitigate impact of kernel (or not) vulnerabilities, like BufferShield or PreEmpt for instance http://www.sys-manage.com/buffershield/tabid/61/default.aspx http://pivx.com/HomeOffice/
It is true that McAfee was active about Patchguard, and as interesting is their technology, this is not the panacea as pointed out Qubes mother
http://theinvisiblethings.blogspot.fr/2012/01/thoughts-on-deepsafe.html

In fact, for a military grade protection, this is not an HIPS patch that is required, as integrity control of code/file and execution must be done before the Bios, not only before the OS.
Virtualisation/Hypervisor technology is used in military grade OS, from LynuxWorks, GreenHills or Bertin/Polyxene solutions that have already discussed on this board http://www.polyxene.fr http://www.ghs.com/products/rtos/integrity_virtualization.html
An OS is a giant puzzle of codes, and as all pieces of code can not be perfect in general, we must accept regular updates and kernel patch in particular.
Now for those who are interested in experimentation, there is some research project that have been published, like TrustVisor, but i seriously do not see the real need http://xmhf.sourceforge.net/doc/trustvisor/
As usual, expecting and building absolute security, and we forget why we use a computer.
Edited links
Rgds

 

I would need to see and test such an exploit and the mechanisms by which it could be delivered in order to determine if classic HIPS can defend a system against it.

 

Yes, I was wondering how such a threat would end up on one's machine to begin with. I'm no exploit expert, but I think it would be safe to say this would be a rare threat to encounter. I would still like to obtain some samples once I get my test machines back so I can see which products if any stop such a kernel level threat. How would such a kernel threat realistically enter one's machine? What vessel would it use? Most threats use java script, iframes, exploits in adobe products, exploits in java, outdated plugins in the browser, unpatched applications in general, flash drives, etc..

 

Metasploit has it:

exploit/windows/browser/adobe_flash_otf_font

In that case it would be delivered against an unpatched system with a Flash applet, which a HIPS would not block. IIRC there are also versions that use binary content embedded in Office documents (but don't quote me on it). Theoretically anything using OpenType fonts could be used to deliver it.

That said, chances are IMHO pretty high that none of us will ever encounter ITW malware that uses it, or anything like it.

 

IOW, it's delivered via the usual attack surfaces and either requires the users browser to automatically play flash, java, or open PDFs which contain that code, or the user has to choose to click on the file and launch it in an insecure environment.

 

From GJ's link:

I suppose it's just as possible for a user to stumble upon or even knowingly visit such a website that contains the attack code. Browser scripting control might come in very handy in these cases.

 

I use NoScript, but I don't always have it fully enabled. Most of the time I encounter a virus on a webpage I test it against NoScript by fully enabling NoScript, and visiting the page again. No script has blocked the redirect, or vessel of delivery every single time. If you want to find some viruses to test No Script against usually all you have to do is do a google image search on something that is trending. Virus writers are smart. They want to expose as many people as possible to their code. There's also the sites that list current infected webpages.

 

Thanks for all the input.

But I think some of you are over analyzing it a bit. The only thing that I´m saying is: KPP is very cool, but it should become stronger. The only way to that is by making it work as hypervisor.

http://www.intel.com/content/www/us...fender-deepsafe-rootkit-protection-paper.html

I agree, but how cool would it be if you could get a second chance? An example: By mistake you have allowed a malicious driver to run on the system, but not to worry, KPP (hypervisor) can still stop the rootkit! It would be basically yet another layer.

 

I agree that the chance is quite small, but it´s still possible.

How does a malicious driver get loaded?

1 Rootkit is able to bypass KPP (exploit)
2 Rootkit is able to bypass HIPS (exploit or bug)
3 Rootkit is installed by user (wrongfully trusted app)

Yeah, but she´s negative about almost all security tools. She´s a very smart lady, but should become a bit more realistic.

 

On the other hand, she's an OS security expert, which means she's one of the people who gets to define what constitutes "realistic." Just sayin'.

Edit: Also I think the old Shelley quote about progress depending on "unreasonable men" might apply. An OS that implements reliable security by isolation is not practical... yet. 200 years ago, neither was a heavier-than-air flying machine.