史上初の大規模ワーム感染「モリスワーム」が現代セキュリティに残したもの

「インシデントの歴史って、実務でどう役立てればいいんだろう……」
「モリスワームって名前は知ってるけど、仕組みを誰かに説明できる自信がない」

チップス

インシデントの歴史って、なんで勉強しなきゃいけないんでしゅか？今の現場で使えるイメージが全然湧かないでしゅ……

ボス

それはな、歴史の意味がまだ分かっていないからだ。「なぜその対策が必要なのか」を根拠から語れるエンジニアと、ただルールに従うだけのエンジニア、どちらが現場で信頼されるか、考えてみろ。

この記事では、1988年に起きた「モリスワーム」の全貌と現代への教訓を解説します。

パッチ管理の本質やCSIRTの必要性を根拠から語れるエンジニアは、現場で確実に差がつきます。
フリーランスとして活躍するための土台が、ここにあります。

1988年11月、インターネットが止まった日

1988年11月2日、インターネット黎明期に突如起きた大規模障害は、セキュリティの概念そのものを塗り替えました。

6,000台のシステムが沈黙した朝

1988年11月2日の夜から翌朝にかけて、米国の大学や研究機関のUNIXシステムが次々と応答不能に陥りました。
約6,000台という被害規模は、当時インターネットに接続されていた全マシン（約60,000台）の約10%に相当します。

チップス

えっ、1988年ってもうインターネットがあったんでしゅか！？なんか意外でしゅね……

ボス

そうだな。当時のインターネット（ARPANET）は、大学や研究機関が中心のネットワークだった。商用利用はまだ黎明期で、誰もが「ここは信頼できる仲間のネットワーク」と信じていた。だからこそ、誰も攻撃を想定していなかったんだ。

コーネル大学の学生だったロバート・タッパン・モリス（当時23歳）が作成したプログラムが、設計上のバグにより制御不能な自己増殖を引き起こしました。
数時間で数千台のシステムが過負荷で停止するという、前例のない事態が発生しました。

事件の規模感を整理すると、以下の通りです。

この事件は「インターネット上で起きた史上初の大規模マルウェア感染」として記録されています。
セキュリティの歴史を語るうえで欠かせない出発点です（参照：Wikipedia – Morris worm）。

なぜここまで広がってしまったのか

感染が止まらなかった最大の理由は、当時のエンジニアが「悪意ある攻撃」をほぼ想定していなかったことです。
1988年のインターネットは、研究者や技術者たちの「善意のネットワーク」として設計されていました。
セキュリティより利便性が優先され、ホスト間の信頼関係がデフォルトで広く設定されていた時代です。

拡散を加速させた背景には、技術的な脆弱性だけでなく、運用面の未整備も大きく影響していました。
当時の環境における問題点を挙げると、以下のようになります。

「性善説」で設計されたネットワークは、ひとつの制御不能なプログラムに対して驚くほど無防備でした。
この教訓は、35年以上経った現在も色褪せていません。

モリスワームの仕組みを解剖する

シンプルに見えて、3つの脆弱性を連鎖させた設計は当時のエンジニアを翻弄しました。

3つの脆弱性が連鎖した攻撃経路

モリスワームは単一の脆弱性を突いたわけではありません。
3つの侵入経路を組み合わせることで、感染を爆発的に広げました。
ひとつの経路が塞がれても別の経路から侵入できる設計が、完全な封じ込めを困難にしました。

3つの攻撃経路を整理すると、以下の通りです。

なかでも fingerd のバッファオーバーフローは、当時の教科書にはほぼ載っていなかった攻撃手法です。
これを実際に悪用したことが、モリスワームを歴史的事件に押し上げた理由のひとつです。

ボス

この3経路の組み合わせは、現代の「多段階攻撃」の原型だ。守る側は全ての穴を塞がなければならないが、攻める側はひとつ見つければいい。この非対称性は今も変わっていないな。

自己増殖の設計と想定外の副作用

モリスワームには、感染を制御するための仕組みが一応組み込まれていました。
感染先のシステムに自分のコピーが既に存在するか確認し、いる場合は増殖を止めるというロジックです。
しかし、管理者に欺かれないよう「7回に1回は確認結果を無視して感染する」という設計が追加されていました。

チップス

えっ、わざとじゃなかったんでしゅか！？バグで被害が広がったってこと？

ボス

そうだ。意図と結果は一致しないことがある。その「7回に1回」の例外処理が裏目に出て、感染済みのシステムにも何度もコピーが作られ続けた。CPUとメモリを食い潰し、最終的にシステムが応答不能になった。リリース前にどれだけ影響範囲を想定できるか、それがエンジニアの力量だな。ふふふ。

モリスは後に「破壊を意図したものではなかった」と語っています。
しかし、意図がどうであれ、結果として数千台のシステムを停止させた事実は変わりません。
ツールを作る側が影響範囲を常に意識しなければならない理由を、この事件が教えてくれています。

この事件がセキュリティの歴史を塗り替えた

モリスワームは単なる障害事例に留まりません。現代のセキュリティ体制の礎を、複数の側面で作りました。

