Section 10.1 Confessions of a Berkeley System Mole | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

10.1 Confessions of a Berkeley System Mole

These confessions are based on an article written by Doug Merritt, Ken Arnold, and me, published in the January 1985 issue of UNIX Review magazine. Although it is an account of activities in the late 1970s, there are plenty of lessons to be learned, some of which are mentioned in indented, italicized text.

This case study shows classic SysAdmin mistakes and cracker techniques. Even Jeff Schriebmann and Bill Joy could not thwart our very successful gray hat attacks on the University of California at Berkeley's UNIX systems.

We were naive crackers, having read nothing of previous cracker exploits, and yet stayed in the systems for more than a year! Still, they got rid of us after three years only because we finished school and started earning a living by cranking out code in Silicon Valley.

When we broke into Berkeley's main UNIX system (which was the world's first PDP 11/70 UNIX system, with Ken Thompson himself having ported UNIX to it) one of my innovations was the insertion of a Trojan horse into the kernel. If someone loaded the octal value 0117 into a particular register prior to calling [the setuid()] system call, the effective UID was changed to 0 and that person instantly became root! 0117 is ASCII for capital "S"; Superuser, of course. This took a couple of lines of code in a location where nobody certainly would be looking for kernel modifications among the 50,000 or so lines of kernel code.

One of Doug Merritt's innovations was to create a modified version of the shell that had a command to activate this Trojan horse. The person became root and could alter the system with impunity. The person then issued another special command and the effective UID was set back to normal. Thus, if SysAdmins issued a ps command they would not see anything out of the ordinary unless they were lucky enough to issue the ps during this brief window. They never had that luck!

One of the SysAdmins, David Moser, was sure that there were crackers in the system. He reminded us of the Frank Burns character from "M.A.S.H." checking his toothpaste for explosives. Well, David decided to print out the entire UNIX kernel code and read every line looking for Trojan horses. Yup! He did find this one and kept talking about octal 117. I really wanted to say, "Hey David, it's ASCII for capital 'S' for Superuser," but I resisted the temptation.

We were primarily interested in the Electrical Engineering and Computer Science (EECS) department's PDP 11/70 in Cory Hall, because that was the original UNIX site (at Berkeley) and continued to be the hotbed of UNIX development, but we "collected" all the other UNIX systems on campus, too. One peculiar aspect of the way the Underground had to operate was that we rarely knew the root password on systems to which we had gained superuser access. This is because there were easier ways to get into, and stay into, a system than guessing the root password. We tampered, for instance, with the su program so that it would make someone superuser when given our own secret password as well as when given the usual root password, which remained unknown to us.

In the early days, one system administrator would mail a new root password to all the other system administrators on the system, apparently not realizing that we were monitoring their mail for exactly this kind of security slip.

This was a classic case of their not analyzing the situation. Ask yourself, "Why does the password need to be changed?" The only real argument is that "it might be compromised." Well, if it is, the account certainly should not be trusted to send the new password through.

By the same reasoning, password aging can be ineffective if the SysAdmins will not hear from the real user in short order if she cannot log in. Such a situation would be a user who does not log in very often. This is because the intruder changed the password since password aging required this for continued access.

Sadly, they soon guessed that this was not a good procedure, and we had to return to functioning as passwordless superusers, which at times could be a bit inconvenient.

Late one night on Cory Hall UNIX, as I was using my illegitimate superuser powers to browse through protected but interesting portions of the system, I happened to notice a suspicious-looking file called /usr/adm/su. This was suspicious because there were almost never any new files in the administrative /usr/adm directory.

If I was suspicious when I saw the filename, I was half paralyzed when I saw it contained a full record of every command executed by anyone who had worked as superuser since the previous day, and I was in a full state of shock when I found, at the end of the file, a record of all the commands that I'd executed during my current surreptitious session, up to and including reading the damning file.

It took me perhaps 10 minutes of panic-stricken worry before I realized that I could edit the record and delete all references to my illicit commands. I then immediately logged out and warned all other members of the group. Because nothing illicit ever appeared, the system administrators were lulled into a sense of false security. Their strategy worked brilliantly for us, allowing us to work in peace for quite a while before the next set of traps were laid.

The next potential trap I found was another new file in /usr/adm called password, that kept track of all unsuccessful attempts to log in as root or to su to root, and what password was used in the attempt. Because none of us had known the root password for months and therefore weren't going to become superuser by anything as obvious as logging in as root, this wasn't particularly threatening to us, but it was very interesting. The first few days that we watched the file it showed attempts by legitimate system administrators who had made mistakes of various sorts.

One of them once gave a password that we discovered, through trial and error, to be the root password on a different system. Several of them gave passwords that seemed to be the previous root password. Most of them were misspellings of the correct root password. Needless to say, this was a rather broad hint, and it took us less than five minutes to ascertain what the correct spelling was.

You might think that, because we had several ways to become superuser anyway, it wouldn't make any real difference whether we knew the actual root password as well. The problem was that our methods worked only so long as nothing drastically changed in the system; the usual way that they managed to win a battle was to restore the entire system from tape and recompile all utilities.

That sometimes set us back weeks, because it undid all of our "back doors" into superuserdom, forcing us to start from ground zero on breaking into the system again. But once we knew the root password, we could always use that as a starting place.

Hint: Change the passwords on root (or the affected accounts) when you make a major upgrade to a system or components such as Apache, CGIs, or the database that replaces programs that possibly could have had Trojan horses in them and there is any chance that an intruder could know the existing passwords.

Had the Berkeley SysAdmins thought to do that they would have kicked out their adversaries, at least for a time.

One of our favorite tricks for hiding our tracks when we modified standard utilities was the diddlei program, which allowed us to reset the last change time on a modified file so that it appeared to have been unchanged since the previous year.

When dealing with a sophisticated attack do not trust time stamps.

Chuck Haley once sent a letter to Jeff Schriebman commenting that he "had even found the card reader program" to show signs of tampering.

Suspect Trojan horses in any program that is set-UID or which might be invoked by root.

This sort of battling continued for several years, and although They were suspicious of most of Us at one time or another, none of us was ever caught red-handed. It undoubtedly helped that we never performed any malicious acts. We perhaps flouted authority, but we always enhanced the system's features. We never interfered with the system's normal operation, nor damaged any user's files. We learned that absolute power need not corrupt absolutely; instead it taught us restraint.

It was reported that an intruder had maintained long-term root access to eBay.com but was not malicious enough to warrant the effort to remove him. At the time of the report he was suspected still to be in control.

Large systems might be "owned" by intruders for long periods of time if the intruders do not do something malicious enough to justify a time-consuming complete analysis. Tools like Tripwire can make this analysis much easier.

This is probably why we were eventually accepted as members of the system staff, even though by then several of us had confessed to our nefarious deeds. Once we were given license to modify and improve UNIX, we lost all motivation to crack system security. We didn't know it at the time, but this has long been known to be one of the most effective ways of dealing with security problems; hire the offenders, so that there is no more us versus them, but simply us.

Top