1 / 32

Rootkit-Resistant Disks

Rootkit-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. Outline. What is a rootkit? What is a RRD?

azize
Download Presentation

Rootkit-Resistant Disks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rootkit-Resistant Disks K. R. B. Butler, S. McLaughlin, P.D. McDaniel Pennsylvania State University, CCS ’08 Presented by: HAN Jin

  2. Outline • What is a rootkit? • What is a RRD? • Prototype Implementation • Evaluation • Discussion

  3. Outline • What is a rootkit? • What is a RRD? • Prototype Implementation • Evaluation • Discussion

  4. 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 fact that a system has been compromised. • An attacker may use a rootkit toreplace vital system executables,which may then be used to hideprocesses and files the attackerhas installed, along with thepresence of the rootkit.

  5. Outline • What is a rootkit? • What is a RRD? • Design • Tokens and Disk Policy • Algorithm • Prototype Implementation • Evaluation • Discussion

  6. What is a RRD? • RRD is Rootkit Resistant Disk,that prevents rootkit persistence.

  7. What is a RRD? • RRD is Rootkit Resistant Disk,that prevents rootkit persistence.

  8. RRD Design • One sentence to summarize the design: Govern the write access to the disk blocks by the embedded disk processor • How to do it? Label some of the disk blocks (e.g. OS binaries) to be “immutable”, and only grant the write access to these blocks when a security token is present (e.g. inserted to the USB port).

  9. Tokens and Disk Policy • normal mode: RRD is used like a regular disk,without any tokens present • Administrator mode:a token is needed, whenadministrative event:e.g. initial installation of an OS onto the disk, and subsequent upgrades to the OS other software packages

  10. 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.

  11. RRD write algorithm

  12. Outline • What is a rootkit? • What is a RRD? • Prototype Implementation • RRD • Host Machine • Installer • Evaluation • Discussion

  13. Prototype Implementation • They implemented an RRD that fulfills block requests over TCP. • Their choice to use a network interfacewas made as development of firmware for commodity disks is prohibitively difficult due 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.

  14. Prototype RRD Host

  15. Prototype RRD • RRD: • Linksys NSLU2 network attached storage link(commonly referred to as “slug”) • 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

  16. 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

  17. 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 driver for the host machine. • The RRD driver consists of 1,314 lines of kernel code and 307 lines of user space code

  18. 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 changing as possible, while at the same time ensuring the mutual exclusivity of mutable and immutable data.

  19. Installer • The key design decision in creating the installer is what data should be mutable or immutable. • 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

  20. Outline • What is a rootkit? • What is a RRD? • Prototype Implementation • Evaluation • Performance • Scalability • Security • Discussion

  21. Experimental Setup

  22. Performance (Postmark)

  23. Performance (System install)

  24. Scalability • Used blocks vs. Labeled blocks

  25. 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

  26. Scalability (label Space)

  27. 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

  28. Outline • What is a rootkit? • What is a RRD? • Prototype Implementation • Evaluation • Discussion • Tokens and atime • Filesystem modification • Maintenance and Usability

  29. Discussions • System tokens and atime: • the use of the atime 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 atime, 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

  30. 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”.

  31. 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

  32. 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

More Related