はじめに
2024年8月12日に、Webアプリケーション開発でよく使用されるHTTPクライアントライブラリ「axios」に脆弱性が発見されました。
(NVDの報告詳細)[https://nvd.nist.gov/vuln/detail/CVE-2024-39338#range-13199434]
この脆弱性（CVE-2024-39338）は、Server-Side Request Forgery（SSRF）と呼ばれる攻撃を可能にするものでした。
NVDによれば、この脆弱性は1.3.2以降から1.7.4(修正対応版)まで続いているとされ、結構長い間気づかれずにいたということになります。
ところで、私はこのServer-Side Request Forgery (SSRF)とは見た時になんぞやという状態でした。
今回は、axiosで発生したこのインシデントを通じて、Server-Side Request Forgery (SSRF)とは何かを調べ、どういった現象が発生するのかを調べていきたいと思います。
SSRFとは何か
そもそもSSRFとは何なのかをまずは調べていきましょう。
まずはAIに説明させてみる
ということで、まずはAIに聞いてみます。
## SSRFの定義と基本的なメカニズム
SSRF（Server-Side Request Forgery）は、攻撃者が脆弱なサーバーを操作して、予期しないHTTPリクエストを送信させる攻撃手法です。
この攻撃により、攻撃者は通常アクセスできないはずの内部リソースや外部システムにアクセスすることが可能になります。
SSRFの基本的なメカニズムは以下の通りです：
- 攻撃者は、脆弱なアプリケーションに特別に細工されたURLを送信します。
- サーバーは、このURLに基づいてリクエストを生成し、送信します。
- リクエストは、通常ならアクセスできないはずの内部ネットワークや外部サービスに向けられます。
## SSRFによって引き起こされる潜在的な問題
SSRFは、以下のような深刻な問題を引き起こす可能性があります：
内部システムへの不正アクセス：攻撃者が組織の内部ネットワークにアクセスし、機密情報を盗み取る可能性があります。
サービス妨害攻撃：内部サービスに大量のリクエストを送信し、サービス停止を引き起こす可能性があります。
データ漏洩：内部APIやデータベースから機密情報を抽出する可能性があります。
第三者サービスの悪用：攻撃者が正規サーバーを経由して第三者サービスにアクセスし、不正行為を行う可能性があります。
さらなる攻撃の足がかり：SSRFを利用して他の脆弱性を探索し、より深刻な攻撃につながる可能性があります。
情報の裏取りをする
AIによると、本来は送ることができないHTTPリクエストを送ることで、アクセスできない情報を取得することができる不正アクセスの攻撃のようです。
ただ、AIは若干重要な単語とかが抜けている可能性があるので、自分で裏取りもしておきましょう。
次はOWASPなどを見て、これらの情報があっているのかの裏付けを行っておきましょう。
(OWASP - Server Side Request Forgery)[https://owasp.org/www-community/attacks/Server_Side_Request_Forgery]
概要の要約
SSRF攻撃では、攻撃者がサーバーの機能を悪用して内部リソースを読み取ったり書き換えたりすることができる。
攻撃者は、サーバー上で実行されているコードでロードしているデータを読み取ったり送信したりするURLを攻撃者が与えたり変更することができる。
URLの手段次第では、AWSメタデータを読み取ったり、http対応データベースに接続したり、非公開の内部機能にPOSTリクエストをし不正に書き換えが出来る。
OWASPによると、攻撃者がhttpリクエストを悪用して不正にURL経由でデータの書き換えや読み取りを行うことが出来る攻撃手法のようです。
日本語情報としては徳丸浩氏のブログ記事があったので、そちらも確認し情報の確度を高めておきたいと思います。
(SSRF(Server Side Request Forgery)徹底入門)[https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html]
徳丸さんの記事では、
SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。
攻撃者は 何らかの方法で 公開サーバーから内部のサーバーにリクエストを送信することにより、内部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。
とあるので、公開サーバー部分から非公開の部分に対して攻撃者が意図的に攻撃ができる脆弱性をついた攻撃手法である感じだと思います。
SSRFとは？
- サービス運営側が意図しないHTTPリクエストにより、公開サーバーから非公開サーバーに第三者がアクセスできる。
- URLに基づくリクエストでアクセスをし、公開サーバー経由で非公開サーバーの情報を読み取ったり書き換えが出来る。
- URLの生成次第では公開サーバーを踏み台として第三者サービスへ不正アクセスを更にアクセスをし被害を広げる。
以上の感じのようです。
なぜaxiosで起こったのか
(Axios におけるサーバー側リクエスト偽造の脆弱性 (CVE-2024-39338))[https://jeffhacks.com/advisories/2024/06/24/CVE-2024-39338.html]
原因
原因としては一箇所の引数を増やす変更だけでした。
1.3.2以前
const fullPath = buildFullPath(config.baseURL, config.url);
const parsed = new URL(fullPath);
const protocol = parsed.protocol || supportedProtocols[0];
1.3.2以降
const fullPath = buildFullPath(config.baseURL, config.url);
const parsed = new URL(fullPath, 'http://localhost');
const protocol = parsed.protocol || supportedProtocols[0];
変更後ではnew URLのインスタンスを生成する時に、第ニ引数にhttp://localhostを渡すようにしています。
これは変更前は絶対パスしか許容しておらず、相対パスが渡された場合にエラーになる場合があるため、それを防ぐために第ニ引数にhttp://localhostに追加したという感じです。
この場合に、//example.comのような相対URLを渡すと、nodeのURLクラスでは自動的にhttp:が付与されるため、axiosのURLクラスの戻り値がhttp://example.comと、
本来想定していないURLが生成されてしまうためのようです。
1.7.4でこの不具合が修正されています。
(fix(sec): CVE-2024-39338 (#6539) (#6543))[https://github.com/axios/axios/commit/6b6b605eaf73852fb2dae033f1e786155959de3a#diff-586c04c24608b86a074073c5514cc195be5c4c87ddb56da233f6d998ada4159fR233]
const fullPath = buildFullPath(config.baseURL, config.url);
const parsed = new URL(fullPath, utils.hasBrowserEnv ? platform.origin : undefined);
const protocol = parsed.protocol || supportedProtocols[0];
このコミットでは他にも修正がなされていますが、主に脆弱性がおきた場所ではブラウザの環境かを確認し、そうでないnodeのようなサーバー環境ならundefinedを使用しURLを生成せずエラーにするようになりました。
まとめ
今回はWebアプリケーション開発で広く使用されているaxiosライブラリに発見された深刻なSSRF脆弱性を調べてみました。
SSRFという脆弱性は初めて知り今回の事で調べてみましたが、URLの安易な生成やリクエスト処理により発生する事象であるとわかりました。
そして、URL生成自体のパターン数や環境による条件の違いにより、URLの生成やリクエストの考慮はとても難しいと学びました。
有名なライブラリでさえも、このようなセキュリティ上の問題を抱えている可能性があるため、
使用している場合には常に警戒を怠らず情報収集を行い、必要ならライブラリのアップデートを迅速に行う必要があります。
また、脆弱性がどのように発生するのかを理解することが重要だと学びました。
SSRFのメカニズムを知ることで、今回の件を通し私はSSRFの発生メカニズムをある程度は理解し、それを避けれるような知識を身につけれたと思います。
最後に
CastingONEではスクラムなどの開発手法も自らアップデートしつつ最高のプロダクトを作っていく仲間を多職種募集中です！興味がある方は気軽にご連絡ください！
Discussion