kernel mitigations_kernle 4.19 mitigations-CSDN博客

*原文链接：Kernel Mitigations - CNO Development Labs (cnotools.studio)

*关于windows kernel mitigations

In this section, we shall take a brief look at some of the Windows kernel mitigations that might hinder or completely block our exploits. Additional details and how to bypass/overcome each of these obstacles(if possible) will be discussed later as per the exploitation scenario.

Kernel Patch Protection(KPP)

Also known as Patch Guard(PG), this is one of the more prominent and effective anti-tampering kernel mitigations aimed at stopping rootkits(and shady software including PSPs) from ravaging around the kernel to accomplish their objectives such as AVs hooking System Service Descriptor Table(SSDT) to gain visibility into system calls etc. It was first introduced in Windows XP x64.

Remember that x86 systems do not have KPP enabled not even on the latest versions.

KPP is designed to detect any changes to critical Windows kernel structures/registers and bugcheck(Code: 0x109/CRITICAL_STRUCTURE_CORRUPTION) or crash the system with a much dreaded Blue/Green Screen Of Death(BSOD/GSOD).

However, it is polled and the beauty of KPP lies in its randomness(apart from its obfuscation) of these checks which means it is quite possible that the changes are not caught instantly but after some time has passed by. This way it takes away the reliability from hooking random stuff in the kernel even if it cannot stop it right away.

As a general rule of thumb, keep in mind that PG checks run every 5-10 minutes.

Bypasses do exist against KPP but since it is a moving target, vulnerabilities may be fixed as happened with InfinityHook. Also, note that KPP may be disabled by using a bootkit or hooks can simply be hidden using EPT/NPT ghost hooks by loading a rogue hypervisor.

Astute readers may observe that there's nothing stopping us from tampering whatever we want in the kernel for an extremely short duration of time to accomplish our goals and then reverting the changes immediately before KPP even gets a chance to trigger on it and none will be the wiser.

Well, this sounds nice in theory, however, since we have no way of knowing when the value was last checked, doing this has a very real(albeit small) chance of BSODing a target system. In our job, no matter how small the chances are, this is not recommended at all and should only be considered as a last resort option.

Remember that KPP is disabled when remote kernel debugging(not lkd) is enabled.

References

1,kernel patch protection:https://en.wikipedia.org/wiki/Kernel_Patch_Protection

2,PatchGuard Analysis from Tetrane:https://blog.tetrane.com/downloads/Tetrane_PatchGuard_Analysis_RS4_v1.01.pdf

3,Subverting PatchGuard Version 2 by Skywing:Uninformed - vol 6 article 1

4,InfinityHook By Nick Peterson:GitHub - everdox/InfinityHook: Hook system calls, context switches, page faults and more.

5,ByePg by Can boluk:GitHub - can1357/ByePg: Defeating Patchguard universally for Windows 8, Windows 8.1 and all versions of Windows 10 regardless of HVCI

6,EfiGuard:https://github.com/Mattiwatti/EfiGuard

7,gbhv:https://github.com/Gbps/gbhv

8,What are little PatchGuard made of? by alex ionescu :https://web.archive.org/web/20150920231011/http://www.alex-ionescu.com/?p=290

9,GhostHook by kasif dekel:GhostHook – Bypassing PatchGuard with Processor Trace Based Hooking

Driver Signature Enforcement(DSE)

Also known as Kernel Mode Code Signing(KMCS), it is another prominent and quite effective mitigations to ensure that all kernel drivers are properly signed with a valid digital signature. It was first introduced in Windows Vista x64.

Remember that x86 systems do not have DSE enabled not even on the latest versions.

Starting from Windows 10 RS1/1607, DSE allows third-party drivers to be loaded iff:

1. Driver is Attestation Signed(signed using Extended Validation(EV) code signing certificate + countersigned by Microsoft Windows Hardware Compatibility Publisher)

2. Driver is Windows Hardware Quality Labs/WHQL-testing Signed

However, there are three notable exceptions to this rule under which it will still allow a driver to load:

1. SecureBoot(SB) is turned off from UEFI settings OR

2. The system was upgraded from an earlier version or a build earlier than Windows 10 RS1/1607 OR

3. Driver was Cross Signed using a valid certificate issued prior to 29th October, 2015

There's a driver blacklist in the form of a Shim Database File(SDB) for use by Kernel Shim Engine(KSE)that blocks some known bad vendor drivers from loading. It is located at: C:\Windows\AppPatch\drvmain.sdb and can be examined by SDBExplorer.

