🔰LINEも重大リスクとして報奨対象にしたSSRF――ハッカーは「サーバー自身」を内部へ送り込む🔯ミカと教授のサイバーセキュリテイ🖥️第10回

SSRF――「外から入れないサーバーへ、内部のサーバー自身を行かせる」

ミカ「教授、前回のディレクトリトラバーサルでは、ファイルの道をたどって、本来見せるつもりのないファイルへ近づく話でしたね」
教授「そうだった」
ミカ「今回はSSRFですか」
教授「Server-Side Request Forgery。サーバーサイド・リクエスト・フォージェリだ」
ミカ「またForgeryですか。第3回のCSRFにも出てきました」
教授「今回は人間のブラウザではなく、サーバーそのものをだます」
ミカ「ハッカーがサーバーへ侵入する？」
教授「もっと怠け者だ」
ミカ「嫌な予感がします」
教授「攻撃者自身は内部へ行かない。会社のWebサーバーに『ちょっと内部まで行ってきて』と頼む」
ミカ「サーバーが攻撃者のお使いをするのですか」
教授「しかも交通費は会社持ちだ」

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

ミカ「SSRFは何を狙っているのですか」
教授「Webサーバーには、外部のURLへアクセスする機能を持つものがある」
ミカ「例えば？」
教授「URLを指定して画像を取り込む、外部サイトのプレビューを作る、Web APIへ問い合わせる、Webhookを送る、といった機能だ」
ミカ「普通に便利な機能ですね」
教授「問題は、利用者が指定したURLをサーバーが十分に確認せず、そのまま取りに行ってしまうことだ」
ミカ「攻撃者がインターネット上の普通のサイトではなく、社内システムの住所を指定したら？」
教授「そこがSSRFだ。OWASPも、利用者が指定したURLを十分に検証せずサーバーが取得する場合、攻撃者が想定外の場所へリクエストを送らせられると説明している。ファイアウォールやVPNの内側にあるサービスまで対象になり得る。 (OWASP)」
ミカ「つまり狙っているのはWebサーバーそのものではなく」
教授「Webサーバーが持っている『内部へ行ける立場』だ」

なぜ成立するのか

ミカ「外部の攻撃者は社内ネットワークへ入れませんよね」
教授「普通はファイアウォールなどで遮断する」
ミカ「では安心です」
教授「ところが、公開Webサーバーはどうだ？」
ミカ「社内の別サーバーと通信することがあります」
教授「そうだ。データベース、認証サーバー、管理API、クラウドサービスなどへ接続する場合がある」
ミカ「つまりWebサーバーは、外から来た私より顔が広い」
教授「会社の受付係のようなものだ」
ミカ「受付係なら社員専用フロアへ電話できます」
教授「攻撃者は受付係に電話して、『私を入れてください』とは言わない」
ミカ「では？」
教授「『受付さん、あなたから社長室へ電話して、この内容を聞いてください』と言う」
ミカ「受付係自身なら、社内からの電話になりますね」
教授「SSRFの本質はそこだ。外部からは拒否されるアクセスを、信用されているサーバー自身に実行させる」
ミカ「ファイアウォールを破るのではなく、門の内側にいる人へ仕事を頼む」
教授「そういうことだ」

身近な例に置き換える

ミカ「いつもの例をお願いします」
教授「高級ホテルにしよう」
ミカ「教授はホテルが好きですね」
教授「外部の人間は、従業員専用フロアへ入れない」
ミカ「カードキーが必要です」
教授「しかしフロント係は入れる」
ミカ「従業員ですから」
教授「そこで怪しい客がフロントへ電話する。『このURLにある写真を確認してください』」
ミカ「URL？」
教授「ホテルの例だ。『この部屋へ行って、机の上の書類を読んでください』と考えよう」
ミカ「その部屋が実は従業員専用フロアだった」
教授「フロント係はホテル内部の人間なので入れてしまう」
ミカ「そして客に内容を伝える」
教授「そうだ」
ミカ「攻撃者は一歩も従業員エリアへ入っていない」
教授「しかし、中に入れる人を代理人にした」
ミカ「これがServer-Side Request Forgery」
教授「『サーバーさん、代わりに行ってきて』攻撃だ」
ミカ「急に親しみやすい名前になりました」

