無料メルマガ登録でプレゼント！書籍「セキュリティ対策の基礎知識」

「SSRF（Server Side Request Forgery）」と呼ばれる脆弱性をご存知でしょうか。「CSRF（Cross Site Request Forgery）」とよく似た言葉ですが、攻撃手法に少し違いがあります。どちらも通常では攻撃できないサーバーに対して、不正な方法でアクセスを試みる攻撃です。

今回はSSRF攻撃についてその概要と被害実例、そしてCSRFとの違いなどについてご紹介いたします。

SSRF攻撃とは

SSRF攻撃とは通常の方法ではアクセスできないサーバーに対して攻撃を仕掛ける手法の一つです。

攻撃者はインターネット上に公開サーバーには直接アクセスできます。しかし内部サーバーへはアクセスできません。しかし公開サーバーから内部サーバーへのアクセスはできる状態を仮定します。

この時、攻撃者は公開サーバーに対して攻撃コマンドを送信することで、公開サーバーを経由して内部サーバーに対して攻撃をしかけることができます。この時、公開サーバーからのコマンドは正規コマンドとして処理されます。これがSSRF攻撃の概要です。

SSRF攻撃の仕組み

具体的なSSRF攻撃の仕組みは様々ですが、攻撃の仕組みの一つとして「rコマンド（rshなど）」があげられます。

rコマンドはUNIX系のOSで使われるコマンドであり、リモートからシェルコマンドを実行するためのコマンドです。上記のイラストのように、攻撃者が公開サーバーにアクセスできれば、公開サーバーからrコマンドを実行することで、内部サーバーへコマンドを送信できる場合があります。

この時、内部サーバーの立場から見れば、公開サーバーは信頼できるサーバーですので、攻撃者からのrコマンドを実行してしまいます。これによりSSRF攻撃が成立します。

上記はSSRF攻撃の一例に過ぎません。例えば公開サーバーに対してHTTPを使いアクセスを行い、URLのパラメータとして攻撃用のコマンドを仕掛けるという手法も考えられます。

プロトコルには他にもあり「file」「ftp」「scp」などを使えばローカルファイルへの攻撃が成立しますし、「smtp」「pop3」を使えばメールサーバーへの攻撃も考えられます。

このようにSSRF攻撃が成立するための脆弱性には様々なパターンがあり、対策方法もいくつかあります。具体的な対策方法は後程紹介することにして、まずはSSRF攻撃による被害実例について紹介します。

SSRF攻撃の被害事例（Capital One）

2019年7月29日、アメリカの大手金融会社Capital Oneにて不正アクセスが発生し1億人以上の個人情報が流出しました。

この事件の概要は次の通りです。2019年3月22日から23日にかけて、Capital OneのAWS環境への不正アクセスが発生。犯人は自分のSlackのチャンネルにて違法に取得したデータベースを投稿します。Capital Oneは7月19日に情報流出の事実を確認。7月29日にFBIが犯人を逮捕しました。

この事件の原因は、Capital Oneが利用していたWAF（Web Application Firewall）の設定ミスでした。Capital OneではAWSを利用していましたが、FirewallはAWS WAFではなく独自に構築したものを使っていました。この独自のWAFに設定ミスがあり、犯人はWAFを経由して、個人情報を入手したと見られています。Capital Oneが独自に構築したWAFにはSSRF攻撃を検出するルールが設定されていなかったとのことです。

逮捕された犯人はワンシントン州のシアトル在住の33歳の女性エンジニアでした。彼女は過去にAmazonのクラウド部門の従業員だったことが確認されています。犯人の女性はTwitterやSlackのアカウントを持ち、違法行為を投稿したことで、今回の逮捕につながりました。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録・ダウンロードは
こちらから

CSRFとの違い

SSRFと似た攻撃としてCSRFがあります。CSRFは攻撃用のWebページを準備し、攻撃用のURLを設定します。攻撃者はWebサイトの訪問者に対して罠ページにアクセスさせて、攻撃用のURLをクリックさせます。攻撃用URLをクリックしたユーザーは正規のユーザーであると認識されるため、正しいリクエストとして処理されてしまいます。

このようにCSRFもSSRFも直接攻撃対象に攻撃を仕掛けるものではなく、正規のクライアントなりサーバーなりをワンクッションとしておいてから攻撃を試みる点で類似しています。

SSRF脆弱性について

SSRF攻撃はサーバーから他のサーバーへのリクエスト先を攻撃者が指定することで発生する脆弱性です。これにより内部ネットワーク上のサーバーへのアクセスが可能になります。この脆弱性はどのように解消すれば良いのでしょうか。

公開サーバーは公開する必要があるため、アクセス元を制限することは難しいでしょう。しかし内部サーバーは外部からの任意のアクセスを許容しているわけではありません。公開サーバーから内部サーバーへのアクセスは、許可するものと制限するものの2つの分類できます。つまり公開サーバーへのリクエストを厳しくチェックし、本来アクセスを許してはいけない内部サーバー(攻撃対象）へのアクセスを制限することが、脆弱性の解消手段の一つです。

SSRF攻撃に効果的な対策

SSRF攻撃に効果的な対策方法として、以下の3つによる対策があげられます。

ファイアウォール

ファイアウォールの設定により、攻撃者が接続先となる攻撃対象を指定しても、接続できないように制限する方法が有効です。少なくともローカルホストに対するアクセスについては厳しく制限する必要があります。注意点として、SSRF攻撃ではない正常のアクセスについて制限してしまうと、本来の目的が果たせなくなってしまいます。

プロキシ

ブラウザにプロキシを設定して全てのアクセスをプロキシ経由にする方法です。そしてプロキシにおいてアクセス制御を行います。プロキシを設定する方法の注意点として、ブラウザが全ての通信をプロキシ経由にするとは限らない点があげられます。さらにループバックアドレスへの通信については、デフォルトでプロキシ経由にならないことにも気を付ける必要があります。

インターセプト

Puppeteerのようにリクエストのインターセプト機能を持つツールを使用している場合には、リクエストの送信先などを制御することができます。しかしこの方法では全ての通信をインターセプトできるわけではありません。

まとめ

サーバーの持つ権限を悪用して攻撃を仕掛けるSSRF攻撃について概要と対策方法について紹介してきました。発生のメカニズムは割とシンプルですが、システムやネットワークの環境によっては対策が抜けていたり、思わぬ脆弱性をつかれたりして、攻撃が仕掛けられることもあり、完全な対策は困難でしょう。

SSRF脆弱性だけでなくWebアプリケーションの脆弱性解消については、とにかくリクエストの真正性を確認した上で、リクエストに付加されているパラメータを適切にバリデーションするなどして、無害なものにすることも有効な対策方法です。

アプリケーション側だけでなく、ファイアウォールのようなネットワーク側での対策も有効です。Webアプリケーションの開発には、仕様なども十分に検討した上で、安全面に配慮した実装を心がけるようにしましょう。