shikata ga nai

Private? There is no such things.

From Information Disclosure to interesting Privilege Escalationを訳してみた

Hello there, ('ω')ノ

 

情報開示から興味深い特権昇格を。

 

脆弱性:

 情報開示

 アカウントの乗っ取り

 特権の昇格

 

記事:
 https://dudy2kk.medium.com/from-information-disclosure-to-interesting-privilege-escalation-61ed3aaaf218

 

subdomain.REDACTED.comでは、ユーザは自社のお金のプログラムを作成できて。

ユーザとしてログインした後、操作できる機能はあまりなくて。

ただ、「アカウントの編集」機能に注意を引いて。


Burp Suiteでインターセプトして、リクエストをキャッチしてみると。

リクエストが下記のエンドポイントに送信されたことがわかって。

 ProgramManagerREDACTED/REDACTED/ updateuser


リクエストメソッドは多くのパラメータを持つ「PUT」だったものの。

目を引いたのは「role_id」と「user_info_id」で。

 

f:id:ThisIsOne:20210727115149p:plain

 

最初に行ったのは、「role_id」パラメータを1から2に変更することで。

ただし、サーバの応答は「401Unauthorized」で。

user_info_id」のパラメータについては、後述することに。


下記のエンドポイントでしばらく遊んだ後に。

 /ProgramManagerREDACTED/REDACTED/updateuser

 

bodyリクエストと最後の2つのディレクトリを削除して。

リクエストを「PUT」から「GET」に変更すると。

 GET /ProgramManagerREDACTED/ 

 

サーバからの応答は、「200OK」で。

さらに応答本体は、隠されたエンドポイントに関する大量の情報で。

 

f:id:ThisIsOne:20210727115248p:plain

 

応答本文はかなり巨大だったので、

admin、passwords、userなどのいくつかのキーワードを検索することに。

 

user」キーワードは、下記の興味深いエンドポイントにつながって。

 /ProgramManagerREDACTED/userInfoDetailsEntities

 

そのエンドポイントを「GET」リクエストでSendすると。

Webアプリケーション上の全ユーザに関する膨大なリークが含まれていて。

ここで、4つのロールIDがあることも理解できて。

 

f:id:ThisIsOne:20210727115331p:plain

 

さらに掘り下げてみることに。

 「user_info_id」値を使用して別のリクエストを送信してみると。

 /ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}


サーバの応答で、「role_id」や「mail」などのユーザー情報を確認できて。

もう1つ重要なことは、メールはクリアテキストでなくハッシュで。

 

f:id:ThisIsOne:20210727121201p:plain

 

role_id」パラメータ値を「4」に変更して。

mail」パラメータ値をハッシュメールに変更して。

PUT」でリクエストを送信すると。

 /ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}

 

5秒後、サーバから「200OK」の応答が返されrole_idが4(admin権限)に変更されて。

再ログインして、管理者になることができて。


Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain