🔰日本テレビ約43万件の個人情報流出の恐れ――ハッカーは「入力欄の奥のOS」を狙っている🔯ミカと教授のサイバーセキュリテイ🖥️第8回

コマンドインジェクション――「入力欄からOSへの命令まで届いてしまう」

ミカ「教授、第2回ではSQLインジェクションを勉強しましたね」
教授「利用者の入力がデータではなく、データベースへの命令として扱われてしまう攻撃だった」
ミカ「今回はコマンドインジェクションですか。何が違うのです？」
教授「命令が届く相手が違う」
ミカ「データベースではない？」
教授「OSだ」
ミカ「WindowsやLinuxのOSですか」
教授「そうだ。入力された文字列が、作りの悪いWebアプリケーションを通してOSへの命令に化けることがある」
ミカ「ホームページの入力欄から、そこまで届くのですか」
教授「届かせてはいけない。だが届いてしまう設計がある。それが今日の授業だ」
ミカ「入力欄の向こうにOSがいるとは思いませんでした」
教授「利用者には白い四角にしか見えない。しかしプログラマーには、その奥に何がつながっているかを想像する責任がある」

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

ミカ「OSコマンドインジェクションとは、簡単に言えば何ですか」
教授「Webアプリケーションが外部から受け取った値を使ってOSのコマンドを実行する仕組みを持っているとき、攻撃者が入力値の中へ別の命令を紛れ込ませ、それをOSに実行させる攻撃だ」
ミカ「文字を入力しただけなのに？」
教授「問題なのは文字そのものではない。その文字をプログラムがどこへ渡すかだ」
ミカ「たとえば？」
教授「Webアプリケーションが、入力されたファイル名を使ってファイル処理をしたり、外部プログラムを起動したり、サーバー上で何らかの処理を実行したりする場合がある」
ミカ「その途中でOSのシェルを使う？」
教授「そうだ。IPAも、外部プログラムを呼び出す機能を持つWebアプリケーションではOSコマンドインジェクションに注意が必要だとしている。攻撃が成立すると、ファイルの閲覧・改ざん・削除、不正なシステム操作、不正プログラムの実行、他システムへの攻撃の踏み台化などにつながり得る。 (情報処理推進機構)」
ミカ「SQLインジェクションより、さらに奥へ入った感じですね」
教授「SQLインジェクションが『データベースへの命令』なら、OSコマンドインジェクションは**『コンピューターそのものへの命令』**と考えると分かりやすい」

なぜ成立するのか

ミカ「なぜ利用者の文字がOSの命令になってしまうのですか」
教授「本来、プログラムは入力値を単なるデータとして扱うべきだ」
ミカ「第2回でも聞きました」
教授「セキュリティの基本原則は何度も登場する。ところがプログラムが、外部から受け取った値をそのままOSへ渡す命令文の一部として組み立ててしまうことがある」
ミカ「命令とデータが一つの文字列になってしまう？」
教授「そうだ」
ミカ「するとOSは、『ここまではプログラマーの命令、ここからは利用者が入力した商品名』とは考えてくれない」
教授「OSは空気を読まない」
ミカ「このシリーズで何度目でしょう」
教授「コンピューターが空気を読まないおかげで、プログラミングは成立している。しかし人間が境界線を曖昧にすると、その忠実さが危険になる」
ミカ「つまり攻撃者は、入力欄に普通のデータではなく、OSが別の命令だと解釈するような文字列を混ぜる」
教授「その考え方だ。具体的な攻撃文字列を覚える必要はない。重要なのは、外部入力をOSコマンドの文字列へ直接組み込む設計が危険だと理解することだ」

身近な例に置き換える

ミカ「今回も身近な例でお願いします」
教授「レストランにしよう」
ミカ「急に平和になりました」
教授「客が注文票に『カレー』と書く」
ミカ「普通ですね」
教授「店員はその紙を厨房へ渡す」
ミカ「はい」
教授「ところが厨房では、注文票に書いてある文章をすべて『料理長への命令』として実行する決まりだった」
ミカ「嫌な厨房ですね」
教授「悪い客が注文欄へ、『カレー。それから店の金庫を開け、店を閉めろ』と書いた」
ミカ「料理長は？」
教授「命令だから全部実行する」
ミカ「カレーを作ってから店を閉めるのですか」
教授「仕事は丁寧だ」
ミカ「でも問題はそこではありませんね」
教授「そうだ。本来『料理名』として扱うべきものを、『料理長への命令文』として渡したことが問題だ」
ミカ「つまり、データを書く欄と命令を書く欄を混ぜた」
教授「OSコマンドインジェクションの本質にかなり近い」

