1 / 27

Rootkits

Rootkits. This presentation is an amalgam of presentations by Mark Michael, Randy Marchany and Ed Skoudis. I have edited and added material. Dr. Stephen C. Hayne. T raditional R oot K its. Replaces key system components Less detectable than application-level Trojan Horse Backdoors

silcox
Télécharger la présentation

Rootkits

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. Rootkits This presentation is an amalgam of presentations by Mark Michael, Randy Marchany and Ed Skoudis. I have edited and added material. Dr. Stephen C. Hayne

  2. Traditional RootKits • Replaces key system components • Less detectable than application-level Trojan Horse Backdoors • Traditionally focused on UNIX systems, but NOW on Windows… • Root access is required initially

  3. Traditional RootKits • On Windows systems… • RootKits Replace Dynamic Link Libraries or alters the system in other ways • On UNIX systems… • RootKits replace /bin/login with a backdoor version of /bin/login

  4. Traditional RootKits • When an attacker enters the backdoor password access is given to the system • Backdoor password still works if other passwords are changed • Login is not recorded in log files for the backdoor user

  5. Traditional RootKits • Some other programs replaced: • du - shows free disk space • RootKits hides space used by attacking tools • find - finds files • Hides attacker’s files • ifconfig - shows status of interfaces • masks promiscuous mode • ls - shows contents of directories • Hides attacker’s files

  6. Traditional RootKits • “Original” Linux RootKit 5 (lrk5) • written by Lord Somer • one of the most full-featured RootKits • includes Trojan versions of the following: • chfn, chsh, crontab, du, find, ifconfig, inetd, killall, login, ls, netstat, passwd, pidof, ps, rshd, syslogd, tcpd, top, sshd, and su

  7. Defending against Traditional RootKits • Remember root-level access is needed to install a RootKit… • Use “echo *” command to look for changes • Get a program to scan /bin/login and see if it has been corrupted • Use a File Integrity Checker such as Tripwire • Save hashes on read-only media

  8. Tripwire • Available from www.tripwire.org • First of the file integrity checkers • Unix and Windows versions available • Network capable versions available • Useful in finding trojan programs

  9. Tripwire • Generates a “signature” for each file based on checksums and other characteristics. • These signatures are stored in a database file that should be kept offline. • This is the baseline.

  10. Security Configuration Management • Video – Open Source • Video– Enterprise NIST 800-171

  11. Tripwire • Advantages • Simple interface, good choice of crypto hash functions, good all-around tool • Security Issues • How to protect DBs…? • Need to protect tripwire executables? • Disadvantages • Kernel mod attacks, initial config takes quite some time to customize, no network security

  12. Kernel-Level RootKits • Trojan Horse becomes the Kernel • Most difficult to detect • Gives the attacker complete control of the underlying system • Nothing on the system can be trusted

  13. Kernel-Level RootKits • Most common feature is execution redirection • Instead of changing other programs to hide files, the kernel hides them • Kernel may also hide processes that are running • Port usage is often masked

  14. Kernel-Level RootKits • Some early Kernel-level RootKits are: • Knark (Linux) • Adore (Linux) • Plasmoid’s Solaris Loadable Kernel Module (Solaris) • The Windows NT kernel-level RootKit (Windows)

  15. Kernel-Level RootKits • Implemented with Loadable Kernel Modules (LKM) • LKM is used to extend the capabilities of the system only for some UNIX systems • LKM makes it easy! • To install the Knark RootKit type: • “insmod knark.o,” • no reboot necessary

  16. KNARK Background • Written by Creed • Released in 1999 • Versions exist for Linux 2.2 and 2.4 kernels • Very popular in ‘script kiddie’ community

  17. KNARK Capabilities • Hide/Unhide files or directories • Hide TCP/UDP connections • Execution Redirection • Unauthenticated privilege escalation via the rootme program within knark • Ability to change UID/GID of a running process • Unauthenticated, privileged remote execution daemon • Kill –31 to hide a running process

  18. Installing KNARK • KNARK IS installed as a Loadable Kernel Module (LKM) • System must have LKM enabled in order to be able to load KNARK • Can be defeated if LKM is disabled, HOWEVER, updating system becomes much more complicated • The KNARK rootkit has an additional LKM module to hide the presence of KNARK from the insmod (installed module) command.

  19. What does KNARK Change? • KNARK modifies the system call table (sys_call_table) within kernel memory by redirecting some system calls (sys_read, sys_getdents) to malicous system calls written by CREED. • These new malicious system calls function as normal except in certain circumstances.

  20. What does KNARK change?

  21. What does KNARK Change? • Can no longer trust the output of the system calls? • Very difficult to detect rootkits such as KNARK using conventional methods • System utility files (ls, ps) are not modified • Kernel Output to system utility files IS modified.

  22. Detecting KNARK • Cyptographic Checksums of system utilities will NOT change when KNARK is installed • May be possible to take cryptographic checksum of selected region of kernel in order to detect rootkit modification of kernel (StMichael) • Can detect presence of KNARK type rootkits by examining sys_call_table

  23. Detecting KNARK • The file /boot/System.map is created when system is initially compiled • /boot/System.map contains correct address of kernel system calls • /boot/system map can be archived or retrieved from a known good system for comparison • Must have Superuser (ROOT) privilege in order to read /dev/kmem (kernel memory)

  24. Detecting KNARK using the kern_check program • Developed by Samhain labs • GPL (‘free’) software • Compares /boot/System.map file against the system call table in kernel memory • Will not work against later versions of Red Hat Linux 2.4 or the Linux 2.6 kernel

  25. KNARK Summary • KNARK is a very powerful tool that was very popular with ‘script kiddies’ • Very difficult to detect with conventional methods • Can no longer trust system output once kernel is compromised • Other kernel rootkits can defeat kern_check program (SuckIT)

  26. Rootkit Summary • Prevent hackers from gaining root access in order to prevent rootkits from being installed • Must check systems on a periodic basis for rootkit exploits • Current advice for a rootkitted system: Wipe out files and re-install operating system. • Is it possible to re-establish trust on a Rootkited System?

  27. Trojan Horse / Rootkit Application-level Traditional RootKit Kernel-level RootKit Evil Program good login good ps good ifconfig good tripwire Trojan login Trojan ps Trojan ifconfig good tripwire good program good program good program good program Kernel Trojan Kernel Module Kernel Kernel

More Related