概要
CVE-2024-38474がなかなか厳しい内容だったのでメモ。公式では具体的な攻撃シナリオが見えなかったので完全に油断してた…
この脆弱性の詳細については報告者のブログを見て貰うとして、その中で特に気になる部分があったので確認した。
以下はRHEL 8互換OSで確認した。
影響を受ける状況
httpd 2.4.60未満の全てのバージョンでmod_rewrite/mod_proxyを利用している特に影響を受ける様子。
特に気になった部分というのが、mod_proxyが対象になっているという点。「Reverse Proxyでも構築してなければ関係なくね?」 と高をくくっていたが、あれ?と思ったのがここ。
...
<FilesMatch \.(php|phar)$>
SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>
...
うん、入ってますね、proxyの文字が。
脆弱性を試用した攻撃シナリオ
対策前のバージョンのhttpdが入ったサーバがあったのでこれで確認してみる。
# yum list installed httpd
インストール済みパッケージ
httpd.x86_64 2.4.37-62.module+el8.9.0+1798+d36b471e @appstream
よくあるハックで 「WordPressに不正にログインできないようにするため、特定のIPアドレス以外からのログイン画面へのアクセスを禁止する」 というのがあると思っている。一般的かどうかは不明だが、近隣では金科玉条のように言われている。
そこでこのような設定を記述してみた。
<Files wp-login.php>
Require local
</Files>
これなら誰も?WordPressにログイン出来ないはず。実際に別のIPを持つPCのブラウザで普通にアクセスしてみると403エラーが出た。
CVE-2024-38475ではURIに与えられた %3f を ? と誤認してhttpdとproxyの先で異なる処理をしてしまうことが問題らしい。
そこで前掲のブログにあったように次のような細工をしてみる。
WordPressでサイトを公開する際に、index.phpへのアクセス制限はしないだろうということで、設定したらログイン画面が表示出来てしまった…
ちなみにAllowOverride AllでWordPressデフォルトのRewrite設定を有効にした場合は、このURLではログイン画面にはアクセス出来なかった。
まとめ
- ミドルウェアにある未知の脆弱性の影響を受ける可能性があるので、IPアドレスでのアクセス制限を過信するのはやめよう。
- WordPressは自動アップデートを利用するとして、ミドルウェアも自動または速やかにアップデートするようにしよう。
- CVE情報を細かくチェックしよう。速報だけで無くNVDの評価のタイミングで再チェックする。(大事)