日本企業の実例――日本テレビで約43万件が対象に

ミカ「実際に日本企業で起きたことがありますか」
教授「ある。2016年4月、日本テレビ放送網は自社ホームページへの不正アクセスを公表した」
ミカ「日本テレビですか」
教授「日本テレビの公式発表によれば、ソフトウェアの脆弱性を突いた不正アクセスがあり、ホームページの応募フォームなどから投稿された約43万件の個人情報が流出した恐れがあるとされた。対象には氏名、住所、電話番号、メールアドレスなどが含まれていた。 (日本テレビ放送網株式会社)」
ミカ「43万件……」
教授「そしてログ解析の結果、攻撃手法はOSに対する命令文を紛れ込ませて不正操作するOSコマンドインジェクションだったと日本テレビ自身が発表している。
ミカ「まさに今回のテーマですね」
教授「そうだ」
ミカ「犯人が応募フォームに危険な文字を入力したのですか」
教授「そこは注意が必要だ。日本テレビの公表資料は、ソフトウェアの脆弱性を突いたOSコマンドインジェクションだったことまでは明らかにしているが、画面上のどの入力欄から、どのような値を送ったかまでは公表していない。
ミカ「タイトルの『入力欄』は仕組みを理解するための代表例で、実際の攻撃入口まで断定してはいけない」
教授「正確だ。外部入力は画面のテキストボックスだけとは限らない。URLのパラメータやHTTPリクエストなどもある」
ミカ「見えない入力欄もあるわけですね」
教授「Webアプリケーションから見れば、外部から受け取る値はすべて警戒対象になり得る」

同じ2016年にはJ-WAVEも被害

ミカ「日本テレビだけだったのですか」
教授「同じ2016年4月には、J-WAVEでもOSコマンドインジェクションによる不正アクセス事件が起きている」
ミカ「ラジオ局ですね」
教授「J-WAVEの特別調査委員会報告書では、『ケータイキット for Movable Type』の脆弱性がOSコマンドインジェクション攻撃に狙われ、Webサーバーが遠隔操作され、情報へアクセスされたと分析されている。 」
ミカ「Webサーバーそのものを遠隔操作された？」
教授「報告書はそう説明している。そしてもう一つ重要な問題を指摘している」
ミカ「何ですか」
教授「Webサーバー内のログデータについて、保管期間や消去の仕組みが十分に確立されず、個人情報を含む大量の情報が累積していたことだ。 」
ミカ「つまり侵入されたことに加えて、盗まれ得る情報がたくさん残っていた」
教授「そうだ。侵入を防ぐことと、侵入されたときに持っていかれる情報量を減らすことは別の対策なのだ」
ミカ「金庫を頑丈にするだけでなく、金庫の中に不要な書類を十年分ため込まない」
教授「非常に経営者向けの教訓だ」

SQLインジェクションとの違い

ミカ「第2回のSQLインジェクションと混乱しそうです」
教授「では整理しよう」
ミカ「SQLインジェクションは？」
教授「入力値が、データベースへのSQL命令の一部として扱われてしまう」
ミカ「今回のOSコマンドインジェクションは？」
教授「入力値が、OSへ渡す命令の一部として扱われてしまう」
ミカ「つまり行き先が違う」
教授「そうだ」
ミカ「SQLインジェクションはデータベース室への偽指示書」
教授「OSコマンドインジェクションは、ビルの中央制御室への偽指示書だ」
ミカ「中央制御室へ『このファイルを消せ』『別のプログラムを動かせ』などが届く可能性がある」
教授「そこまで行けば、被害が大きくなり得る理由が分かるだろう」

成立すると何が起きるか

