🔰三菱電機への不正アクセスでも注目された「見えないファイルへの抜け道」――ハッカーは「ファイルの住所」を狙っている🔯ミカと教授のサイバーセキュリテイ🖥️第9回

ディレクトリトラバーサル――「見せるつもりのないファイルまで、なぜ読まれるのか」

ミカ「教授、前回は入力欄からOSへ命令が届くコマンドインジェクションでしたね」
教授「そうだった」
ミカ「今回はディレクトリトラバーサル。名前からして山歩きみたいですが」
教授「山ではなく、サーバーのフォルダを歩く」
ミカ「普通に歩くだけなら健康的です」
教授「ところが攻撃者は、立入禁止区域まで歩いていく」
ミカ「急に不健康になりました」
教授「今日のテーマは、Webサイトから本来公開するつもりのないファイルへ到達してしまう仕組みだ」

これは何を狙う攻撃なのか

ミカ「ディレクトリとはフォルダのことですね」
教授「ほぼそう考えてよい。サーバーの中でも、ファイルはフォルダの階層に整理されている」
ミカ「Windowsなら『ドキュメント』の中に『顧客』、その中に『2026年』みたいな感じですね」
教授「そうだ。そしてWebアプリケーションの中には、利用者からファイル名などを受け取り、そのファイルを表示する機能がある」
ミカ「請求書のPDFを表示するとか」
教授「商品説明書をダウンロードするとかな」
ミカ「普通の機能ですね」
教授「問題は、利用者から受け取った『ファイルの場所』を、そのまま信用してしまう場合だ」
ミカ「攻撃者が別の場所を指定する？」
教授「そうだ。本来公開用として決められたフォルダから外へ移動するようなパスを与え、非公開のファイルへ到達しようとする」
ミカ「それがトラバーサル？」
教授「Traversalは横断、移動といった意味だ。IPAも、パス名のチェックが不十分な場合、本来公開を想定していないファイルが閲覧される可能性があると説明している。 」
ミカ「つまり狙っているのはパスワードではなく」
教授「ファイルの住所だ」

なぜ成立するのか

ミカ「でもWebサイトには、公開するファイルだけを置くのでは？」
教授「理想的にはそうだ。しかし実際のサーバーには、設定ファイル、ログ、プログラム、認証に関係する情報など、外部へ見せるべきでないものも存在する」
ミカ「Webページの裏側には、いろいろなファイルがある」
教授「そうだ」
ミカ「では、例えば『manual.pdfをください』と要求されたら、プログラムがそのファイルを探して返す」
教授「ここまでは正常だ」
ミカ「でもファイル名の指定部分へ、別のフォルダへ移動する意味を持つパスを入れたら？」
教授「入力値の検証が不十分なら、プログラムが予定していたフォルダの外まで探しに行ってしまう可能性がある」
ミカ「受付係に『資料室のAファイルをください』と言う代わりに、『廊下を戻って、階段を上って、社長室の金庫の横のファイルをください』と言うようなものですね」
教授「そして受付係が『承知しました』と取りに行ってしまう」
ミカ「断ってください」
教授「その『断る仕組み』をプログラマーが作らなければならない」

身近な例に置き換える

ミカ「もっと身近な例をお願いします」
教授「ホテルにしよう」
ミカ「今回は旅行ですか」
教授「宿泊客には302号室が割り当てられている。ホテルのアプリには『部屋の写真を見る』という機能がある」
ミカ「room302.jpgを表示する」
教授「そうだ。ところがアプリが利用者から指定されたファイル名を何でも受け入れる」
ミカ「攻撃者が『302号室ではなく、支配人室へ行ってこの書類を取ってきて』と指定する？」
教授「そういうイメージだ」
ミカ「アプリがそのまま従ったら、宿泊客が見るはずのない書類まで見えてしまう」
教授「ディレクトリトラバーサルとは、部屋番号を指定する機能を、館内探索ツアーに変えてしまう攻撃とも言える」
ミカ「しかも支配人はツアーを許可していない」
教授「攻撃者は旅行代理店を通さないからな」

日本企業の関連事例――三菱電機への大規模不正アクセス