Note that WHQL-testing is mostly automatic and it is not unusual for bad drivers to slip past testing and get certified.

Some bypasses include temporary patching of a global variable that controls DSE - ci!g_CiOptions(KPP-protected) by exploiting a vulnerable signed driver, using kernel shellcode/PIC as the payload instead of a driver or acquiring valid certificates from third-parties.

DSE may be turned off forcefully by enabling Test Signing mode from an admin prompt and rebooting:

bcdedit /set testsigning on

References

1,Microsoft's driver signing policy:Driver Signing Policy - Windows drivers | Microsoft Docs

2,Back doors for cross-signed driver by Geoff Chappell:Back Doors for Cross-Signed Drivers

3,A quick insight into the Driver Signature Enforement by j00ru:A quick insight into the Driver Signature Enforcement | j00ru//vx tech blog

4,Windows driver signing bypass by desubi:Windows driver signing bypass by Derusbi – Where security meets innovation

5,tdl by hfiref0x :GitHub - hfiref0x/TDL: Driver loader for bypassing Windows x64 Driver Signature Enforcement

6,kdu by hfiref0x :GitHub - hfiref0x/KDU: Kernel Driver Utility

7,DSEFix by hfiref0x :GitHub - hfiref0x/DSEFix: Windows x64 Driver Signature Enforcement Overrider

8,Stryker by hfiref0x: GitHub - hfiref0x/Stryker: Multi-purpose proof-of-concept tool based on CPU-Z CVE-2017-15303

9,DRIVERMAIN.SDB by geoff chapplle:DRVMAIN.SDB

10,Getting a kernel mode driver signed for win 10:Driver Signing | Add, Subtract, or Die!

Kernel Address Space Layout Randomization(KASLR)

KASLR is designed to prevent predicting addresses of some desired kernel memory by randomizing the base address of the kernel image, kernel modules and device drivers on a per-boot/load basis. It was first introduced in Windows Vista.

Over the years, it has undergone some significant changes like High Entropy ASLR(22 bits of entropy) and Force ASLR(randomize even for non-ASLR compiled modules) along with the information disclosure leaks that have been fixed by Microsoft make this a truly effective mitigation.

Remember that KASLR is meant to protect against REMOTE kernel exploits and not LOCAL exploits. This is because it is trivial to retrieve the base address of a kernel module from a Medium-IL process as compared to a Low-IL/sandboxed process.

Some of the interesting changes made to KASLR over the years are:

1. The offset of Self-Reference PML4E has been randomized from the static value of 0x1ed. This consequently leads to VA randomization of the base of paging structures(PxE) and its entries

2. Kernel address leak from GDI objects have been fixed

3. Kernel address leak from DesktopHeap(TEB) and GdiSharedHandleTable(PEB) has been fixed

4. Kernel address leak from SGDT/SIDT instruction is fixed when VBS is enabled

5. Low-IL processes cannot use NtQuerySystemInformation() or EnumDeviceDrivers() to leak kernel addresses

6. HAL Heap VA is now randomized

There exists bypasses against KASLR but they usually rely on additional vulnerabilities in the form of information leaks.

References

1,software defense：mitigating common exploitation techinque:Software defense: mitigating common exploitation techniques – Microsoft Security Response Center

2 i got 99 problems but a kernel pointer anit one https://www.youtube.com/watch?v=5HbmpPBKVFg

3,windows kernel address leaks by sam brown :GitHub - sam-b/windows_kernel_address_leaks: Examples of leaking Kernel Mode information from User Mode on Windows

Data Execution Prevention(DEP)

DEP is designed to prevent code execution in non-executable portions of memory/data segment of memory. In other words, DEP ensures that no memory page is both writable and executable(W^X) simultaneously. It was first introduced(fully) in Windows 8.

Remember that DEP is enforced both via software and hardware support.

Since Windows 8, drivers now have a pool type known as NonPagedPoolNx which essentially marks it as non-executable non-paged memory pool.

DEP is enforced on a per-page basis via a Page Table Entry(PTE) control bit known as NoExecute(NX) bit.

Some bypasses include using Return Oriented Programming(ROP) payload in the kernel/re-using existing kernel code to execute our code, flipping the NX bit in the PTE or redirecting execution flow to a User-Mode(UM) allocated page.

DEP may be turned off forcefully by running the following command from an admin prompt and rebooting:

bcdedit.exe /set nx AlwaysOff