shikata ga nai

Private? There is no such things.

Account Takeover via Access Token Leakageを訳してみた

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を介しての2つの方法があって。

DoS、SSRF、XSS、ファイルアップロードのトリックを試したものの。

強力なファイルタイプの検証を行っているようで。

また、クライアント側からイメージをフェッチしているのでSSRFは使用できず。

 

そこで、Burpのコラボレータのリンクを使用してリクエストを確認しようとすると。

興味深いことに気づいて。

Referrerヘッダで、accessTokenがtokenパラメータを介してリークしていて。

 

f:id:ThisIsOne:20210827131857p:plain


攻撃シナリオ:

1.被害者は、テンプレートを作成していて。

2.被害者は、サードパーティのWebサイトからテンプレートに画像を追加して。

3.サードパーティのWebサイトの所有者(または従業員)は。

 被害者のアクセストークンを(ログから)取得して。

 アカウント全体を乗っ取ることができて。

 

Best regards, (^^ゞ

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

f:id:ThisIsOne:20200404115457p:plain