LINEもSSRFを報奨対象にしていた

ミカ「日本企業でもSSRFは問題になっていますか」
教授「もちろんだ。ただし、ここは正確に言おう。今回確認した範囲では、国内の著名企業が『SSRFによって大規模情報漏えいが発生した』と公式に原因を明示した代表例は、海外のCapital Oneほど明確には確認できなかった」
ミカ「無理に日本企業の被害事例を作ってはいけませんね」
教授「そのとおりだ。しかし、日本企業がSSRFを重大な脆弱性として扱っている明確な例はある」
ミカ「どこですか」
教授「LINEだ。2018年、LINE Security Bug Bounty Programでは、SSRFを報奨対象として追加し、『Webサーバーを中継して、本来外部から到達できない別のサーバーやネットワークへ攻撃が可能になる脆弱性』として説明していた。当時の報奨参考額は2,500ドルだった。 (LINE ENGINEERING)」
ミカ「被害が出てから対処したのではなく、外部研究者に見つけてもらう」
教授「バグバウンティの重要な考え方だ」
ミカ「翌年は？」
教授「2018年通年の報告では、SSRFやSQLインジェクションなどによってファイルシステムやデータベースへ全面的にアクセスできるほど深刻な場合、重要アプリケーションでは1万～3万ドルという報奨基準が示された。 (LINE ENGINEERING)」
ミカ「ただURLを読み込むだけの欠陥に、そんな金額が？」
教授「『URLを読み込むだけ』で終わらない可能性があるからだ」

海外の代表例――Capital One

ミカ「実際に大規模な被害へつながった事件は？」
教授「SSRFを説明するときによく取り上げられるのが、2019年の米金融大手Capital Oneの事件だ」
ミカ「1億人以上の情報が流出した事件ですね」
教授「そうだ。事件を分析したNTTデータ先端技術の資料では、WAFの設定不備を入口としてSSRF攻撃を許し、クラウド環境のインスタンスメタデータから高い権限を持つIAMロール情報を取得できたこと、さらにS3へのアクセス権限が大きすぎたことなど、複数の問題が連鎖したと整理されている。 (IntelliLink)」
ミカ「SSRFだけで一瞬にして全部盗まれたわけではない？」
教授「そこが重要だ。SSRFが最初の扉となり、その先に強すぎる権限やアクセス制御の問題があった」
ミカ「また最小権限の原則が登場しました」
教授「第10回ともなると、最小権限君は準レギュラーだ」

クラウドでは「内部の名札」が狙われる

ミカ「クラウドでは、なぜSSRFが特に怖いのですか」
教授「クラウド上の仮想サーバーには、そのサーバー自身から参照できるインスタンスメタデータサービスが用意されている場合がある」
ミカ「メタデータ？」
教授「そのサーバー自身に関する設定情報などを取得する仕組みだ」
ミカ「外部の私からはアクセスできない？」
教授「通常、インスタンス内部から利用するものだ。AWSも、インスタンスメタデータは基本的にインスタンス内部から利用する仕組みだと説明している。 (AWS ドキュメント)」
ミカ「ところがSSRFで、そのサーバー自身にアクセスさせたら？」
教授「攻撃対象の構成や権限によっては、重要な情報へ到達する足掛かりになる可能性がある」
ミカ「サーバー専用の社員証発行所へ、サーバー本人を行かせるわけですね」
教授「非常に分かりやすい」
ミカ「攻撃者は受付の外に立ったまま」
教授「そして中の社員へ『社員証を見せてきて』と頼む」