CERT/CCの誕生：インシデント対応体制の原点

モリスワームが残した最大の遺産は、CERT/CC（コンピュータ緊急対応チーム調整センター）の設立です。
事件当時、インシデントに対応する統括組織が存在しませんでした。
研究者たちは個別に連絡を取り合い、場当たり的な対処しかできませんでした。この反省が、組織的な対応体制の必要性を認識させました。

米国防総省の資金援助を受け、カーネギーメロン大学にCERT/CCが設立されたのは、事件からわずか数週間後の1988年11月末から12月のことです。
CERT/CCは現在も脆弱性情報の収集・公開を行う組織として機能しています（参照：Carnegie Mellon University SEI – CERT Division）。

CERT/CCが現代に残したものを挙げると、以下の通りです。

今や多くの企業・組織が当たり前のように持つCSIRTの原型は、モリスワームへの反省から生まれました。
「対応できる組織を作れ」という教訓は、今も現場で生き続けています。

コンピュータ犯罪法が整備されたきっかけ

モリスワームはセキュリティ技術だけでなく、法制度の面でも大きな転換点になりました。
当時の米国では、コンピュータへの不正アクセスを直接罰する法律の適用が曖昧でした。
モリスワームの事件は、既存の法律で新しい形の犯罪を裁く先例となりました。

ロバート・モリスは Computer Fraud and Abuse Act（CFAA、1986年制定）に基づき起訴され、1990年に有罪判決を受けました。
判決の詳細は連邦控訴裁判所の記録に残っています（参照：United States v. Morris, 928 F.2d 504, 2d Cir. 1991）。
判決の概要は以下の通りです。

チップス

バグのせいで被害が広がったのに、それでも有罪になるんでしゅか……なんか厳しい気がするでしゅ。

ボス

意図は量刑に影響するが、結果責任は免れない。これはセキュリティエンジニアが脆弱なコードを書いたときにも通じる考え方だ。ツールを作る側は、その影響範囲を常に意識しなければならないということだ。

「意図的な破壊でなくても、不正アクセスは犯罪になる」という先例が、この判決で打ち立てられました。
エンジニアが法的リスクを意識するべき理由を、歴史が教えてくれています。

現代のセキュリティエンジニアへの教訓

35年以上前の事件が、今も色褪せない理由があります。
本質は変わっていないからです。

脆弱性管理の本質は35年前から変わっていない

モリスワームが突いた3つの脆弱性は、すべて「既知の問題」でした。
パッチが間に合わなかったのではなく、適用する文化がなかったのです。
sendmailのdebugコマンドの問題はすでに認識されていましたが、多くの管理者が「うちは大丈夫だろう」という油断のもとで放置していました。

現在も状況は根本的には変わっていません。
IPAの「情報セキュリティ10大脅威 2024」でも、既知の脆弱性への対応遅れが毎年のように指摘されています（参照：IPA 情報セキュリティ10大脅威 2024）。
モリスワームから引き出せる教訓は、今もそのまま通用します。主なポイントは以下の通りです。

これらは新しい話ではありません。モリスワームの時代から言われ続けてきた基本原則です。
それでも被害は繰り返されます。
「知っている」と「実践している」の間には、いつも大きな溝があります。

このインシデントを知るエンジニアが評価される理由

セキュリティの歴史を語れるエンジニアは、現場での信頼が違います。
「なぜその対策が必要なのか」を本質から語れるからです。

ボス

歴史を知らないエンジニアは、なぜその対策が必要なのか理解できていないことが多い。理解なき対策は、状況が変わった途端に形骸化する。ふふふ。

フリーランスとして複数の現場を渡り歩く場合、歴史的背景の理解は特に価値を発揮します。
クライアントへのセキュリティ施策の説明で具体的なインシデントを引き合いに出すと、提案の説得力が格段に増します。
歴史知識が活きる具体的な場面を挙げると、以下のようになります。

チップス

わかりました！インシデントの歴史を学ぶって、ただの知識じゃなくて、現場での説得力につながるんでしゅね！

ボス

そういうことだ。セキュリティの歴史は、現在進行形の問題に直結している。チップス、お前もそろそろ付箋のパスワードを卒業する段階に来たな。

チップス

それはもうやめましたでしゅ……たぶん。

モリスワームを「昔話」で終わらせず、現代の文脈に接続できるエンジニアが、これからも現場で求められる存在です。

まとめ

1988年のモリスワームは、単なる「過去の事件」ではありません。
CERT/CCの設立、コンピュータ犯罪法の整備、パッチ管理文化の必要性。
現代のセキュリティを構成する要素の多くは、この事件への反省から生まれました。

脆弱性管理の基本、インシデント対応体制の整備、最小権限の原則。
これらは35年以上前から言われ続けてきた原則です。それでも被害は繰り返されます。
「知っている」と「実践している」の間には、いつも大きな溝があります。

歴史を知り、本質を語れるエンジニアは現場で確実に差がつきます。
セキュリティのキャリアをさらに前進させたい方は、是非次のステップを検討してください。