Lessons From the Internet Worm 33 Years Later

by Mark Rasch on November 5, 2021

Thirty-three years ago, on November 2, 1988, the internet changed. So did our attitudes about computer crime.

Now, mind you, the internet was not much of a thing back then. The ARPANet and its components, like MILNet and others, had been around for more than a dozen years by then, and a few thousand computers (or, more accurately, servers) were connected to each other using the TCP/IP protocols. These were mainly government institutions (.gov), military installations (.mil), educational institutions (.edu), think-tanks and research institutions (.net) and a few scattered commercial entities (.com); mostly large financial institutions and the like.

The internet protocols were used for communication (sendmail) and transferring files (ftp), but mostly for sharing computing resources at a time when powerful (well, powerful at the time) computers were few and far between. Tim Berners Lee was a year away from releasing the protocols that would make up the World Wide Web, and the dial-up messaging board service Prodigy existed in three cities: Atlanta, San Francisco and Hartford. The online forum Whole Earth ‘Lectronic Link, or, the WELL, was about three years old and had a few hundred participants.

By 1988, computer “hacking” was already a thing. Besides phreaking cases like John Draper (Cap’n Crunch) and Kevin Mitnick and the Hannover hackers discovered by Cliff Stoll, there had already been dozens of cases of unauthorized access to or misuse of computerized information. Even the 1983 movie War Games was partly inspired by the real-world activities of high school hacker David Scott Lewis, as well as some actual hacks into the DoD. A specialized computer crime law had been passed by Congress in 1984 and amended two years later. A similar New York State law had already been used to prosecute someone who hacked into Kodak.

On the evening of November 2, 1988, a young graduate student at Cornell University logged into a computer at the MIT media lab and released a computer program he had designed. The program—a “worm”—was designed to robustly break into as many connected computers as it could find. It used a variety of techniques to do so, including a simple password cracking (dictionary attack) program, what would today be called a stack overflow or buffer overflow feature and an exploitation of vulnerabilities in basic internet and UNIX protocols or daemons like sendmail, finger and ftp. The program’s author simply wanted to see if an autonomous hacking program was viable—he never intended it to do any harm. Unfortunately, the worm acted like the brooms in the Sorcerer’s Apprentice—replicating wildly (and beyond the control of the author) and wreaking havoc across the .com, .mil, .edu and .net domains—such as they were in 1988.

We had been warned of this possibility. When Congress was considering drafting a computer crime law in October of 1983, Rep. Dan Glickman and the House Committee on Science and Technology called as a witness a UNIX security guru with Bell Labs in Morristown, New Jersey, and a consultant to the NSA on cybersecurity issues. (Page 507). The witness told members of the committee that what he called computer “joyriding” by kids required few tools and no sophistication, but that these activities had serious implications for real-world problems. It could impact the entire fabric of U.S. industry which is so dependent on computerization that damage done by outsiders could disrupt almost any kind of service you could mention. The witness called on corporate America to be strongly committed to computer security and warned of damaging incidents of computer intrusion even when no theft or damage was intended. That was in 1983. The witness would later become the chief scientist of the National Computer Security Center for the NSA.

The Cornell grad student was himself no neophyte, but a sophisticated “hacker” in the old sense of the word—a tinkerer, an explorer, a scientist. In fact, the grad student had himself lectured at the NSA about how to hack, and, in his own words, “how to get away with it.”

What we Learned About Computers and Computer Security

To say that the 1988 worm was a wake-up call implies that there had not been previous or subsequent wake-up calls. In fact, from an infosec standpoint, we’ve been hitting the snooze button (more or less) since the 1950s. But the 1988 worm taught us a few lessons that bear repeating, even 33 years later.

1. Computers are More Highly Connected Than we Know or Imagine

One of the reasons the worm spread so widely was that, even in 1988, computers on the internet were connected in ways that we did not appreciate. The same is true today. It’s not just about the connection of computers to each other, but to interdependencies. When an entity like SolarWinds or Colonial Pipeline is compromised, other entities wholly distinct from them are impacted. An attack on a payment processor impacts the entire payment processing and banking system. When we think of our “supply chain” we have to consider computers, networks, hardware, software, cables, yes—but also providers, cloud services, IT support as well as vendors, suppliers, customers, etc. It is much, much, much more heavily connected and interconnected than we think.

2. We are far More Dependent Upon Computers Than we Think

Similar to the point about interconnectivity is the fact that we are interdependent. Power, water, telecom, transportation, energy, as well as dependence on people, technologies, hardware, software, etc. increases our vulnerability to attack. Even if we do a great job of security, we are vulnerable to anyone anywhere in the infrastructure. Resilience, DR and BCP need to be an integral part of our information security program.

3. In the Absence of Preparation, a Disruptive Attack Prevents an Effective Response

