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