WO2012005565A1

WO2012005565A1 - A method for rootkit resistance based on a trusted chip

Info

Publication number: WO2012005565A1
Application number: PCT/MY2010/000229
Authority: WO
Inventors: Ahmad Abdu Muthana Abdulrahman; Abd Manan Jamalul-Lail; Bin Shamsuddin Solahuddin; Faizal Bin Mubarak Mohd; Ahmad Zaid; Abdul Kadir Azimah
Original assignee: Mimos Berhad
Priority date: 2010-07-06
Filing date: 2010-10-28
Publication date: 2012-01-12
Also published as: MY150351A

Abstract

The method and system are disclosed for disk protection against persistent rootkits. The method includes disk protection against persistent rootkits (rootkits that attempt to modify the system image) based on trusted chip (34). Further, the method provides a real-time protection to prevent rootkit from being written to system image. The present method is for disk protection against persistent rootkits (rootkits that attempt to modify the system image) based on the trusted chip (34). The method labels all blocks in the disk where the system files are labeled as system area blocks and the remaining blocks as user area blocks. The labeled blocks are stored in a table protected by the trusted chip integrated on the host machine. During the normal process, all write operations to system area are verified before writing is made to the system area blocks.

Description

A METHOD FOR ROOTKIT RESISTANCE BASED ON A TRUSTED CHIP FIELD OF THE INVENTION

The present invention relates generally to computer security. More particularly, the invention relates to utilizing Trusted Platform Module (TPM) functionalities to prevent rootkits from being persistent by modifying system area.

BACKGROUND OF THE INVENTION

In the area of computer hardware the users need a method for protecting disk against persistent rootkits that attempts to modify system image. Since a rootkit, being a malicious program exploits operating system vulnerabilities to gain control of victim host in order to abuse data and resources of the users. A rootkit may lead to compromising the computer system by giving unauthorized users administrative access to the computer. As a result, an unauthorized user may use the computer, any of the functions or information to perform malicious activities.

A rootkit may be installed by authorized users unknowingly or installed deliberately by users having access to the computer. A rootkit may also be installed through network if a computer has a connection to the network. Recovering from rootkit is a tedious task. In some cases, the only possible way to get rid of rootkit is to erase all the data by formatting the disk and reinstall the software.

A rootkit may hide as a part of kernel level code. The kernel level code is trusted by the computer and thus the rootkit may not be detected. Moreover, when a rootkit infects the system image (binaries and configuration files) it becomes persistent and exists across reboots. A persistent rootkit may prevent successful patches and system repair from being successfully applied.

According to one existing method, which includes preventing installation of rootkits on a standalone computer i.e. when a computer is operating in a normal mode and rebooting the computer into a safe mode wherein network connections of the computer are disabled. In this method installation of software is allowed only in safe mode after granting permission from master computer.

According to another existing method, an external rootkit detection tool may be provided. The tool may include external static memory with input/output (I/O) port interface to an external I/O port on target computing platform. The tool further may include a boot image disposed in the external static storage, and rootkit detection and remediation logic disposed in the external static memory and referenced by the boot image. The external static memory may include a universal serial bus (USB) key and, correspondingly, the I/O port may include an external USB port. In this method the detection or prevention is not persistence process because it only executes during boot time only.

According to yet another existing method, an anti-virus based on a security chip is provided. In this method the detection or prevention may not be persistence process because it verifies the integrity of key files during boot time only

Accordingly, the present invention proposes a method for protection of disk from persistent rootkit based on a trusted chip (34).

SUMMARY OF THE INVENTION

The present invention includes a system and method for rootkit resistance based on a trusted chip (34), which is a major need for the hardware industry. It is therefore an object of the instant invention to provide an efficient method and system for preventing installation of rootkits in system image in normal mode and thus preventing rootkits from being persistent by intercepting writing commands to hard disk.

According to one aspect of the invention, it may include an ability to prevent unauthorized modification of system image. According to another aspect of the invention, it allows trusted chip (34) to play an important role in protecting system image against rootkits. The table containing the information about status of disk blocks termed as System Area Table {SAT (36)}, may be protected by the trusted chip (34) and its integrity value may be stored securely in the memory of the trusted chip (34).

According to yet another aspect of the invention, restriction of unauthorized modification of system image neither needs an external storage or physical token to maintain information about status of disk blocks nor needs another machine to grant a permission to update the system image.

BRIEF DESCRIPTION OF DRAWINGS

These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Fig. 1 is a flow chart illustrating a method to resist rootkit based on a trusted chip (34), in accordance with an aspect of the present technique;

Fig. 2 is a block diagram illustrating a method to resist rootkit based on a trusted chip (34), in accordance with an aspect of the present technique; Fig. 3 shows an illustrative diagram showing a system for rootkit resistance based on a trusted chip (34);

