令和3年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問3｜眠っていたPCが招いた感染——情報処理安全確保支援士で学ぶ脆弱性パッチ運用とWake on LANの落とし穴

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和3年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問3
• 主なテーマ: 脆弱性修正プログラム（セキュリティパッチ）の配信運用、Wake on LAN（WoL）、マジックパケット、ブロードキャストの転送、EDR、ARPテーブルの悪用、パケット収集による通信監視

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「脆弱性が見つかったら、修正プログラム（セキュリティパッチ）を当てる」——セキュリティ対策の基本中の基本です。ところが、現実の大きな組織では、これが意外なほど難しい。パッチを当ててよいか検証に時間がかかり、当てる対象のPCが何百台もあり、しかも一部のPCはずっと電源が入っていない。「全台に確実に当てる」ことが、こんなにも厄介なのです。

情報処理安全確保支援士試験の午後Ⅰで出題されたこの事例は、製造業の会社を舞台に、長く眠っていた一台のPCがマルウェアに感染した同業他社の事例をきっかけに、自社のパッチ配信運用を見直していく物語です。そこで活躍するのが、電源の入っていないPCを遠隔から起動させるWake on LAN（WoL）という技術。しかしこの便利な技術は、使い方を誤れば——あるいは攻撃者に悪用されれば——夜間に社内のPCを次々と起動させ、感染を広げる凶器にもなり得ます。

この記事を読むと、パッチ配信運用のどこに穴が空きやすいか、WoLのマジックパケットがどんな仕組みで動くのか、なぜネットワークをまたぐと起動できないのか、そしてEDRやパケット収集装置といった「導入済みの仕組み」をどう組み合わせて守りを固めるかが見えてきます。地味だけれど、実務に直結するテーマです。

インシデントの概要

舞台は、従業員1,500名の製造業G社です。研究開発に定評があり、従業員はWebアクセスでの情報収集や電子メールでの営業活動・情報交換にインターネットを使っています。G社は情報セキュリティポリシを整備して運用していました。

G社のシステムは、内部システムLAN、DMZ、利用者LAN、検証LANに分かれています。内部システムLANには、資産管理サーバ、配信サーバ、ログ蓄積サーバ、EDR管理サーバなどが置かれていました。すべてのPCとサーバには固定IPアドレスが割り当てられ、EDR（Endpoint Detection and Response＝端末上の不審な挙動を検知し対応する仕組み）のエージェントプログラムが導入されています。情シ部以外の従業員には、PCの管理者権限を与えていませんでした。

セキュリティパッチの配信は、配信サーバが一手に担っていました。各PCはパッチをOSベンダのサイトから直接ではなく、配信サーバからダウンロードします。配信の流れはこうです。OSベンダがパッチをリリースしたら、担当者がリリースノートを確認する。検証LANのPCにパッチを適用し、社内利用のアプリを2日間動作させて「PCの動作に問題がないこと」を確認する。新たな不具合情報が公開されていないことを確かめたうえで、パッチを配信サーバに置く。各PCは起動時に配信サーバへ問い合わせ、適用すべきパッチがあればダウンロードして適用する——。

慎重で、よく考えられた運用に見えます。しかし、この仕組みには一つの前提が隠れていました。「PCが起動していること」です。起動しないPCには、いつまでもパッチが届かない。この見落としが、後に問題として浮かび上がります。

何が起きたのか

ある日、情シ部のC主任が、同業他社のH社で発生したセキュリティインシデントの解説記事を見つけます。その内容は、G社にとって他人事ではありませんでした。

8月、H社の一台のPC（PC-H）がマルウェアQに感染していたことが判明します。各種ログから、PC-Hが外部の不審なサーバに約50Mバイトのデータを送信していたことが分かりました。PC-Hでは秘密情報が扱われていたため、H社は秘密情報が送信された可能性が高いと判断します。マルウェアQはOSの脆弱性を悪用して感染を広げるタイプで、その脆弱性に対するパッチ（パッチQ）は5月にOSベンダからリリースされ、H社では6月までに、PC-Hを除く全PCに適用されていました。

問題はPC-Hでした。このPCは1月から起動されておらず、7月に起動したときには、適用すべきパッチが多数たまっていた。そのため起動後、パッチQの適用が完了するまでに時間がかかり、その「無防備な隙間」の時間にマルウェアQに感染したと推測されたのです。さらに、マルウェアQの感染調査に必要なログが一部しか取得されていなかったため調査は難航し、決着は10月までもつれ込みました。記事は、H社のセキュリティ運用に問題があったと結論づけていました。

この記事に心配になったC主任は、自社のログを調査します。すると、G社にも1か月以上起動していないPCが30台あることが分かりました。これらをこのまま数か月起動しないでおくと、PC-Hと同じ問題が起きる可能性があった。眠っているPCが、いつ「無防備なまま目を覚まして感染する爆弾」になるか分からない——C主任は、B部長に相談したうえで、必要な対策を二つにまとめ、情シ部のD君とともに具体化することにしました。

