Hello there, ('ω')ノ
偶発的なRCEを。
脆弱性：
無制限のファイルアップロード
記事：
https://medium.com/@__mr_beast__/the-accidental-rce-7ceef9cee179
ツール：
Burp Suite
今回は、偶然に見つけたリモートコード実行の脆弱性について共有することに。
ターゲットは、「redacted.com」と呼ぶことに。
それは、Eコマースのウェブサイトで。
検索バーでXSSを探し始めたものの、残念ながら見つからず。
次にアカウントを作成して、ログインした後に。
ユーザがソーシャルハンドルにリンクを追加できることに気付いたので。
リンクによって、アラートをトリガすることができて。
別のアカウントを作成して、他の誰かが攻撃者のプロファイルを表示すると。
アラートがトリガされるかどうかを確認してバグを報告することに。
さらにテストをすすめると興味深い部分があって。
ポップアップ表示されたアラートを閉じているときに。
Webページのどこかをクリックすると。
ユーザが問題に関するチケットを発行できる新しいページが表示されて。
そして、ユーザがチケットを発行しているときに。
いくつかのファイルを添付できることに気づいたので。
PHPシェルをアップロードしようとしたものの、アップロードできず。
その後、Webアプリケーションが「.jpg」、「.png」、「.pdf」の拡張子のみを。
許可するという事実がわかって。
セキュリティメカニズムがどのように機能しているかをよりよく理解するために。
Burp Suiteを起動し、有効な「.jpg」ファイルをアップロードして。
応答を傍受すると、ファイルは「redacted.com」のディレクトリに。
アップロードされて。
PHP Webシェルの名前を変更して、拡張子を「.jpg」に変更したものの。
アップロードすることができなかったので。
セキュリティメカニズムがどのように機能しているかを理解して。
下記にポイントをまとめることに。
・ファイル拡張子は、クライアント側でのみ検証されていて。
・ファイルの内容はサーバ側で検証されていて。
そこで、サーバ側の検証をエスケープするために。
Webシェルのコードに「GIF98」を追加して。
https://www.unphp.net/decode/f107ff38cae10439530ab2f65ffe4617/
ファイル名のクライアント側の検証をバイパスするために。
「.jpg」を追加したものの今回もRCEが取れず。
ファイルはアップロードされたものの。
「.jpg」拡張子を変更するとエラーが発生して。
サーバ側で、ファイル拡張子の検証が正しく機能していない場合もあるかと思い。
同じWebシェルに「.jpg」拡張子と「GIF98」を。
Webシェルのコードにアップロードして。
リクエストをリピータに送って。
ファイル名を「webshell.jpg」⇨「webshell.php％00.jpg」に変更して。
サーバー側の「.jpg」拡張子を切り捨てることに。
すると、PHPファイルとしてアップロードされて。
Best regards, (^^ゞ