ミカ「日本企業でも、ディレクトリトラバーサルが問題になった事例はありますか」
教授「関連事例としてよく挙げられるのが、2019年に発生し、2020年に公表された三菱電機への大規模な不正アクセスだ」
ミカ「三菱電機ですか」
教授「三菱電機の公式発表によると、2019年3月、中国拠点にあるウイルス対策管理サーバーが未公開の脆弱性を突いたゼロデイ攻撃を受け、そこから国内外の端末へ侵入が拡大した。感染の疑いがある端末は国内外で132台とされた。個人情報や企業機密が流出した可能性も公表された。 」
ミカ「ウイルス対策ソフトを管理するサーバーが入口ですか」
教授「皮肉だろう」
ミカ「警備会社の詰め所から泥棒が入ったようなものですね」
教授「なお、ここは正確に区別する必要がある。三菱電機自身の公式発表は、侵入に使われた未公開脆弱性を『ディレクトリトラバーサル』とは明記していない」
ミカ「では、なぜ関連事例として扱われるのですか」
教授「当時、三菱電機の事件との関連が報じられたトレンドマイクロの法人向け製品には、ディレクトリトラバーサルの脆弱性が公表されていた。JVNも、同社製品にディレクトリトラバーサルの脆弱性が存在したことを公表している。 」
ミカ「つまり、『三菱電機事件＝ディレクトリトラバーサルだった』と断定してはいけない」
教授「そのとおりだ。しかし、企業の重要なセキュリティ製品にも、ファイルの経路処理に関する脆弱性が存在し得るという現実を示す関連事例としては重要だ」
ミカ「サイバーセキュリティの記事では、攻撃者だけでなく書き手も慎重でないといけませんね」
教授「断定のしすぎも、情報セキュリティ上の事故になりかねない」

「一つ上のフォルダ」がなぜ危険なのか

ミカ「ディレクトリトラバーサルでは、フォルダの階層を上へ移動する考え方が使われるのですね」
教授「そうだ。コンピューターには、現在の場所から親ディレクトリへ移動するといった相対パスの仕組みがある」
ミカ「それ自体は悪いものではない？」
教授「もちろん。正常なファイル操作でも使われる」
ミカ「SQLもOSコマンドも同じでしたね。道具そのものが悪いわけではない」
教授「そのとおり。問題は、利用者が自由に指定できる値を、そのままファイルパスとして信用することだ」
ミカ「『一つ上へ行く』を何度も許してしまえば、公開フォルダの外へ出られる可能性がある」
教授「そうだ」
ミカ「ホテルの宿泊客が『階段を一つ上へ』を繰り返して、最上階の社長室へ」
教授「そのホテルは途中で警備員を置くべきだな」

成立すると何が起きるか

ミカ「非公開ファイルを読まれると、具体的に何が困りますか」
教授「読まれるファイルによる」
ミカ「設定ファイルなら？」
教授「データベースの接続先やシステム構成など、攻撃の手掛かりになる情報が含まれている可能性がある」
ミカ「ログなら？」
教授「利用者名や内部のパス、処理内容などが残っている場合がある」
ミカ「認証関連のファイルなら？」
教授「さらに深刻だ。JPCERT/CCは、Pulse Connect Secureのディレクトリトラバーサル脆弱性では、認証前の攻撃者が任意のファイルを読み取れる可能性があり、過去にログインした利用者の認証情報やセッション情報が含まれるファイルまで閲覧され得たと説明している。 」
ミカ「ファイルを一つ読めるだけだと思ったら、そのファイルの中に次の扉の鍵が入っているかもしれない」
教授「そこが怖いところだ」
ミカ「一つの脆弱性が別の侵入につながる」
教授「サイバー攻撃は、弱点を一個使って終了するとは限らない。一つ目の穴から、二つ目の鍵を探すことがある」

「読むだけ」だから軽いとは限らない

ミカ「でも、ファイルを読むだけなら改ざんより軽いのでは？」
教授「そうとも限らない」
ミカ「なぜですか」
教授「例えば、秘密鍵、設定情報、アクセス情報などが読まれれば、それを使って別の攻撃へ進める可能性がある」
ミカ「銀行の金庫を開けなくても、警備員の勤務表と暗証番号を書いた紙を読めたら危ない」
教授「そういうことだ」
ミカ「しかも被害に気付きにくそうです」
教授「ファイルが削除されれば誰かが気付く。しかしコピーされただけなら、元のファイルはそこに残っている」
ミカ「泥棒が何も持ち出していないように見える」
教授「実際には写真を撮って帰ったようなものだ」
ミカ「静かな泥棒ですね」
教授「情報漏えいには静かなものが多い」

安全な範囲で仕組みを確認する

