Rootkit-Resistant DisksRootkit-Resistant Disks

K. R. B. Butler, S. McLaughlin, P.D. McDaniel

Pennsylvania State University, CCS ’08

Presented by: HAN Jin

Outline

• What is a rootkit?

• What is a RRD?

• Prototype Implementation

• Evaluation

• Discussion

2

Outline

• What is a rootkit?What is a rootkit?

• What is a RRD?

• Prototype Implementation

• Evaluation

• Discussion

3

What is a rootkit

• Rootkit is a software system that consists of a program, or combination of several programs, designed to hide or obscure the designed to hide or obscure the fact fact that a system has been compromised a system has been compromised.

• An attacker may use a rootkit toreplace vital system executablesvital system executables,which may then be used to hideprocesses and files the attackerhas installed, along with thepresence of the rootkit.

4

Outline

• What is a rootkit?

• What is a RRD?What is a RRD?– DesignDesign– Tokens and Disk PolicyTokens and Disk Policy– AlgorithmAlgorithm

• Prototype Implementation

• Evaluation

• Discussion

5

What is a RRD?

• RRD is Rootkit Resistant Disk,that prevents rootkit persistence.

6

What is a RRD?

• RRD is Rootkit Resistant Disk,that prevents rootkit persistencepersistence.

7

RRD Design

• One sentence to summarize the design:

Govern the writewrite access to the disk blocks by the embedded disk processordisk processor

• How to do it?Label some of the disk blocks (e.g. OS binaries) to be “immutableimmutable”, and only grant the write write accessaccess to these blocks when a security tokena security token is present (e.g. inserted to the USB port).

8

Tokens and Disk Policy

• normal mode:

RRD is used like a regular disk,without any tokens present

• Administrator mode:a token is needed, when

administrative event:e.g. initial installation of an OS onto the disk, and subsequent upgrades to the OS other software packages

9

Tokens and labels

• Written data blocks are labeled with the token, and become immutable.

• Only when the corresponding token is inserted, can the labeled blocks be rewritten.

10

RRD write algorithm

11

Outline

• What is a rootkit?

• What is a RRD?

• Prototype ImplementationPrototype Implementation– RRDRRD– Host MachineHost Machine– InstallerInstaller

• Evaluation

• Discussion

12

Prototype Implementation

• They implemented an RRD that fulfills block requests over TCP.

• Their choiceTheir choice to use a network interface was was mademade as development of firmware for commodity disks is prohibitively difficult due to a lack ofdue to a lack of open firmware and development environments.

• They claim their prototype RRD provides the same functionality and security guarantees described before, and can be used as the root partition of a running system.

13

Prototype

RRD Host

14

Prototype RRD

• RRD:– Linksys NSLU2 network attached storage link

(commonly referred to as “slugslug”)– External HDD– USB thumb drive as physical tokens.

• Slug:– receive block requests from the network– store and enforce the RRD’s policy– act as an entry point for physical tokens

15

Change to Slug

• Changes to slug:

– replace default firmware with the SlugOS Linux distribution

– upload netblockd (2,665 lines of code)a server program they developed to satisfy block I/O requests over TCP sockets

– udev framwork is used to detect physical tokens and notify netblockd of their insertion and removal

16

Host machine

• In a typical RRD scenario, a standard SCSI or ATA driver would suffice for communication between the host and disk.

• Because their prototype exports a non-standard interface, they implement an RRD device driverRRD device driver for the host machine.

• The RRD driver consists of 1,314 lines of kernel code and 307 lines of user space code

17

Installer

• Performing an installation with an RRD requires knowing when the token should be present in the disk and when it should be removed.

• It is desirable for the installer to cooperate with the administrator to simplify the installation process

• The installer should require as little token as little token changing as possiblechanging as possible, while at the same time ensuring the mutual exclusivity of mutablmutable and immutableimmutable data.

18

Installer

• The key design decision in creating the installer is what data should be mutable or what data should be mutable or immutableimmutable.– The MBR, boot loader, kernel and any kernel modules

must be immutable to prevent overwriting by kernel level rootkits.

– Similarly, all libraries and binaries should be immutable to prevent user level rootkits from installing trojan versions.

– Any system configurations and startup scripts should be made immutable, along with scripts defining repeatedly executed tasks

19

Outline

• What is a rootkit?

• What is a RRD?

• Prototype Implementation

• EvaluationEvaluation– PerformancePerformance– ScalabilityScalability– SecuritySecurity

• Discussion

20

Experimental Setup

21

Performance (Postmark)

22

Performance (System install)

23

Scalability

• Used blocks vs. Labeled blocks

24

• The overhead due to label creep in both cases is roughly 10% of labeled data, it represents less than 1% of the total space on the partition

label creep does not waste significant disk space

25

Scalability (label Space)

26

Security

• In order to test the ability of their prototype to correctly protect immutable data

• Install a rootkit on a system booted from the prototype RRD:Mood-NT rootkit

• Verify that it fails to become persistent

27

Outline

• What is a rootkit?

• What is a RRD?

• Prototype Implementation

• Evaluation

• Discussion– Tokens and atime– Filesystem modification– Maintenance and Usability

28

Discussions

• System tokens and atimeatime:– the use of the atimeatime attribute for UNIX-based

file systems– In a Linux system, whenever a file is

accessed, regardless of whether it is modified or otherwise changed, the time it was accessed, or atimeatime, is affected.

– In the Linux 2.6 kernel it is possible, and common, to disable atime altogether by mounting the filesystem with the noatime attribute

29

Discussions

• Filesystem modification:– if there is a write request and free inode

descriptors are available in the block, the filesystem may attempt to write data to the block.

– This will fail if the token is not present, and the filesystem will have no knowledge that the write failed because of a lack of access privileges, but would rather be a message such as “BAD BLOCK”.

30

Discussions

• Maintenance and Usability– Token cloning and disk backup– Revocation of existing tokens and token

escrow– Large-scale token management and initial

RRD configuration

• Considerations for Windows Systems

31

Future work

• Tighter integration between the install programs and the RRD is needed

• Integration with intelligent commodity disks over other interfaces such as SCSI or IDE/ATA is needed

• Explore the usability of administrator tokens as a method for enforcing security

32