サービス拒否前（未確認のアカウントに2FAを設定）を。
脆弱性：
アプリケーションレベルのDoS
記事：
https://medium.com/@kalvik/pre-denial-of-service-set-up-2fa-on-unverified-account-8399af52ea2d
今回は、未確認のアカウントで2FAを設定して。
その電子メールの実際のユーザのサービス拒否を。
引き起こす方法について説明することに。
被害者が、まだ自分のアカウントを登録していないと仮定して。
セットアップフローは、次のとおりで。
・アカウントのサインアップ
・電子メールの確認
・2FAのセットアップ
電子メールを確認しないと、セキュリティ標準に従って2FAを設定できず。
ただ、この制限をうまく回避して、電子メールを確認せずに。
2FAをセットアップすることができて。
Webサイトは、websocketを使用していて。
確認済みのアカウントで2FAを設定すると。
最初のWebSocketリクエストは、下記のとおりで。
[“{\”msg\”:\”method\”,\”method\”:\”2fa/generateMFA\”,\”params\”:,\”id\”:\”XXXX\”}”]
それで、下記のリクエストだと認証システムアプリで。
2FAを設定するために使用される秘密鍵が返されたので。
[“{\”msg\”:\”method\”,\”method\”:\”2fa/getSecretKey\”,\”params\”: ,\”id\”:\”XXXX\”}”]
未確認のアカウントから上記のリクエストを送信してみようと思って。
被害者のアカウントにログインして、下記のリクエストを送信すると。
残念ながら、「アカウントが確認されていません」という返信があって。
[“{\”msg\”:\”method\”,\”method\”:\”mfa/getSecretKey\”,\”params\”:,\”id\”:\”24\”}”]
その後、いくつかのヒットと試行の後に。
下記が、2FAを設定する最初のリクエストだと気づいたので。
被害者のアカウントから下記のリクエストを再度送信すると空白の応答を受け取って。
[“{\”msg\”:\”method\”,\”method\”:\”mfa/generateMFA\”,\”params\”:,\”id\”:\”XXXX\”}”]
再度、下記のリクエストを送ってみると秘密鍵を取得することに成功できて。
秘密鍵は、10〜12文字の長さで。
[“{\”msg\”:\”method\”,\”method\”:\”mfa/generateMFA\”,\”params\”:[],\”id\”:\”24\”}”]
Google Authenticatorを開いて、その秘密のコードを使用して。
2FAをセットアップすると成功して。
このようにして、未確認のアカウントで2FAを設定して。
その電子メールの実際のユーザが将来、Webサイトにアクセスするのを。
ブロックすることができて。
Best regards, (^^ゞ
