Shikata Ga Nai

Private? There is no such things.

Account takeover worth $1000を訳してみた

Hello there, ('ω')ノ

 

1000ドル相当のアカウント乗っ取りを。

 

脆弱性:

 アカウント乗っ取り

 認証回避

 情報漏えい

 パスワード再設定の不具合

 

記事:

 https://infosecwriteups.com/account-takeover-worth-1000-611452063cf

 

今回は、誤って構成された 2FA と OAuth を使用して。

最大規模の組織の 1 つでアカウントを乗っ取ることができて。

 

脆弱性に入る前に、すべてがどのように機能するか。

特に認証がどのように機能するかについて足がかりを得て。

これは、バグをより明確に理解するのに役立って。

 

Web サイトにサインインするには複数の方法がありますが2 つの方法に分類できて。

1 つ目は通常のメールとパスワードを使用する方法で。

もう 1 つは Google、GitHub などを含む OAuth を使用する方法で。

 

この Web サイトのセキュリティ機能は、このバグで大きな役割を果たした 2FA で。

顧客はこれを使用して、セキュリティ レイヤを追加できて。

 

それでは、手順とバグに移ることに。

基本的な偵察から始めましたが、何も見つからなかったので。

認証テストに移り、アカウントを作成して、重複登録、パスワードを忘れたバグや。

SQL インジェクションなどをテストして。

次に、2FA を有効にし、2FA コードをブルート フォースして。

メール、パスワード ログイン、Oauth ログインの両方でこれを試しましたが。

何も機能せず。

 

 

翌日、Google oauth アカウントで 2FA を有効にし、すべてのリクエストを傍受し。

ウェブサイトが 2FA コードをサーバに送信するときのように。

ジューシーなリクエストをリピータに送信して。

 

 

さらにいくつかの 2FA バグをテストし、うんざりしてアカウントの 2FA を停止して。

その間、すべてのリピータでリクエストに行った後、上記のリクエストでつまずき。

それを再度送信し、JWT トークンを受け取って。

authenticatorコードを 000000 のようなランダム コードに変更し。

再度リクエストを送信して、受け取った JWT トークンを推測して。

 

 

アカウントで 2FA を無効にした後でも、このリクエストを使用して。

JWT コードを取得できて。

この JWT トークンは基本的に、ユーザの認証に使用される Cookie で。

これが実際に脆弱性であることを確認するために。

1 日待ってから再度リクエストを送信し、JWT トークンを受け取って。

 

ハッキングされたアカウントに直接ログインする方法が必要ったので。

ログインしたWebサイトを閲覧し始めたところ、oauthアカウントに。

パスワードを設定して、誰でもメールとパスワードを使用して。

ログインできる機能があることがわかって。

 

 

パスワード設定リクエストを使用し、JWT トークンを受け取ったものに置き換えて。

送信するとパスワードが追加されて。

 

 

oauth を回避して、電子メールとパスワードを使用して。

直接ログインできるようになって。

このバグは、Google OAuth ログインに影響するだけでなく。

下記のサイトで使用されるすべての OAuth プロバイダに影響して。

 GitHub、Microsoft、Bitbucket、Azure Active Directory

 

注::

このバグは、顧客がアカウントで 2FA を有効にしてから無効にした場合にのみ。

発生する可能性があって。

 

影響:

攻撃者がアカウントにアクセスできたら。

1.攻撃者は、API キーなどの機密情報を表示および編集できて。

2.組織名と製品名を編集して。

3.メンバーをアカウントに招待して。

4.組織からユーザを削除して。

5.アカウントにパスワードを追加して。

6.アカウントを削除して。

 

