フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか

ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ <a href="https://t.co/e26L1Bj32Z">pic.twitter.com/e26L1Bj32Z</a></p>&mdash; スタバでMacを開くエンジニア (@MacopeninSUTABA) <a href="https://twitter.com/MacopeninSUTABA/status/1652315366373363712?ref_src=twsrc%5Etfw">April 29, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
これに対して、私は以下のようにツイートしましたが、

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 <a href="https://t.co/LH21zphCTV">https://t.co/LH21zphCTV</a></p>&mdash; 徳丸 浩 (@ockeghem) <a href="https://twitter.com/ockeghem/status/1652673176852381696?ref_src=twsrc%5Etfw">April 30, 2023</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
こちらも124.1万件の表示ということで、非常に注目されました。多くの反応を頂きましたが、意外に難問ということのようで、ゴールデンウィーク明けにいくつか漏洩経路を紹介したいと思います。

## 2024/1/3 18:20 追記、1/4 10:40編集
令和6年能登半島地震に際して無料のWiFi 00000JAPAN が携帯各社から提供されたことに関連して、フリーWi-Fiの危険性に言及する目的でこの記事が読まれているようです。この記事ではフリーWi-Fiの危険性の「可能性」について技術的な観点から解説していますが、フリーWi-Fiだけが特別危険というわけではありません。そもそも、HTTPSはフリーWi-Fi向けに開発されたものではなく、インターネット自体が盗聴・改ざんその他のリスクが元々あるために導入されたものです。
フリーWi-Fiを含めインターネットを安全に使うためには、HTTPSを提供者・利用者の双方が正しく使う必要があります。HTTPSの正しい使い方はこの記事全体で説明していますが、利用者側の要点をまとめると以下のとおりです。またこの記事ではVPNの使用は推奨していませんし、VPNでは防げない脅威についても説明しています。繰り返しますが、以下はフリーWi-Fiで**なくても**必要な対応です。

- 重要度の高いサイトはブラウザのブックマークからアクセスする
- HTTPS接続されていることを目視確認する
- 証明書のエラーが表示されたら利用をやめる

（追記終わり）

## 無線LANに対する攻撃
やはり「スタバのFreeWi-FIを使いながら」という前提ですので、無線LANの脅威から説明します。一般に無線LANの脅威というと、「暗号化されていない無線LAN」を思い浮かべる方も多いと思いますが、フリーWi-Fiの多くは「暗号化されていても盗聴される」問題があります。それは、無線LANのパスワード（事前共有鍵、パスフレーズ）が公開されているためです。以下の記事が参考になります。

[パスワードが公開された公衆無線LAN、暗号化されていても盗聴できる？ | 日経クロステック（xTECH）](https://xtech.nikkei.com/it/atcl/column/17/090600370/091100008/)

また、偽アクセスポイント、すなわち攻撃者がカフェのWi-Fiを偽装したアクセスポイントの脅威があります。本物のアクセスポイントと同じSSIDとパスワードを設定した偽アクセスポイントは、悪魔の双子（Evil Twin）（[英語版Wikipedia](https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks))）と呼ばれ、利用者からは本物と区別することが非常に難しく大きな脅威となります。以下、カフェのWi-Fiに対する脅威の代表例として、偽アクセスポイントを用いて説明します（下図）。
![pseud-ap-003.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22718/5fc4eb95-a918-0ca8-9f12-a93da46c956f.png)
偽アクセスポイントの場合、上図の有線LANの部分で盗聴ができるので、無線の暗号化は関係ありません。また、中間者攻撃（man-in-the-middle attack; MITM）が可能になるので、攻撃のバリエーションが広がります。

いずれの場合でも、通信路がHTTPS(TLS)で暗号化されていれば、簡単に通信内容が盗聴できるわけではありません。しかし、サイト等に脆弱性が存在する、あるいは利用者の使い方が間違っていると通信内容が漏洩する可能性があります。

