Statistics

Members: 1925
News: 293
Web Links: 1
Visitors: 3830388

Who's Online

Damn Vulnerable LinuxDamn Vulnerable Linux (DVL) is a Linux-based (modified Damn Small Linux) tool for IT-Security & IT-Anti- Security and Attack & Defense. [CLICK HERE FOR MORE INFOS! ]

Featured Conference Video

T16-Recon2006-Joe_Stewart-OllyBonE.gif OllyBone - Semi-Automatic Unpacking on IA-32. View the conference video here!
Home
Secure Window’s Kernel with TPM
User Rating: / 11
PoorBest 
Written by Pranav Sharma   


Now days in era of IT world everything evolves around computers. Today’s computer store vital user data and intricate softwares. The spine for computers is agile Kernel which hosts the unswerving operating system (OS). The kernel should be open enough to allow diverse third party softwares run resourcefully without any limitations while maintaining its security and integrity. To protect system code and data from being overwritten maliciously or inadvertently by code of a lesser privilege, Windows allows differentiation between privileges in its user and kernel mode processes.

Patchgaurd for Windows Vista is fairly known but its execution hampers the functioning of third party competent tools, however disabling it makes kernel prone to malicious attacks leading to OS crash. In this paper I am introducing a technique to secure kernel using Trusted Platform Module (TPM) which maintains Windows kernel security while allowing open interactions in parallel. The idea overcomes full or none security limitations of Microsoft patchgaurd, by allowing opportunity to simply install and work with trusted list of vendor softwares while restricting un-trusted ones. While the patchgaurd is applicable for Windows Vista only, the provided solution is suitable for older flavors like Windows2000 and XP also.

The intended audiences for this paper are researchers or security groups which strive to provide trustworthy and robust security solutions to their customers.

Kernel Vulnerabilities Overview:

 

Outside the context of approved modifications any change to windows critical structures lead to BSOD (Blue screen of death) and kernel instability. Most kernel implementations do not provide a mechanism by which its critical portions can be confirmed to ensure that they have not been tampered with. Following critical kernel structures are under threat:

  1. SSDT (System Service Descriptor Table)

It contains the information about the service tables that are used by operating system for dispatching system calls. This is the most prone area and is hooked by notorious hackers with their drivers. It is created during the initialization of NTOSKRNL. Each entry in the table contains the address of the function to be executed for a given service ID.

  1. GDT (Global Descriptor Table) and IDT (Interrupt Descriptor Table)

It describes the memory segments which are used by kernel. It is special area of interest to malicious applications as modifying its certain key entries allows less privileged applications to play around with kernel memory. IDT is hooked to intercept certain hardware or software interrupts before they are handled by kernel.

  1. System images (ntoskrnl.exe, ndis.sys, hal.dll)

  1. Processor MSR

It is initialized by x64 kernel to nt!KiSystemCall64 during boot. Modifying the address of this register can also lead to OS unsteadiness. Latest processors have dedicated instruction set to dispatch system calls for example: Syscall and Sysenter. Before this Windows, was forced to dedicate a soft-interrupt for exclusive use as a system call vector. These instructions take advantage of processor defined model specific register which holds the address of routine that is intended to gain control in kernel mode when a system call is received.

TPM Overview:

Trusted platform module is a sealed standalone hardware module to store, generate and manage secure keys. It provides high root of trust and numerous benefits over straightaway storing keys in unsecure devices like disk or memory. Few known benefits of TPM are:

  1. Support for standard encryption algorithms like RSA, SHA etc.
  2. Cryptographic Co-processor to do fast and standalone encryption and decryption operations.
  3. IO for protected messaging with external and internal communication bus.
  4. HMAC engine to validate authdata and command alterations while in transit.
  5. Platform Configuration Register to achieve AIK attestation, sealed storage and platform boot.
  6. Trusted Computing Group standard set of API to work.

Problem Context:

There are numerous ways by which kernel structures can be modified which lead to OS failure, few of them are:

  1. Dll injection and Dll forwarding
  2. Documented or un documented Win API
  3. Kernel mode and user mode drivers

These functionalities provided by windows can be exploited for both evil and fine intentions. A rootkit utilize them for malicious purposes while an antivirus employs them for fine purpose. The problem lies with identifying and allowing the right level of access and privileges to individual application or driver. The trusted tools should not be restricted to any valid level access while untrusted should not be allowed to run in kernel mode. Below mentioned samples provide evidences how the abovementioned features can be exploited.

SSDT hooking by API leading to OS crash

System Service Description Table is created during the initialization of NTOSKRNL Each entry in the table contains the address of the function to be executed for a given service ID. The INT 2Eh handler looks up this table based on the service ID passed in EAX register and calls the corresponding system service. The code for each function resides in the kernel and the memory pages of this are protected to be read and written from kernel mode only. The easiest way to put a hook into the system services is to locate the SSDT used by the operating system and change the function pointers to point to some other malicious function.

NTDLL,Dll functions are provided as wrapper on NTOSKRNL These wrappers use the INT 2E instruction to switch to the kernel mode and execute the requested system service. A system service can be easily called through these various Win32 API available in KERNEL32.Dll and ADVAPI32.Dll.The sample below brings BSOD from a simple user mode API MapViewOfFile by using above mentioned technique and illustrate how easily kernel can be hooked .

KernalMem.exe

GDT and IDT hooking by driver leading to OS crash

Global Description Table describes the memory segments which are used by kernel. It is special area of interest to malicious applications as modifying its certain key entries allows less privileged applications to play around with kernel memory.