AWSもSSRFを意識した防御を用意している

ミカ「クラウド側でも対策しているのですか」
教授「している。AWSはEC2のInstance Metadata Service Version 2、IMDSv2を提供している」
ミカ「何が違うのですか」
教授「簡単に言えば、メタデータを取得する前にセッション指向の追加手順を必要とすることで、単純なSSRFなどへの多層防御を強化している。AWS自身も、IMDSv2をオープンなファイアウォールやリバースプロキシ、SSRFに対する防御強化として説明している。 (AWS ドキュメント)」
ミカ「Webアプリケーション側だけでなく、クラウド側にも壁を作る」
教授「そうだ。SSRF対策も多層防御だ」
ミカ「一枚の壁に全部任せない」
教授「城シリーズはまだ続いている」

URLを入力できる機能は意外に多い

ミカ「SSRFが入り込みやすい機能は何ですか」
教授「例えば、利用者がURLを指定してサーバー側に何かを取得させる機能だ」
ミカ「画像の取り込み」
教授「URLプレビュー」
ミカ「外部APIとの連携」
教授「Webhook」
ミカ「PDF生成で外部画像を読み込む」
教授「そういった機能だ」
ミカ「『URLを入力してください』という欄を見たら、プログラマーは少し緊張する？」
教授「よい習慣だ」
ミカ「利用者は？」
教授「普通に使ってよい」
ミカ「また作る側だけ眠れない」
教授「セキュリティ連載とは、プログラマーの睡眠時間を少しずつ削る企画なのかもしれない」

成立すると何が起きるか

ミカ「SSRFに成功すると、何が起こるのですか」
教授「構成によってさまざまだ。内部だけに公開している管理サービスへのアクセス、内部APIへの問い合わせ、内部ネットワークの情報収集、クラウドのメタデータへのアクセスなどにつながる可能性がある。OWASPも、内部RESTサービス、クラウドメタデータ、内部向けサービスなどが標的になり得ると説明している。 (OWASP)」
ミカ「外部から直接アクセスするとファイアウォールが止める」
教授「しかしWebサーバーからのアクセスなら？」
ミカ「内部から来た通信として扱われる場合がある」
教授「そうだ。特に『内部から来た通信だから信用する』という設計が危険になる」
ミカ「また信用しすぎ問題ですね」
教授「サイバーセキュリティでは、場所だけで信用しないという考え方が重要になる」
ミカ「会社のLANの中だから安全」
教授「それだけでは不十分だ」

Blind SSRFという見えない攻撃もある

ミカ「サーバーが取得した情報を画面に表示しなければ安心ですか」
教授「必ずしもそうではない」
ミカ「表示されないのに？」
教授「攻撃者へ応答内容が直接返らなくても、サーバーに意図しない通信を送らせられる場合がある。これをBlind SSRFと呼ぶことがある」
ミカ「目隠しSSRF？」
教授「そんな感じだ」
ミカ「中身が見えないなら役に立たないでしょう」
教授「応答時間や成功・失敗の違いなどから内部サービスの存在を推測されたり、外部への通信そのものを利用されたりする可能性がある。MDNも、応答本文を直接取得できない場合でも、ステータスや処理時間などから情報を推測される可能性を説明している。 (MDN Web Docs)」
ミカ「見えなくてもノックはできる」
教授「そして返事の仕方で、部屋に誰かいるか分かることがある」

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

ミカ「今回も攻撃コードなしで仕組みを確認しましょう」
教授「では黒板に三つ書く」
ミカ「①利用者」
教授「②公開Webサーバー」
ミカ「③社内管理サーバー」
教授「外部利用者から③へは直接アクセスできない」
ミカ「ファイアウォールがあります」
教授「ところが②には『URLから画像を取得する』機能がある」
ミカ「普通なら外部の画像サイトを指定する」
教授「そうだ。では利用者が③の住所を指定できたら？」
ミカ「②のWebサーバーが③へアクセスする」
教授「③から見ると？」
ミカ「社内側の②から来たアクセスです」
教授「これがSSRFの基本構造だ」
ミカ「攻撃者は③へ一度も直接接続していない」
教授「だからSSRFは、サーバーを代理人にする攻撃なのだ」

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