## HTTPSを使わずに接続した

利用サイトがHTTPSに対応していない、あるいはHTTPS対応のサイトだが利用者がHTTPで接続してしまった場合、上記の方法で通信内容はすべて盗聴されます。
今どきHTTPSを使っていないサイトは稀だと思いますが、中間者攻撃でHTTPに誘導される可能性があります。下記の動画では、某メガバンクのオンラインバンキングサイトに対して、中間者攻撃でHTTP接続して通信内容が漏洩する模様をデモしています。このサイトはHTTP通信をHTTPSにリダイレクトしていますが、これを回避する攻撃を行っています。またサイト側がTCP80番ポートを閉じていても、この攻撃は可能です。詳しくは下記の動画を参照ください。

<iframe width="560" height="315" src="https://www.youtube.com/embed/k0xBCjWPqcU" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

この攻撃への対策は、下記となります。

- サイト側: HSTS(Strict-Transport-Security)（[MDNの解説](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security)）の設定によりHTTPSを強制する
- 利用者側: HTTPSで接続していることを目視確認する

## httpsなURLに接続したがブラウザの警告を無視する操作をした

利用者がHTTPSで接続をしていても、攻撃者がBurp SuiteのようなMITMプロキシを用いている場合は、Burp Suite側でHTTPSを一旦復号して、再暗号化するという方法で通信内容を盗聴することができます。しかし、この場合ブラウザ上でエラーとなり、利用者が強いて警告を無視する操作をしなければ通信は継続できません。先の動画でも、この様子をデモしています。

この攻撃の対策は下記となります。

- サイト側: HSTS(Strict-Transport-Security)（[MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security)）を設定すると証明書エラーを無視できなくなる
- 利用者側: ブラウザでの証明書エラーが表示されたら利用を停止する

動画で紹介したメガバンクでは、HSTSの設定はありませんでした。

![mitm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/22718/f5043773-94f8-a558-1ccd-3417347d77b7.png)

## ブラウザではなく専用アプリで利用したが、そのアプリに証明書検証を行わない脆弱性があった
ブラウザではなくスマホアプリ等でサービスを利用する場合、証明書の検証はアプリ側の責務となります。たまに、アプリ側の証明書検証が十分でなく、盗聴を許してしまう場合があります。筆者が見つけた例を下記に示します。

