Ghost in the Wires: My Adventures as the World’s Most Wanted Hacker (13 page)

A short while later, the instructor pulled Lenny and me out of the computer room and accused us of typing unauthorized commands. I asked, “Is doing a directory of my own files unauthorized?” Both Lenny and I were sent to the dean for further proceedings.

Over the next several weeks, Pierce’s administrators held a kangaroo court hearing on our case. They still suspected we were behind the hacking incident, but still couldn’t prove it. No eyewitnesses. No fingerprints. No confessions. Nonetheless, Lenny and I were both expelled from Pierce, based on circumstantial evidence.

L
enny and I wanted to get the source code for Digital Equipment Corporation’s VMS operating system so we could study it to find security flaws. We would also be able to look for developers’ comments about fixing security problems, which would let us work backward and figure out what those problems were and how we could exploit them. We also wanted to be able to compile parts of the operating system ourselves, so it would be easier for us to install some backdoor patches in the systems we compromised. Our plan was to launch a social-engineering attack on DEC to get into the VMS development cluster. I got the dial-up number for the VMS development modem pool.

When Lenny was at work, he went to the terminal box for the building to find a fax line belonging to another tenant. Because a lot of companies had office suites in the same building, he could punch down someone else’s line on an unused cable pair that went into VPA’s computer room, and no one would be able to trace our outgoing calls.

Meanwhile, I went to the Country Inn hotel near his office and used a pay phone to call Lenny. Once I had him on the line on one phone, I used another pay phone to call DEC’s main number in Nashua, New Hampshire, where its labs and developers were.

Then I stood there between the two phones with a receiver held up to each ear.

I told the woman who answered in Nashua that I worked at DEC
too, then asked where the computer room was and got the phone number for operations.

When I called that department, I used the name of someone in development and asked if operations supported the “Star cluster” group of VMS systems that were used by VMS development. The DEC employee said yes. I then covered that mouthpiece with my hand and spoke to Lenny through the other one, telling him to dial the modem number.

Next I told the operator to type in a “show users” command to show who was logged in. (If you were in the process of logging in, as Lenny was, it would show this by displaying “” along with the device name of the terminal that was being used for logging in.) This is what she saw on her display:

The “” indicated the type of device Lenny was on, TTG4.

I then asked the operator to type in a “spawn” command:

spawn/nowait/nolog/nonotify/input=ttg4:/output=ttg4:

Because she wasn’t keying in usernames or passwords, she didn’t think anything about what I was asking her to do. She should’ve known what a spawn command did, but apparently operators rarely used it, so evidently she didn’t recognize it.

That command created a logged-in process on the modem device that Lenny was connected to in the context of the operator’s account. As soon as the operator typed in the command, a “$” prompt appeared on Lenny’s terminal. That meant he was logged in with the full privileges of the operator. When the “$” showed up, Lenny was so excited that he started shouting into the phone, “I’ve got a prompt! I’ve got a prompt!”

I held Lenny’s phone away from my head and said calmly to the operator, “Would you excuse me? I’ll be right back.”

I pressed that phone against my leg to mute the mouthpiece, picked up the other phone, and told Lenny, “Shut up!” Then I went back to my call with the operator.

Lenny immediately checked to see if security audits were enabled. They were. So rather than setting up a new account for us, which would have raised suspicions by triggering an audit alarm, he just changed the password on a dormant account that had all system privileges.

Meanwhile, I thanked the operator and told her that she could log out now.

Afterward, Lenny dialed back up and logged in to the dormant account with his new password.

Once we had compromised VMS development, our objective was to get access to the latest version of the VMS source code. It wasn’t too difficult. When we listed the disks that were mounted, one of them was labeled “VMS_SOURCE.” Nothing like making it easy for us.

At that point, we uploaded a small tool designed to disable any security audits in a way that wouldn’t trigger an alarm. Once the alarms had been disabled, we set up a couple of user accounts with full privileges and changed a few more passwords on other privileged accounts that hadn’t been used in at least six months. Our plan was to move a copy of the latest version of the VMS source code to USC so we could maintain full access to the code even if we got booted off the Star cluster.

After setting up our new accounts, we also went into the email of Andy Goldstein. He had been a member of the original VMS design team at Digital and was well known throughout the VMS community as an operating-system guru. We knew he also worked with VMS security issues, so we figured his email would be a good place to look for information about the latest security issues DEC was trying to fix.

We discovered that Goldstein had received security bug reports from a guy named Neill Clift. I quickly learned that Clift was a grad student at Leeds University in England, studying organic chemistry. But he was obviously also a computer enthusiast with a unique talent: he was very skilled at finding vulnerabilities in the VMS operating system, which he faithfully alerted DEC to. What he didn’t realize was that now he was alerting me as well.

This laid the groundwork for what would prove to be a goldmine for me.

While searching through Goldstein’s emails, I found one that contained a full analysis of a clever patch for “Loginout,” the VMS log-in program. The patch was developed by a group of German hackers who belonged to something they called the “Chaos Computer Club” (CCC). A few members of the group focused on developing patches for particular VMS programs that enabled you to take full control of the system.

