Hello there, ('ω')ノ
アクセストークンの漏洩によるアカウントの乗っ取りを。
ターゲットは、マーケティングを効率的に自動化できるWebサイトで。
今回は、target.comと呼ぶことに。
プロファイルの更新機能をテストしているときに。
下記の興味深いリクエストに遭遇して。
PUT /api/account/general-info/ HTTP/1.1
Host: services.target.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://bo.target.com/
Content-Type: application/json
accessToken: 795b74eXXXXXXXXXXcba9abd3beaa3ec40b5d3ed
Content-Length: 213
Origin: https://bo.target.com
DNT: 1
Connection: close
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site{"company":"DSPH","domain":"https://darksocietypenetration.com","cellphone":"+91-83xxxxxx36","companySize":"2","businessSector":20,"logo":{"height":0,"base64":"","square":true,"width":0}}
プロファイルの詳細を変更するためにaccessTokenヘッダを使用していて。
他の認証されたアクションの場合は、そのようなヘッダはなくて。
2番目のアカウントのaccessTokenヘッダの値に変更して。
2番目のアカウントの詳細が変更できて。
また、他の認証済みリクエストにaccessTokenヘッダを追加しても。
2番目のアカウントの詳細が変更できて。
さらに調査していると、accessTokenの値が静的であることがわかって。
つまり、accessTokenはログアウト後も同じで。
なので、被害者のaccessTokenを取得できれば。
彼の完全なアカウントを引き継ぐことができるわけで。
しかしながら、accessTokenヘッダの値は推測できないので。
被害者のaccessTokenを取得する方法を見つけることに。
ウェブサイトの電子メールマーケティングの下には。
独自の電子メールテンプレートを作成できるセクションがあって。
自分の電子メールで画像ファイルをアップロードするには。
自分のデバイスもしくは画像のURLを介しての２つの方法があって。
DoS、SSRF、XSS、ファイルアップロードのトリックを試したものの。
強力なファイルタイプの検証を行っているようで。
また、クライアント側からイメージをフェッチしているのでSSRFは使用できず。
そこで、Burpのコラボレータのリンクを使用してリクエストを確認しようとすると。
興味深いことに気づいて。
Referrerヘッダで、accessTokenがtokenパラメータを介してリークしていて。
攻撃シナリオ：
１．被害者は、テンプレートを作成していて。
２．被害者は、サードパーティのWebサイトからテンプレートに画像を追加して。
３．サードパーティのWebサイトの所有者（または従業員）は。
被害者のアクセストークンを（ログから）取得して。
アカウント全体を乗っ取ることができて。
Best regards, (^^ゞ
