Hello there, ('ω')ノ
理論的に可能なアカウントの乗っ取りを。
脆弱性：
IDOR
アカウントの乗っ取り
記事：
https://ironfisto.medium.com/theoretically-possible-to-practical-account-takeover-c9383ab03f76
今回、見つけたはアカウント乗っ取りで。
これは、アプリケーションの偵察と理解を備えたIDORの優れたチェーンで。
暗号の引き出しプロセスはシングルステップのプロセスではなかったので。
アプリは非常に安全に見えて、身元も確認していたので。
アカウントの乗っ取りを直接テストしようとして。
ただ、影響があったとしても被害者が持っている暗号資産の量くらいですが。
POC：
１．電子メールで2つのアカウントを作成して。
両方のアカウントの主キーであるUUIDを記録してから。
２．パスワードリセット機能に移動して、メールIDを入力して。
パスワードリセットリンクを取得して。
https://domain.tld/changePassword/{user-primary-key-id}/{reset-token}
３．リンクを見るとこれは脆弱に見えたので。
ユーザの主キーを被害者の主キーに置き換えて送信すると。
https://domain.tld/changePassword/{victim-primary-key-id}/{attacker-reset-token}
リクエスト：
POST /changePassword/62c4ffb0-be57-11e8-a68e-8d01686939c8/378fce7754fcdadebb6de5d778753c9916ffed192c942756b45bfeabd4e856f00799a6db002a292eb5cfe007208cc7b1 HTTP/1.1
リクエストボディ：
{"password":"urhacked"}
このリクエストへの応答は200だったので。
すべてのユーザのアカウントを引き継ぐことができて。
しかし、どのユーザも被害者のメールID、またはUUID主キーがわからないので。
不要な要求なので、理論的に考えられる攻撃と自分のテストアカウントは。
互いにぶつかり合っていてたので。
次は、UUIDを取得する方法を理解することで。
アプリケーションを理解すると紹介機能があって。
リンクは、下記のとおりで。
https://domain.tld/?source=4vyryrtfhf
これで、被害者に属するソース参照パラメータができたもののUUIDはリークしなくて。
次にソース参照パラメータを受け取る別のエンドポイントを見つけて。
https://domain.tld/fast/4vyryrtfhf
下記のように犠牲者のUUIDを取得できて。
なので、Google Dorksを使用すると、任意のユーザのソースパラメータと。
UUIDを取得することができたので。
アプリケーションのユーザアカウントを乗っ取ることに。
４．自分のアカウントを使用してパスワードのリセットトークンを取得して。
パスワードのリセットリンクで被害者のUUIDを使用すると。
それが、被害者のアカウントを引き継ぐことができた方法で。
Best regards, (^^ゞ
