Shikata Ga Nai

Private? There is no such things.

2FA Bypass due to information disclosure & Improper access control.を訳してみた

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 があり。

  1.アカウントベースの 2FA

  2.組織ベースの 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, (^^ゞ