Saturday, April 7, 2007

Back Doors

When someone gets on your system once, they want to have a way to get in again so they make an alternate access method for this purpose. This is referred to as a back door. In case you plug the initial hole the attacker used, they will have another way to access the system. Sometimes they add a new account. They could also misconfigure files or deliver toolkits. An attacker with a back door really "owns" your system. This attacker might even make the system more secure to keep ownership.

Three main types of back doors are:
  • Application-level trojan horse: These are set up as client/server. The server resides on the attacker's system and the client resides on the client's system. The victim must install the client portion. The victim will be duped into installing the software thinking it does something useful that they would want (which may also be true).
  • Kernel-level root kit: Most difficult to remove or detect since it's in the kernel. At the kernel-level, so many things could be modified that you cannot trust anything the system tells you. Most of the time, best thing is the reformat your machine. Processes, port usages, etc., can all be hid.
  • Traditional root kit: These try to replace key functions in the system-usually executables and libraries. If this is done, they will act in a trojanized fashion. They may open back doors. If they do, they will give a back door password that will generally not be logged to audit files. This back door password will not change even if all the other system passwords are changed. They initially began on Unix systems , but have been attacking Windows for several years now. On windows, the dll's (dynamic linked libraries) are usually attacked. On unix, the executable files in the \bin and \sbin directories are typically attacked. Standard functions that are replaced are du (disk usage), find (finds files, but hides attacker's files, ifconfig(shows status of interfaces, but hides promiscuous mode), ls (lists files, but hides attacker's files)

How to defend yourself against Application-level trojans?

  • Keep your anti-virus definitions up to date
  • Don't download programs from untrusted sources
  • Don't auto-run active-x controls

How to defend yourself against Kernel-level rootkits?

  • Keep the attacker from gaining the required root-level access that is necessary to install any rootkit
  • Don't try to install your own rootkit
  • Use a kernel without LKM (Loadable kernel module) support
  • Use a rootkit checker if you suspect you may have one (chkrootkit for unix)

How to defend against Traditional rootkits?

  • Prevent attacker's from gaining root access--root is required to install a rootkit
  • Never install a rootkit on your system "to study it or for fun"
  • Use the "echo" command like netstat, but it may also be "trojanized" these days...
  • Get a program to scan /bin/login and see if it's been corrupted
  • Use a file integrity checker like tripwire
  • Compare file hashes with a hash database

How to find "hidden back door"--sometimes discovered by noticing a listening port, although a listening port is not required, since a port could be opened by the host machine after receiving syn packets on other ports from the attacker.

  • Nmap port scanner can help
  • Run "netstat -an" locally
  • Run lsof (unix) or Inzider (windows)
  • Look for anomalous traffic
  • Know legitimate processes which should be running-esp. if they have root privileges
  • Sometimes you just won't be able to find it...

Even virtual machines are susceptible to rootkits! Some other anti-rootkit scanner tools are: Strider GhostBuster and Strider HoneyMonkey, port explorer, boclean, tauscan, trojan hunter, and pest patrol

Unix Rootkit analysis/detection tools: Chkrootkit (best one), rkscan, carbonite, rkdet, checkps, lsm (loadable security module), lcap (linux kernel capability bounding set editor)

Windows deterrence tools: tripwire, symantec, registryprot (free at http://www.diamondcs.com.au/index.php?page=products)

Good website with forums on this topic: www.wilderssecurity.com

No comments: