令和4年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問2｜NASが乗っ取られランサムウェアに感染した日——情報処理安全確保支援士で学ぶIoT機器の脆弱性インシデント事例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和4年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問2
• 主なテーマ: IoT機器（NAS・ルータ）の脆弱性、パストラバーサル、OSコマンドインジェクション、UPnPによる外部公開、ダイナミックDNS、sudo設定の悪用、ランサムウェア感染、検索エンジン対策（noindex）

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

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

「ファイルが開けない」——オフィスで起きるトラブルとしては、よくある話に見えます。しかしその裏で、社内の共有ストレージそのものが攻撃者に乗っ取られ、ランサムウェア（データを暗号化して身代金を要求する不正プログラム）に感染していたとしたら。情報処理安全確保支援士試験の午後Ⅰで出題されたこの事例は、まさにそういう「気づいたときには手遅れ」のインシデントを扱っています。

舞台になるのは、家庭やオフィスで使われるNAS（ネットワークに接続して複数の人でファイルを共有できるストレージ機器）とルータ（社内ネットワークとインターネットをつなぐ通信機器）です。どちらも、専門知識がなくても設置できる便利なIoT機器（インターネットにつながる組み込み機器）として普及しました。その「手軽さ」が、実は大きな落とし穴でした。

この記事を読むと、攻撃者がどうやって認証（利用者が本人かを確かめる仕組み）を回避し、NASの中で任意のコマンドを実行し、最終的に管理者権限まで奪ってランサムウェアを動かしたのか、その一連の流れが見えてきます。受験者にとっては、パストラバーサルやOSコマンドインジェクションといった頻出のWeb脆弱性を「ストーリーの中で」理解できる題材です。そして経営者・管理職にとっては、「在宅勤務のために何気なく行った設定変更」が、どれほど深刻なリスクを呼び込むのかを知る教材になります。

インシデントの概要

物語の中心にいるのは、ネットワーク機器を開発・販売するZ社です。従業員200名の中堅企業で、国内の中小企業を顧客に事業を展開しています。Z社が手がけるのは二つの製品。一つはファイル共有用のNAS製品「製品X」、もう一つはインターネット接続用のルータ製品「製品Y」です。どちらもLinux（広く使われている基本ソフト）をベースにしたOSを積んでいます。

Z社は「z-sha.co.jp」というインターネットドメイン名（インターネット上の住所にあたる名前）を持っており、製品Xの利用者は、Z社が提供するダイナミックDNSサービス（以下、DDNS-Z）を使うことで、インターネットの外側から自分のNASにアクセスできるようになっていました。ダイナミックDNSとは、契約のたびに変わってしまう不安定なIPアドレス（ネットワーク上の機器を識別する番号）に、固定の名前を結びつけ続けてくれる仕組みです。

そんなZ社に、ある日、顧客のA社から障害の報告が入ります。A社は従業員30名のデザイン会社。製品Xと製品Yを使い、デザインデータをNAS（以下、A社に設置されたものをNAS-A、ルータを ルータ-A と呼びます）に保存して社内で共有していました。報告の内容は、「NAS-A上のファイルが、名前は表示されるのに開けない」というもの。一見すると、よくあるファイル破損のようにも思えます。

しかし、ここに伏線がありました。A社は在宅勤務者の増加に対応するため、わずか7日前に、NAS-Aとルータ-Aの設定を変更し、従業員の自宅からインターネット越しにNAS-A上のファイルへアクセスできるようにしていたのです。便利になったはずのこの変更が、攻撃者を招き入れる扉になっていました。

何が起きたのか

調査を担当したのは、Z社の保守サポート課のK氏です。

K氏はまず、NAS-Aがどうやって外部からアクセスできるようになっていたのかを確認しました。NAS-Aは、DDNS-Zを使って「https://nas-a.z-sha.co.jp/」というURLでアクセスできるようになっていました。ルータ-AのグローバルIPアドレス（インターネット側から見える住所）が変わっても名前でたどり着けるよう、Z社のDNSサーバ（名前とIPアドレスを対応づけるサーバ）では、ホスト名「nas-a」に割り当てているIPアドレスを更新する仕組みが動いていました。このとき更新されるのがAレコード（ホスト名とIPv4アドレスを対応づける情報）で、その情報の有効期間を表すTTL（Time To Live。キャッシュをどれだけの時間保持してよいかを示す秒数）は、300秒という短さに設定されていました。IPアドレスが頻繁に変わっても、すぐに新しい住所へ追従できるようにするための設定です。

さらにK氏は、A社のネットワークと機器の設定を細かく見ていきます。問題は、NAS-Aを外部公開していた仕組みにありました。NAS-AにはUPnP（Universal Plug and Play。機器同士が自動で設定を行うための仕組みで、認証なしでリクエストを受け付ける仕様）を使った「UPnP設定要求機能」が有効になっており、ルータ-A（製品Y）に対して「インターネット側のポート443宛に来た通信を、NAS-Aのポート443へ転送してほしい」と自動で要求していました。ルータ-A側もUPnP機能が有効だったため、その要求どおりにポートフォワーディング（外部からの通信を内部の特定機器へ転送する設定）とファイアウォール（通信の出入りを制御する仕組み）の穴あけが、人手を介さず自動で行われていたのです。つまり、誰かが意識して「外に公開する」と決めたわけではなく、機器同士の自動連携によって、NAS-Aがインターネットに口を開けていました。

