要約

  • RFC 10027が扱う攻撃では、利用者の認証自体は成功する。攻撃者が自分の端末で始めた要求を、利用者が別の端末から承認してしまう点が問題である。
  • 正規に発行されたQRコードやユーザーコードは、処理待ちのフローが存在することを示せる。しかし、誰が提示したか、利用者が開始したか、どのクライアントにトークンが渡るかまでは示さない。
  • Daniel FettはPieter Kasselman、Filip SkokanとRFCを共著した。三人の指針は、近接性、プロトコル選択、権限縮小、検知、失効、復旧を重ね、単独の対策を万能視しない。

テレビや会議室のディスプレーで長いパスワードを入力するのは不便である。そこで画面にQRコードを出し、手元のスマートフォンで本人確認と認可を済ませる。使い慣れた端末に認証を移す設計は合理的で、共有端末に認証情報を残さない利点もある。

だが、その利点は二つの端末が正しく対応していることを前提にする。RFC 10027は、消費端末と認可端末の間を、人がQRコードや短いコードとして運ぶ区間が未認証になりやすいと指摘する。

攻撃者は自分の端末でフローを開始し、正規サーバーが発行したコードを得る。それを「社内サポートからの再設定」「ファイル共有の確認」などの説明とともに利用者へ送る。利用者は正規サイトでログインし、MFAを終え、許可を押す。サーバーは利用者を正しく識別した。しかし、利用者の目の前にある端末と、要求を始めた端末が同じであるとは限らない。

認証の成功と認可の誤配

この事象を「MFAの突破」と呼ぶと、修復すべき箇所を誤る。MFAは利用者本人を確認する役割を果たしている。欠けているのは、その本人がどの開始端末、目的、権限受領先を承認したかという結び付きである。

RFC 10027は、攻撃者のクライアントにアクセスを認可させるCross-Device Consent Phishingと、認証済みセッションを移すコードを渡させるCross-Device Session Phishingを分ける。攻撃者が得るのはパスワードとは限らず、アクセストークン、リフレッシュトークン、利用可能なセッションの場合がある。したがって、パスワード変更だけでは復旧を証明できない。

コードが持つ証拠は限定的である。正しい形式、正規発行、未使用、短い有効期限は検証できる。それでも、提示者、利用者の期待、端末間の距離、権限範囲、受領クライアントは別の事実である。真正なデータが、偽の説明の中で使われる。

Daniel Fettが示す分離の方法

Fettは自身のサイトで、アイデンティティーとWebプロトコルの安全性を専門とするコンサルタントであり、OpenID FoundationとIETFのOAuth／OpenID Connectに取り組むと説明している。IETFの記録には発行者識別、Proof of Possession、OAuth安全性、選択的開示などのRFCが並ぶ。RFC 10027は三人の共同成果であり、Fett一人の発明でも、特定製品を彼が管理している証拠でもない。

ここで重要なのは方法論である。形式的解析は、モデルが定めたプロトコル層、攻撃者能力、安全目標の範囲で攻撃を排除できる。モデルが抽象化した実装や人の解釈まで自動的に保証するものではない。

同じ注意が「認証済み」という表現にも必要だ。誰を、どの相手に、どの取引について認証したのか。利用者本人、開始端末、要求文脈、意思、認可、トークン受領者、資源アクセスは別の項目である。正規サーバーの要求でも開始者は攻撃者かもしれない。送信者拘束トークンでも、その鍵を持つ送信者が攻撃者の端末なら目的を外す。

対策は関係を強くするが、意図そのものではない

短命・一回限り・一意なコードは再利用を難しくする。しかし対話型の攻撃者は、利用者が反応してから新しいコードを作れる。レート制限は大量攻撃を遅らせる一方、少数の標的には弱い。教育は有効だが、正規画面を使う巧妙な誘導は通常フローと見分けにくい。

BLE、NFC、UWB、同一ネットワーク、位置情報による近接確認は、遠隔のコード差し替えを難しくする。とはいえVPN、位置偽装、NAT、モバイル回線、正当な遠隔承認がある。近接性は有力なリスク信号であって、利用者の意思と同義ではない。

管理端末や信頼済みネットワークだけに開始を許せば、誰でもコードを作れる状態を避けられる。信頼には登録、アテステーション、更新、失効が必要で、侵害された管理端末はなお危険である。スコープや寿命を絞る措置は誤認可後の被害を減らす。送信者拘束はトークンの持ち出しを防ぎやすくするが、攻撃者端末が自分の鍵で使うことまでは止めない。

そのためRFCは能力に応じてプロトコルを選ぶ。対応端末では、BLEによる近接性とオリジンに結び付く認証を使うFIDOのクロスデバイス認証が優先される。サーバーから利用者へ既存チャネルがある場合はCIBAが選択肢になるが、予期しない要求への対策が要る。OAuth Device Authorization Grantは最小限の端末でも動く反面、未認証チャネルへの依存が大きい。高価値・機密・業務中枢の資源では追加対策なしに選ぶべきではない。

「許可済み」の先を結ぶ記録

Heng LuのRunning-Code Primacyを監査原則として当てはめると、画面上の宣言と運用結果を分けられる。「許可済み」は一つの状態にすぎず、どの端末がどの能力を受け取り、何に使ったかが結果である。

必要な記録は、開始クライアントの識別と状態、認可端末と方式、両画面に示した目的とスコープ、近接・端末結合の証拠、利用者判断、トークンの受領先と制約、初回利用、異常、失効、復旧を結ぶ。プライバシーのため最小化し、アクセスを制限する必要がある。それでも、緑色のチェックだけでは代用できない。

責任も制御面に沿って分ける。製品部門は利便性とリスクを比較し、ID部門はプロトコルと権限を選ぶ。端末・ネットワーク部門は信頼と近接性を管理し、不正対策部門は異常な開始と同意を検知する。資源サーバーは制約を執行し、サポートと対応部門は認可とセッションを失効させる。システムが未認証の区間を残した責任を、利用者の注意力だけに移してはならない。

結論はQRコードの禁止ではない。目に見える受け渡しを、認証済みの関係と呼ばないことである。

情報源