Apache
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: 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 ヘッダーを悪用してリクエストプロセスを再起動することが可能です。なぜなら、返された Status が 200 で、Location ヘッダーが / で始まる場合、応答はサーバーサイドリダイレクションとして処理されるべきだからです。
RFC 3875（CGI に関する仕様）の Section 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)
