Hello there, ('ω')ノ
情報開示から興味深い特権昇格を。
脆弱性：
情報開示
アカウントの乗っ取り
特権の昇格
subdomain.REDACTED.comでは、ユーザは自社のお金のプログラムを作成できて。
ユーザとしてログインした後、操作できる機能はあまりなくて。
ただ、「アカウントの編集」機能に注意を引いて。
Burp Suiteでインターセプトして、リクエストをキャッチしてみると。
リクエストが下記のエンドポイントに送信されたことがわかって。
ProgramManagerREDACTED/REDACTED/ updateuser
リクエストメソッドは多くのパラメータを持つ「PUT」だったものの。
目を引いたのは「role_id」と「user_info_id」で。
最初に行ったのは、「role_id」パラメータを1から2に変更することで。
ただし、サーバの応答は「401Unauthorized」で。
「user_info_id」のパラメータについては、後述することに。
下記のエンドポイントでしばらく遊んだ後に。
/ProgramManagerREDACTED/REDACTED/updateuser
bodyリクエストと最後の2つのディレクトリを削除して。
リクエストを「PUT」から「GET」に変更すると。
GET /ProgramManagerREDACTED/
サーバからの応答は、「200OK」で。
さらに応答本体は、隠されたエンドポイントに関する大量の情報で。
応答本文はかなり巨大だったので、
admin、passwords、userなどのいくつかのキーワードを検索することに。
「user」キーワードは、下記の興味深いエンドポイントにつながって。
/ProgramManagerREDACTED/userInfoDetailsEntities
そのエンドポイントを「GET」リクエストでSendすると。
Webアプリケーション上の全ユーザに関する膨大なリークが含まれていて。
ここで、4つのロールIDがあることも理解できて。
さらに掘り下げてみることに。
「user_info_id」値を使用して別のリクエストを送信してみると。
/ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}
サーバの応答で、「role_id」や「mail」などのユーザー情報を確認できて。
もう1つ重要なことは、メールはクリアテキストでなくハッシュで。
「role_id」パラメータ値を「4」に変更して。
「mail」パラメータ値をハッシュメールに変更して。
「PUT」でリクエストを送信すると。
/ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}
5秒後、サーバから「200OK」の応答が返されrole_idが4(admin権限)に変更されて。
再ログインして、管理者になることができて。
Best regards, (^^ゞ
