平成31年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問2｜ホテルのWi-Fiが認証情報を奪った——情報処理安全確保支援士で学ぶ偽AP・フィッシングとパスワードレス認証の事例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 平成31年度 春期 情報処理安全確保支援士試験 午後1 問2
• 主なテーマ: 偽アクセスポイント（Evil Twin）、DNS偽装、サーバ証明書とHSTS、多要素認証とOTP/TOTPの限界、FIDO/WebAuthnによるパスワードレス認証、公開鍵暗号とディジタル署名、オリジン検証によるフィッシング耐性

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

出張先のホテルで、何気なく宿泊客用のWi-Fiにつなぐ。多くの人が当たり前にやっている行動です。ところが、そのありふれた一手が、会社のメールアカウントを丸ごと奪われる入口になることがあります。情報処理安全確保支援士の午後1で出題されたこの事例は、海外拠点を持つ商社を舞台に、偽のアクセスポイントから始まる認証情報の窃取と、それを根本から防ぐ認証基盤の作り直しを正面から扱っています。

パスワードは、長く認証の主役でした。しかし、攻撃の手口が「パスワードを盗む」から「パスワードを盗んだあとに本物のサイトへ中継する」へと進化したいま、パスワードだけ、あるいはパスワードに一度きりの数字を足しただけの認証では守りきれない場面が増えています。このセキュリティインシデント事例は、その限界をはっきりと描き出します。

この記事を読むと、攻撃者がどうやって「正規サイトになりすます」連鎖を組み立てるのか、なぜ証明書のエラーが出ずに偽サイトへ誘導されてしまったのか、そしてワンタイムパスワードでも防げないフィッシングがあるのはなぜか、最後になぜパスワードレス認証（FIDO/WebAuthn）だけがその攻撃を止められるのかが見えてきます。受験者には認証分野の頻出論点が詰まっており、システムの導入を判断する立場の経営者・管理職には「ルールの周知だけでは守れない」「認証基盤への投資こそが本質的対策になる」ことを理解する教材になります。

インシデントの概要

舞台は、東京に本社を置く従業員1,000名の商社、U社です。U社は複数の海外拠点を設けて海外向けに営業を展開しており、海外拠点の従業員数は1拠点あたり十数名と小規模でした。

情報システムの管理体制は、本社と海外拠点で分かれていました。本社の情報システムは本社の情報システム部が管理し、各海外拠点の情報システムは現地の情報システム担当者が管理します。電子メールの送受信も二本立てで、本社はオンプレミス環境（自社内に設置・運用するサーバ環境）を導入していましたが、海外拠点ではP社が提供するクラウドサービス型のWebメールサービス（以下、メールサービスP）を使っていました。海外拠点では、全従業員に会社からスマートフォンとノートPCが貸与されていました。

平穏に見えたこの体制に、ある日、ほころびが現れます。海外拠点Qの従業員Sさんのメールアドレスを送信者とする、不審なメール。それが、一連のインシデントの最初の兆候でした。

何が起きたのか

1月10日、本社の情報システム部に一本の連絡が入ります。「Sさんから来たはずのメールが、どうもおかしい」。連絡してきたのは、ふだんからSさんとやり取りのある本社従業員でした。送信者は確かに海外拠点QのSさんのメールアドレス。しかし内容が不審だというのです。

調査を担当したのは、情報処理安全確保支援士（登録セキスペ）であるTさんでした。Tさんがまず手をつけたのは、当該メールのヘッダ情報（メールの配送経路や送信元などが記録された見えない情報）の確認です。すると、そのメールはまぎれもなくメールサービスPから送信されたものでした。なりすましの単純な偽装ではなく、Sさんのアカウントそのものが使われている可能性が浮かび上がります。

海外拠点Qの情報システム担当者Yさんに確認を依頼すると、嫌な事実が返ってきました。1月10日に、Sさんのアカウントから送られたと考えられる不審なメールの送信履歴が、複数残っているというのです。アカウントの乗っ取りはほぼ確実でした。Tさんはすぐさま、Yさんにメールサービス上のSさんのアカウントを一時的に無効化するよう依頼します。被害の拡大を止める初動です。

幸い、会社が貸与していたSさんのスマートフォンとノートPC、そしてSさんのメールボックスには、重要情報は含まれていませんでした。さらにTさんは、被害がSさん一人にとどまるのかを見極めるため、海外拠点Q全従業員のアカウントについて、メールサービスPに残っていた全送信履歴をYさんに確認してもらいます。結果、不審な送信履歴はSさんのアカウント以外には見当たりませんでした。被害は局所的でしたが、では、なぜSさんだけが狙われ、どうやってアカウントは奪われたのか。Tさんの調査は、ここから核心へ向かいます。

調べていくと、1月10日のSさんの状況が浮かび上がってきました。その日、SさんはアジアのZ国に出張中で、宿泊先のホテルの宿泊客用無線LAN（以下、ホテルWi-Fi）を使っていたのです。

