Stop Root Kits Before They Touch Your Network - Embedded.com

Stop Root Kits Before They Touch Your Network

The root kit is the stealthiest and most dangerous form of malware (malicious software) at large today. A root kit is a package of software that installs itself on a system and then modifies the operating system to mask the root kit's existence. The fact that a root kit masks its existence by modifying the operating system means that it can be very difficult to detect a root kit after it's installed.

But by using Trusted Hardware and Network Access Control together, it's possible to reliably detect root kits and also to prevent their installation in the first place.

This practice is not theoretical. In fact, it's becoming increasingly popular in high-security environments where systems must be secure. Even better, the Trusted Computing Group has developed standards to ensure multi-vendor interoperability in this area: Trusted Platform Module (for Trusted Hardware) and Trusted Network Connect (for Network Access Control). A list of products that implement these standards is included on the Trusted Computing Group web site.

The Dangers of Root Kits
Why is it so important to detect root kits? A root kit can change the behavior of a system subtly and without detection. Passwords and other sensitive data on the computer can be logged and sent abroad for criminal exploitation. File servers and databases can be probed to extract or delete valuable information. Other systems can be infected.

Resources can be used for criminal enterprises such as storing illegal data (like stolen credit card numbers) and mounting Distributed Denial of Service (DDOS) attacks. Or the root kit can be programmed to lie low until activated by remote control, making it a “bot” or “zombie”. A bot is like the Manchurian Candidate depicted in the Frank Sinatra film of the sixties, a highly dangerous element that can explode at any time.

The development of root kits has become a business. In fact, it has become an entire black-market economy. Software developers create increasingly sophisticated root kits and sell them to criminals who create “botnets” (networks of bots) by finding vulnerable machines, compromising them, and installing root kits on them. After stealing what they can from the infected machines, the botnet masters rent the botnets to other criminals who use them to send spam, mount phishing attacks, store stolen information, etc. Money can be extorted from legitimate businesses by threatening a botnet-based DDOS attack if the funds are not paid.

Tracking these criminals is difficult. They use botnets to cover their tracks, sending anonymous encrypted messages along random paths. Once found, the criminals are often in countries with weak cybersecurity laws and poor extradition abilities. Prosecuting cybercriminals may take a back seat to more pressing matters of poverty and war.

Figure 1: Trusted Hardware (TPM) and Remote Attestation (TNC) verify critical client software

Detecting Root Kits
Since a root kit has modified the operating system, it can easily defeat client security software that scans the machine for suspicious files. The root kit simply shows only clean files to the security software.

The root kit can even create a clean virtualized environment where the user works in innocent happiness while the root kit does its dirty work below. If the root kit has a bug, it may expose its presence to higher layer software by causing the machine to behave abnormally.

Detecting root kits in software has become a game of cat and mouse. Unfortunately, the mice (the bad guys) are winning. The cats need better tools. Several new technologies (Trusted Hardware and Network Access Control) promise to tip the balance back in the cats' favor.

Trusted hardware is not a new concept. In fact, you probably have trusted hardware in your laptop right now, although it may not be turned on. The Trusted Computing Group (TCG) is an industry consortium that defines open standards for trusted computing.

Several years ago, the TCG published standards for the Trusted Platform Module (TPM), an embedded security function that provides certain essential security features such as tamper-resistant key storage and cryptographic operations. Publishing a standard interface for the TPM encouraged rapid development of products that conform with this standard, just as TCP/IP and HTTP have done for the Internet.

Today, the cost of a TPM is minimal. All corporate-grade laptops and desktops shipped today include a TPM and software that uses the TPM is becoming increasingly popular. For example, Windows Vista Ultimate includes a BitLocker feature that can encrypt your hard drive with a key stored securely on the TPM.

For the purposes of defeating root kits, the most important feature of the TPM is the ability to measure firmware and software during the boot sequence (known as “Trusted Boot”) and the ability to communicate these measurements to a policy server during a Network Access Control (NAC) handshake (known as “Remote Attestation”).

Taken together, these two abilities allow the policy server to reliably and securely determine exactly what software was booted on a system. If the software is vulnerable to attack, it can be automatically upgraded to patch the vulnerabilities. If the system is actually infected, it can be quarantined and disinfected. But how does the Trusted Boot and Remote Attestation work?

Trusted Boot
Modern PCs go through a boot sequence that starts when a firmware BIOS is loaded and run. After performing a Power On Self Test (POST), the BIOS loads and runs the boot loader, which loads and runs a second-stage boot loader, which loads and runs the operating system kernel, which loads and runs kernel drivers, etc. The details of the actual boot sequence may differ slightly but the general concept of a multi-stage boot sequence applies for many computing systems.