Best regards, (^^ゞ

2FA Bypass Do Re Miを訳してみた

Hello there, ('ω')ノ

 

2FAバイパス Do Re Miを。

 

脆弱性:

 2FA バイパス

 

記事:

 https://medium.com/@ashlyn.lau_17206/2fa-bypass-do-re-mi-cfcfc3775d2e

 

すべての 2FA バイパス手法が同等に作られているわけではなく。

これまで遭遇した最も一般的なシナリオは、次のいずれかで。

 

 ・2FA チェックなしで保護されたエンドポイント

 ・サーバ応答での 2FA トークンの開示

 

今回は遭遇した新しいシナリオで。

認証のために有効なユーザ ID とパスワードを送信した後、アプリケーションは。

「ユーザだけが持っているもの」コンポーネントの ID の証明として。

第 2 要素認証を要求して。

 

任意のランダムな mtoken (123456 など) の値を入力し、[ログイン] を選択して。

予想どおり、入力された mtoken値が mtoken_secret値と比較して。

異なるハッシュ値を生成したため、2FA ログインは拒否され。

下記は、無効な mtokenを含むサーバの応答で。

 

 

開発者の直感では、目立った 3 つのパラメータ値があり見過ごされる可能性があって。

操作する 3 つのパラメータは次のとおりで。

 

Do: mtoken

Re: mtoken_secret

Mi: mtoken_t

 

これは、“”や 0 などのデフォルトの空または false 値から。

通常開始するロケット科学ではなく。

特定のフラグが false または値が null/空の場合、プログラムは。

2FA チェックをスキップし、値を変更して。

別の特徴的な組み合わせを作成することを想定していて。

Do Re Mi (試行1)

 

追跡を断ち切るために、下の最後のコンビが大当たりして。

サーバは、認証済みのセッション トークンを返して。

2FA 認証がバイパスされて。

 

Do: mtoken = 0

Re: mtoken_secret #最初のログイン サーバーの応答から返される値

Mi: mtoken_t = “”

 

 

Best regards, (^^ゞ

Business Logic Vulnerability via IDORを訳してみた

Hello there, ('ω')ノ

 

IDOR によるビジネス ロジックの脆弱性を。

 

脆弱性:

 IDOR

 支払いの改ざん

 

記事:

 https://sagarsajeev.medium.com/business-logic-vulnerability-via-idor-6d510f1caea9

 

今回は、e コマース Web サイトから任意の製品を 10 ドルで購入できた方法を。

これは、IDOR を可能にする脆弱なパラメータのために可能で。

ターゲット ドメインは、スタートアップの E コマース Web サイトで。

 

・保存された XSS を報告しましたが、最近のペンテストで既に特定されており。

 修正に向けて準備が整っているとのことで。


・パラメーター改ざんのバグを期待して、カート チェックアウト オプションの。

 テストを開始しましたが、何も見つからず。


・その後、リクエスト本文の製品 ID である <PID> パラメータに気付いて。

 

 

・ amount パラメータの操作方法をいろいろ試してみましたが。

 サーバ側の検証により、バイパスが不可能になって。


・amount パラメータには脆弱性はありませんでしたが、PID はどうか。

 

重要:

1.低価格の製品 A をカートに追加して。

 (実際のPoCでは10ドル前後の製品を追加して)

 

2.他の製品 B の PID を取得して。 (400 ドルの製品を選んで)

 

他の製品の PID をどのように把握したのか疑問に思われるかもしれませんが。

製品 B をカートに追加するだけで、そこから PID を取得できて。

また、「この製品を共有する」オプションが PID をリークすることもわかったので。

そこからコピーして、ここで使用できて。

 

3.POST リクエストで、製品 A の PID を製品 B の PID に置き換えて。

    (金額パラメータはまだ $10 で)

 

4.リクエストを転送すると合計金額は $10 と表示され。

 

5.10 ドルで購入して。


技術的には 400 ドルの製品を 10 ドルで購入したことになって。

 

Best regards, (^^ゞ

Escalating Open Redirect to XSSを訳してみた

Hello there, ('ω')ノ

 

Open Redirect を XSS にエスカレートするを。

 

脆弱性:

 オープンリダイレクト

 XSS

 

記事:

 https://sagarsajeev.medium.com/escalating-open-redirect-to-xss-d2b9355e5f05

 

今回は、ターゲット Web サイトで Open Redirect を見つけて。

XSS にエスカレートし、それによって重大度を高めることができた方法について。

 

ターゲットドメインを次のようで。

https://www.radacted.com/resources?search=hacker

   

 ・「hacker」という検索語がページに反映されていることに注意して。

 ・ここで可能な限りすべての方法で XSS を試したものの見つからず。

  そこで、Open Redirects を探すことに。

 

下記のPayloadsAllTheThings は、大いに助けてくれて。

 

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Open%20Redirect


そして、次のペイロードが XSS をトリガすることがわかって。

    https://redacted.com/resources?next=sub.redacted.com&next=javascript:confirm(document.cookie)

 

被害者がこのリンクをクリックすると、sub.redacted.com にリダイレクトされ。

1 ~ 2 秒以内に XSS ペイロードがトリガされ。

 

ノート:

1.上記のすべての例で、被害者は自分のアカウントにサインインしていて。


2.「next」パラメータは URL に手動で追加して。

 「 ?continue= 」、「 ?redirect_uri= 」、「 ?return=」、「 ?go= 」。

 「?continue_to=」などを手動で追加することもできて。


3.次のパラメータの sub.redacted.com は、ホワイトリストに登録された任意の。

 SLD (セカンドレベルドメイン)にすることができるので。

 ターゲットのサブドメインをそれに追加すると、そのジョブが実行されて。


4.AND 演算子を使用すると、両方の条件が真になるので。

 「javascipt:confirm(document.cookie)」もクライアント側で実行されて。

 

ヒント :

& などの演算子で URL エンコード (または二重 URL エンコード) も試して。

これは、特定のフロントエンドの制限を回避するのに役立つ場合があるので。

 

Best regards, (^^ゞ

An Unusual Tale of Email Verification Bypassを訳してみた

Hello there, ('ω')ノ

 

メール認証バイパスの珍しい話を。

 

脆弱性:

 メール認証バイパス

 ブルートフォース

 レート制限バイパス

 

記事:

 https://sagarsajeev.medium.com/an-unusual-tale-of-email-verification-bypass-dcf884d544eb

 

今回は、メール認証バイパスをどのように報告したかを。

ドメインを「https://www.redacted.com/account/login」とすると。

attack@email.com としてアカウントにログインして。

メールオプションの変更に移動し、メールを。

attacker@email.comからvictim@email.comに変更すると。

4 桁の OTP がvictim@email.com に送信され、変更が確認 (検証) されて。

レート制限は設定されていないので、ブルートフォーシングによって。

正しい OTP が見つかって。


しかし、正しい OTP を提出すると、ページに間違った OTP が表示されて。

正しい OTP が Web サイトによって拒否された理由がわからず。

すべてのリクエストをリピータの OTP ブルートフォース リクエストして。

手動で検査することに。

試行錯誤の 2 時間後、リクエストの間に埋め込まれた「sec」と呼ばれる。

隠しパラメータに出くわして。

 

リピータでは120回目のリクエスト以降にしか現れない、かなり特殊なパラメータで。

それを 3 回確認しましたが、実際には 120 回目のリクエストの後でしか。

表示されず。

また、120 回目のリクエストの後、ステップ値 1 ずつ増加していくことに。

 

>120 番目のリクエストの「sec」値は 1

>121 番目のリクエストの「sec」値は 2

>122 番目のリクエストの「sec」値は 3

>123 番目のリクエストの「sec」値は 4

> など

 

すると、120 回目のリクエスト以降のすべての試行で。

別のサブドメインへの 302 リダイレクトが発生することにも気付いて。

ターゲットが Web サイトのトラフィックを減らすため。

またはブルートフォース攻撃を防ぐために選択した方法のように感じて。

 

パラメータはクライアント側に大きく依存していたため。

120 番目のリクエストから「sec」パラメータを削除するだけで。

後続のすべてのリクエストからパラメータが削除され。

上記の OTP ブルートフォーシングをもう一度試し。

正しい OTP を取得して入力すると。

電子メールは、attacker@email.com からvictim@email.com に変更されて。

 

影響:

この問題は、電子メールの検証をバイパスするために使用でき。

攻撃者は、その電子メール アカウントにアクセスできなくても。

任意の人の代わりにアカウントを作成できて。

 

Best regards, (^^ゞ