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:
- 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.
- 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.
- System
images (ntoskrnl.exe, ndis.sys,
hal.dll)
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:
- Support for standard encryption algorithms like RSA, SHA etc.
- Cryptographic Co-processor to do fast and standalone encryption
and decryption operations.
- IO for protected messaging with external and internal
communication bus.
- HMAC engine to validate authdata and command alterations while in
transit.
- Platform Configuration Register to achieve AIK attestation, sealed
storage and platform boot.
- 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:
- Dll injection and Dll forwarding
- Documented or un documented Win API
- 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:
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.
- 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
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:
- 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.
- 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.
- 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
|