To perform a Trusted Boot a Platform Configuration Register (PCR) on the TPM is used to store a hash of all the software in the boot sequence. To understand how this works, we must understand the PCR. The PCR is reset to zero with each hard reset.

The TPM design ensures that the only other way to modify the PCR value (other than hardware attacks) is to “extend” it with a value, which causes the TPM to perform a cryptographic hash of the value with the existing PCR value and store the output of this hash in the PCR.

So during the boot sequence, each piece of firmware or software hashes the next component in the boot sequence and extends the PCR with the value of that hash. At the end of the boot sequence, the PCR contains a hash that reflects the contents of the entire boot sequence.

Certain PCR values reflect “good” configurations (configurations permitted by organizational policy). Because of the special properties of the cryptographic hash function, it is computationally infeasible for a root kit or any other software in the boot sequence to change the PCR value from a bad value to a good one. So the PCR value at the end of the boot sequence represents reliable evidence about the exact set of software loaded during the boot sequence.

Generally, this is the set of firmware and software that is critical to the security of the system (the “Trusted Computing Base” or TCB). If there is additional software in the TCB (like Anti-Virus software), that software can be hashed and the hash extended into the PCR value before the software is loaded.Remote Attestation
When a system that has performed a Trusted Boot connects to a network protected with a NAC system, a Remote Attestation protocol can be used to securely convey the system's PCR value to a policy server where it can be compared against a list of PCR values for known good configurations.

If the PCR value is on the list, the system has a good configuration and can safely be granted whatever network access is appropriate for it. If the PCR value is not on the list of good configurations, the PCR value can be compared against a list of known vulnerable configurations (old versions of the OS, old patches, etc.).

If the PCR value is found on that list, the system can be quarantined and patched. And if the PCR value is completely unrecognized, then additional analysis can be triggered to figure out if the system has been compromised.

There are two reasons to perform these comparisons on the server instead of on the system itself. First, the system cannot be trusted to check its own configuration since it may be infected. Second, the list of good configurations may be large and frequently changing as new vulnerabilities are discovered and new patches made available. Therefore, it's best to keep this list on the server.

As mentioned in the introduction, the Trusted Computing Group has created a set of standards for NAC: the Trusted Network Connect standards or TNC (see Figure 1, above ). The TNC standards define network protocols and APIs (Application Programming Interfaces) that allow products from different vendors to interoperate properly when performing NAC operations.

When used with the Trusted Platform Module, the TNC standards provide a complete and effective way to detect root kits. Of course, the TNC standards and the many products that implement them can also be used without the TPM for more conventional NAC configurations.

Preventing Root Kits
What more can be done to prevent root kits? Certainly, it's better to prevent a system from becoming infected than to detect the infection afterwards. The best ways to prevent root kit infections are:

* Keep software up to date, installing security patches when available
* Use a personal firewall and anti-virus software on all systems
* Do not run software unless you are absolutely sure you trust it
* Do not open emails or files unless you are sure they are trustworthy
* Remember that emails can be easily forged
* Do not visit unfamiliar web sites
* Do not insert untrusted media (CDs, USB drives, etc.) into your machine
* Disable the Windows autorun feature to avoid accidentally running software
* Run software with reduced privileges, if possible
* Pay attention to security-related messages. Don't just click OK.
* Use NAC technology (such as TNC) to ensure secure system configurations
* Employ hardware security devices like firewalls and Intrusion Detection Systems to detect spreading outbreaks

These are all well-known security best practices. If you do not follow them, your chance of contracting a root kit or other infection will increase substantially. However, they do not provide a complete guarantee of security.

If an attacker is able to exploit a zero-day vulnerability (one for which no patch is yet available) and this exploit is not detected by the Intrusion Detection System or other security measures, that attacker may well be able to install a root kit in spite of your best efforts.

In that case, root kit detection comes into play. This is also true if one of the best practices listed above is not followed. Having the ability to detect a root kit is an essential tool in every IT department's toolkit.

Conclusion
Root kits are a major threat to computing security. The security practices listed above should be followed to prevent root kit infections. But having a secure and reliable way to detect root kits is also essential. Trusted hardware is the only reliable way to do this. And remote attestation makes this manageable.

Products based on the TCG's open standards for trusted hardware (TPM) and remote attestation (TNC) are widely available at a reasonable cost. In fact, all corporate grade laptops and desktops include a TPM these days. Considering the damage and risks that root kits can cause, organizations should seriously consider turning on their TPMs and employing root kit prevention and detection technology.

Steve Hanna is Distinguished Engineer at Juniper Networks and Co-chair of the Trusted Network Connect Work Group in the Trusted Computing Group

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.