A Japanese version of this is on Note.
I build RoamSwitch, a network security app for Mac and Linux, on my own. Maybe it's this line of work, but every time I write about AI agents automating cyberattacks, I keep thinking back to 1992, the year I entered this industry. What I was looking at then and what I'm looking at now are supposedly different technologies entirely, yet they keep feeling like the same shape to me. Worth actually writing that down properly, checking memory against real technical history rather than just vibes.
When VAX/VMS and HP-UX Shared the Same Room
In 1992 I worked for a large US computer company's Japan office. The machine in front of me was a VAX running VMS. Across the room, another terminal ran HP-UX. Something as basic as password protection had already walked two completely separate histories by then, and I noticed it constantly.
VMS password protection in its first version, 1978, used a 32-bit hash built on an AUTODIN-II CRC (cyclic redundancy check). CRCs were designed to catch transmission errors, not resist deliberate tampering, so this was less a vulnerability than a case of using the wrong tool for the job. The words "penetration" and "prepituitary" happen to collide at the same CRC32 value, 0xBF6A229E. DEC finally moved to a Purdy-polynomial-based algorithm in version 2, 1980.
HP-UX used a DES-based hash through crypt(3), a 12-bit salt run through 25 rounds of DES, clever for the time, but the password itself was only meaningfully used up to 8 characters, weak against dictionary attacks from day one. Steal /etc/passwd and run it through a cracking tool, and you'd have a few passwords within the hour, that was the common understanding back then. Shadow files were a patch, not a fix.
HP-UX had another weakness, the "trusted host" mechanism built on rlogin and .rhosts/hosts.equiv. HP-UX 9.0, released that same July 1992, predated its full move to System V (SVR4) and still carried a strong BSD flavor, rlogin was one of those native BSD features. Log in without a password from a trusted host, purely for convenience, and the moment your DNS or network path got hijacked, that convenience became the door in. Deciding trust based on a hostname, a value anyone could spoof, was the core problem.
TCP/IP Was Never Designed With Security In Mind
Go deeper and the foundation under most of this, TCP/IP itself, was never designed with security in mind either. Vint Cerf and Robert Kahn's 1974 design existed to interconnect networks of fundamentally different character, ARPANET, packet radio, satellite networks. The whole thing was built on the assumption that participants were a mutually trusting research community. Authentication and encryption appear nowhere in the protocol stack. ARPANET's full cutover to this TCP/IP came nine years later, January 1, 1983, a coordinated one-day switchover from the old protocol (NCP) that everyone just calls "flag day."
Worth a note here. The VAX I touched in 1992 didn't actually speak this TCP/IP natively. VMS's native networking protocol was DEC's own DECnet, and using TCP/IP meant bolting on a third-party product, companies like The Wollongong Group had been selling those since late 1983. HP-UX, meanwhile, had TCP/IP built in natively since 4.2BSD, 1983. Two different networking philosophies sharing the same room, one proprietary and one TCP/IP, stitched together after the fact so they could talk to each other. That structure kept repeating for decades after.
The person who first documented this structural weakness, in a fittingly ironic way, was Robert Morris Sr. A cryptographer at Bell Labs, he published "A Weakness in the 4.2BSD UNIX TCP/IP Software" in 1985, showing that because TCP sequence numbers were predictable, an attacker could impersonate a trusted host without ever receiving a single response packet. He left Bell Labs the following year to become chief scientist at the NSA's National Computer Security Center, helping produce the official evaluation criteria for computer security, the Rainbow Series.
Then, the night of November 2, 1988, his son Robert Tappan Morris (a Cornell grad student at the time) released what would become known as the Morris Worm from MIT's network. The worm's own methods were a different lineage from the father's paper. Four vectors, chained together. One, abusing sendmail's DEBUG mode, meant for debugging, which let part of a mail message get executed as a command directly. Two, a buffer overflow in fingerd. A fixed-length buffer, written to unchecked via gets(), exploited to overwrite the stack's return address and run arbitrary shellcode. That's the same "stack smashing" technique Aleph One would formalize eight years later, already in live use here. Three, the same .rhosts/hosts.equiv trust abuse. Four, a simple brute-force password guess using a dictionary of a few hundred words plus username variations.
Morris's own design mistake is baked into this worm too. To make reinfection hard to detect, it allowed itself to reinfect an already-infected host with some probability, one in seven. That probability turned out to be set too high, and dozens of infection processes piled up on a single machine, chewing through CPU and memory until the host stopped functioning. Not malice, the attacker's own miscalculation multiplied the damage, a pattern that would repeat in worm outbreaks for years afterward. In the end, roughly 6,000 systems, about a tenth of the internet at the time, were affected. This incident is what drove DARPA to establish CERT/CC (Computer Emergency Response Team Coordination Center) at Carnegie Mellon, effectively founding "computer security incident response" as its own discipline. The trial produced the first felony conviction under the 1986 Computer Fraud and Abuse Act (CFAA).
A father points out the theoretical fragility of a trust model, a son goes and breaks essentially that same trust model (different shape, same idea) for real. This is, to me, the single most emblematic story of that era, less a technical vulnerability than the field of computer security itself emerging out of what feels like a family conversation.
There was already an official yardstick in the VAX/VMS world too, by the way. TCSEC, the Orange Book, drawn up in 1983 by the NCSC (National Computer Security Center, part of the NSA, the same place Robert Morris Sr. later moved to), intended for the Department of Defense. It graded systems from D (lowest) to A1 (highest), and that grade drove product selection in government procurement. A serious attempt at quantifying trust, but the thing being evaluated was always a single, standalone system, the idea of being attacked over a network by a different system wasn't yet front and center in how the criteria were designed. What the Morris Worm exploited was precisely that gap, each system had been graded seriously on its own, but nobody had graded what happened once they were wired together.
PGP and the First Crypto War
In 1991, Phil Zimmermann released PGP (Pretty Good Privacy) for free. Letting anyone protect their email with strong encryption sounds obviously fine, but at the time it was potentially a violation of US arms export regulations (ITAR). Zimmermann himself became the subject of a DOJ investigation.
That conflict reached its peak in 1993 when the Clinton administration proposed the Clipper Chip. An encryption chip meant for standard inclusion in phones and similar consumer devices, built with "key escrow" so the government held a copy of every chip's key. Law enforcement wanted to decrypt with a warrant. The public wanted the right to use strong encryption freely. The Clipper Chip itself never caught on in the end, helped along by opposition from groups like the Electronic Frontier Foundation, but the underlying question, how much cryptographic strength should ordinary people be allowed, kept resurfacing in new forms for years after. I was only a few years into the industry at the time, and honestly had no real sense of how large a fight this would stay.
1995, Mitnick and SATAN
A few years into my career, 1995 turned out to be a big year in two separate ways.
One was Kevin Mitnick's arrest in North Carolina on February 15. It traces back to the previous Christmas, 1994, when he broke into the machines of Tsutomu Shimomura (then at the San Diego Supercomputer Center). Tracing the intrusion technique later, I remember reading it over and over just for the sheer audacity of completing authentication without ever receiving a single response packet.
Here's the actual sequence. Mitnick first used reconnaissance commands, finger, showmount, rpcinfo, to establish that an rlogin-based trust relationship existed between an X terminal and a server in Shimomura's environment. He then neutralized that server itself, flooding it with SYN packets spoofed from real but unresponsive source addresses. What we'd now just call a SYN flood, filling it with half-open connections until it went silent. With the server muted, he predicted the TCP sequence number it would have issued to a legitimate client by sending it a series of separate SYN packets and watching how it behaved. Then he spoofed the server's IP to the X terminal and completed the three-way handshake without ever receiving a single response packet. The one command sent over that connection, impersonating root, was echo + + >> /.rhosts. That's it. Root from any host on earth now had unconditional login to that X terminal.
This is regarded as the first real-world use of the TCP sequence number prediction attack Robert Morris Sr. described as theory in his 1985 paper. Nine years later, the attack technique from that paper got executed as an actual intrusion. Shimomura tracked Mitnick down himself using sophisticated network monitoring techniques, eventually leading to the FBI arrest. It was widely covered at the time as the turning point where the era of lone hackers repeatedly outmaneuvering national agencies gave way to individuals being run down by expert technical skill, I remember it being big news.
The other was Dan Farmer and Wietse Venema's free release of SATAN (Security Administrator Tool for Analyzing Networks) about two months later, April 5. A scanner for surfacing known vulnerabilities across a network, it's the direct ancestor of what we'd now call a vulnerability scanner. Built as a defensive diagnostic tool, but one of the earliest examples of the industry broadly recognizing that the same tool doubles as reconnaissance for an attack, "dual-use" in a way that raised enough alarm to draw threatening noises from the Department of Justice. The industry hadn't yet gotten used to defense and offense sharing the same code, a structure that's completely unremarkable today.
Japan was building out its own equivalent infrastructure around the same time. What had been volunteer-run incident response activity since roughly 1992 formally became "JPCERT/CC" (Computer Emergency Response Team Coordination Center) in October 1996, eight years behind the US's CERT/CC, founded in response to the Morris Worm. At my own employer, though, the idea of actually contacting an incident response body when something happened hadn't really taken root yet, the instinct was still to absorb the problem locally and handle it in-house.
Weakened Crypto Got Broken Anyway
In 1994, Netscape built encrypted communication (SSL 2.0) into its browser and published the spec that November, the same year. The pitch was safely exchanging credit card numbers over the web, groundbreaking at the time. Export policy cast a shadow here too, though, versions sold outside the US were restricted to a weakened 40-bit "export grade" cipher.
That restriction became a real problem faster than expected. In August 1995, researchers in France, Sweden, and the UK independently ran workstation clusters for eight straight days and brute-forced their way through that 40-bit RC4. Worse followed in January 1996. Ian Goldberg and David Wagner, then UC Berkeley grad students, found a flaw in Netscape's own random number generation. It seeded from predictable values like process ID and system time, narrowing the key space so dramatically that a single ordinary desktop could recover the key in seconds to minutes. Weaken the strength by policy, and implementation sloppiness stacks right on top of it, breaking things even faster than the theoretical weakness alone would predict. Export controls ended up doing the opposite of raising the floor on encryption strength. They just weakened the browser the honest users were running.
The Day Stack Overflows Became Public Knowledge
In November 1996, Phrack issue 49 carried Aleph One's (real name Elias Levy) "Smashing the Stack for Fun and Profit," the first systematic, general-audience explanation of overflowing a stack buffer to overwrite the return address and execute arbitrary code.
Reading this paper left me with mixed feelings, because the technique itself wasn't new. The fingerd attack the Morris Worm used in 1988 was, in principle, the exact same stack smashing. A technique understood only by a handful of researchers and a small number of attackers became, with this paper, public knowledge anyone could read and reproduce. Whatever the ethics of that, buffer-overflow-driven worms and intrusions surged for years after this paper's publication. Code Red in 2001 and SQL Slammer and Blaster in 2003 trace back, at the root, to this same class of vulnerability. Widely shared knowledge raises the defensive floor and widens the attacker's base at the same time. I got that double edge driven home repeatedly over my first several years in the industry.
From a Foreign Computer Company to a Japanese Manufacturer, Melissa to Log4Shell
I stayed at that US computer company until roughly 1997, right as the internet was properly entering the corporate world, and it was around then that I first felt, viscerally, the fear of work that used to live entirely inside the internal network suddenly connecting directly to the outside world. After that I moved to the internal systems department of a large Japanese electronics manufacturer, taking on a much wider range of internal servers. IIS servers were only one slice of that, and the roughly 50 that would later get thrown around by Code Red were just one corner of it.
Worth being honest here, my own technical grounding grew up on the VAX/VMS and HP-UX side, I never went deep on Windows. And yet a good chunk of what's coming next (Outlook macros, IIS buffer overflows, Windows network services) happens squarely on the Windows side. I spent a lot of this period chasing down failures on an OS I wasn't native to, learning it on the fly under pressure.
Melissa in 1999 hit not long after I'd started at the manufacturer. A macro virus that read the Outlook address book and forwarded itself, it brought the internal mail servers to their knees overnight. I remember manually distributing antivirus definition updates by hand, and getting it drilled into me, not intellectually but through the sheer chaos on the ground, that security isn't just the IT department's problem, it's directly tied to the behavior of every single employee who touches email.
A little before that, February 2000, Japan enacted its own "Act on the Prohibition of Unauthorized Computer Access." Before that, Japan had no law directly punishing unauthorized access itself (misusing an ID or password) without concrete resulting damage, there was a real sense of being powerless to act until harm had actually materialized. Fourteen years behind the US, which already had the CFAA in 1986, the country finally had a legal foothold.
Code Red in 2001 was a large-scale worm exploiting an already-disclosed IIS buffer overflow, and our IIS servers were hit across the board. The patch had existed for nearly a month before real damage occurred, the same shape you still see in CVE response today, and I felt it firsthand here for the first time. By then, "applying patches" was already becoming a dedicated job rather than something squeezed in on the side. By the time SQL Slammer and Blaster hit in 2003, firewalls and antivirus had gone from "nice to have" to "non-negotiable," and my own work had shifted from individual trouble tickets to designing the company's entire network perimeter.
Between 2003 and 2006 I got pulled into a distinctly Japan-specific mess. A virus called Antinny, parasitic on the file-sharing software Winny, would publish an infected PC's desktop, documents, and email address book straight onto the network without consent. In March 2004, investigation files from the Kyoto and Hokkaido prefectural police leaked one after another, and by 2006 internal Maritime Self-Defense Force documents leaked too, escalating to the point where the Chief Cabinet Secretary at the time publicly asked citizens to stop using Winny. I remember getting pulled into internal audits just to check "is Winny installed anywhere here." Winny's developer, Isamu Kaneko, was arrested in 2004 on suspicion of aiding copyright infringement, convicted at first instance, then acquitted on appeal by the Osaka High Court in 2009, with the Supreme Court upholding that acquittal in 2011. Where the responsibility for building software ends and the responsibility for its misuse begins feels like a question that connects straight through to today's debates over AI tools. Technically, Winny was also a network built on the good-faith assumption that strangers would fairly exchange files with each other, and Antinny is exactly what tore through that trust assumption, the identical shape to everything else in this piece.
Watching the Stuxnet news in 2010, I honestly went quiet for a while. It showed a cyberattack could step outside the code entirely and physically destroy equipment. The meaning of what we'd all been defending shifted a notch. Then Snowden's disclosures in 2013 raised a possibility nobody wanted to sit with, that the attacker isn't just a criminal or a hostile state's intelligence service, but potentially your own country's. That shakes the very premise of "who do you trust" at its root. WannaCry/NotPetya in 2017 saw an exploit reportedly held by the NSA (EternalBlue) leak and get weaponized to hold systems worldwide hostage. That's around when I first started hearing executives, not just engineers, talk about patch schedules as a direct business risk. SolarWinds in 2020 and Log4Shell in 2021 drove home something worse, that the dependency packages and vendor software you trust and build on can themselves become the attack path. Hardening your own network was no longer enough. The outside world itself had become suspect, and I felt that shift keenly.
Lay my own career changes alongside this timeline and each incident, technically completely different from the others, keeps telling the same shape of story. Somewhere, "we can trust this" got assumed, a hostname, a TCP sequence number, a dependency package in the supply chain, whoever's on the other end of the network, and that assumption is exactly where the attack ends up entering later. VMS's CRC, rlogin's .rhosts, the design of TCP/IP itself, all share one thing, none of them were built with a malicious third party sneaking in as a design consideration.
What I Think Computer Security Actually Is
Looking back over these thirty-odd years, this is the understanding I've landed on. Computer security isn't really an independent technical discipline so much as a continuous, after-the-fact reconciliation, born the instant a system built assuming only trustworthy people would touch it gets touched by people you can't trust. VAX/VMS, UNIX/BSD, TCP/IP, all of them were originally built for a small community of researchers and engineers, and none of them accounted for a malicious presence outside that community. That's not a fair thing to fault them for, it was more than sufficient at the time. The problem is that every time scale expanded from there, that same trust assumption got betrayed all over again.
And now, the AI agent story I keep writing about looks, to me, like a straight remake of the same structure. GTG-1002's trick in 2025, convincing an AI agent that this is legitimate, authorized work, is at bottom the exact same shape as rlogin trusting "this connection came from a trusted host" and skipping the password. The material used to decide trust changed from a hostname to a model's natural-language explanation of intent, but the underlying structure, handing over authority based on trust in something you have no way to verify, hasn't changed since 1988.
Building RoamSwitch's MCP server as read-only from the very start, looking back, was really just putting this history's lesson into practice. Decide the scope of the damage a betrayed trust can do at design time, before deciding what to trust in the first place. The 1988 worm, 1995's SATAN, and 2025's AI agent abuse all start from the identical failure, the scope of what got trusted turned out wider than anyone had assumed. Technology has cycled through generation after generation over these thirty-plus years. The shape of the problem we're actually up against has barely changed at all.
Top comments (0)