ここに、二つの落とし穴がありました。一つ目は、U社には「会社から貸与されたノートPCを、U社以外の無線LANに接続してはならない」というルールがあったにもかかわらず、Sさんがそのルールを知らなかったこと。二つ目は、ホテルWi-FiのSSID（無線LANを識別する名前）が宿泊客で共通であり、そのSSIDと事前共有鍵（接続に必要な合言葉のような鍵）が、ロビーなどの共有スペースに堂々と張り出されていたことです。つまり、その鍵は誰でも知ることができました。

Sさんのノートパソコン（以下、PC-S）は、IPアドレスとDNSサーバ（ドメイン名をIPアドレスに変換する電話帳のようなサーバ）の情報を、DHCP（接続時にこれらの設定を自動で配る仕組み）で自動取得する設定になっていました。Sさんはその日、メールサービスPを使うために、Webブラウザのアドレスバーにサービスのアドレス（FQDN。サーバを特定する正式なドメイン名）を自分で手入力し、表示されたログインページに利用者IDとパスワードを入力しました。手入力という、むしろ慎重な行動です。にもかかわらず、Sさんのアカウントは奪われた。

決定的な手がかりは、二つありました。一つは、メールサービスPの監査ログ（誰がいつどこからログインしたかの記録）です。不審メールが送られていた時間帯のログインは、出張先のZ国だけでなく、Sさんが行ってもいない南米のW国のIPアドレスからのものでした。もう一つは、Sさんの証言です。SさんがメールサービスPにアクセスしたとき、「サーバ証明書が信頼できない」というエラーは、Webブラウザに一切表示されなかったというのです。

本来、偽のサイトにHTTPS（通信を暗号化する仕組み）で接続すれば、証明書の検証に失敗してブラウザが警告を出すはずです。それが出なかった。Tさんはここに着目し、メールサービスPの仕様を調べます。メールサービスPはHTTP over TLS、すなわちHTTPSでサービスを提供しており、暗号化されていないHTTPでアクセスした場合はHTTPSのURLにリダイレクト（自動的に転送）される仕様でした。しかし、HSTS（HTTP Strict Transport Security。ブラウザに対して「このサイトには常に最初からHTTPSで接続せよ」と指示する仕組み）は実装されていませんでした。この一点が、証明書エラーが出なかった謎を解く鍵になります。

ここまでの調査から、Tさんは攻撃者の手口（事例では「手口G」と呼ばれます）を次のように推測しました。攻撃者は、無線LANアクセスポイント、DNSサーバ、Webサーバの三つを自前で用意していました。攻撃者のDNSサーバには、メールサービスPのFQDNを、攻撃者が用意したWebサーバのIPアドレスに結びつけるAレコード（ドメイン名とIPアドレスの対応を記した設定）が仕込まれていました。

そして、攻撃者の無線LANアクセスポイントには、ホテルWi-Fiとまったく同じSSIDと事前共有鍵が設定されていたと考えられます。SSIDも鍵も共有スペースに張り出されているのですから、攻撃者がそれを真似た「偽の双子」を用意するのは容易でした。Sさんのパソコンは、ホテルWi-Fiにつなごうとして、見分けのつかない攻撃者の偽アクセスポイントにつないでしまったのです。

接続した瞬間、PC-SにはDHCPを通じて攻撃者のDNSサーバの情報が設定されます。これで、Sさんがアドレスバーに正しいFQDNを手入力しても、その名前解決（ドメイン名からIPアドレスを引く処理）は攻撃者のDNSサーバが答えるようになりました。返ってくるのは、攻撃者のWebサーバのアドレス。Sさんは「メールサービスPにアクセスしているつもり」で、実際には攻撃者のWebサーバの偽ログインページを見ていたのです。

最後の落とし穴が、証明書エラーの不在でした。HSTSが実装されていないため、Sさんのブラウザは最初の接続をHTTPで始めます。攻撃者のWebサーバはそのHTTP接続にそのまま応答すればよく、HTTPSへの切り替え（=サーバ証明書の検証）が走りません。だから「信頼できない証明書」の警告は出なかった。もしHSTSが実装されていれば、ブラウザは最初からHTTPSで接続しようとし、偽サーバの不正な証明書を検出して警告を出していたはずでした。

警告が出ないことに安心したSさんは、偽サイトに利用者IDとパスワードを入力してしまいます。攻撃者は、こうして盗んだ認証情報を使ってメールサービスPに不正アクセスし、Sさんになりすましてメールを送信していたのです。偽アクセスポイント、偽DNS、偽Webサーバ——三つの偽物が連鎖し、HSTS未実装という穴がそれを後押しした。Tさんはこの全容を情報システム部長に報告します。

部長の指示は二つでした。一つは、貸与ノートPCをU社以外の無線LANに接続してはならないというルールの全社周知。もう一つが、より本質的な対策——メールサービスPの認証方式そのものの強化でした。