Apache
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
Apacheサーバーが実行している拡張を確認します。それらを検索するには、次のコマンドを実行できます：
また、この設定を見つけることができる場所は次のとおりです：
これらの攻撃はOrangeのこのブログ投稿で紹介され、文書化されています。 "混乱"攻撃は基本的に、Apacheを作成するために協力する数十のモジュールが完全に同期していないことを悪用し、その中のいくつかが予期しないデータを変更することで、後のモジュールに脆弱性を引き起こす可能性があります。
**mod_rewrite**は、r->filenameの内容を?の後で切り捨てます（modules/mappers/mod_rewrite.c#L4141）。これは完全に間違っているわけではなく、ほとんどのモジュールはr->filenameをURLとして扱います。しかし、他の場面ではこれがファイルパスとして扱われることがあり、問題を引き起こす可能性があります。
パスの切り捨て
以下のルールの例のようにmod_rewriteを悪用して、期待されるパスの最後の部分を削除し、単に?を追加することでファイルシステム内の他のファイルにアクセスすることが可能です。
誤解を招くRewriteFlagの割り当て
次のリライトルールでは、URLが.phpで終わる限り、それはphpとして扱われ、実行されます。したがって、?文字の後に.phpで終わるURLを送信し、パスに悪意のあるphpコードが含まれた別のタイプのファイル（画像など）を読み込むことが可能です：
ユーザーがアクセスを拒否されるべきファイルにアクセスすることが可能です。これは次のような設定で発生します:
これは、デフォルトでPHP-FPMが.phpで終わるURLを受け取るためです。例えば、http://server/admin.php%3Fooo.phpのように、PHP-FPMは?の後のすべてを削除するため、前のルールがそれを禁止していても、前のURLは/admin.phpを読み込むことを許可します。
Apacheに関する面白い事実は、以前のリライトがdocumentRootとルートの両方からファイルにアクセスしようとすることです。したがって、https://server/abouth.htmlへのリクエストは、ファイルシステム内の/var/www/html/about.htmlと/about.htmlの両方でファイルをチェックします。これは基本的にファイルシステム内のファイルにアクセスするために悪用される可能性があります。
CGIソースコードの漏洩
末尾に%3Fを追加するだけで、cgiモジュールのソースコードが漏洩します：
PHPソースコードの開示
サーバーに異なるドメインがあり、そのうちの1つが静的ドメインである場合、これを悪用してファイルシステムを横断し、phpコードを漏洩させることができます:
前の攻撃の主な問題は、デフォルトではほとんどのファイルシステムへのアクセスが拒否されることです。これはApache HTTP Serverの設定テンプレートに示されています：
しかし、Debian/Ubuntu オペレーティングシステムはデフォルトで /usr/share を許可しています：
したがって、これらのディストリビューションの /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 は効果的に同一になります。
この講演 では、クライアントによって送信された不正な Content-Length が Apache に誤って PHP ソースコードを返させる 脆弱性が提示されました。これは、ModSecurity と Apache Portable Runtime (APR) のエラーハンドリングの問題によるもので、二重応答が r->content_type を text/html に上書きすることにつながります。
ModSecurity が戻り値を適切に処理しないため、PHP コードを返し、それを解釈しません。
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 はローカルでのみアクセス可能であるべきです：
Content-Typeをserver-statusに設定し、Locationヘッダーを/で始めることでアクセスすることが可能です。
mod_proxy にリダイレクトして、任意の URL の任意のプロトコルにアクセスする:
しかし、X-Forwarded-For ヘッダーが追加され、クラウドメタデータエンドポイントへのアクセスが防止されます。
PHP-FPMのローカルUnixドメインソケットにアクセスして、/tmp/ にあるPHPバックドアを実行します：
公式の PHP Docker イメージには、コマンドラインPHPパッケージ管理ツールであるPEAR（Pearcmd.php）が含まれており、これを悪用してRCEを取得できます：
Check Docker PHP LFI Summary の詳細は、Phith0n によって書かれています。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