In the worm attack, security researchers learned that they had no mechanism to communicate with each other in the absence of the ARPANet itself. Despite adding things like the US CERT, ISACs, data sharing and command centers, the problem, if anything, is worse today. The COVID-19 response has meant that users are even more distributed and reliant on a functioning infrastructure than ever. In the event of a disruptive attack, most people would not know who to call, what data to collect or how to respond.

4. All Systems can be Compromised and all Protocols can be Exploited

Don’t be too impressed with this technological terror you have constructed. As networks, devices, services and software become more sophisticated, so, too, do the manner and means of exploitation. While users are significantly more aware in 2021 about security and technology issues than they were in 1988, there simply are orders of magnitude more of them. And there are orders of magnitude more vulnerabilities. While you can’t give up hope, you have to be continuously vigilant.

5. You Don’t Need Amazing Skills to Successfully Hack Systems

There is a persistent myth: The “super hacker”—the kind you see on TV or in the movies who, with a few keystrokes decrypts the most sophisticated encryption algorithms—usually punctuated with the phrase, “I’m in!” Yeah. Right. In the 1988 worm case, a large percentage of computers were attacked because users chose simple passwords like “Password.” That would never happen 33 years later, amirite? (That’s my password – “AMIRITE”) Or a simple e-mail titled, “RE: YOUR TAX REFUND” (all caps helps, right?). Companies need to defend against the stupid and unsophisticated attacks, because there are thousands of them. Often thousands of them a day. Sometimes thousands of them an hour.

6. There are People With Amazing Skills

On the other hand, there are individuals, hacker organizations and nation-state actors who have phenomenal skills, training, tools and abilities. While you can’t just give up, you need to have a balanced approach to security that at least tries to detect such attacks and thwart or minimize their impact. Remember, it’s not about whether you get hacked anymore, its about when and how. And how you survive.

7. Motivations Include Money, Fame, Curiosity, Terrorism, Espionage and More

There are several aspects to this. First, the 1998 worm really represented the end of innocence on ARPANet. Until that point, we mostly based security on trusted relationships—because there were so few relationships online. While trust could be abused or spoofed, it was rare. Now, those days are gone. We begin with a zero-trust model and work from there. Second, many entities operate from the assumption that “Well, I don’t really have anything important here—why should I care?” You know, I only make widgets, I don’t have any PII or PHI and I don’t process credit cards online. Nobody would want to go after me!. That’s simply not the case anymore. Anyone can be a target for reasons that they cannot begin to fathom. Things like cyberbullying, revenge porn, doxxing, SWATting and the like did not exist in 1988, but there were precursors of online aggression, theft of personal information and false personation.

8. We are not Adequately Prepared for a Massive Attack

The ARPANet was designed to be decentralized for resilience and to survive a possible nuclear war. It has no central “command and control”; it was designed to be an archipelago – a series of islands, each responsible for its own waters, with boats traveling between them. But in a tsunami, the model of an archipelago may not be the best model. Even recognizing that a particular attack is part of a massive and coordinated attack is difficult. Responding effectively is that much more so. While we are now much more connected (and it is easier to communicate) than in 1988, we are similarly more dependent on the technologies to communicate. In 1988, landline phones and even TELEX machines served as a backup for when “the internet was down.” Many institutions can only communicate over the web. Sure, when there is a massive attack we will muddle through. But we remain vulnerable.

9. We are far too Siloed (What we Have Here is Failure to Communicate)

Another lesson from the worm was how siloed we are. By geography. By industry. By regulator. By trade organization. By technology. An oil refinery in Texas has little way to notify a law firm in Geneva of an attack. Nor would they. The mechanism built to speed up communications—ISAC’s, Birds of a Feather, CERTs, etc.—in many ways exacerbate these problems. Sure, with many industries moving to common cloud platforms (AWS, Google, Microsoft) we can update configurations that impact multiple institutions across the world, but we also create single points of vulnerability with single points of failure. I’m not suggesting that there is a real solution to this issue, just that it remains much as it was in 1988.

10. Compliance Does not Equal Security

Firewall? Check. Monitoring? Check. Password protection? Check. Checklists and compliance are necessary and essential components of any information security program. Yet almost every time a computer system is hacked, exploited, overwhelmed or disrupted, it was—or it was at least thought to be—compliant. Security is a process and a mindset. It changes and evolves with the threat environment. It requires imagination and creativity. It forces the defender to get into the mind of the attacker. That’s why defenders like the author of the 1988 worm are often the best—or at least the most successful—attackers. If you want to be a defender, be an attacker. Attack your own system. Think of what you would do if you wanted to get in and defend against that. Assuming that the defense is legal, appropriate and cost-effective.

The good news is, we have learned a great deal about computer security and made great strides in the last 33 years. The bad news? So have the hackers.