ミカ「今回も、実際のサイトを攻撃せずに仕組みだけ確認しましょう」
教授「黒板にこう書こう」
ミカ「公開用フォルダがあります」
教授「その中にmanual.pdf、price.pdf、guide.pdfがある」
ミカ「利用者はWeb画面で、この三つだけダウンロードできる」
教授「正常な設計なら、利用者が指定した番号を見て、プログラム側が対応するファイルを返す」
ミカ「1ならmanual.pdf、2ならprice.pdfという具合ですね」
教授「そうだ。ところが危険な設計では、利用者が入力したファイル名そのものをサーバー上のパスへ連結する」
ミカ「そこが問題ですね」
教授「攻撃者が公開フォルダの外を示す値を送っても、プログラムがそのまま処理する可能性がある」
ミカ「では安全な設計は？」
教授「利用者にサーバー上のパスを自由に指定させない」
ミカ「ファイル番号だけ受け取って、実際のファイル名はプログラム側で決める」
教授「非常に良い」
ミカ「受付で『どこでも好きな部屋へ行ってください』ではなく、『A、B、Cの資料のどれですか』と選ばせる」
教授「それだけでも設計思想が大きく変わる」

プログラマーはどう防ぐか

ミカ「では開発者向けの対策です」
教授「第一は、外部から受け取ったファイル名をそのまま使用しないことだ」
ミカ「IPAもそう言っていますか」
教授「IPAは根本的な解決策として、外部から受け取るパラメータを直接ファイル名として使用せず、プログラム側で固定したファイル名との対応付けを行う方法を示している。 」
ミカ「つまり？」
教授「例えば利用者から『report2026.pdf』という文字列そのものを受け取るのではなく、『report=3』のような識別子だけを受け取り、3ならプログラム側で決めたファイルを表示する」
ミカ「利用者に住所を書かせない」
教授「そうだ。目的地の番号だけ選ばせる」
ミカ「どうしてもファイル名を受け取る必要がある場合は？」
教授「許可する文字、形式、ファイル名を厳格に制限し、パスを正規化した後に想定したディレクトリ内に収まっていることを確認する」
ミカ「危険な文字だけを削除する方法は？」
教授「ブラックリストだけに頼るのは危険だ。表記の変形やエンコードなどを考えると、漏れが起きやすい」
ミカ「今回も『悪いもの全部禁止』より『良いものだけ許可』ですね」
教授「セキュリティ界の常連だ」

非公開ファイルをWebサーバーに置きすぎない

ミカ「プログラム以外にも対策がありますか」
教授「重要だ。そもそも読まれたら困るファイルを、Webから簡単に到達できる場所へ置かない」
ミカ「個人情報や重要な設定ファイルですね」
教授「IPAも、重要情報をWebサーバー上のファイルとして保存する場合、公開領域の外に置くことなどを対策として挙げている。 」
ミカ「金庫をホテルのロビーに置かない」
教授「たとえ鍵を掛けていてもな」
ミカ「バックアップファイルも？」
教授「よく忘れられる。古い設定ファイル、バックアップ、開発時の一時ファイルなどが外部から見える場所に残ると、思わぬ情報源になる」
ミカ「『old』『backup』『temp』という名前を見ると、急に不安になります」
教授「プログラマーは過去を大切にしすぎることがある」

最小権限も再登場

ミカ「また最小権限ですか」
教授「今回も出演してもらう」
ミカ「レギュラーですね」
教授「Webアプリケーションを動かしているユーザーが、サーバー内のあらゆるファイルを読める必要はない」
ミカ「必要なフォルダだけ読めるようにする」
教授「そうだ。仮にパス処理に欠陥があっても、OS側のアクセス権で止められる可能性がある」
ミカ「アプリケーションの壁を突破されても、次の壁がある」
教授「多層防御だ」
ミカ「このシリーズ、壁を作る話が多いですね」
教授「壁がなければシリーズ第9回まで続かなかっただろう」

プログラマーが覚えておきたい基本

ミカ「今回もまとめてください」
教授「七つにしよう」
・利用者が入力したファイル名やパスをそのまま使用しない
・可能なら識別番号と固定ファイルをプログラム側で対応付ける
・入力値は許可リスト方式で制限する
・パスを正規化し、許可されたディレクトリ内に収まることを確認する
・重要ファイルをWeb公開領域へ置かない
・Webアプリケーションのファイルアクセス権限を必要最小限にする
・CMS、ライブラリ、VPN機器などの脆弱性情報を確認し、更新を行う
ミカ「SQLインジェクションやコマンドインジェクションと共通点がありますね」
教授「外部から来た値を信用しない」
ミカ「そして、自由に命令や場所を指定させない」
教授「セキュアコーディングの基本が見えてきたな」