Fig. 4 shows an illustrative diagram showing communication between Trusted Monitoring Service {TMS (32)} and trusted chip (34) in accordance with an aspect of the present technique; Fig. 5 is a flowchart illustrating a method for rootkit resistance based on a trusted chip (34) in accordance with an aspect of the present technique.

DETAILED DESCRIPTION Of INVENTION

The present invention proposes method to resist rootkit based on a trusted chip (34), in accordance with an aspect of the present technique. A rootkit is a malicious program that may be user level process and kernel level process. User level rootkit may grant unauthorized user a privileged access to computer system. Once unauthorized user is granted the privileges he/she can exploits this access to steal confidential data, modifying data, or using computer resources in malicious activities, for example to attack another machine or machines on the network.

The damage may be complicated when it comes to kernel level rootkits or what is called persistent rootkits. This type of rootkits may be very difficult to detect and/or remove. They hide themselves as part of operating system kernel code and thus the disk located in H.D.D 30 (hereinafter referred to as 'disk') of the host machine becomes persistent-infected. Kernel rootkits may be especially difficult to detect and remove, because they operate at the same level as the operating system itself, and are thus able to intercept or subvert any operation made by the operating system. Any software, such as antivirus software, running on the compromised system may be easily subverted. In a situation such as this, the whole system can no longer be trusted while it is running.

Referring to Fig. 1 is a flow chart illustrating a method to resist rootkit based on a trusted chip (34). As illustrated, labeling the blocks in the disk may take place at step 300. In order to prevent rootkits from being written into system area the disk blocks are labeled as immutable (read-only) blocks and mutable (read/write) blocks. It has been illustrated in Fig. 3 system 8. According to this arrangement, disk blocks occupied by the system image (binaries and configurations) may be considered immutable while remaining disk blocks may be considered as mutable blocks. Immutable blocks may not be illegally modified.

At step 302 Creation of System Area Table {SAT (36)} may take place. SAT (36) may be created once operating system is installed and encrypted.

At step 304 storing blocks into SAT may take place. The Labeled information may be stored in SAT (36). SAT (36) may be stored locally on the same hard disk partition containing the operating system and may be fully protected by trusted chip (34). The trusted chip (34) at least may be of TPM or any other equivalent trusted chip (34). TPM chip may be a trusted hardware; TPM chips can compute and securely store integrity measurements of a software stack. Any attempt to modify SAT (36) may be noticed by the trusted chip (34). Using a local file protected by trusted chip (34) for labelling information has another advantage, it may eliminate the need for external storage for example, physical token or another machine. Furthermore, encrypting and verifying integrity of SAT (36) may be advantageous in the manner that it may provide a protection for SAT (36) and may allow detection of any unauthorized attempt to corrupt it.

At step 306 the integral value may be computed. The integrity of the SAT (36) may be measured by the trusted chip (34) at least through hashing operation.

At step 308 the integrity value may be stored in the memory of the trusted chip (34). SAT (36) may be encrypted and its integrity value may be computed and stored in the memory of the trusted chip (34). In other embodiments, only the integrity value of SAT (36) may be stored in the memory of trusted chip (34). Upon completion of installation process SAT 36 may be created containing labelling information of disk blocks in which the blocks occupied by operating system binaries are labelled as immutable blocks and the rest blocks are labelled as mutable blocks. At step 310, the integral value of the SAT (36) may be verified. Fig. 5 shows an embodiment wherein the integrity value of SAT (36) may be stored in memory of trusted chip (34). Whenever a disk operation is detected (step 202) it may be checked to determine whether it is writing operation (step 204). Having detected a writing command the integrity of SAT (36) may be verified to determine whether it has been compromised or not (step 206). As a result the writing command may be denied if SAT (36) found not to be integral ("No" in step 208) and the user may be motivated to restore the original SAT (36) protected by trusted chip (34) or if it is integral ("Yes" in step 208) the process may proceed by checking whether the target blocks of writing command belong to system area (step 210). Writing to user area blocks may be allowed ("No" in step 210) while writing to system area blocks ("Yes" in step 210) requires further verification in order to verify the validity of the writing command (step 212). The writing command may allow proceeding for valid writing commands (step 216) while invalid and unauthorized writing commands may be denied ("No" in step 214). Referring to Fig. 2 is a block diagram illustrating the method to resist rootkit based on a trusted chip. As illustrated, methodology starts at storing module (SM) (400).

Storing blocks into SAT (36) may take place in the Storing Module (SM) (400).

The Labeled information may be stored in SAT (36). SAT (36) may be stored locally on the same hard disk partition containing the operating system and fully protected by trusted chip (34). The trusted chip (34) at least may be of TPM or any other equivalent trusted chip. TPM chip may be a trusted hardware; TPM chips may compute and securely store integrity measurements of a software stack.

