Hello there, ('ω')ノ
情報漏えいによる 2FA バイパス & 不適切なアクセス制御を。
脆弱性：
DoS
MFA バイパス
記事：
https://akashhamal0x01.medium.com/2fa-bypass-due-to-information-disclosure-improper-access-control-f9a5a8a4e0af
今回は、DOS を探しているときに 2FA バイパスを見つけた方法を。
ロジックが実装されていない場合は DOS が可能であるため。
組織/チームベースの Web サイトなどでこれらのタイプの脆弱性を調べる価値があり。
次のような攻撃を実行するために知っておくべきことや。
Web サイトに必要な条件/機能がいくつかあり。
・独自の組織を作成し、他の組織に参加でき。
・ログアウトすると、最後に組織にログインしていたときに組織にログインし。
たとえば、あなたが組織 A の所有者であり、組織 B に参加している場合。
組織 B に切り替えてログアウトし、再度ログインすると、組織 B にいるはずで。
・2FA があり。
１．アカウントベースの 2FA
２．組織ベースの 2FA
組織ベースの 2FA が有効になっている場合、その組織にログインするには。
アカウント ベースの 2FA を有効にする必要があり。
以上が技術的な詳細で。
アカウントの 2FA を有効にして、認証フローをいじり始め。
資格情報 (電子メールとパスワード) を入力すると、次のような詳細が表示され。
・応答は、“2fa”:”<JWT_TOKEN>”などの JWT トークンを含むパラメーターを。
明らかにして。
・応答では、組織 ID とともに参加した組織の名前と、それらの組織で 2FA が。
有効になっているかどうかも明らかになり。
リークされた <JWT_TOKEN> を使用して、API エンドポイントに。
直接 HTTP リクエストを発行しようとして。
（ウェブサイトでは、ほとんどの CRUD アクションに API を使用しているため）
しかし、トークンは実際には認証トークンではないため、403 Denied になり。
しかし、何かが起こるかどうかを確認することに。
<JWT_TOKEN> は、 2FA HTTP リクエストで「code」パラメータとともに使用され。
「code」には 6 桁の Google 認証コード値が含まれていて。
ということで、流れはこんな感じで。
電子メールとパスワードを入力
⇩
応答には、“2fa”:”<JWT_TOKEN>”が表示され。
⇩
2fa コードを入力する必要があり。
⇩
下記のHTTP 本文に6 桁の 2fa コードを入力し。
{“2fa”:”<JWT_TOKEN>”, “code”:<6 digit 2fa code”>}
そのため、「2fa」とその値が「code」パラメータとともに発行され。
2FA ステップが完了してアカウントにログインし。
つまり、2FA ステップを完了するには「2fa」が必要で。
脆弱性は見つかりませんでしたが、あるシーンが頭に浮かび。
DOS につながると思ったので試してみたいと思い。
シーンは次のようなもので。
・2 つの組織に参加しているとして。
1 つは自分が所有者である自分の組織で。
2 つ目は「メンバー」の役割を持つ攻撃者の組織で。
アカウント 2FA が有効になっておらず、組織ベースの 2FA が。
有効になっている組織がないと仮定し。
攻撃者組織 (組織 B) にログインしていて、ログアウトしたとして。
アカウントにログインすると、組織 B に移動し。
これは、ログアウトしたときに組織 B にいたためで。
フローは単純に見えますが、ログインする前に、攻撃者組織 (組織 B) の所有者が。
組織ベースの 2FA を有効にすると、ログインが拒否されるので。
ログインするには、2FA を有効にする必要があり。
確認してみることに。
上記のことを実行すると、メールとパスワードを入力するときに2つのオプションが与えられることがわかりました。
・「この組織では 2FA が有効になっています。2FA をセットアップしてください。」
オプションをクリックすると、被害者のメールにアクセスできないため。
コードがメールに送信され、これを選択する価値はなく。
・2 番目のオプションは「Switch Org」で、2FA が有効になっていない組織。
（この場合は自分の組織）に切り替えることができ。
HTTP リクエストを分析したところ、下記のようなOrg に切り替えるための 。
下記のようなリクエストが。
POST /api/org/<ORGID>
Host: example.com
{“2fa”:”<JWT_TOKEN>”}
そこで、漏洩した情報を受け入れてアカウントにログインできる。
エンドポイントを発見して。
したがって、最終的なシナリオは次のようになり。
注：
このシーンでは、被害者は 2 つの組織に参加しており。
2FA が有効になっている組織は 1 つだけで。
また、被害者はアカウントベースの 2FA を有効にしていて。
メールとパスワードを入力して。
⇩
応答から『2fa”:”<JWT>』を取得し。
2FA が有効になっていない組織の組織 ID を取得し。
次に、次の http 要求を発行して。
POST /api/org/<ORG ID>
Host: example.com
{“2fa”:”<JWT_TOKEN>”}
アカウントにログインするため、アカウント 2FA をバイパスして。
要するに、リークされた値を受け入れてアカウントにログインできる。
エンドポイントを見つけ。
この記事は、主に機能／例外／エッジ ケースの実装方法に依存していて。
この記事がDOS の発見、新しいエンドポイントの発見などに適用できて。
Best regards, (^^ゞ
