認証なしで乗っ取られる、Webサーバーの深刻な欠陥

本記事は、よく見られる被害の流れをもとに構成したモデルケースです。特定の企業・事件を指すものではありません。

何が起きたのか

1. 公表当日：深刻な脆弱性が発表されるWebサイトを動かすためのサーバーソフトの開発元が、修正版とあわせて脆弱性を公表しました。専門機関も「認証なしで、外部から任意の操作をされるおそれがある」として、早急な更新を呼びかけました。
2. 翌日：「うちは関係あるの？」社内の担当者は、自社サイトがどのソフトの、どのバージョンで動いているのかを知りませんでした。レンタルサーバーなのか、制作会社が用意したクラウドのサーバーなのかも曖昧です。制作会社に問い合わせたものの、当時の担当者が退職しており、回答まで数日かかりました。
3. 数日後：探る通信が届き始める深刻な脆弱性が公表されると、それを抱えたサーバーを探す自動的な通信が一斉に増えることがあります。このサイトにも、見慣れない形式のアクセスが記録され始めていました。
4. 1週間後：対象だったと判明サイトは制作会社が個別に構築したサーバーで動いており、対象のバージョンを使っていました。すぐに修正版へ更新しましたが、調査で見覚えのないファイルが見つかったため、サーバーを作り直すことに。その間、サイトは一時公開停止となりました。

入口になった“ほころび”

この事例で問題だったのは、脆弱性そのものよりも、「自社のサイトが何で動いているかを、誰も把握していなかった」ことです。把握できていれば、公表当日に「対象かどうか」を判断し、更新を依頼できていました。

• 構成の記録がなかった：サーバーの種類、使っているソフトの名前とバージョン、管理している会社。この3つが、どこにも書き残されていませんでした。
• 更新の責任があいまいだった：一般に、複数の利用者で1台を共有する「共用サーバー」では、サーバーソフトの更新はサーバー会社が行うことが多い一方、「VPS」や「クラウド」で自社専用に用意したサーバーは、利用者側（または委託した制作会社）が更新する契約になっていることが多くあります。どちらの形なのかを、社内で誰も知りませんでした。
• 情報を受け取る窓口がなかった：注意喚起は公表当日から出ていましたが、社内でそれを見る人も、制作会社から連絡を受ける取り決めもありませんでした。

「認証なし」の欠陥は、なぜ深刻なのか

多くの不正アクセスは、パスワードを盗んだり推測したりすることから始まります。ところが「認証なしで悪用できる」脆弱性は、ログインそのものを飛び越えてしまうため、どれだけ強いパスワードを設定していても防げません。

さらに、修正版が公表されると、攻撃者もその情報を手に入れます。どこを直したのかを手がかりに攻撃方法が研究され、対象のサーバーを機械的に探し回る動きが始まることもあります。つまり、公表された直後こそ、更新までのスピードが問われる時期です。会社の規模や知名度は関係なく、「古いバージョンが動いているかどうか」だけで狙われます。

こうした注意喚起は、国内ではJPCERT/CC（一般社団法人JPCERTコーディネーションセンター）↗（新しいタブで開きます）や、IPA（独立行政法人情報処理推進機構）のセキュリティ情報↗（新しいタブで開きます）で公開されています。製品名や影響の範囲、修正版の有無が日本語でまとめられているので、まずはここを確認する習慣をつけると安心です。

今日からできる確認

1. サーバーの種類を確認する：契約書や請求書、サーバー会社の管理画面を見て、「共用サーバー」「VPS」「クラウド」「専用サーバー」のどれかを確かめます。共用サーバーなら、サーバー会社のお知らせページで緊急時の対応方針を確認しておきましょう。
2. ソフトの名前とバージョンを書き出す：Webサーバーのソフト、OS、CMS（WordPressなど）の名前とバージョンを一覧にします。分からなければ、制作会社に「使っているソフトとバージョン」「更新は誰が、どの頻度で行っているか」「緊急の脆弱性が出たとき、誰が判断して連絡をくれるか」の3点を質問してください。
3. 注意喚起の情報源をブックマークする：JPCERT/CCとIPAのページを登録し、月に一度でも目を通します。メールで受け取れるサービスもあります。
4. 緊急時の連絡ルートを決める：「公表を知ったら、誰が、誰に、何を確認するか」を一行でもいいので書き残しておきます。

外から見て、サーバーのソフト名やバージョンが表示されていないかは、まもりスキャンの簡易診断でも確認できます。ただし、表示を隠していても古いバージョンのままなら危険は残るため、最終的には管理している会社への確認が欠かせません。