K氏がNAS-Aを調べると、深刻な事実が次々と明らかになります。

• デザインデータのファイルが暗号化され、拡張子（ファイル名の末尾につく種類を示す文字列）が書き換えられていた。
• A社に身に覚えのない、英語で書かれた脅迫文のテキストファイルが、NAS-Aに置かれていた。
• そして決定的だったのが、ファイル共有機能でもWeb操作機能でもアクセスできない「/root」というディレクトリ（管理者専用の領域）配下のファイルまで暗号化されていたことです。

ここでK氏は重要な判断を下します。今回の障害はランサムウェアによるものであり、しかも「A社のPCが感染してNAS-A上のファイルを暗号化したのではなく、NAS-A自体がランサムウェアに感染したことでファイルが暗号化された可能性が高い」と。

なぜそう言い切れたのか。鍵は、暗号化された範囲にありました。もしA社のPCから普通のファイル操作で暗号化されたのなら、PCから見える共有フォルダの中身は被害に遭っても、PCからは決して触れられない「/root」配下のような領域までは届かないはずです。ところが現実には、その手の届かない領域まで暗号化されていた。これは、ランサムウェアがNAS-Aの内部で、PC利用者よりはるかに強い権限で動いていたことを意味します。だからこそ「PC感染」ではなく「NAS-A自身の感染」と判断できたのです。

確信を得たK氏は、脆弱性、アクセスログ、DDNS-Zという三つの観点から、さらに調査を進めることにしました。

認証を回避し、コマンドを実行する——二つの脆弱性

NAS-Aの脆弱性修正プログラムの適用状況を確認すると、数週間前に公開されていた製品Xのパッチ（以下、パッチM）が当てられていませんでした。このパッチMは、Web管理機能に関する二つの脆弱性——脆弱性1と脆弱性2——を修正するものでした。未適用のまま放置されていたNAS-Aは、攻撃者にとって格好の標的だったのです。

まず脆弱性1。製品Xには「除外リスト」という仕組みがあり、「/css」「/images」「/js」といったディレクトリは、認証なしでアクセスしてよい場所として登録されていました（画像やデザインファイルなど、誰が見ても問題のない静的ファイルを置く想定です）。ところが、認証なしアクセスの処理にバグがあり、本来は除外リストに入っていない——つまり認証が必要なはずの——ファイルにまで、認証なしでアクセスできてしまったのです。

その手口が巧妙でした。攻撃者は「http://192.168.0.1/images/..%2fstatus.cgi」のようなURLを使います。「..%2f」という文字列は、URLエンコード（URLで使えない文字を「%」と数字に置き換える表記）された「../」、すなわち「一つ上の階層へ戻る」という相対パス記法です。「/images/」という許可された場所から入り、「../」で一つ上に抜けることで、本来認証が必要な「status.cgi」へたどり着いてしまう。このように、許可されたディレクトリから上位の階層へ抜け出して目的のファイルに不正アクセスする攻撃手法を、パストラバーサル（ディレクトリトラバーサルとも呼ばれる、パスをたどって本来見えてはいけない領域に到達する攻撃）と呼びます。

次に脆弱性2。製品XのWeb管理機能には、指定したIPアドレスに対してping（相手と通信できるかを確認するコマンド）を実行する便利な機能がありました。しかし、このIPアドレスの処理にも脆弱性があり、入力値に細工をすると任意のOSコマンドを実行できてしまったのです。たとえば「ping 127.0.0.1;whoami」という文字列を送ると、本来のping実行に続けて、セミコロンの後ろにある「whoami」（現在のユーザー名を表示するコマンド）まで実行されてしまいます。アプリケーションへの入力を通じてOSのコマンドを不正に実行させるこの手法を、OSコマンドインジェクション（入力値にOSコマンドを注入し、サーバ上で勝手に実行させる攻撃）と呼びます。

そして恐ろしいのは、この二つを組み合わせたときです。脆弱性1で認証を回避しながら、脆弱性2でコマンドを注入する。つまり「POST /images/..%2fping.cgi」のようなリクエストを送れば、ログインすら不要で、NAS-A上で任意のOSコマンドを実行できてしまいました。認証という最初の防壁が、完全に無力化されていたのです。

パッチMが加えた「処理の順番」という防御

このうち脆弱性1に対して、パッチMは賢い対策を加えていました。認証なしアクセスの処理の流れに「パス名の正規化」という工程を挟み、しかもその順番を厳密に定めたのです。パス名の正規化とは、「/images/../status.cgi」のように相対パス記法を含むパス名を、「/status.cgi」という実際の場所を表す形式へ変換する処理です。

正しい処理の順番は、次の三段階でした。まず①URLデコード（「..%2f」を「../」へ戻す）、次に②パス名の正規化（「../」を解決して実際のパスへ変換する）、最後に③除外リストとの比較（そのパスが認証なしアクセスを許可された場所かを判定する）。