The Interrupt Descriptor Table is hooked to intercept certain hardware or software interrupts before they are handled by kernel. Win DDK does provide functions such as HalGetInterruptVector() and IoConnectInterrupt() to hook hardware interrupts for NT systems. Intel’s data structures –IDTR and Interrupt Gate Descriptor can be easily discovered through sidt Assembly instruction. This instruction places the base and limit of IDT in a 6-byte location specified by the operand. Once you get the base address of IDT, you can index the interrupt number you want to hook in this table and change the Old stack of registers. Example :

IntHook.cpp

Proposed Solution:

  1. Software Implementation

If once crooked driver gets installed or user mode application penetrates into kernel mode then there are seldom methods to restrict those committing blunders. So the solution is to initially restrict application or driver entering such domain. It can be provided through installing the developed kernel patch, ideally it should be installed after every fresh operating system install before loading the machine with other third party tools. After installation of the kernel patch application, as shown above, all calls will be routed after verifying the trust worthiness of vendor from TPM. Only allowed or trusted application vendor tools can be installed. Such early discovery of un trusted application access to kernel, escort to quick remedial action. Various proactive methods which will be implemented in kernel patch application to secure kernel are:

(1/2) Core API access control to prevent kernel API access, kernel Dll injection and forwarding

NtDll.dll exports a set of functions that begin with the Nt prefix. Most of these function use interrupt 2E to transfer the control handle to kernel. For example, when a Windows application issues a call to CreateFile located in kernel32.dll, the call is redirected to NtCreateFile, which passes it on to NT's kernel for further processing. The special design of this mechanism allows a device driver to hook these interfaces, thus providing a way for monitoring activities performed by Windows NT/2000 applications. Providing a top level kernel driver to provide access to abovementioned API only to authenticated set of user mode applications will in turn secure the vital kernel data structures. Only signed vendors applications obtained from TPM should be allowed to work with these critical API.

(3) Driver signing and validation to prevent untrusted or malicious driver installation

Windows NT/2000 offers monitoring functionality through the use of the undocumented PsSetCreateProcessNotifyRoutine function exported from NTOSKRNL. This function allows a device driver to register a callback function that receives notifications from the operating system whenever a new process is started. Driver can be developed keeping the tips to decipher the malicious instincts.

Further a mechanism to mandate deriver installer verification can prevent malicious rootkits and hackers accessing the kernel data structures. Only signed drivers from trusted vendors list obtained from TPM should be allowed to be installed in machine.

  1. TPM Implementation Architecture

The TPM is especially designed to act as root of trust for the collection and reporting of integrity metrics. It works in eight modes which are in different combination of:

1 Enabled / Disabled

2 Active / Inactive

  1. Owned / Unowned

Each TPM module has a unique endorsement key pair EK which are generated by random number generator module. The private part of key always resides in TPM and maintains its identification. Since the private key to decrypt the data resides in TPM, only genuine machine can retrieve the information. The keys always adhere to guidelines provided by FIPS and are never accessible without authorization .This EK is used to further generate Attestation Identity Keys AKI. These AKI are used to sign all data which originates from it.

The attestation process involves standard cryptographic methods. A remote client generates a random value (called a nonce or challenge), and sends it to the server. At that system, the TPM creates a record containing the nonce and the current PCR values .The TPM signs this record with its private key and the signed record is returned to the client, along with the public key and credentials. The client then uses the public key to verify the signature on the record and, then extracts the data from the record. Then client passes encrypted request to administrator server with server’s public key and its private key. Server authenticates the client request and as per the user privileges, it creates a response encrypted with his private key and client’s public key and forwards it to client. The authenticated client who already holds the server public key decrypts the policy sent, by server public key and his own private key. Client stores the file in its local drive for future references as it can be required when client is not connected to server or wants to work in offline mode. This policy will be renewed with latest copy after regular intervals if there are any changes. Security is maintained as private keys of both client and server are stored in their respective TPM which is reliable root of trust. The policy is used by above mentioned security application to allow or restrict client machine third party tools and softwares.

Limitations:

  1. The solution is catering limited set of API and methods to corrupt kernel, while there exists much more undocumented API and ways which should be incorporated into the solution to confirm absolute kernel safety.

  1. Since external software vendors can not be forced to provide digital signatures along with their installations, the mechanism to validate trust of vendor just by name is implemented.

  1. EK is unique to each TPM module, so in case of TPM’s failure or change its data becomes unusable.

Future enhancement:

Maintaining checksum of various critical structures along with last working XORed cached copies of kernel structures can in turn provide some opportunities to recuperate from the unrecoverable conditions like BSOD. Software polling can also be provided which can recurrently keep vigilance on the serious data structures to track any unwanted in consistencies and can keep on backup of healthy last working kernel structures copy. Further if installation of one driver has ceased the system operations then it can be automatically disabled in subsequent reboot after such failure. These measures help to mitigate the risk by taking preventive actions avoiding further upcoming failures. Further logs of application using Kernel API every now and then can be maintained to keep track of possible infecting application. For more security concerns DLL forwarding with hooking along with registry keys prone to attack can be restricted on the basis of application privileges

Conclusion:

Preventive access to kernel as per the vendor credibility is the desirable solution to make OS stable. It concurs to user’s third party tools benefits along with harnessing OS flexibility and maintaining OS stability side by side. TPM is desired, reliable and trust worthy hardware solution while OS booting and after booting to maintain the integrity and guard critical information.

References:

Jeffrey Richter

Programming Applications for Microsoft Windows fourth edition. Microsoft Press

Sven B. Schreiber

Undocumented Windows 2000 Secrets - A Programmer's Cookbook, Addison-Wesley

Walter Oney

Programming the Microsoft Windows Driver Model by Microsoft Press