1 / 48

Backdoors, Trojans and Rootkits

Backdoors, Trojans and Rootkits. CIS 413 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. B ack D oors. An alternative entryway No fancy authentication needed

Pat_Xavi
Download Presentation

Backdoors, Trojans and 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. Backdoors, Trojans and Rootkits CIS 413 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. Back Doors • An alternative entryway • No fancy authentication needed • Maintains access on a system • Usually access is needed initially • Still works when front door is closed

  3. Back Doors • An attacker with back door access “owns” the system • Attackers might make the system more secure to keep ownership • The attacker does the work of the administrator

  4. Back Doors Melded into Trojan Horses • Application-level Trojan Horse Backdoors • Traditional RootKits • Kernel-level RootKits

  5. Application-Level Trojan Horse Backdoor Tools • Adds a separate application to the system • Made up of a server and client part • server is installed on victims machine • client is installed on attackers machine • Victim must install the server portion • Once installed the attacker “owns” the victims machine

  6. Application-Level Trojan Horse Backdoor Tools • Log Keystrokes • Gather system information • Get passwords from the SAM database • Control the file system • Edit the registry • Control applications and services • Redirect Packets

  7. Application-Level Trojan Horse Backdoor Tools • Application redirection • Any DOS application can be spawned • useful for setting up command-line backdoors • Multimedia control • View files in a browser • Hidden mode • Encryption between client and server

  8. Application-Level Trojan Horse Backdoor Tools • Plug-ins: • Streaming video from server machine • More encryption methods • Blowfish, CAST-256, IDEA, Serpent, RC6 • Stronger security than a lot of commercial products! • Stealthier methods for transport

  9. Defenses against Application-Level Trojan Backdoors • Most Anti-virus programs will notice and remove the tools mentioned • Update virus definitions regularly • Don’t run programs downloaded from untrusted sources • Don’t auto-run ActiveX controls

  10. Hidden Backdoors SQL Server Hack! Backdoor listens on port ABC • Attacker takes over your system and installs a backdoor to ensure future access • Backdoor listens, giving shell access • How do you find a backdoor listener? • Sometimes, they are discovered by noticing a listening port • Nmap port scan across the network • Running "netstat –na" locally • Running lsof (UNIX) or Inzider (Windows) Network

  11. Sniffing Backdoors • Who says a backdoor has to wait listening on a port? • Attackers don't want to get caught • They are increasingly using stealthy backdoors • A sniffer can gather the traffic, rather than listening on an open port • Non-promiscuous sniffing backdoors • Grab traffic just for one host • Promiscuous sniffing backdoors • Grab all traffic on the LAN

  12. Non-Promiscuous Backdoor – Cd00r • Written by FX • http://www.phenoelit.de/stuff/cd00r.c • Includes a non-promiscuous sniffer • Gathers only packets destined for the single target machine • Several packets directed to specific ports (where there is no listener) will trigger the backdoor • Sniffer grabs packets, not a listener on the ports • Backdoor root shell starts to listen on TCP port 5002 only when packets arrive to the trigger ports

  13. Non-Promiscuous Backdoor – Cd00r in Action Sniffer analyzes traffic destined just for this machine, looking for ports X, Y, Z Server • The idea has been extended to eliminate even port 5002 • Netcat can push back a command shell from server, so no listener ever required • Connection goes from server back to client SYN to port X SYN to port Y SYN to port Z After Z is received, activate temporary listener on port 5002 Connection to root shell on port 5002

  14. Promiscuous Backdoor • Can be used to help throw off an investigation • Attacker sends data for destination on same network • But the backdoor isn't located at the destination of the backdoor traffic • Huh? How does that work?

  15. Firewall WWW DNS Promiscuous Backdoor in Action Sniffer listens for traffic destined for WWW server • Backdoor is located on DNS server • All packets sent to WWW server • DNS server backdoor sniffs promiscuously • In switched environment, attacker may use ARP cache poisoning • Confusing for investigators Internet

  16. Sniffing Backdoor Defenses • Prevent attacker from getting on system in the first place (of course) • Know which processes are supposed to be running on the system • Especially if they have root privileges! • Not easy, but very important • Beware of stealthy names (like "UPS" or "SCSI") • Look for anomalous traffic • Look for sniffers

  17. Traditional RootKits • Replaces key system components • Less detectable than application-level Trojan Horse Backdoors • Traditionally focus on UNIX systems • Root access is required initially

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

  19. 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 wtmp or utmp files for the backdoor user

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

  21. Traditional RootKits • 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

  22. Defending against Traditional RootKits • Try harder to stop attackers from getting root access • Remember root-level access is needed to install a RootKit • Use “echo *” command to look for changes

  23. Defending against Traditional RootKits • 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

  24. Tripwire • Available from www.tripwire.org • First of the file integrity checkers • Unix and NT versions available • Network capable versions available • Academic version is free. Commercial versions are not. • Useful in finding trojan programs

  25. 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. • Latest threat involves dynamic exec redirection. This is part of the newer Kernel Module Rootkits.

  26. Tripwire • List of files to check: tw.config • All files in a directory will be checked. • Can prune directories from the check step. • Can examine just the directory and nothing else. • Can check by access time but not recommended since you’ll get a report of everything that changed. Everything!

  27. Tripwire • Security Issues • Need to protect the DB • Need to protect the vulnerable executables • Advantages • Simple interface, good choice of crypto hash functions, good all-around tool • Disadvantages • Kernel mod attacks, initial tw.config takes some time to customize, NT version is good but costs $$$, no network security

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

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

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

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

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

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

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

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

  36. What does KNARK change?

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

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

  39. 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)

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

  41. 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)

  42. 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?

  43. Trojan Horse Backdoors 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

  44. Here Come the Worms! • Compromising systems one-by-one can be such a chore • Worms are attack tools that spread across a network, moving from host to host exploiting weaknesses • Worms automate the process • Take over systems • Scan for new vulnerable systems • Self-replicate by moving across the network to another vulnerable system • Each instance of a worm is a “segment”

  45. 2001: Year of the Worm? • In 2001, we saw: • Ramen • L10n • Cheese • Sadmind/IIS • Code Red and Code Red II • Nimda • To date, worms haven’t been nearly as nasty as they could be • Most damage is a result of worm resource consumption • New generations of worms arrive every 2 to 6 months

  46. Coming Soon - Super Worms • Be on the lookout for very nasty new worms • Multi-functional • Spread, steal, erase, etc. • Multi-platform • Win, Linux, Solaris, BSD, AIX, HP-UX… • Multi-exploit • Many buffer overflows, etc. • Zero-Day exploits • Just discovered; no patch available • Polymorphic • Metamorphic • We’ve seen many of these pieces, but no one has rolled them all together… yet!

  47. Worm Defenses • Buffer overflow defenses help a lot here • Rapidly deploy patches • Anti-virus solutions • At the desktop… • …AND at the mail server • …AND at the file server • Incident response capabilities, linked with network management

More Related