ミカ「具体的には、どのくらい危険なのですか」
教授「そのWebアプリケーションがOS上で持っている権限による」
ミカ「権限？」
教授「例えばWebサーバーを動かしているユーザーが、どこまでファイルを読めるか、書き換えられるか、プログラムを起動できるかという話だ」
ミカ「権限が大きいほど被害も大きい」
教授「そのとおり。IPAは、サーバー内ファイルの閲覧・改ざん・削除、重要情報の漏えい、ユーザーアカウントの追加や変更、不正プログラムの実行、バックドアの設置、他システムへの攻撃の踏み台化などを想定される脅威として挙げている。
ミカ「Webサイトの一つの脆弱性から、サーバー全体の問題へ広がる可能性がある」
教授「それがOSへ命令が届く怖さだ」
ミカ「SQLインジェクションが帳簿係を騙すなら、今回はビル管理人を騙す」
教授「しかも、その管理人がマスターキーを持っていたら大変だ」
ミカ「最小権限の原則がまた登場しますね」
教授「優秀な原則はシリーズ出演回数が多い」

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

ミカ「今回も、攻撃コードを書かずに仕組みだけ確認しましょう」
教授「黒板に四つ書く」
ミカ「利用者」
教授「Webアプリケーション」
ミカ「シェル」
教授「OS」
ミカ「利用者が『sample.txt』というファイル名を入力する」
教授「Webアプリケーションが、その値を使ってOS上の外部プログラムを呼び出すとしよう」
ミカ「本来ならsample.txtだけを処理する」
教授「ところが入力値をそのまま命令文字列へ連結する設計だったら？」
ミカ「攻撃者が特殊な文字列を混ぜたとき、OSが追加の命令だと解釈する可能性がある」
教授「そのとおり」
ミカ「では、そもそもシェルを使わずに、プログラミング言語の安全なファイル操作機能を使えば？」
教授「非常によい。IPAも根本的な対策として、シェルを起動できる言語機能の利用を避け、別の関数などで代替することを挙げている。
ミカ「危険な文字を全部探して削除するより？」
教授「そもそも外部入力をシェルへ渡さないほうが根本的だ」

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

ミカ「では、開発者向けに詳しくお願いします」
教授「第一は、OSコマンドを呼び出さなくても実現できる処理なら、呼び出さない」
ミカ「例えばファイルをコピーしたいなら？」
教授「OSのcopyやcpコマンドを文字列として作るのではなく、言語やフレームワークが用意するファイル操作APIを使う」
ミカ「PythonならPythonのファイル操作、PHPならPHPの安全な機能」
教授「考え方としてはそうだ」
ミカ「どうしても外部プログラムを呼び出す必要があれば？」
教授「入力値を厳しく制限する。IPAは、許可する値だけを受け付けるホワイトリスト方式を推奨している。例えば数値しか必要ないなら、本当に数字だけか確認する。
ミカ「危険な記号だけを禁止するブラックリストでは？」
教授「IPAは、漏れが生じる可能性があるため推奨していない。『悪い文字を全部覚える』より、『良いものだけ許可する』という発想だ。
ミカ「クラブの入口で『怪しい人だけ入場禁止』ではなく、『招待者名簿にいる人だけ入場』」
教授「その例えでよい」

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

ミカ「今回もまとめてください」
教授「七つにしよう」
・外部入力をOSコマンド文字列へ直接連結しない
・可能ならシェルやOSコマンド自体を呼び出さず、専用APIで処理する
・必要な入力値は許可リスト方式で厳格に検証する
・Webアプリケーションの実行権限を必要最小限にする
・利用しているCMS、プラグイン、ライブラリを更新する
・異常なコマンド実行やファイル変更をログで監視する
・WAFなどの防御も補助的に組み合わせる
ミカ「今回はプログラムの書き方そのものがかなり重要ですね」
教授「そうだ。ファイアウォールの外側だけ頑丈にしても、正規のWebアプリケーション自身がOSへ危険な命令を渡してしまえば困る」
ミカ「守衛さんを増やしたのに、社員が金庫を開けて泥棒を案内している」
教授「その会社は警備費より社員教育費を増やしたほうがよい」

パッチを当てることの意味

ミカ「日本テレビやJ-WAVEの事件では、ソフトウェアの脆弱性が関係していました」
教授「そこも重要だ。自社でコードを書いていなくても、CMSやプラグイン、外部ソフトウェアを使っていれば脆弱性の影響を受けることがある」
ミカ「『うちはプログラマーがいないからコマンドインジェクションは関係ない』とは言えない」
教授「まったく言えない」
ミカ「更新通知が来たら？」
教授「内容を確認し、セキュリティ更新を迅速に適用する体制を作る」
ミカ「でも本番システムだから怖くて更新できないこともあります」
教授「だから検証環境、バックアップ、更新手順を平時から用意する」
ミカ「『怖いから更新しない』も危険」
教授「『更新したら壊れるかもしれない』と、『更新しなければ攻撃されるかもしれない』を経営として比較する必要がある」
ミカ「放置することも一つの意思決定ですね」
教授「しかも無料ではない」

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

