bttea/cve-2024-4577-rce-pocCVE-2024-4577 RCE PoC
PHPの実装中、開発チームはWindowsオペレーティングシステム内のエンコーディング変換におけるBest-Fit機能に気づきませんでした。この見落としにより、認証されていない攻撃者が特定の文字シーケンスを使用して、以前のCVE-2012-1823の保護を回避できるようになります。引数インジェクション攻撃を通じて、リモートのPHPサーバー上で任意のコードが実行される可能性があります。
このPoCは学習および研究目的のみに使用してください。違法行為に使用しないでください。法的結果に対する責任はすべてあなた自身にあります。
この脆弱性は、DEVCORE (@d3vc0r3)のOrange Tsai (@orange_8361)によって発見されました。彼の優れた研究をフォローしてください。私たちの役割は、この問題のエクスプロイトを再現および開発することだけでした。
なぜ、すでに多くの公開PoCが存在するのに、エクスプロイトスクリプトを書き直す必要があるのか？
多くの公開PoCは同じ元のエクスプロイトに基づいているため、多くのベンダーがこれらのPoCを参考にし、特定のキーワードをブロックして悪用を防いでいます。しかし、多くの場合、すべての潜在的なエクスプロイトベクトルをブロックすることを見落としています。これに対処するため、スクリプトにはランダムなパラメータを生成する簡単なメカニズムと、PHP CGIインジェクションからRCEに至るためのさまざまなLFI-to-RCE悪用方法が含まれており、成功率を高めています。
環境の脆弱性を再現しようとテスト中に、PoCが常にHTTP 500エラーを引き起こし、調整しても変わらないことに気付きました。脆弱な環境で作業していたため、エラーの原因を調査し始めました。そして、Devcoreの記事を思い出しました。その記事では、特定のエクスプロイトシナリオでは、RCEエクスプロイトが実際に成功していてもサーバーがHTTP 500エラーを返すことがあると述べられていました。これを念頭に置いて、ローカルでcalc.exeを起動できるかテストしてみたところ、驚いたことに動作しました——それはブラインドRCEでした！
しかし、Apacheのエラーログを確認すると、attackが正常に実行されたにもかかわらず、allow_url_includeに関連するエラーが見つかりました（根本的な原因はまだ完全には理解できていません。知見があれば連絡してください）。これにより、ブラインドRCEをテストするオプションも含めたエクスプロイトを作成しました😊。
ターゲットがWindows 7より前のOSバージョンの場合でも、他の方法で可視RCEやリバースシェルに昇格できます。ただし、これらの手法はこの記事の範囲外のため、詳細には触れません。ペネトレーションテスターやレッドチームスペシャリストとして、かなり迅速に代替解決策を見つけられるはずであり、それは興味深いプロセスになるでしょう😉。
2024年11月15日更新
仕事の要件により、スクリプトを継続的に改善し、すべての環境で可能な限り互換性を持たせ、RCEを達成する可能性を最大化するようにしました。これは、一部のターゲットで多くの公開PoCを使用してもPHPを正常に実行できなかったことがきっかけでした。最終的に、この問題を予期せず解決し、エラー500が発生するほぼすべてのケースを克服し、PHPの実行結果を正常に表示できるようになりました。その結果、ブラインドRCEはそれほど重要ではなくなりました。 😧
エクスプロイトの条件
依存関係をインストールする必要があります:
$ python3 -m pip install requestsスクリプトを直接実行して使用方法を確認してください。以下のコマンドを実行して、ターゲットが脆弱かどうかを確認できます。
$ python3 CVE-2024-4577.py <target> <php shell>
ターゲットにエクスプロイトが存在する場合、PHPの実行結果をローカルに保存できます。これはphpinfoを表示する必要がある場合に便利です。
$ python3 CVE-2024-4577.py <target> "phpinfo()" --save info.html
ターゲットがブラインドRCEに対して脆弱な場合、スクリプトはローカルポートで待ち受け、ターゲットサーバーにPHPを実行させ、リクエストを送信してエクスプロイトの存在を確認しようとします。リクエストを受信した場合、ターゲットサーバーがコマンドを正常に実行したことを示します。
