1 / 40

Getting rooted and never knowing it

Getting rooted and never knowing it. The importance of kernel integrity Job de Haas <job@itsx.com>. Overview. The issue Detection How to avoid it? Introducing kmod. What can be done about it?. The issue. root is almighty lots of opportunities to hack root root can change the kernel

barth
Download Presentation

Getting rooted and never knowing it

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. Getting rooted and never knowing it The importance of kernel integrity Job de Haas<job@itsx.com>

  2. Overview • The issue • Detection • How to avoid it? • Introducing kmod. • What can be done about it?

  3. The issue • root is almighty • lots of opportunities to hack root • root can change the kernel • the kernel is critical to detect abuse  A kernel attack can be very effective.

  4. Some arguments • When you get rooted you have lost anyway but why do we make it so easy? • It is so sophisticated that the risk is very low kernel hacking falls in the scriptable class • My OS is closed source so it won't be feasible who are you kidding? • All solutions result in unworkable situations  So lets do better!

  5. Detection • Host-based Intrusion detection • Network-based Intrusion detection • Misuse detection • Anomaly detection • System health monitoring

  6. Detection • Audit trails • System monitoring • Integrity checking • Network protocol sniffing and reconstruction

  7. What to hide from? • Black Hat: repeatedly use a system without detection • White Hat: hide or protect detection measures. • Tripwire (and other host based IDS) • Process accounting • Auditing trail software • ‘netstat’, ‘lsof’, ‘ps’ etc.

  8. What to hide? • Use your imagination: anything the kernel does or shows can be changed: • Processes • Backdoors: changed programs • Files • System logging • Network connections or interface state • File modification times • Loadable modules • …

  9. How to fool tripwire • Tripwire calculates signatures of • File content • File properties (timestamps, owner) • Directory properties (number of files in it) • The (modified) kernel should preserve these properties. • execve() opens different file than open() does • stat() returns original values

  10. What is a Kernel? • The Operating System ‘program’ • Offers services to ‘userland’ • Creates and maintains processes • Separation of privileges and memory • Access to devices • … • Extensible: network protocols, filesystems • No internal privilege levels • …

  11. What is a Kernel? - 2 • ‘Userland’ can • inquire about kernel state • change kernel state • For example: state of network devices • Through: • System calls • /dev devices (e.g. /dev/kmem) • /proc filesystem

  12. How to modify a kernel? • Loadable kernel modules • Write-able kernel memory • Write directly in /dev/(k)mem • The kernel executable • Build a new kernel

  13. Loadable modules • Modularization of the kernel • Only use resources when needed • Generally works well for any design • Mechanism: • Compiled code is resolved against kernel symbols • Memory is allocated • Code is copied in and an initialization function is called

  14. Introducing kmod • Goal: • Demonstrate effect of kernel modifications • Targeted at Solaris • ‘Easy’ to use. • Use several ways to manipulate kernel • Open Source

  15. Details: How to proceed? • Think about how to fool programs. • Use the Kernel internal stuctures: • Switch tables • Linked lists • Global variables

  16. Kernel switch tables. • Changing function pointers • Kernel uses ‘switch tables’ for extensibility. • Overwrite function pointer: • old_execve = sys_call_table[SYS_execve] • sys_call_table[SYS_execve]=new_execve

  17. Kernel linked lists. • Used for dynamically adding entries • Hide:

  18. Where to start? • Decide where to intercept • Hide processes: • Memory device (/dev/(k)mem • Filesystem switch table (/proc) • Hide backdoors: • Execve -> syscall table • Hide files: • Filesystem switch table (ufs_getattr())

  19. Example: execve() • Has an entry in the syscall table: /usr/include/sys/syscall.h: #define SYS_execve 59 • Looks like: /usr/include/sys/exec.h: struct execa { char *fname; char **argp; char **envp; }; extern int exece(struct execa *, rval_t *);

  20. Example: execve() 2 • Modify behavior: • Safe pointer to original exece() • Replace it with pointer to our new_exece() • Do our work and call old_exece() • Advantages: • No detailed knowledge needed about original exece() • Not very dependent on kernel patches that might change the original exece()

  21. Example: execve() 3 • We want to change: • Test if we call a backdoor executable • If not do nothing and call old_exece • If so redirect the call to our backdoor-ed version by supplying a new fname • Make sure it is not visible from userland that a different executable has been called

  22. Example: execve() 4 • We need to test the pathname only: int new_exece(struct execa *eap, rval_t *rp) { if (backd_head && !ishid(p)) { if (error = lookupname(eap->fname, UIO_USERSPACE, FOLLOW, NULLVPP, &vp)) return (error); backdp = backd_head; while (!VN_CMP(backdp->vp, vp) && ((backdp = backdp->bd_nxt) != NULL)); if (backdp) { kmod_log(KMOD_CE_DEBUG3, "exec matched, redir to %s\n", backdp->bdfname);

  23. Example execve() 5 lookupname(backdp->bdfname, UIO_SYSSPACE, FOLLOW, NULLVPP,&vnp); size = strlen(backdp->bdfname) + 1; cp = regsp->r_sp - size; error = copyout(backdp->bdfname, (caddr_t) cp, size); eap->fname = (char *) cp; return(old_exece(eap, rp)); }

  24. Example: execve() 6 • Result if we have an entry with backdp->bdfname = “/bin/login”: • execve(“/bin/login”, a,e) will really do execve(“/bin/mylogin”,a,e) but • open(“/bin/login”) will still do open(“/bin/login”)

  25. System calls • Some system calls that were changed: • fork fork1 • kill sigqueue • exec exece

  26. Filesystem routines • ufs_readdir ufs_lookup • ufs_create ufs_remove • ufs_rename ufs_setattr • ufs_getattr • pr_readdir pr_lookup • spec_ioctl

  27. Miscellaneous • For /dev/kmem: • mmread • For netstat: • tcp_wput • strrput

  28. Other features • /proc or /dev/kmem hides a process which has a ‘hidden flag’. • fork() will hide a child of a hidden process. • Signals to hidden processes fail. • Information on network objects hidden from ‘netstat’

  29. Other features • Files and directories with a special prefix are hidden. • stat() will show ‘correct’ number of files in directory (nlink) • Reboot proof

  30. Reboot proof mechanism • Rename an existing kernel module: /kernel/strmod/connld /kernel/misc/<prefix> • Place rogue module at that spot. • Redirect all UFS routines for /kernel/strmod/connld to /kernel/strmod/<prefix> • Have the rogue module load /kernel/strmod/<prefix> and hide itself

  31. Demonstration • Following steps: • Hack root remote • Install kmod kit • Install backdoor • Run tripwire • Inspect system with other tools: ps, lsof • Reboot • Check again

  32. Advanced • No loadable module support? • Copy directly into kernel memory • In-kernel network daemons -> hide network connections • Modify executable code directly if possible • Change network stack protocol behavior • Phrack 55: September 9, 1999 • http://ww.phrack.com

  33. Advanced 2 • Snoop ttys through loadable modules • Install and hide ipfilter and redirect traffic based on some token to a local backdoor.

  34. What can be done about it? • Securelevel protection. • Reduce root: Fine grained privileges. • Userland kernel integrity checker • Easily fooled • In-kernel kernel integrity checker • Chicken and egg problem • IPD http://www.pedestalsoftware.com

  35. Securelevels • Protection mechanism • Prevents all users including root from modifying kernel memory directly • Found in *BSD and Linux • Not found on most commercial Unices • Depends on the value of 2 bits in the kernel

  36. Fine grained privileges • Examples: • Capabilities: ftp://linux.kernel.org/pub/linux/libs/security/linux-privs/index.html • Mandatory Access Control (MAC) • ftp://ftp.tislabs.com/pub/lomac/ • http://www.trustedbsd.org/downloads/ • Trusted Solaris • PitBull from Argus Systems

  37. FreeBSD: Jail • Developed by Poul-Henning Kamp for FreeBSD 4.0 • Beefed up chroot() • Acts a bit like a MAC system with one label: jail  simplification • More info: http://www.nluug.nl/events/sane2000/papers/kamp.pdf

  38. Windows? • Same problems • Internals less understood (yet) • Open Source project: • http://www.rootkit.com

  39. Acknowledgement • Gene Kim, Tripwire for supplying the demonstration copy.

  40. References • Phrack 50-55, http://www.phrack.com • THC http://thc.pimmel.org • UNIX Internals by Valhalia • Design and Implementation of the 4.4BSD Operating System • http://docs.sun.com • http://www.itsx.com/kmod.html

More Related