[Android版KindleにおけるSSLサーバ証明書の検証不備の脆弱性CVE-2014-3908 | 徳丸浩の日記](https://blog.tokumaru.org/2014/09/androidkindlesslcve-2014-3908.html)

対策は下記のとおりです。

- 提供側: スマホアプリ等の脆弱性診断により証明書検証を確実にする
- 利用者側: 信頼できるアプリを使う or アプリ使用時はモバイルデータ通信を利用する

## サーバーにて脆弱な暗号アルゴリズムの使用を許してしまう脆弱性がある
TLS/SSLの仕様上あるいは実装上の脆弱性が発見されることがたまにあります。この代表例がPOODLE脆弱性です。詳しくは、はるぷさんの解説記事をご覧ください。

[SSL v3.0の脆弱性「POODLE」ってかわいい名前だけど何？？ | BLOG - DeNA Engineering](https://engineering.dena.com/blog/2014/10/poodle/)

この記事でも解説されていますが、POODLEの攻撃にはMITMが使われるので、カフェの偽アクセスポイントでの攻撃は典型的ケースと言えます。言い換えれば、MITMの危険性がない環境ではPOODLEの現実的な脅威はない、ということになりますが、POODLEの脅威のため、SSLというプロトコル自体が使用停止になりました。
対策は下記のとおりです。

- サイト側: TLS 1.2以上のみを有効にして、SSL実装（OpenSSL等）を常に最新の状態に保つ
- 利用者側: 最新のブラウザを用いる（最新のブラウザはSSLを無効化している）

## CookieのSecure属性欠落
ウェブアプリケーションの脆弱性によっても、通信内容が盗聴される場合があります。その代表例がCookieのSecure属性欠落です。すなわち、Set-Cookieする際にSecure属性をつけておかないと、平文通信の際にCookieが盗聴されるというものです。
詳しくは下記のブログ記事や動画を参照ください。

[HTTPSを使ってもCookieの改変は防げないことを実験で試してみた | 徳丸浩の日記](https://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-on-ssl.html)

<iframe width="560" height="315" src="https://www.youtube.com/embed/yXNOJE9kGK8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

サイト側の対策は下記となります。CookieのSecure属性欠落は脆弱性診断で頻繁に指摘されています。

- CookieにSecure属性を設定する（根本的解決策）
- HSTSを設定する（緩和策）

利用者側の対策は難しいので、以下くらいかと思います。

- 信頼できるサイトを用いる
- 公衆無線LANの利用を避ける

## セッションIDの固定化(Session Fixation)攻撃
セッションIDの固定化という攻撃方法があります。詳しくは以下の記事を参照ください。

- [安全なウェブサイトの作り方 - 1.4 セッション管理の不備 | 情報セキュリティ | IPA](https://www.ipa.go.jp/security/vuln/websecurity/session-management.html)
- [とくまるひろしのSession Fixation攻撃入門 | 徳丸浩の日記](https://blog.tokumaru.org/2009/01/introduction-to-session-fixation-attack.html)

この攻撃の過程で「悪意ある人があらかじめ用意したセッションIDを、何らかの方法で利用者に送り込み」というステップが必要になります。すなわち、攻撃者が用意したCookieを利用者に送り込む必要があります。「そんなことができるのか」と思われる方が多いと思いますが、MITMだとそれができます。以下の記事や動画で解説しています。

[HTTPSを使ってもCookieの改変は防げないことを実験で試してみた | 徳丸浩の日記](https://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-on-ssl.html)（再掲）

<iframe width="560" height="315" src="https://www.youtube.com/embed/GP1eEit1quY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

サイト側対策は下記の通りです。

- セッションIDの固定化対策として、ログイン直後にセッションIDを変更する（根本的解決策）
- Cookieの接頭辞を用いる（[MDNの解説](https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies)）（緩和策）
- HSTSを設定する（緩和策）

一方、セッションIDの固定化脆弱性を一般の利用者が見破ることは困難なので、利用者側の対策としては以下くらいではないかと思います。

- 信頼できるサイトを用いる
- 公衆無線LANの利用を避ける

セッションIDの固定化脆弱性は最近珍しくはありますが、脆弱性診断ではたまに指摘されています。

## ファイル共有を有効化していた
Windowsには[ネットワークプロファイル](https://support.microsoft.com/ja-jp/windows/windows-10-%E3%81%A7-wi-fi-%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%92%E5%85%AC%E8%A1%86%E3%81%BE%E3%81%9F%E3%81%AF%E3%83%97%E3%83%A9%E3%82%A4%E3%83%99%E3%83%BC%E3%83%88%E3%81%AB%E3%81%99%E3%82%8B-0460117d-8d3e-a7ac-f003-7a0da607448d)という機能があり、パブリックあるいはプライベートに設定することができます。公衆無線LANの場合はパブリックにする必要があります。まちがってプライベートに設定している場合ですが、以下の脅威があります。

> 公共の場で無線LANを利用するときに、このファイル共有機能が有効になっていると、他人からパソコンやスマートフォン内のファイルが読み取られたり、ウイルスなどの不正なファイルを送りこまれたりすることがあります。公共の場で無線LANを利用する際には、必ずファイル共有機能を解除しましょう。
> [無線LANの安全な利用｜基本的な対策｜一般利用者の対策｜国民のための情報セキュリティサイト](https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/enduser/security01/07.html) より引用

ウイルス感染自体は公衆無線LANを使ってなくても可能性のあることですが、偽アクセスポイントに接続することで、感染するウイルスの可能性が増えます。その典型例がWannaCryです。WannaCryはtcp/445ポートに対する攻撃により感染するので、ファイアウォールで守られたネットワークでは通常感染はしませんが、偽アクセスポイントに接続し、ネットワークプロファイルをプライベートに設定していると、感染の可能性が増えます。
下記の動画では、偽アクセスポイントの利用を想定して、WannaCryが悪用するWindowsの脆弱性 MS17-010の攻撃と、パソコンからのファイル共有経由での漏洩をデモしています。

<iframe width="560" height="315" src="https://www.youtube.com/embed/qMbB9DUkz-k" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

利用者側対策は下記となります。

- 公衆無線LANに接続する場合はネットワークプロファイルをパブリックに設定する
- ソフトウェアを最新の状態に保つ

また、この種の攻撃はVPNでは防御できない場合が多いです（ノートンセキュアVPNにて検証）。VPNを使っている場合でも上記対策は怠らないようにしましょう。

## ショルダーハッキング
ショルダーハッキングというのは、端末を操作している近くの人が画面やキーボード操作を覗き見するという意味で、その際に「肩越しに覗く」イメージからショルダーハッキングと命名されていますが、当然ながら覗き見は肩越しとは限りません。

参考: [ソーシャルエンジニアリングの対策｜社員・職員全般の情報セキュリティ対策｜企業・組織の対策｜国民のための情報セキュリティサイト](https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/business/staff/12.html)

対策は、下記となります。

- のぞき見防止フィルターの使用
- 周囲に人がいる場合はパスワードやクレジットカード情報の入力を避ける

ショルダーハッキングは、元ツイートの「スタバのFreeWi-Fiを使いながら」という点は関係ないので、題意に沿っているかは微妙なところです。

## 離席中の攻撃
カフェ等では、パソコンを自席に置いたまま離席する人がたまにいます。確かにカフェでのトイレというのは結構悩ましい問題でして、貴重品やパソコンは持っていくにしても、飲み物は放置してよいのか、でも飲み物をトイレに持ち込みたくないという深刻な(?)問題があり、気の弱い私などは「カフェではトイレを我慢する」という、あまり健康にはよろしくない（かもしれない）対応をしています。
さて、パソコンを置いたまま離席すると、当然ながらパソコンを盗まれる可能性がありますし、その際に画面を開いたままですと、簡単にログイン中のサイトやパソコンの中のファイルを盗み見されます。また、パソコンを盗まれないまでも、離席中のパソコンにキーロガーその他のマルウェアを仕込まれるという可能性もあります…ただ、怪しいことこの上ないので、むしろパソコンごと盗む方が手っ取り早いとは思います。
この種の攻撃も、「スタバのFreeWi-Fiを使いながら」という点は関係ないので、題意に沿っているかは微妙です。

対策としては、当然下記となります。

- カフェなどではパソコンを放置したまま離席しない

## ではどうすればよいか
働き方改革が進んだ結果、カフェ等のオープンスペースで仕事をすることは推奨されているようでもありますし、Appleシリコン搭載のMacBookがむやみに電池のもちがよいので、カフェでも使いたいというのは当然の心理かと思います。しかし、上記のような脅威もありますので、以下に注意しつつ利用するのがよいかと思います。

- HTTPS接続していることを目視確認する
- サイト利用時はブラウザに予め登録したブックマークを用いる
- TLS証明書のエラーを無視しない
- ソフトウェアを常に最新に保つ
- Windowsの場合、ネットワークプロファイルをパブリックに設定する
- カフェ等では機密性の高いサイトは利用しない
- 信頼できる（脆弱性対策されているであろう）サイトを用いる
- テザリング等、別の通信手段を用いる
- 覗き見防止フィルターを用いる
- カフェなどではパスワードやクレジットカード番号の入力を避ける
- パソコン等を自席に放置したまま離席しない