Their VMS Loginout patch also modified the log-in program in several ways, instructing it to secretly store user passwords in a hidden area of the system authorization file; to cloak the user with invisibility; and to disable all security alarms when anyone logged in to the system with a special password.

Newspaper stories about the Chaos Computer Club mentioned the name of the group’s leader. I tracked down the guy’s number and called him up. By this time, my own reputation in the hacking community was starting to grow, so he recognized my name. He said I should talk to another member of the group, who, sadly, turned out to be in the end stages of cancer. When I called him at the hospital, I explained that I’d obtained an analysis of the club’s backdoor patches for the VMS Loginout and “Show” programs and thought they were wickedly clever. I asked if he had any other cool tools or patches he’d be willing to share.

The guy was both supercool and talkative, and he offered to send me some information. Unfortunately, he said, he’d have to send it by snail mail, since the hospital didn’t have a computer. Several weeks later, I received a packet of printouts detailing some of the hacks the group had created that weren’t already in the public domain.

Expanding on the Chaos Computer Club’s work,
Lenny and I developed some improved patches that added even more functionality. Essentially, the CCC created a framework that we then built upon. As new versions of VMS came out, Lenny and I kept adapting our patches. Because Lenny always worked at companies that had VMS systems, we were able to test our patches on his work systems and deploy them into systems we wanted to maintain access to.

After some major DEC clients were compromised, the company’s programmers wrote a security tool that would detect the Chaos patch. Lenny and I located the detection software and analyzed it, then simply modified our version of the Chaos patch so DEC’s tool wouldn’t be able to find it anymore. It was quite simple, really. This made it easier for us to install our patch into numerous VMS systems on Digital’s worldwide network, known as Easynet.

If locating the code wasn’t hard, transferring it was. This was a lot of code. To reduce the volume of code, we compressed it. Each directory contained hundreds of files. We’d compress all of them in a single file and encrypt it, so that if anyone found it, it would look like garbage.

The only way to retain access to the files so we’d be able to study them at leisure was to find systems on DEC’s Easynet that connected to the Arpanet, giving us the ability to transfer them outside DEC’s network. We only found four systems on Easynet that had Arpanet access, but we could use all four to move the code out piece by piece.

Our original plan to store a copy of the code at USC proved a little shortsighted. First of all, we realized we should use more than one storage location for redundancy, so all that work wouldn’t go to waste if the code was discovered. But it turned out there was an even bigger issue: the code base was humongous. Trying to store it all in one location would run too big a risk of being detected. So we began spending a lot of time hacking into systems on the Arpanet, looking for other safe “storage lockers.” It began to feel like getting the code from DEC was the easy part, while the big challenge was figuring out where to stash copies of it. We gained access to computer systems at Patuxent River Naval Air Station, in Maryland, and other places. Unfortunately, the system at Patuxent River had minimal storage available.

We also tried to set ourselves up on the computer systems at the Jet Propulsion Laboratory, in Pasadena, California, using our customized version of the Chaos patch.

JPL eventually realized one of their systems had been compromised, possibly because they were watching for any unauthorized changes to the VMS Loginout and Show programs. They must have reverse engineered the binaries to identify how the programs were being modified and decided it was the Computer Chaos Club who had gained access. JPL management went to the media with that version of the story, which
led to huge news coverage about the German hackers who had been caught breaking into the JPL computers. Lenny and I chuckled over the incident. But at the same time, we were a bit nervous because we were detected.

Once we started the transfers, we had to keep them going night and day, moving the code bit by bit. It was a very slow process. The dial-up speed of the connections at the time (if you could even use the word “speed”) was a maximum of T1 speeds, which was about 1.544 megabits per second. Today, even cell phones are much faster than that.

Soon DEC detected our activity. The guys responsible for keeping the systems up and operational could tell that something was going on because of the heavy network traffic in the middle of the night. To make matters worse, they discovered that their available disk space was disappearing. They didn’t usually have a lot of volume on the system: it would be counting in megabytes, whereas we were moving gigabytes.

The nighttime activity and the disappearing disk space pointed to a security issue. They quickly changed all the account passwords and deleted all the files we stored on the system. It was a challenge, but Lenny and I weren’t deterred. We just kept hacking back in, night after night, despite their best efforts. In fact, because the staff and users of the system didn’t realize that we had their personal workstations under our control and could intercept their keystrokes, it was easy for us to immediately obtain their new log-in credentials every time they changed them.

DEC’s network engineers could see all along that lots of large files were being transferred, but they couldn’t figure out how to stop it. Our unrelenting assault had them convinced that they were under some kind of corporate espionage attack by international mercenaries who’d been hired to steal their flagship technology. We read their theories about us in their emails. It was clearly driving them crazy. I could always log on to see how far they were getting and what they were going to try next. We did our best to keep them chasing red herrings along the way. Because we had full access to Easynet, we could dial in from the United Kingdom, and other countries throughout the world. They couldn’t identify our entry points because we were constantly changing them.

We were facing a similar challenge at USC. Administrators there had likewise noticed that disk space on a few MicroVAXes was disappearing. We’d start transferring data at night, and they’d come on and kill the network connection. We’d start it up again, and they’d bring the system down for the night. We’d just wait them out, then start up our transfer again. This game continued for months.