対策1は、マルウェア感染を確認したときに、感染経路や外部に流出した情報を特定するための手段の導入。H社が調査に苦しんだのは、ログが足りなかったからでした。C主任は、L2SW（レイヤ2スイッチ）のミラーポート（流れる通信を複製して取り出す口）に接続するタイプのパケット収集装置を導入し、J社のサービスで通信内容を分析することを考えます。そして、たった一台のパケット収集装置を、どこに付けるかを慎重に検討しました。マルウェア感染がDMZでもどのLANで起きても、マルウェアからインターネットへの通信が必ず通過するL2SWに接続する——その場所こそが、G社では「インターネットとの通信を許可されている唯一の出口」であるDMZのL2SW1でした。出口を一点に絞って見張る、という発想です。

対策2は、社内におけるセキュリティパッチの配信手順の改善でした。ここで主役になるのが、Wake on LAN（WoL）です。

D君は提案します。「1か月起動していないPCを自動的に起動して、パッチを適用すればいい」。C主任が応じます。「当社のPCはWoLに対応している。WoLとは、対応PCに特定の起動パケットを送ると、そのPCが起動する仕組みだ。PCを利用者LANに接続しておけば、資産管理サーバから起動パケットを送って、PCを自動的に起動できる」。眠っているPCを夜間などに叩き起こし、パッチを当ててから再び眠らせる——理にかなった改善案でした。

D君は動作検証を始めます。検証LANのPC-XとPC-Yを使い、PC-Xを起動しておき、PC-Yはシャットダウンしておく。PC-XからPC-Yに対し、「FF:FF:FF:FF:FF:FF」（すべてのビットが1のブロードキャストMACアドレス）に続けて、起動したいPCのMACアドレスを16回繰り返したデータを含む起動パケット（マジックパケット）を送ると、PC-Yが起動することを確認しました。マジックパケットとは、6バイトの同期データに続けて、起こしたい端末のMACアドレスを16回並べた、特徴的な構造のパケットです。

ところが、資産管理サーバからPC-Yの起動を試みると、起動しませんでした。C主任に相談すると、「L3SW（レイヤ3スイッチ）の設定を変更する必要がある」との助言を受けます。マジックパケットはブロードキャスト（同一ネットワーク内の全端末宛て）で送られますが、L3SWは通常、ブロードキャストを別のセグメント（ネットワークの区切り）に転送しません。資産管理サーバとPCが別セグメントにあると、起動パケットが届かないのです。そこでD君はL3SWの設定を変え、起動パケットを他のセグメントに転送するようにしました。すると、資産管理サーバからPC-Yを起動でき、利用者LANのPCも起動してパッチが適用されることを確認できました。

しかし、WoLには光と影があります。WoLについて調べていたD君は、図5に示されたマルウェアRの記事を見つけ、背筋が寒くなります。マルウェアRは、起動していないPCをWoLで夜間に起動させ、感染を広げるのです。その手口はこうでした。感染するとすぐに、自身が動作するPCのARPテーブル（同一ネットワーク上のIPアドレスとMACアドレスの対応表）から、後の活動に必要な情報を読み取って保持する。夜間に、ARPテーブル中のPC全てにpingコマンドを送り、起動しているかどうかを確認する。起動しているPCには感染拡大を試みる。そして起動していないPCを発見したら、WoLを使ってそれらを起動させ、感染拡大を試みる——。

pingで生死を確認するにはIPアドレスが必要で、WoLで起動させるにはMACアドレスが必要です。ARPテーブルには、その両方が載っている。マルウェアRは、感染したPCのARPテーブルを「社内のPC名簿」として悪用し、昼は眠って気づかれず、夜は社内のPCを次々と叩き起こして感染を広げる——WoLという善意の技術が、攻撃者の手にかかれば感染拡大の道具に変わるのです。

D君は考えます。昼間はPCが不審な振る舞いをすれば発見して対処できるが、夜間は多くの従業員が不在で発見が難しい。そこで、マルウェアRに限らず、WoLを悪用するマルウェアへの対策をC主任に相談しました。C主任が助言したのは、PCが夜間に不審な振る舞いをしたときに、当該PCをネットワークから隔離する対策（対策3）でした。D君は、この対策3を、G社で導入済みのシステムを用いて実現する方法を立案します。EDRのエージェントには、PC上で起動する全プロセスを監視し、指定した時間帯に指定したコマンドが実行された場合に、当該PCの通信を遮断する機能がありました。これを使い、夜間にARPテーブルを読み取る「arpコマンド」の実行を検知したら、当該PCをネットワークから隔離する——。手元にある仕組みを組み合わせて、新たな脅威に立ち向かったのです。対策3は対策1・2と併せて承認され、各対策の運用が始まり、G社のマルウェア対策は強化されました。