https://pushsecurity.com/blog/
いつものセキュリティホールmemoさんの記事で気になったので
◆悪用成立シナリオをAIに訊いてみた◆
RFC 8628で定義されている OAuth 2.0 Device Authorization Grant（デバイスフロー） において、
この攻撃の核心は、「正規のログイン手順の中に、
悪用の操作手順
- 攻撃者によるコード取得攻撃者は自分のデバイスから認証サーバーへリクエストを送り、*
*ユーザーコード（例: ABC-123）**を取得します。 - 被害者へのフィッシング（誘導）攻撃者は「セキュリティ確認のため」や「特典の受け取り」
などの口実を使い、被害者に以下の2点を伝えます。 - 正規の認証用URL（例:
google.com/device）にアクセスすること - 攻撃者が取得したユーザーコードを入力すること
- 被害者による承認被害者は、URL自体が本物であるため安心してアクセスし、
指示されたコードを入力します。その後、自分のID/ パスワードでログインし、「デバイス（実際は攻撃者のもの） のアクセスを許可しますか？」という画面で「はい」 を押してしまいます。 - 攻撃者によるトークン奪取被害者が承認した瞬間、攻撃者のデバイスがポーリング（待機）
していた認証サーバーからアクセストークンが発行されます。 これにより、攻撃者は被害者のパスワードを知ることなく、 アカウントへアクセス可能になります。
なぜこれが成り立つのか？
このフローでは、**「コードを入力している人間（被害者）」と
ポイント:攻撃の成功には、被害者に「偽のサイト」ではなく、**「本物のサイトに、攻撃者のコードを入力させる」** というソーシャルエンジニアリング（騙しのテクニック） が不可欠です。
なお、各種アプリのすべての機能を使用するには、Gemini アプリ アクティビティを有効にする必要があります。
No comments:
Post a Comment