Hello there, ('ω')ノ
悪い双子：JWT悪用シナリオの特殊なケースを。
脆弱性：
アカウントの乗っ取り
記事：
https://medium.com/@sandh0t/the-bad-twin-a-peculiar-case-of-jwt-exploitation-scenario-1efa03e891c0
今回は、特定の状況下でJWTの不適切な実装を悪用する新しい手法を。
JWT、およびJWTが認証メカニズムとしてどのように実装されているかについての。
基本的な理解が必要で。
最初、一般的な脆弱性を探し始めましたが、結果はなく。
アプリケーションは十分に保護されており。
プログラムが開始されてからしばらく経っていたので。
他のハッカーがすでにそのような種類のバグを発見している可能性が高くて。
次に、認証プロセスがどのように機能するかを詳しく調べることに。
これは、Webアプリを事前テストするときのお気に入りで。
認証はJWTトークンに基づいており、以下に説明するように。
JWTトークンの構造は非常にミニマリストでシンプルで。
エンコードされたJWTトークン：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTAzMDcsImlhdCI6MTY0NjIxOTU0NiwiZXhwIjoxNjgwNDMzOTQ2fQ.C6g3y48Q8ZFvElOtTwZ5NckObGXY5aX-Xn-7w-G3
デコードされたJWTトークン：
{
“alg”: “HS256”,
“typ”: “JWT”
}.
{
“id”: 10307,
“iat”: 1646219546,
“exp”: 1680433946
}.
C6g3y48Q8ZFvElOtTwZ5NckObGXY5aX-Xn-7w-G3
ユーザのアカウントIDを表す「id」値に注意して。
「id」を別のユーザアカウントに関連付けられた値に変更する方法を見つけた場合。
そのユーザとして認証し、彼のアカウントを引き継ぐことができるため。
このことはすぐに注意を引いて。
そこで、そのようなアクションを実行する方法を見つけ出し。
Noneアルゴリズムやアルゴリズムの混乱手法など。
一般的なJWTの脆弱性をすべて試し、秘密鍵を解読しようとしましたが成功せず。
次に基本に戻ることにし、サブドメインを再度収集するための。
調整プロセスを開始して。
The Bad Twin：
同じWebアプリをホストしているステージングサブドメインがあることに気づいて。
メインのWebアプリケーションが「www.redacted.com」でホストされ。
ステージングWebアプリが「staging.redacted.com」でホストされていると仮定して。
そこで、「www.redacted.com」のメインアプリで作成したアカウントを使用して。
「staging.redacted.com」にサインインしようとしましたが、成功せず。
新しいアカウントを作成することに。
JWTトークンの構造は同じですが、「id」値が異なって。
デコードされたJWTトークン：
{
“alg”: “HS256”,
“typ”: “JWT”
}.
{
“id”: 512,
“iat”: 1646219546,
“exp”: 1680433946
}.
58bkoGTGO6lnZbcO-k7v4NgQXaX5ZC-Y3-w3yxwtF8E
これは、両方のWebアプリが異なるデータベースを使用して。
データを保存していることを示していて。
これは一方が本番環境に使用され、もう一方がステージングに使用されるため正常で。
ステージングアプリからJWTトークンを使用して。
メインアプリにログインしようとすると。
「www.redacted.com」のメインWebアプリで。
アカウントID=512のユーザとしてログインして。
両方のWebアプリがデータの保存に異なるデータベースを使用している場合でも。
それらは同じコードに基づいており。
JWTトークンの署名に同じ秘密鍵を使用しているようで。
したがって、「The Bad Twin」という名前で。
アカウントの乗っ取り：
攻撃者が行う必要があるのは、「staging.redacted.com」でユーザを作成し。
JWTトークンを取得してから、それらのJWTトークンを使用して。
「id」値のユーザとして「www.redacted.com」にログインすることで。
基本的に、攻撃者は「www.redacted.com」で。
新しいアカウントが作成されていることを考慮して。
10307–512=9795個のアカウントを乗っ取る可能性があって。
Best regards, (^^ゞ
