Rootkits Subverting the Windows Kernel
This book is different. Instead of covering the
attacks, this book will teach you how attackers
stay in after the break-in.In the case of forensics,
the discussion is a defensive one—how to detect
the attacker and how to reverse-engineer
malicious code.
Logic Bomb
>law enforcement, pen testers, red teams
The best way to counter forensics is with
stealth: If no attack is suspected, then no
forensics are likely to be applied to the system.
Attackers may use stealth in different ways.
Some may simply try to step lightly by keeping
network traffic to a minimum and avoiding
storing files on the hard drive. Others may
store files but employ obfuscation techniques
that make forensics more difficult.Even if an
attack is suspected and forensics end up being
used a good stealth attack will store data in
obfuscated ways to escape detection.
Stealth is not required is when the attacker
simply wants to crash the target computer.
For example, perhaps the target computer
is controlling an anti-aircraft system.
In this case, stealth is not a concern—just
crashing the system is enough to achieve
the objective.
A rootkit is a "kit" consisting of small and
useful programs that allow an attacker to
maintain access to "root," the most powerful
user on a computer. In other words, a rootkit
is a set of programs and code that allows a
permanent or consistent, undetectable presence
on a computer.
Rootkits are useful only if you want to
maintain access to a system.
Figure 1-1. Menu for a kernel rootkit.
Win2K Rootkit by the team rootkit.com
Version 0.4 alpha
-----------------------------------------
command description
ps show process list
help this data
buffertest debug output
hidedir hide prefixed file or directory
hideproc hide prefixed processes
debugint (BSOD)fire int3
sniffkeys toggle keyboard sniffer
echo
*"(BSOD)" means Blue Screen of Death
if a kernel debugger is not present!
*"prefixed" means the process or filename
starts with the letters '_root_'.
*"sniffer" means listening or monitoring software.
Cyberwarfare
Siberian gas pipeline explosion.
morris
ls (system binaries)
tripwire
Modification-Software
easter eggs
spyware modification
source code mofication
A rootkit will typically be deployed after a
successful software exploit. Many hackers
have a treasure chest of exploits available,
but they may have only one or two rootkit
programs.
A rootkit usually requires access to the
kernel and contains one or more programs
that start when the system is booted. There
are only a limited number of ways to get
code into the kernel (for example, as a
device driver). Many of these methods
can be detected forensically.
One novel way to install a rootkit is to
use a software exploit. Many software
exploits allow arbitrary code or third-party
programs to be installed. Imagine that
there is a buffer overflow in the kernel
(there are documented bugs of this nature)
that allows arbitrary code to be executed.
Kernel-buffer overflows can exist in almost
any device driver (for example, a printer driver).
Upon system startup, a loader program can
use the buffer overflow to load a rootkit.
The loader program does not employ any
documented methods for loading or
registering a device driver or otherwise
installing a rootkit. Instead, the loader
exploits the buffer overflow to install
the kernel-mode parts of a rootkit.
The buffer-overflow exploit is a mechanism
for loading code into the kernel. Although
most people think of this as a bug, a rootkit
developer may treat it as an undocumented
feature for loading code into the kernel.
Because it is not documented, this
"path to the kernel" is not likely to be
included as part of a forensic investigation.
Even more importantly, it won't be protected
by a host-based firewall program.
Only someone skilled in advanced reverse
engineering would be likely to discover it.
It is possible to design a virus or worm
program that spreads via software exploits
that are not detected by intrusion-detection
systems (for instance, zero-day exploits ).
Such a worm could spread very slowly and
be very difficult to detect. It may have been
tested in a well-stocked lab environment with
a model of the target environment. It may
include an "area-of-effect" restriction to keep
it from spreading outside of a controlled
boundary. And, finally, it may have a
"land-mine timer" that causes it to be
disabled after a certain amount of time
—ensuring that it doesn't cause problems
after the mission is over.
The Virus Problem
Even though a rootkit is not a virus, the
techniques used by a rootkit can easily be
employed by a virus. When a rootkit is
combined with a virus, a very dangerous
technology is born.
warhol worms
systems and hardware.
Programming languages that are type-safe
are more secure from certain exploits, such
as buffer overflows. Without type safety,
program data is just a big ocean of bits.
The program can grab any arbitrary handful
of bits and interpret it in limitless ways—
regardless of the original purpose of the data.
For example, if the string "GARY" were
placed into memory, it could later be used
not as text, but as a 32-bit integer,
0x47415259 (or, in decimal, 1,195,463,257
—a rather large number indeed!). When data
supplied by an external user can be
misinterpreted, software exploits can
be employed.Conversely, programs written
in a type-safe language (like Java or C# )
would never convert "GARY" to a number;
the string would always be treated as text
and nothing else.
weakness in software today. It has been the
enabler for thousands of software exploits.
And, it's a bug—an accident that can be fixed.
PREfix and PREfast-Microsoft Tools
States -Particles in UNiverse
A good rootkit should be able to bypass any
security measures, such as firewalls or
intrusion-detection systems (IDSes). There
are two primary types of IDSes: network-based
(NIDS) and host-based (HIDS).Sometimes
HIDSes are designed to try to stop attacks
before they succeed. These "active defense"
systems are sometimes referred to as a
host-based intrusion-prevention systems
(HIPSes).
For the rootkit, the biggest threat is HIPS technology.
A HIPS can sometimes detect a rootkit as it installs
itself, and can also intercept a rootkit as it
communicates with the network. Many HIPSes
will utilize kernel technology and can monitor
operating systems. In a nutshell, HIPS is an
anti-rootkit. This means that anything a rootkit
does on the system most likely will be detected
and stopped. When using a rootkit against a
HIPS-protected system, there are two choices
: bypass the HIPS, or pick an easier target.
NIDS
Network-based IDS (NIDS) is also a concern
for rootkit developers, but a well-designed
rootkit can evade a production NIDS.
Although, in theory, statistical analysis
can detect covert communication channels,
in reality this is rarely done.
Network connections to a rootkit will likely
use a covert channel hidden within
innocent-looking packets. Any important
data transfer will be encrypted. Most NIDS
deployments deal with large data streams
(upward of 300 MB/second), and the little
trickle of data going to a rootkit will pass by
unnoticed. The NIDS poses a larger detection
threat when a publicly known exploit is used
in conjunction with a rootkit. When using a
publicly known exploit, an attacker may
craft the exploit code to mimic the behavior
of an already-released worm (for example,
the Blaster worm). Most security
administrators will mistake the attack
as simply actions of the known worm,
and thus fail to recognize a unique attack.
No comments:
Post a Comment