ミカ「では開発者側の対策です」
教授「最も重要なのは、利用者が指定したURLを何でもサーバーに取得させないことだ」
ミカ「ホワイトリストですか」
教授「使える場合は強力だ。接続先が決まっているなら、許可したドメインやIPアドレスだけに限定する。OWASPも、接続先が特定できるケースでは許可リスト方式を重要な対策として挙げている。 (OWASP Cheat Sheet Series)」
ミカ「『どこへでも行きます』ではなく、『この3社だけ配達します』」
教授「そうだ」
ミカ「URLの形式も確認する？」
教授「当然だ。プロトコル、ホスト名、IPアドレスなどを正しく検証する」
ミカ「URLにhttpと書いてあればOK、ではない」
教授「全然足りない」
ミカ「リダイレクトは？」
教授「そこも注意点だ。最初のURLは許可された外部サイトでも、リダイレクト先が内部アドレスなら意味がない。OWASPの防御資料でも、リダイレクト処理を慎重に扱う必要が示されている。 (OWASP Cheat Sheet Series)」
ミカ「最初の住所だけ確認して、タクシーが途中で行き先を変えるようなものですね」
教授「最後の目的地まで確認する必要がある」

ネットワーク側でも止める

ミカ「アプリケーションでURLを検証すれば十分ですか」
教授「十分とは言い切れない」
ミカ「また多層防御ですね」
教授「Webサーバーから、そもそも必要のない内部ネットワークや管理サービスへ通信できないよう、ネットワーク側でも制限する」
ミカ「Webサーバーが経理サーバーへ行く必要がないなら、道を閉じる」
教授「そうだ」
ミカ「アプリケーションにバグがあっても、ネットワークが止める」
教授「SSRF対策では、この出口側の通信制御が非常に重要だ」
ミカ「普通のファイアウォールは外から中への入口を守るイメージでした」
教授「SSRFでは、『中にいるサーバーがどこへ行けるのか』も考える」
ミカ「門番だけでなく、社員の外出先まで管理する」
教授「少し息苦しい会社だが、サーバーにはそれくらいでよい」

最小権限がまた登場

ミカ「そして最小権限ですね」
教授「出番だ」
ミカ「今回はどの権限ですか」
教授「仮にWebサーバーが内部サービスへアクセスできても、そのサーバーに強大なクラウド権限を与えていなければ、被害を限定できる可能性がある」
ミカ「Capital Oneの教訓ですね」
教授「そうだ。SSRFだけではなく、その先に何の権限があるかが被害の大きさを決める。NTTデータ先端技術の分析でも、WAFの問題に加え、IAMロールやS3のアクセス権限が大きかった点を重要な要因としている。 (IntelliLink)」
ミカ「最小権限君、第10回も出演」
教授「そろそろ出演料を請求されそうだ」

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

ミカ「今回もまとめてください」
教授「七つにしよう」
・利用者が指定したURLを無条件でサーバーに取得させない
・接続先が決まっている場合は許可リスト方式を使う
・URL、プロトコル、ホスト名、IPアドレスを厳格に検証する
・リダイレクト後の接続先まで確認する
・Webサーバーから不要な内部ネットワークへの通信を遮断する
・クラウドや内部サービスの権限を必要最小限にする
・クラウドではIMDSv2などSSRFを意識した保護機能を利用する
ミカ「今回はコードだけではありませんね」
教授「そうだ。アプリケーション、ネットワーク、クラウド権限の三つを合わせて守る」
ミカ「一人のプログラマーだけでは完結しない」
教授「だからセキュリティはチーム競技なのだ」

