web-dev-qa-db-ja.com

LFI攻撃における/ proc / self / environの内容のセキュリティへの影響

ウェブサイトでの侵入テスト中に、インストールされた古いwordpressプラグインにローカルファイルインクルードの脆弱性が見つかりました。攻撃者はLFIの脆弱性を悪用して/ etc/passwdおよびインデックスページ。ただし、/ proc/self/environを含める場合、攻撃者が見るのはこれだけです。

CONTEXT_DOCUMENT_ROOT=/home/[website]/public_htmlCONTEXT_DOCUMENT_ROOT=/home/[website]/public_html

/ proc/self/environは他の情報を表示するはずではありませんか？あなたのユーザーエージェントなど？もしそうなら、なぜこのウェブサイトで表示されるのはCONTEXT_DOCUMENT_ROOTだけなのですか？

攻撃者が/ proc/self/environをインクルードし、ユーザーエージェントを表示する場合、改ざんデータを使用して、たとえばユーザーエージェントをPHPコードに変更し、シェルをアップロードすることができます。例またはアウトバウンドを開くTCP接続など。

つまり、これはすべて/ proc/self/environのショーなので、/ proc/self/environが基本的に攻撃者から安全であることを意味しますか？または、彼らはどうにかしてこれを操作してユーザーエージェントを表示し、PHPコードを実行しますか？（これが愚かな質問である場合は私に許してください。セキュリティに少し慣れていません。また、部屋の象を無視します。実際のLFIの脆弱性は修正されるので、まったく脆弱ではありませんが、/ proc/self/environの質問にはまだ興味があります。）

attacksfile-accessfile-inclusion
2
Jason Rigley

/proc/self/environには、プロセスの環境が含まれています。この場合、CONTEXT_DOCUMENT_ROOTのみが存在するように見えます（2つのコピーの間に\ 0が存在します）。

これはする可能です。 phpアプリケーションがCGIとして実行されていない場合は、HTTP_変数をそこに表示する必要はありません。他のSAPI（FastCGIやApacheモジュールなど）は、それらを異なる方法で受け取ります。

ただし、サーバー環境のみを表示していて、アプリケーションにパラメーターを渡すために使用されていない場合でも、PATHやHOMEなどの一般的な変数がそこに表示されないのは奇妙に思えます。また、同じ変数が2回出現することも、あまり意味がありません。

/proc/self/environの内容を印刷するための基本的なphpファイルをアップロードしてみませんか？

攻撃者が/ proc/self/environをインクルードし、ユーザーエージェントを表示する場合、改ざんデータを使用して、たとえばユーザーエージェントをPHPコードに変更し、シェルをアップロードすることができます。例またはアウトバウンドを開くTCP接続など。

どういたしまして。コードを実行するには、サーバーは含まれているユーザーエージェントをeval（）する必要があります。

ただし、環境コンテンツは、今後の攻撃のためにサーバーに関する詳細情報（パスなど）を取得するのに役立ちます。

2
Ángel