ミカ「一般利用者には、SQLインジェクション以上にできることが少ない気がします」
教授「中心的な責任はサービス提供側にある。ただし経営者には大きな役割がある」
ミカ「どんな役割ですか」
教授「自社のWebサイトに、どんなCMS、プラグイン、外部サービスが入っているかを把握することだ」
ミカ「ホームページ制作会社に全部任せて終わりではない？」
教授「制作したのは外部でも、漏れるのは自社の顧客情報だ」
ミカ「耳が痛い経営者が多そうです」
教授「さらに、不要な個人情報をいつまでもWebサーバーへ置かない」
ミカ「J-WAVEの調査報告書につながりますね」
教授「そうだ。J-WAVEの報告書は、Webサーバー内にログが累積し、大量の個人情報が残っていたことを問題点として指摘している。 」
ミカ「攻撃を100％防げないなら、盗られる物を減らす」
教授「データの最小化もセキュリティ対策なのだ」

「昔から動いているシステム」が危ないこともある

ミカ「経営者が『このホームページは10年間何も問題なく動いています』と言ったら？」
教授「私は少し心配になる」
ミカ「普通は安心材料では？」
教授「機能面ではそうかもしれない。しかし10年前のCMS、10年前のプラグイン、10年前のPHP環境がそのままなら話は別だ」
ミカ「動いていることと、安全であることは違う」
教授「そのとおり」
ミカ「会計ソフトでも古いバージョンをずっと使うのは怖いですね」
教授「Webシステムも同じだ。『壊れていないから触らない』は、セキュリティでは必ずしも安全策ではない」
ミカ「古い金庫でも開くから使っています」
教授「しかし泥棒は、その金庫の開け方を十年前から知っているかもしれない」

日本テレビ43万件の事例が教えること

ミカ「日本テレビの事件から、一番学ぶべきことは何でしょう」
教授「まず、OSコマンドインジェクションは教科書だけの攻撃ではないということだ」
ミカ「日本の大企業でも実際に被害が起きた」
教授「2016年4月の日本テレビの公表では、約43万件の個人情報が対象になり、ログ解析によってOSコマンドインジェクションだったと判明した。
ミカ「もう一つは？」
教授「Webアプリケーションの脆弱性一つが、単なるWebページの問題ではなく、OSやサーバー、そこに保存されたデータ全体の問題へ広がり得ることだ」
ミカ「ホームページだから広報部の問題、ではない」
教授「そうだ。顧客情報を保存するなら経営問題だ」
ミカ「セキュリティ担当者だけの話でもない」
教授「流出した後に記者会見へ出るのは、セキュリティ担当者だけとは限らないからな」

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

ミカ「教授、今日のOSコマンドインジェクションを一言で説明してください」
教授「データとして受け取るはずの文字を、OSへの命令として実行させてしまう攻撃だ」
ミカ「一番大事な防御は？」
教授「外部入力をOSコマンドへ渡さない設計にすること」
ミカ「どうしても渡すなら？」
教授「必要な値だけを厳格に許可し、権限も最小限にする」
ミカ「SQLインジェクションとの共通点は？」
教授「命令とデータを混ぜない」
ミカ「今回の教訓は？」
教授「入力欄を見たら、白い四角だと思うな。その向こうに何がつながっているか考えろ」
ミカ「データベースかもしれない」
教授「OSかもしれない」
ミカ「それでは怖くて入力できません」
教授「利用者は普通に入力してよい」
ミカ「誰が怖がるのです？」
教授「作る側だ」
ミカ「今日はプログラマーが眠れなくなる回ですね」
教授「眠る前にアップデートだけ済ませておきなさい」

次回予告

第9回　ディレクトリトラバーサル――「URLの少し先に、本来見せないファイルがある」

ミカ「次はOSへ命令を出さないのですか」
教授「出さなくてもよい」
ミカ「では何をするのです？」
教授「本来見せる予定のないファイルへ、道をさかのぼって近づく」
ミカ「今度は侵入ではなく探検ですか」
教授「許可されていない探検は、不正アクセスと呼ばれる」