Case study #1
The following is a mixture of tactics from several incidents occuring
in 1997 and 1998.
- Attacker (1) probes .washington.edu from
a remote site, using network scanning tools like
(Note: These tools are all publically available).
- After identifying targets, attack them remotely. The most
common targets lately are rpc.mountd,
wu-ftpd, imapd or BIND's named on
Linux systems (preferably RedHat Linux <= 5.1), where
these daemons are vulnerable and running by default upon
- If they haven't already obtained root access by exploiting
buffer overruns in TCP/IP service daemons, they try using other
- Once the system is "owned", Install a backdoor (e.g., replace
login binary), programs to hide processes and network
connections, and clean up footprints in logs and accounting
records (As seen in CERT Ongoing
Network Monitoring Attacks advisory and articles on Unix hacking).
These trojan horse daemons (e.g., in.telnetd,
in.ftpd, or /bin/login) have backdoor passwords,
or use tricks like giving a root shell to logins to normal user
accounts when a specific terminal type (e.g.,
"ansi-mini") is used.
Use something like RootKit to make the job
easier. [Example] Since RootKit replaces
ls with one that hides files, try the following:
[Note -- Only "script kiddies" are too unskilled to change the
defaults, so don't expect this to be a definitive test. Read
more about Linux
RootKit version 4]
# cd /dev
# echo pty?
ptyq ptyp ptyr <-- If these show up, standard RootKit is installed
# mv pty? /tmp
- There are even tools that automate RootKit
- Run RootKit's bindshell to give yourself
shell access, but without ever having to log in.
- Install a sniffer to steal
accounts (will get more root accounts faster this way), while
starting a new scan of another target domain.
- Install an IRC "bot" to communicate,
possibly transfer files (using DCC), and keep control of their
channel (this script will process bot user
files, making them a bit more
readable.) See also: CIAC-2318_IRC_On_Your_Dime.pdf.
- Read root email, as well as other users if there is time,
to find passwords and learn what root is up to.
- If a choice target (2) is found that can't be
broken otherwise, but has a possible trust
relationship (i.e., .rhosts entry for root
account), use DNS cache
poisoning (3) and walk in through the front
door using rsh without a password and possibly without
wtmp entry! (Read the "motd" file
found with this tool.)
- If it is obvious that root isn't watching, start running
crack on password files stolen
from other sites via holes (e.g., sendmail,
insecure CGI scripts, Trojan Horse IRC client or -- probably
the easiest way -- by just asking to borrow an account).
- Occassionally go back to retrieve
sniffer logs, results of probing and/or password cracking, or
to compile/store new tools.
- Casually administered workstations are a risk.
- "Clear text" passwords are a risk.
- Don't assume that hacker attacks are always from "out there" --
Getting a foot hold on local systems is not that hard.
(1) "Attacker" here means one or more people involved
in a single incident, or series of incidents.
(2) DNS spoofing is described in several pages on the web,
(3) "Choice targets" are more of your favorite systems
that don't yield to remote attacks, file servers (where you can
get access to lots of accounts and big password files), name servers
(for DNS cache poising), systems with compilers that run operating systems
to which you don't otherwise have access, and IRC servers that make it
easier for you to attack or monitor channels.
Dave Dittrich <firstname.lastname@example.org>
Last modified: Tue Mar 30 13:01:40 1999