経営者は「社内だから安全」を捨てる

ミカ「経営者は何を学べばよいですか」
教授「まず、『インターネットからアクセスできない社内サーバーだから安全』という思い込みを捨てる」
ミカ「SSRFでは、公開Webサーバーが代わりにアクセスしてしまう」
教授「そうだ」
ミカ「社内ネットワークも認証を付ける？」
教授「重要な内部サービスなら、接続元が社内だからという理由だけで無条件に信用しないことだ」
ミカ「ゼロトラストの考え方に近いですね」
教授「その方向につながる」
ミカ「内部APIにも認証」
教授「アクセス権限も限定する」
ミカ「ログも取る」
教授「そして公開Webサーバーから内部への不要な通信経路を閉じる」
ミカ「会社の中だから全部つながっていて便利、は危険」
教授「便利という言葉が今日も出たな」
ミカ「第10回まで来ると、便利というだけで警報が鳴ります」

「URLを取得するだけ」の機能を軽く見ない

ミカ「経営者からすると、『URLから画像を取得するだけの機能でしょう』と思いそうです」
教授「その『だけ』が危険だ」
ミカ「画像取得機能がサーバーから通信する」
教授「だから、そのサーバーがどこまで通信できるかを考える必要がある」
ミカ「新しいWebサービスを開発するときに？」
教授「『この機能は外部URLを受け取るか』『サーバー自身が外部へ通信するか』『内部ネットワークへ到達できるか』を設計段階で確認する」
ミカ「完成後にセキュリティ診断するだけではない」
教授「設計時点から考える」
ミカ「家を建て終えてから、『そういえば玄関を付け忘れた』では遅い」
教授「その家はセキュリティ以前に出入りできない」

LINEのバグバウンティが教えること

ミカ「LINEの事例から経営者が学べることはありますか」
教授「脆弱性は攻撃者より先に見つけたほうが安い、ということだ」
ミカ「バグバウンティですね」
教授「LINEは2018年にSSRFを報奨対象として明示し、さらにSSRFなどによってファイルシステムやデータベースへ全面的にアクセスできるほど深刻なケースには、高い報奨額を設定した。 (LINE ENGINEERING)」
ミカ「ハッカーに攻撃されて数億円失うより、研究者に報奨金を払って先に直す」
教授「そのほうが安い場合は多い」
ミカ「教授、それは税務的にも損金ですか」
教授「急に専門分野へ戻ってきたな」
ミカ「安全な経費に見えてきました」
教授「その話は税務シリーズでやろう」

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

ミカ「教授、SSRFを一言で説明してください」
教授「外部の攻撃者が自分で内部へ入るのではなく、内部へアクセスできるサーバーを代理人にして、代わりに行かせる攻撃だ」
ミカ「狙われるのは？」
教授「サーバーが持つ通信できる立場と信用だ」
ミカ「防御は？」
教授「サーバーに自由な行き先を与えない」
ミカ「そして内部だからと信用しすぎない」
教授「そのとおり」
ミカ「つまり、知らない人から『ちょっと社内サーバーまで行ってきて』と言われても？」
教授「行かない」
ミカ「URLを渡されても？」
教授「行かない」
ミカ「教授から頼まれたら？」
教授「目的地を確認してから行きなさい」
ミカ「教授も信用しない？」
教授「第10回まで勉強した成果が出ているな」

次回予告

第11回　マルウェアとランサムウェア――「侵入した後、なぜ会社全体の仕事まで止められるのか」

ミカ「今度はWebサーバーの話から離れますか」
教授「少し広がる」
ミカ「何が狙われるのです？」
教授「パソコン、サーバー、ファイル、バックアップ、そして会社の業務そのものだ」
ミカ「いよいよ会社が止まりますね」
教授「第11回は、『パソコンが壊れた』と『会社が営業できない』の間に何があるのかを考えよう」