CVE-2021-3156:Baron Samedit

【CVE-2021-40438】攻撃コード(PoC)ありのApacheサーバのSSRFの脆弱性のリスクと対応について解説します。

投稿日: カテゴリー: セキュリティ
Pocket

CVE-2021-40438とはどんなリスクのある脆弱性なのか。パッチはあるのか

CVE-2021-40438はApacheサーバでmod_proxyが有効な場合、サービスのリソースの取得・変更・削除ができる可能性があるというSSRFの脆弱性です。

条件1 Apache HTTP Server 2.4.48以下のバージョン
条件2 mod_proxyが有効(デフォルト有効)

リスクを考える上でSSRFとは何か判らないと先にすすみません。CSRF(クロスサイトリクエストフォージェリ)という脆弱性と比較するとわかりやすいです。
CSRF(クロスサイトリクエストフォージェリ)    →「人」の信用を利用して意図しない要求を行う
SSRF(サーバサイド・リクエストフォージェリ) → 「サーバ」の信用を利用して意図しない要求を行う
具体的なリスクとしては外部からアクセスが制限されているから安全と高を括っている内部サーバに管理者向けコンソールやリソースが不正にアクセスされる可能性があります。

SSRFはアプリケションサーバを起点に不正アクセスが行われてしまう脆弱性

※CVE-2021-40438のパッチはすでに公開されています。

CVE-2021-40438のPoC(実証概念コード)

文字列は特徴的でunix:で始まりパイプ「|」までにコードを挿入する形式です。UDSソケットのパスに挿入したコードが追加されている出力があれば脆弱です。

GET /?unix:testtesttesttest| http://google.com/ HTTP / 1.1

CVE-2021-40438の対策

根本対策:2.4.51以降にアップデートしてください(2.4.49/2.4.50もパッチが不完全)

保険対策(低減策):リクエストのクエリでunix:とパイプ「|」が含まれた文字列があるか(エンコードされた文字列も含む)で検知・遮断する

2.4.51以降にアップデートしてください

CVE-2021-40438の攻撃コード(PoC)と発生する原理

脆弱性の理解はパッチでどこが修正されたのか見るのが確実です。

「修正前のコード」

 (ptr2 = ap_strcasestr(r->filename, "unix:")) &&
 (ptr = ap_strchr(ptr2, '|'))) {

「修正後のコード」

 !ap_cstr_casecmpn(r->filename + 6, "unix:", 5) &&
 (ptr2 = r->filename + 6 + 5, ptr = ap_strchr(ptr2, '|'))) {

修正後はproxy:から見てプロキシURLの先頭に「unix:」がないと処理が進まないよう条件が厳しくなりました。
unix domain socketなんていつから使えるようになったかと言えば、apache 2.4.7 からです。
FlaskのようなWSGI(Web Server Gateway Interface) 構成のアプリはsocketをtcp port に書き換えないといけない煩わしさが問題になっっていたがProxyPassで解決すべく追加されました。
「unix:」位置がどこにあっても検索されるとパスへの不正追加は行われSSRFにつながる可能性があるということです。

 

うちのサービスはmod_proxy使っている止めて大丈夫なの?

mod_proxyモジュール自体はデフォルトで入っています。従って入っているかではなく設定しているかを確認します。
一般にはリバースプロキシでキャッシュしてサイトパフォーマンスを向上させたり、メンテナンスで停止中に別サーバでサービスを継続できるようにしたりといった用途で設定します。
他にはApache httpdとTomcatを連携させる方法としてAJP (Apache JServ Protocol) を利用している場合mod_proxy_ajp は mod_proxyモジュールに依存しているため利用しています。
負荷分散の観点ではApache2.2以降で利用可能なmod_proxy_balancerと組み合わせ実現している可能性もあります。
mod_proxyでどんな設定があるのかは公式ドキュメントを読むのが一番ですが思い切りまとめると
ProxyPass:自分のパスを他のサーバに結びつける設定(アクセスをプロキシさせる時に利用)
ProxyPassReverse:リバースプロキシしたサーバからのレスポンスを書き換えて自分にむける設定(ヘッダ情報の書き換えに利用)
の2つとなります。
「Tomcatを使っていてAJPの手法を取っているか」
「リバースプロキシなど負荷分散の設定をApacheで行っていたりするか」
あたりをヒアリングして引っ掛かれば利用している可能性があるとして今回のアップデートの必要性を訴えて良いかと思います。

mod_proxyはAJPやリバースプロキシをApacheで利用している際に利用されているので今回の脆弱性への対応を促す

以上です。参考になれば幸いです。