この順番が決定的に重要です。もし正規化やデコードより先に除外リストと突き合わせてしまうと、「/images/..%2fstatus.cgi」という見かけ上は「/images/」で始まる文字列が「許可されたディレクトリ」と誤判定され、攻撃をすり抜けてしまいます。エンコードを元に戻し、相対パスを実際のパスへ変換し、本当の到達先を確定させてから判定する——この順序があって初めて、パストラバーサルを封じることができるのです。NAS-Aは、この修正が入る前の状態のまま放置されていました。

ログに残らなかったコマンドと、管理者権限の奪取

K氏は次に、NAS-Aのアクセスログ（誰がいつどんなリクエストを送ったかの記録）を調べました。すると、外部からHTTPSのリクエストを使ってOSコマンドを実行する攻撃ツール——以下、WebShellと呼びます——がNAS-A上に仕込まれ、実際にコマンドが実行されていたことが判明します。

ログをたどると、攻撃の足跡がくっきりと残っていました。13時01分にはパストラバーサルでの探りが、13時02分にはコマンド注入の試行が記録され、13時05分には「shell.cgi?cmd=whoami」というGETリクエスト（URLにパラメータを載せて送る方式）でコマンドが実行されていました。WebShellがすでに設置され、稼働していたことがわかります。

ところがここで、K氏は一つの壁にぶつかります。GETメソッド（リクエストの一種で、データをURLに含めて送る方式）で実行されたコマンドの内容はログに残っていて読み取れたのに、POSTメソッド（データをリクエストの本体＝ボディに載せて送る方式）で実行されたコマンドの内容が、まったく分からなかったのです。

理由は、ログの記録方式にありました。GETリクエストではコマンドがURLの一部として送られるため、URLを記録するアクセスログにそのまま残ります。一方、POSTリクエストではコマンドがボディ部分に入っており、このボディはアクセスログに記録されていませんでした。つまり、攻撃者がPOSTで何を実行したのかは、ログだけからは復元できなかったのです。攻撃の全容を解明しようとする防御側にとって、これは大きな痛手でした。

それでもK氏は、攻撃者がどうやって決定的な一手——WebShellの設置とランサムウェアの実行——にたどり着いたのかを突き止めます。

WebShellが置かれていたディレクトリは、本来は書き込み不可の領域でした。普通なら、攻撃者はそこにファイルを置けません。ところが、rootアカウント（システムを何でも操作できる最上位の管理者）の権限を使えば、書き込み可能に変更できてしまいます。問題は、攻撃者がどうやってroot権限を手に入れたか、です。

ここで浮かび上がったのが、製品Xのsudoコマンド(一般ユーザーが特定のコマンドだけを管理者権限で実行できるようにする仕組み)の設定でした。製品Xでは、設定ファイルに「www ALL=NOPASSWD: /bin/tar」と記述されていました。これは「wwwというアカウントは、パスワードなしでtarコマンドを管理者権限で実行してよい」という意味です。tarコマンドは、複数のファイルを一つのアーカイブ（書庫ファイル）にまとめたり展開したりする、標準的なコマンドで、製品Xではファームウェア（機器を動かす組み込みソフト）のアップデート時に、root権限でアーカイブを展開するために正規の用途で使われていました。

ところが、このtarコマンドには「落とし穴」がありました。tarには、アーカイブ処理の途中で任意のOSコマンドを実行できるオプションが存在するのです。具体的には「--checkpoint」と「--checkpoint-action=exec=（コマンド）」という組み合わせを使うと、tarの本来の用途とは無関係に、指定したコマンドをroot権限で実行できてしまいます。ファームウェアのアップデート時にはこのオプションは使っていなかったものの、設定上は「tarならパスワードなしでroot実行OK」となっていたため、攻撃者はこの抜け道を突いたのです。

こうして、K氏は攻撃の全体像を組み立てました——「攻撃者は、Web管理機能の脆弱性とtarコマンドのオプションを悪用し、書き込み不可のディレクトリを書き込み可能に変更してWebShellを設置した。そのうえでWebShellを使い、ランサムウェアを実行した」。認証回避、コマンド実行、権限昇格、そしてランサムウェアの実行。すべてがつながった瞬間でした。Z社は、製品Xでtarコマンドのオプションが悪用されるのを防ぐ対策の検討に着手します。

検索エンジンに「見つかってしまう」NAS

最後にK氏は、DDNS-Zの観点からも調査を進めました。すると、DDNS-Zを使って製品XにアクセスするためのURLが、インターネットの検索エンジンで特定のキーワードを検索するだけで、いとも簡単に見つかってしまうことが分かりました。攻撃者は、わざわざ標的を探し回らなくても、検索エンジンを使えば「公開されているNAS」を一覧で発見できてしまう。これでは、攻撃対象にされて当然です。

そこでZ社は、各Webページの`<head>`セクションに「`<meta name="robots" content="noindex">`」（検索エンジンのロボットに対し、このページを検索結果に登録しないよう指示するタグ。「none」でも同様の効果が得られる）を記載し、検索エンジンに登録されないようにする対策を検討しました。