Any attempt to modify SAT (36) may be noticed by the trusted chip (34). Using a local file protected by trusted chip (34) for labelling information has another advantage in the manner that it may eliminate the need for external storage for example, physical token or another machine. Furthermore, encrypting and verifying integrity of SAT (36) may be advantageous in the manner that it provides a protection for SAT (36) and may allow detection of any unauthorized attempt to corrupt it.

The integral value may be computed or measured in the Measuring Module (MM) (402).

The integrity of the SAT36 may be measured by the trusted chip (34) at least through hashing operation.

The integrity value may be stored in the memory of the trusted chip (34) in the loading module (LM) (404). SAT (36) may be encrypted and its integrity value may be computed and stored in the memory of the trusted chip (34). In other embodiments, only the integrity value of SAT (36) may be stored in the memory of trusted chip (34). Upon completion of installation process SAT (36) may be created containing labelling information of disk blocks in which the blocks occupied by operating system binaries are labelled as immutable blocks and the rest blocks are labelled as mutable blocks.

Communication between Trusted Monitoring Service {TMS (32)} with trusted chip may take place in Interception module (IM) (406). Fig. 4 illustrates the communication between trusted monitoring services TMS (32) with trusted chip (34) during normal mode. The TMS (32) may be a kernel level service, which may be capable of intercepting all writing requests to the hard disk. It may be tamper-proof code protected with obfuscation techniques. It may be capable of measuring the integrity of SAT (36) loaded on the memory and communicating with trusted chip (34). The integrity of TMS (32) may be measured as part of chain of trust every time the computer system is powered up in order to maintain its integrity.

The integral value of the SAT (36) may be verified in the Verification Module (VM) (408). Fig. 5 shows an embodiment wherein the integrity value of SAT (36) is stored in Measuring Module (memory of the trusted chip (34)). Whenever a disk operation is detected (step 202) it may be checked to determine whether it is writing operation (step 204). Having detected a writing command the integrity of SAT (36) may be verified to determine whether it has been compromised or not (step 206). As a result the writing command may be denied if SAT (36) is found not to be integral ("No" in step 208) and the user may motivated to restore the original SAT (36) protected by trusted chip (34) or if it is integral ("Yes" in step 208) the process proceeds by checking whether the target blocks of writing command belong to system area (step 210). Writing to user area blocks may be allowed ("No" in step 210) while writing to system area blocks ("Yes" in step 210) may requires further verification in order to verify the validity of the writing command (step 212). The writing command may be allowed to proceed for valid writing commands (step 216) while invalid and unauthorized writing commands may be denied ("No" in step 214).

Referring to Fig. 3 is an illustrative diagram showing a system for rootkit resistance based on a trusted chip (34). It shows an illustrative system 8 for preventing persistent rootkits. In order to prevent rootkits from being written into system area the disk blocks are labelled as immutable (read-only) blocks and mutable (read/write) blocks. According to this arrangement, disk blocks occupied by the system image (binaries and configurations) may be considered immutable while remaining disk blocks may be considered as mutable blocks. Immutable blocks may not be illegally modified. Labelling information may be stored in SAT (36). SAT (36) is created once operating system is installed encrypted and its integrity value is computed and stored in the memory of the trusted chip (34). SAT (36) is stored locally on the same hard disk partition containing the operating system and fully protected by trusted chip (34). Any attempt to modify SAT (36) may be noticed by the trusted chip (34). Using a local file protected by trusted chip (34) for labelling information has another advantage in the manner that it eliminates the need for external storage for example, physical token or another machine. Furthermore, encrypting and verifying integrity of SAT (36) may be advantageous in the manner that it may provide a protection for SAT (36) and may allow detection of any attempt to corrupt it. In certain embodiments, the system area SAT (36) may be stored entirely in the memory of trusted chip (34). In other embodiments, only the integrity value of SAT (36) may be stored in the memory of trusted chip (34). Upon completion of installation process SAT (36) may be created containing labelling information of disk blocks in which the blocks occupied by operating system binaries may be labelled as immutable blocks and the rest blocks may be labelled as mutable blocks.