経営者・利用者はどう防ぐか

ミカ「一般利用者には、今回もできることが少ないですか」
教授「アプリケーションの脆弱性そのものはサービス提供者側の責任が大きい。しかし経営者には重要な確認事項がある」
ミカ「何でしょう」
教授「まず、自社サイトにどんなCMS、プラグイン、VPN、ファイル共有システムなどが動いているか把握する」
ミカ「ホームページ制作会社に全部任せたままにしない」
教授「そうだ。脆弱性が公表されたとき、自社がその製品を使っているか分からなければ、パッチを当てる判断すらできない」
ミカ「IT資産の棚卸しですね」
教授「会計の棚卸しと同じで、存在を把握しなければ管理できない」
ミカ「ほかには？」
教授「Webサーバーに何が保存されているか確認する。不要な個人情報、古いバックアップ、昔のログを漫然と残さない」
ミカ「盗まれないことに加えて、盗まれる物を減らす」
教授「情報の最小化だ」
ミカ「100個の機密ファイルを置いておいて『全部守ります』より、必要な10個だけ置く」
教授「守る対象が減れば、防御も監査もしやすくなる」

「URLを知らなければ見つからない」は防御ではない

ミカ「教授、誰にも教えていないURLなら安全ですか」
教授「それをセキュリティ対策とは呼ばない」
ミカ「検索エンジンにも載っていません」
教授「攻撃者が検索エンジンだけを使うとは限らない」
ミカ「では、『リンクを置いていないから秘密』も？」
教授「秘密ではない。単に案内板がないだけだ」
ミカ「裏口に鍵を掛けず、『場所を誰も知らないから大丈夫』と言っているようなものですね」
教授「そのとおり。場所を秘密にすることと、アクセスを制御することは別物だ」
ミカ「このシリーズ、経営者が言いそうな安心材料を一つずつ壊していきますね」
教授「壊しているのは安心材料ではない。思い込みだ」

三菱電機の事例から経営者が見るべきこと

ミカ「三菱電機の事件から、経営者が学ぶべきことは？」
教授「特定の脆弱性名だけに注目しないことだ」
ミカ「どういう意味ですか」
教授「三菱電機の公式発表では、ウイルス対策管理サーバーの未公開脆弱性を突かれ、そこから複数拠点へ侵入が広がった。つまり、守るために導入した製品そのものも攻撃面になり得るということだ。 」
ミカ「セキュリティソフトを入れたから終わり、ではない」
教授「ソフトウェアには更新が必要で、アクセス権限も必要で、監視も必要だ」
ミカ「そして、そこから読めるファイルを限定する」
教授「そうだ。万一突破されても、何でも見える状態にしない」
ミカ「セキュリティとは『入られないこと』だけではないですね」
教授「入られても広がらない、見られない、持ち出せないところまで考える」

ミカと教授の一言で締める

ミカ「教授、今日のディレクトリトラバーサルを一言で説明してください」
教授「利用者に許したファイルの入口から、フォルダの道をたどって、本来見せるつもりのないファイルへ到達される攻撃だ」
ミカ「攻撃者は何を狙っている？」
教授「ファイルそのものだけではない。ファイルの住所を決める仕組みだ」
ミカ「プログラマーの一番大事な対策は？」
教授「利用者にサーバー内を自由に道案内させない」
ミカ「経営者は？」
教授「見られたら困る情報を、必要以上にWebサーバーへ置かない」
ミカ「なるほど。今日は『道』の話でしたね」
教授「そうだ」
ミカ「教授、帰り道を間違えて研究室の秘密ファイルを見つけたら？」
教授「そこには学生のレポート採点表がある」
ミカ「すぐ戻ります」
教授「今日一番迅速なインシデント対応だ」

次回予告

第10回　SSRF――「外から入れないサーバーへ、なぜ内部のサーバー自身がアクセスしてしまうのか」

ミカ「今度は私が入るのではないのですか」
教授「入らない」
ミカ「攻撃者も？」
教授「直接は入らない」
ミカ「では誰が？」
教授「会社のサーバー自身に行ってもらう」
ミカ「ハッカーは自分で侵入することすらやめたのですか」
教授「優秀な攻撃者ほど、他人に仕事をさせるものだ」