10.1 Confessions of a Berkeley System MoleThese 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.
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.
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.
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.
Chuck Haley once sent a letter to Jeff Schriebman commenting that he "had even found the card reader program" to show signs of tampering.
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.
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 |