【Uber事件】そのログイン、本当に自分のもの？認証とセッションの落とし穴。

自分のスマホに届いた通知を、自分の指で承認した。それなのに、なぜ別の場所にいる攻撃者のパソコンが社内システムに入れたのでしょうか。 2022年のUber事件を入り口に、パソコンから始まったログインを、認証サーバーがどうやってスマホの返答と結びつけるのかを図解します。何度も通知を送る「MFA疲労攻撃」、画面に出た番号を照合する方法、圏外でも認証アプリが6桁のコードを作れる理由を順にたどります。 後半のテーマは、誤って承認した後のこと。攻撃者のブラウザーに渡った「入館証」は、パスワードを変えるだけで回収できるのでしょうか。Cookie、セッションの失効、アクセストークンの有効期限の違いから考えます。 事件の経緯とUberの対応は同社の公表に基づいています。番号照合・TOTP・セッション管理の図は、各方式を説明するための一般例です。 【主な出典】 Uber「Security update」 https://www.uber.com/us/en/newsroom/security-update/ Cisco Duo「Duo Auth API」 https://duo.com/docs/authapi Microsoft Learn「How number matching works」 https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match IETF RFC 6238「TOTP」 https://www.rfc-editor.org/rfc/rfc6238.html NIST SP 800-63B-4「Authenticators」 https://pages.nist.gov/800-63-4/sp800-63b/authenticators/ OWASP「Session Management Cheat Sheet」 https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html Microsoft Learn「Revoke user access」 https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access

• #二要素認証
• #Uber