CSM CC baby-doe hack

David M. Larue
Back to home page

Go To Bottom

The baby_doe attack: A report to the CSM Sysadmin group. 11-6-96.

First Light

Four weeks ago yesterday, Kathleen Lamb entered my office with a sheaf of email printouts saying: "baby_doe is one of your machines, right?". I have responsibilities in the mathematics and the mining departments, and baby_doe was one of Robin Murphy's machines, an obscure Sun in the robotics lab in the Brown Building. It serves passwords to 2 machines and files to 6, has anonymous ftp, and is logged into directly by Dr. Murphy's students.

These emails were from various sites around the world that were complaining that some machine of theirs had been probed by baby_doe the previous night. After some time-zone conversions, their logs suggested that things had been going on through the night. Their logs would have several probes in rapid succession, suggesting an automated program at work.

I logged on to baby_doe and began poking around.

No one appeared to be logged on, and no unusual processes appeared to be running. The "last" log showed the usual activity, and a couple of ftp entries from victor.brad.ac.uk.

Having in hand several names of sites which had been probed, I initiated a find that spawned greps for one of those strings. Paydirt: in an out-of-the-way directory, /usr/include/rpc, there was a subdirectory named ".. ", and relative to the file scan/bug was reported by grep to contain the name of the site. The probes had indeed come from baby_doe, and the nest of the attacker had been uncovered.

I went over to the robotics lab, pulled baby_doe off of the network and rebooted in single user mode. Somewhat at leisure, I could now examine the files that had been left behind.

What

Half of the files consisted of what I have since learned is called a "Root Kit" -- a collection of hacked source code to various important system files and shell scripts to compile and install them, for use by someone who has broken root on a machine of a given operating system, in this case SunOS 4. Versions for SunOS 5 and Linux are also in wide circulation. There were hacked versions of login, netstat, ps and ifconfig. Netstat and ps were hacked to not report the processes and network connections made by the attacker. ifconfig was modified to not announce when the network interface had been placed into so-called "promiscuous mode", where it can listen to all packets in the vicinity. And login? It had both a backdoor, enabling a particular password to gain one root access, and was recording all username/password entries made.

These files were restored from elsewhere, and checked to be un-hacked. The password file was cleansed, and users of the system required to change their passwords.

The other half of the files consisted of the attacker's tools for probing other systems. There was a program to listen to all packets on the network in Brown. And there was "piss = ph0bos' internet security scanner".

This latter initiated probes for information and weaknesses in SMTP, FTP, RPC, POP, HTTPD. And there was a list of 1300 sites, and a log file telling of its night (it ran for perhaps 10 hours) of adventure, with another list of 3000 sites waiting in the wings.

How and Who

How did the perpetrators break root? This we are uncertain about. The machine in question had a stock installation of SunOS 4.1.3, running such entry points as sendmail, anonymous ftp, nfs and yp. A graduate student had recently moved a disk over and rebuilt the exports file, erroneously giving world access to mount that disk -- this would give fairly easy access to baby-doe as a user. But alas, it turns out CSM is filtering NSF mounts at the gateway, so it was another way. Once in, there are a number of cert advisories that point to ways to break root.

Who were the perpetrators? The "last" log had been cleansed of the logins by the intruder, but he neglected to cleanse his ftp entries, used to bring over his tools, and perhaps pick up some of his results. They pointed to victor.brad.ac.uk, a machine in the engineering department of the University of Bradford in Yorkshire, England. sendmail had dumped core during the hack, and this pointed to a throw-away account on cyberspace.org, an "electronic town hall" in Ann Arbor, MI. But once there, I found that ph0bos, the purported author of piss, also had an account there, and was occasionally on, evidently primarily to do a little mail, from a variety of sites, mostly academic sites in England, including victor.brad.ac.uk. The Computing Center has not been accorded much cooperation to date from sites that might be able to give information as to the identity of the attacked (and which might have themselves been compromised).

Tools

Tools that might make breaking in harder, or early notification or tracing the attacker easier:

  1. A reading of the CERT advisories (ftp://info.cert.org, http://www.cert.org) suggests a variety of patches and fixes, for machines of a wide variety of architectures, that should be made to close doors that attackers come in on. This is no small task.
  2. Our machines should be scanned by the same tools the attackers use, such as an ISS or SATAN ( ftp://ftp.win.tue.nl/pub/security) or Crack ( ftp://info.cert.org/pub/tools/crack).
  3. Better network filtering, monitoring, analyzing and reporting tools need to be put in place. For example, a tcp wrapper such as tcpd ( ftp://ftp.win.tue.nl/pub/security) to filter or log accesses through inetd, and IDENT to aid in identifying the user behind those accesses.
  4. Any of several things to mitigate the current circumstance of passwords crossing, in cleartext, networks that can be listened to. This would include upgrading the wiring and network electronics so that packets meant for a given machine are heard only by that machine, and encryption of transmitted login passwords such as by S/KEY (ftp://ftp.bellcore.com/pub/nmh).
  5. Assurances of the integrity of the system files, such as secure lists of the MD5 signatures ( ftp://ftp.rsa.com/pub/rfc1321.txt) and a regular means of verifying them, as might be provided by tripwire ( ftp://coast.cs.purdue.edu/pub/COAST/Tripwire).

How did we do?

  1. Root was broken into, so some fairly large holes existed, and some likely still exist, in our systems. A systematic review is in order.
  2. It is of course embarrassing that sites around the world knew we had a problem before we did, so tools for monitoring and analyzing need to be put in place.
  3. The attacker was greedy, attacking 1300 sites, and not up-to-date, probing mostly for older well-known weaknesses. (He of course succeeded in our case!) So we were lucky.
  4. Once we knew, we flushed him out, saved copies of the nest and hacked programs, cleaned up, tightened security and made systems available to end-users fairly rapidly.
  5. The goal was restoring the system to use instead of trapping the intruder, so a block at the gateway to the campus was made and the machine brought back up the same day. For reasons unrelated to the attack, baby_doe's name was changed to baby-doe, but this also aided her security.
  6. CERT was advised of the attack (ref. #2664), and a mailing to the lengthy list of probed sites was made advising them they had been targeted, here with Carol Ward as the point of contact. These were time consuming activities.
  7. I did reboot multi-user before saving what was in /tmp, which was a mistake -- I now believe there were things of interest there that are now gone.
  8. And everything was very time expensive.
All in all, we fared reasonably well. I would anticipate that security incidents will re-occur, perhaps with greater frequency or destructiveness, and exhort everyone to give some thought to preventative measures. Naturally we all have many other things to do, and it is difficult to budget the resources needed. Go to Top

Back to home page
(version 2, created 11-6-96, updated 12-5-96, dml)