Integrity
Protection Driver (IPD)
A common technique
that hackers use to diguise themselves on compromised systems is
installing a "rootkit", which is typically a program or
suite of programs used to cover up evidence of intrusion and to
hide tojans and other applications and data (such as agents used
in Distributed Denial of Service (DDOS) attacks). One of the most
powerful rootkit techniques is to alter the behavior of the operating
system by running as a kernel driver in privileged mode. These applications
are capable of hiding processes, files, directories, registry keys
and values. They also alter the access control mechanisms and manipulate
the Operating System in other ways.
The IPD uses
some of the same techniques as rootkits to attempt to block new
drivers from being installed or executed by anyone, including Administrator
or System. The goal is to block any new device drivers from executing
at all, even on a compromised system.
How it works
The IPD uses
undocumented service function hooking to alter access rights on
driver-related registry keys, values and files to be read-only no
matter what account is requesting access. This effectively prohibits
the Service Control Manager or user applications from changing service
and driver keys and values in the registry and from adding to or
replacing existing driver binaries in the %SystemRoot%\system32\drivers
directory.
- The IPD
provides Registy protection for existing drivers. It blocks changes
and additions to registry keys and values within the "services"
section of the registy (HKLM\System\CurrentControlSet\Services),
including the ControlSet00x ones.
- The IPD
provides file protection for existing drivers. It blocks the writing,
deleting and adding of files and directories within the %SystemRoot%\system32\drivers
directory (not including the etc directory).
The IPD restricts
all processes except some system processes(*) from obtaining the
following privileges:
- Debug Privilege
- TCB Privilege
- Create Token
Privilege
- Assign Primary
Token Privilege
The IPD forbids
any process from opening \Device\PhysicalMemory.
The IPD forbids
any process, except select system processes, from creating threads
in others processes and from writing in the virtual memory space
of other processes.
(*) See h_tok.c
for a list of the system images that are permitted these privileges.
The IPD starts
immediately at boot time, but does not engage until 20 minutes after
startup.
Obtaining
the Software and Source
Download
the Source and Binaries
The IPD and
accompanying source code are licensed under an Open Source license
that lets you use, view and modify the source code. See the readme
file that accompanies the distribution or click
here
for the precise terms.
Installing
the IPD
To install
the IPD device driver, open a command prompt and change your working
directory to the location of your unzipped distribution. Execute
the ipdinstall.exe program to install and start the driver:
ipdinstall.exe install
The driver
is installed for "automatic" startup, which means it will automatically
start at system boot. The driver engages 20 minutes after it has
started.
IMPORTANT:
* Once the
Driver is started it may not be stopped.
* Once
the Driver is engaged it may not be removed. Even if the appropriate
Service Control Manager function call marks the driver for deletion,
the driver will still not be removed.
Removing
the IPD
IPD can only
be removed before it engages 20 minutes after startup. After removing
the IPD, you must reboot the computer. If the driver has already
engaged then you will have to reboot and remove it within 20 mintes
of boot up.
Issue this
command to remove the dirver:
ipdinstall.exe remove
Is there
a way to circumvent the IPD?
The IPD attempts
to block known methods for loading and executing device driver code.
There may be undocumented or undiscovered methods for installing
and executing driver code. As new methods are discovered the IPD
can be updated to counter those methods.
Functionality
Issues
The IPD is
designed to alter the operating system's normal operating behavior.
In doing so, there will be some loss of functionality. The following
are some of the constraints you may encounter:
\Device\PhysicalMemory
issues:
NTVDM requires
access to \Device\PhysicalMemory on startup. This means that no
16-bit applications will work (unless an NTVDM session was running
before the IPD driver engaged and the 16-bit application is not
configured to run in it's own memory space). Some screen savers
will not work because of this.
Legitimate
device drivers may attempt to open \Device\PhysicalMemory during
normal operation. The IPD will block these attemps and so may cause
unexpected results. So far, we have not encountered any device drivers
that do this after startup.
Debugging Programs:
The IPD blocks
the ability to debug programs.
Support
There is no
support. Bug reports should be sent to
bugs@pedestalsoftware.com.
|