Referring to Fig. 4 is an illustrative diagram showing the communication between TMS (32) with trusted chip (34). Fig. 4 illustrates the communication between trusted monitoring services TMS (32) with trusted chip (34) during normal mode. The TMS (32) may be a kernel level service, which may be capable of intercepting all writing requests to the hard disk. It may be tamper-proof code protected with obfuscation techniques. It may be capable of measuring the integrity of SAT (36) loaded on the memory and communicating with trusted chip (34). The integrity of TMS (32) may be measured as part of chain of trust every time the computer system is powered up in order to maintain its integrity. Referring to Fig. 5 is a flowchart illustrating a method for rootkit resistance based on a trusted chip (34). It shows an embodiment wherein the integrity value of SAT (36) is stored in Measuring Module {memory of trusted chip (34)}. Whenever a disk operation is detected (step 202) it may be checked to determine whether it is writing operation (step 204). Having detected a writing command the integrity of SAT (36) may be verified to determine whether it has been compromised or not (step 206). As a result the writing command may be denied if SAT (36) is found not to be integral ("No" in step 208) and the user may motivated to restore the original SAT (36) protected by trusted chip (34) or if it is integral ("Yes" in step 208) the process proceeds by checking whether the target blocks of writing command belong to system area (step 210). Writing to user area blocks may be allowed ("No" in step 210) while writing to system area blocks ("Yes" in step 210) may requires further verification in order to verify the validity of the writing command (step 212). The writing command may be allowed to proceed for valid writing commands (step 216) while invalid and unauthorized writing commands may be denied ("No" in step 214).

Even though the present invention focuses mainly on rootkits that attempt to write themselves into system image (binaries and configuration files) it could potentially be used for preventing any malicious code form modifying the system image.

Claims

1. A method for resisting at least one rootkit based on a trusted chip, the resisting method comprising:

storing System Area Table SAT (36) in a hard disk under protection of the trusted chip (34) using storing module (SM) (400);

measuring the integrity value of SAT (36) using measuring module (MM) (402);

storing the integrity value of SAT (36) in memory of the trusted chip (34);

loading an image of the SAT (36) into memory of the trusted chip (34) using loading module (LM) (404);

intercepting writing commands to hard disk blocks by trusted monitoring service (TMS) using interception module (IM) (406);

verifying the integrity value of the SAT (36) using verification module (VM) (408); verifying the validity of writing command using the TMS (32); and

preventing system image modification of the hard disk by resisting at least one rootkit.

2. The method according to claim 1, wherein storing the SAT (36) in the hard disk under protection of the trusted chip (34) using at least one of encryption method.

3. The method according to claim 1 , wherein the integrity value of the SAT (36) of the trusted chip (34) may be measured by hashing operation or any equivalent measuring tool.

4. The method according to claim 1 , wherein the TMS (32) may be a trusted kernel level service.

5. The method according to claim 1 , wherein the TMS (32) may check the status of target blocks of the SAT (36).

6. The method according to claim 1 , wherein the TMS (32) may further allow writing of commands to user area blocks.

7. The method according to claim 1 , wherein the TMS (32) still further verify the validity of writing commands to system area blocks.

8. The method according to claim 1, wherein the TMS (32) still further deny writing operation if the integrity value of the SAT (36) is not integral.

9. The method according to claim 1, wherein the TMS (32) still further automate user notification to restore the original copy of the SAT (36) if the integrity value of the SAT (36) is not integral.

10. The method according to claim 1, wherein the verification of writing commands to SAT (36) may be found to be valid then the writing operation is allowed, otherwise it may be denied.

11. The method according to claim 1, wherein the SAT (36) at least stored entirely in the memory of the trusted chip (34).

12. The method according to claim 1, wherein the trusted chip (34) at least may be of TPM (34) or any other equivalent trusted chip (34).

13. The method according to claim 1, wherein the verification of the writing operation may be performed by either authorized user or assigned to an authorized trusted intelligent service.

14. The method according to claim 1, wherein the status of blocks allocated by system area and user area may be stored in the SAT (36).

15. The method according to claim 1, wherein only authorized access may be allowed to memory of the trusted chip (34) by any type of authentication.

16. A system for resisting at least one rootkit based on a trusted chip, the resisting system comprising:

storing module (SM) (400) adapted to store SAT (36) in hard disk under protection of the trusted chip (34);

measuring module (MM) (402) adapted to measure the integrity value of the SAT36; loading module (LM) (404) adapted to load an image of the SAT (36) into memory of the trusted chip (34); interception module (IM) (406) adapted to intercept writing commands to hard disk blocks by TMS (32); and

verification module (VM) (408) adapted to verify the integrity of the SAT (36).

17. A computer program adapted for resisting at least one rootkit based on a trusted chip, the computer program comprising:

a program code adapted for storing SAT (36) in hard disk under protection of the trusted chip (34) using storing module (SM) (400);

a program code adapted for measuring the integrity value of the SAT (36) using measuring module (MM) (402);

a program code adapted for storing the integrity value of SAT (36)

in memory of trusted chip (34);

a program code adapted for loading an image of the SAT (36) into the memory of the trusted chip (34) using loading module (LM) (404);

a program code adapted for intercepting writing commands to hard disk blocks by TMS (32) using interception module (IM) (406);

a program code adapted for verifying the integrity of the SAT (36) using verification module (VM) (408);

a program code adapted for verifying the validity of writing command using the TMS (32); and

a program code adapted for preventing system image modification of the hard disk by resisting at least one rootkit.