ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。
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）
また、偽アクセスポイント、すなわち攻撃者がカフェのWi-Fiを偽装したアクセスポイントの脅威があります。本物のアクセスポイントと同じSSIDとパスワードを設定した偽アクセスポイントは、悪魔の双子（Evil Twin）（英語版Wikipedia）と呼ばれ、利用者からは本物と区別することが非常に難しく大きな脅威となります。以下、カフェのWi-Fiに対する脅威の代表例として、偽アクセスポイントを用いて説明します（下図）。
偽アクセスポイントの場合、上図の有線LANの部分で盗聴ができるので、無線の暗号化は関係ありません。また、中間者攻撃（man-in-the-middle attack; MITM）が可能になるので、攻撃のバリエーションが広がります。
いずれの場合でも、通信路がHTTPS(TLS)で暗号化されていれば、簡単に通信内容が盗聴できるわけではありません。しかし、サイト等に脆弱性が存在する、あるいは利用者の使い方が間違っていると通信内容が漏洩する可能性があります。
HTTPSを使わずに接続した
利用サイトがHTTPSに対応していない、あるいはHTTPS対応のサイトだが利用者がHTTPで接続してしまった場合、上記の方法で通信内容はすべて盗聴されます。
今どきHTTPSを使っていないサイトは稀だと思いますが、中間者攻撃でHTTPに誘導される可能性があります。下記の動画では、某メガバンクのオンラインバンキングサイトに対して、中間者攻撃でHTTP接続して通信内容が漏洩する模様をデモしています。このサイトはHTTP通信をHTTPSにリダイレクトしていますが、これを回避する攻撃を行っています。またサイト側がTCP80番ポートを閉じていても、この攻撃は可能です。詳しくは下記の動画を参照ください。
この攻撃への対策は、下記となります。
- サイト側: HSTS(Strict-Transport-Security)（MDNの解説）の設定によりHTTPSを強制する
- 利用者側: HTTPSで接続していることを目視確認する
httpsなURLに接続したがブラウザの警告を無視する操作をした
利用者がHTTPSで接続をしていても、攻撃者がBurp SuiteのようなMITMプロキシを用いている場合は、Burp Suite側でHTTPSを一旦復号して、再暗号化するという方法で通信内容を盗聴することができます。しかし、この場合ブラウザ上でエラーとなり、利用者が強いて警告を無視する操作をしなければ通信は継続できません。先の動画でも、この様子をデモしています。
この攻撃の対策は下記となります。
- サイト側: HSTS(Strict-Transport-Security)（MDN）を設定すると証明書エラーを無視できなくなる
- 利用者側: ブラウザでの証明書エラーが表示されたら利用を停止する
動画で紹介したメガバンクでは、HSTSの設定はありませんでした。
ブラウザではなく専用アプリで利用したが、そのアプリに証明書検証を行わない脆弱性があった
ブラウザではなくスマホアプリ等でサービスを利用する場合、証明書の検証はアプリ側の責務となります。たまに、アプリ側の証明書検証が十分でなく、盗聴を許してしまう場合があります。筆者が見つけた例を下記に示します。
Android版KindleにおけるSSLサーバ証明書の検証不備の脆弱性CVE-2014-3908 | 徳丸浩の日記
対策は下記のとおりです。
- 提供側: スマホアプリ等の脆弱性診断により証明書検証を確実にする
- 利用者側: 信頼できるアプリを使う or アプリ使用時はモバイルデータ通信を利用する
サーバーにて脆弱な暗号アルゴリズムの使用を許してしまう脆弱性がある
TLS/SSLの仕様上あるいは実装上の脆弱性が発見されることがたまにあります。この代表例がPOODLE脆弱性です。詳しくは、はるぷさんの解説記事をご覧ください。
SSL v3.0の脆弱性「POODLE」ってかわいい名前だけど何？？ | BLOG - DeNA Engineering
この記事でも解説されていますが、POODLEの攻撃にはMITMが使われるので、カフェの偽アクセスポイントでの攻撃は典型的ケースと言えます。言い換えれば、MITMの危険性がない環境ではPOODLEの現実的な脅威はない、ということになりますが、POODLEの脅威のため、SSLというプロトコル自体が使用停止になりました。
対策は下記のとおりです。
- サイト側: TLS 1.2以上のみを有効にして、SSL実装（OpenSSL等）を常に最新の状態に保つ
- 利用者側: 最新のブラウザを用いる（最新のブラウザはSSLを無効化している）
CookieのSecure属性欠落
ウェブアプリケーションの脆弱性によっても、通信内容が盗聴される場合があります。その代表例がCookieのSecure属性欠落です。すなわち、Set-Cookieする際にSecure属性をつけておかないと、平文通信の際にCookieが盗聴されるというものです。
詳しくは下記のブログ記事や動画を参照ください。
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた | 徳丸浩の日記
サイト側の対策は下記となります。CookieのSecure属性欠落は脆弱性診断で頻繁に指摘されています。
- CookieにSecure属性を設定する（根本的解決策）
- HSTSを設定する（緩和策）
利用者側の対策は難しいので、以下くらいかと思います。
- 信頼できるサイトを用いる
- 公衆無線LANの利用を避ける
セッションIDの固定化(Session Fixation)攻撃
セッションIDの固定化という攻撃方法があります。詳しくは以下の記事を参照ください。
この攻撃の過程で「悪意ある人があらかじめ用意したセッションIDを、何らかの方法で利用者に送り込み」というステップが必要になります。すなわち、攻撃者が用意したCookieを利用者に送り込む必要があります。「そんなことができるのか」と思われる方が多いと思いますが、MITMだとそれができます。以下の記事や動画で解説しています。
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた | 徳丸浩の日記（再掲）
サイト側対策は下記の通りです。
- セッションIDの固定化対策として、ログイン直後にセッションIDを変更する（根本的解決策）
- Cookieの接頭辞を用いる（MDNの解説）（緩和策）
- HSTSを設定する（緩和策）
一方、セッションIDの固定化脆弱性を一般の利用者が見破ることは困難なので、利用者側の対策としては以下くらいではないかと思います。
- 信頼できるサイトを用いる
- 公衆無線LANの利用を避ける
セッションIDの固定化脆弱性は最近珍しくはありますが、脆弱性診断ではたまに指摘されています。
ファイル共有を有効化していた
Windowsにはネットワークプロファイルという機能があり、パブリックあるいはプライベートに設定することができます。公衆無線LANの場合はパブリックにする必要があります。まちがってプライベートに設定している場合ですが、以下の脅威があります。
公共の場で無線LANを利用するときに、このファイル共有機能が有効になっていると、他人からパソコンやスマートフォン内のファイルが読み取られたり、ウイルスなどの不正なファイルを送りこまれたりすることがあります。公共の場で無線LANを利用する際には、必ずファイル共有機能を解除しましょう。
無線LANの安全な利用｜基本的な対策｜一般利用者の対策｜国民のための情報セキュリティサイト より引用
ウイルス感染自体は公衆無線LANを使ってなくても可能性のあることですが、偽アクセスポイントに接続することで、感染するウイルスの可能性が増えます。その典型例がWannaCryです。WannaCryはtcp/445ポートに対する攻撃により感染するので、ファイアウォールで守られたネットワークでは通常感染はしませんが、偽アクセスポイントに接続し、ネットワークプロファイルをプライベートに設定していると、感染の可能性が増えます。
下記の動画では、偽アクセスポイントの利用を想定して、WannaCryが悪用するWindowsの脆弱性 MS17-010の攻撃と、パソコンからのファイル共有経由での漏洩をデモしています。
利用者側対策は下記となります。
- 公衆無線LANに接続する場合はネットワークプロファイルをパブリックに設定する
- ソフトウェアを最新の状態に保つ
また、この種の攻撃はVPNでは防御できない場合が多いです（ノートンセキュアVPNにて検証）。VPNを使っている場合でも上記対策は怠らないようにしましょう。
ショルダーハッキング
ショルダーハッキングというのは、端末を操作している近くの人が画面やキーボード操作を覗き見するという意味で、その際に「肩越しに覗く」イメージからショルダーハッキングと命名されていますが、当然ながら覗き見は肩越しとは限りません。
参考: ソーシャルエンジニアリングの対策｜社員・職員全般の情報セキュリティ対策｜企業・組織の対策｜国民のための情報セキュリティサイト
対策は、下記となります。
- のぞき見防止フィルターの使用
- 周囲に人がいる場合はパスワードやクレジットカード情報の入力を避ける
ショルダーハッキングは、元ツイートの「スタバのFreeWi-Fiを使いながら」という点は関係ないので、題意に沿っているかは微妙なところです。
離席中の攻撃
カフェ等では、パソコンを自席に置いたまま離席する人がたまにいます。確かにカフェでのトイレというのは結構悩ましい問題でして、貴重品やパソコンは持っていくにしても、飲み物は放置してよいのか、でも飲み物をトイレに持ち込みたくないという深刻な(?)問題があり、気の弱い私などは「カフェではトイレを我慢する」という、あまり健康にはよろしくない（かもしれない）対応をしています。
さて、パソコンを置いたまま離席すると、当然ながらパソコンを盗まれる可能性がありますし、その際に画面を開いたままですと、簡単にログイン中のサイトやパソコンの中のファイルを盗み見されます。また、パソコンを盗まれないまでも、離席中のパソコンにキーロガーその他のマルウェアを仕込まれるという可能性もあります…ただ、怪しいことこの上ないので、むしろパソコンごと盗む方が手っ取り早いとは思います。
この種の攻撃も、「スタバのFreeWi-Fiを使いながら」という点は関係ないので、題意に沿っているかは微妙です。
対策としては、当然下記となります。
- カフェなどではパソコンを放置したまま離席しない
ではどうすればよいか
働き方改革が進んだ結果、カフェ等のオープンスペースで仕事をすることは推奨されているようでもありますし、Appleシリコン搭載のMacBookがむやみに電池のもちがよいので、カフェでも使いたいというのは当然の心理かと思います。しかし、上記のような脅威もありますので、以下に注意しつつ利用するのがよいかと思います。
- HTTPS接続していることを目視確認する
- サイト利用時はブラウザに予め登録したブックマークを用いる
- TLS証明書のエラーを無視しない
- ソフトウェアを常に最新に保つ
- Windowsの場合、ネットワークプロファイルをパブリックに設定する
- カフェ等では機密性の高いサイトは利用しない
- 信頼できる（脆弱性対策されているであろう）サイトを用いる
- テザリング等、別の通信手段を用いる
- 覗き見防止フィルターを用いる
- カフェなどではパスワードやクレジットカード番号の入力を避ける
- パソコン等を自席に放置したまま離席しない
Comments
フリーWifiを使う際の注意点として、VPN接続を利用するのはいかがでしょうか。私はトレンドマイクロのVPN機能を愛用してます。（ちょっと通信速度が遅くなりますが）
https://ykk333.hatenablog.com/entry/2019/08/26/234153
こちらの記事はサーチエンジンで上位の方に出てくるSecure属性に関する記事です。検証結果を見ると、CookieのSecure属性を付与するだけだと根本的解決に至らないのでは…？と思い質問しました。
記事内に
「Apacheの設定(検証にはApacheを使用)が間違っているのかとかなり当惑したが 調べたところ、secure属性があると http通信のときは Cookieをブラウザに保存しないという挙動になるらしい」と記載があったため上記の根本的解決にならないのではという疑問が浮かびました。
私自身の家にパソコンが無く、実際に検証できる訳では無いのですがセキュリティの勉強中なので気になってしまいコメントさせていただきました。
めちゃくちゃ暇な時に返信頂けると嬉しいです。
@charter さん
コメントありがとうございます。はい、VPNは有力です。今回の記事はVPNに頼らない場合を中心に書かせていただきました。また、「VPNでは守れない」場合も書きました。
大手のVPNサービスを使う分には問題ないと思いますが、中には怪しいサービスもありますので、そこだけご注意いただければと思います。
@MiuraKazuma さん
コメントありがとうございます。参照先の記事は間違っていますね。このような記事がGoogleの検索上位にヒットするのは困ったものだと思います。
Secure属性つきのCookieがHTTP通信の場合ブラウザに保存されないのは事実では、これは安全性確保のための意図的な仕様です。なぜなら、HTTP通信の場合、改ざんされているかもしれないからです。
ユーザーはまずHTTPSでアクセスする必要があります。これはユーザー側の責務です。そして、ブラウザ側で証明書エラーにならない場合、通信は改ざんされてないと保証されます。大前提としてこれをやらないと意味がありませんし、そのことは今回の記事に書いた通りです。
この状態でセットしたCookieですが、Secure属性がないとHTTP通信の場合でもサーバーに送信されてしまい、そこで盗聴される可能性があります。これを防ぐのがSecure属性の効果です。
記事、勉強になりました。
こういうときにフリーWifiだからと、テクノロジーに目が行きやすいですけど、そもそもオープンな場所で機密情報を扱うという危険性も見ないといけませんよね。
証明書でありがちなのが、社内のシステムで自己証明書を使っていると、無視することが癖づいていたり、ブラウザ設定をゆるくしていることもあるので、そこをつかれることもありそうですね。
関連して、よい機会なので質問させてください。レストランなど不特定多数の人が使うアクセスポイントでは、しばしば非常に強度の弱いパスフレーズ（例えば、施設の名前そのまま）が用いられています。こうしたアクセスポイントを見る度に「こんなことするくらいならいっそ暗号化しない方がいいのでは？」と疑問に感じていたのですが、この疑念は正しいのでしょうか？
いっそ暗号化しない方がいいのでは、という疑問はその通りだと思いますが、その理由はちょっと違っています。パスワードが単純だからまずいのではなく、パスワードをいくら複雑にしていても、それが公開されているので意味がないのです。詳しくは本文で紹介している以下の記事を参照してください。
https://xtech.nikkei.com/it/atcl/column/17/090600370/091100008/
HTTP接続した際にフィッシングサイトにリダイレクトさせ、ユーザーの誤認により認証情報などを窃取するという攻撃手法も取れそうですね。
Httpsであることの確認を目視に頼るのは、見落としや思い込みなどの影響を受けやすいためあまり望ましい対策とは言えないのではないでしょうか。
Firefoxにはhttps-onlyモードという機能があり、http接続を自動的にhttpsにアップグレードしたり失敗した場合は警告を表示したりしてくれますが、このような機能を使用するのが良いのではないかと思っています。
Lichさん。はい、Firefoxのhttps-onlyモードはよいですね。
偽APとか使わなくても、ARPスプーフィングで行けたり
あまりフリー使わない方がいいですね！
@kuniyonkunisan ありがとうございました。採用させていただきます。
おそらく令和６年の西暦が間違っています by kuniyonkunisan 2024/01/04 00:05
@hydrohue2037 ご指摘ありがとうございます。採用させていただきます。
"WikiPedia" を "Wikipedia" に修正 by hydrohue2037 2023/05/08 23:52
参考になりありがとうございます。
確かに「境界外ネットワークに端末が接続したときにどういうリスクがあるか」を考えるのは、セキュリティだけでなくDX・働き方改革を進める上でも良い題材ですね。
現時点では社内NWではそのまま接続、社外ではVPNを強制するという使い方の企業が多いのかなと思います。進んだ会社では条件付きアクセスで社外からはMFA必須にするという感じでしょうか。
さらにセキュアな端末にするには、データレスPCやユーザーアフィニティがない共有PCにして、必要な場合のみVDI接続させるという形がありますが、現時点ではセキュリティやDX投資に積極的な一部先進企業のみという印象です。
上記のようなエンドポイント対策に加えて、CASBソリューションも今後一般化していくのではないかと注目しています。
Let's comment your feelings that are more than good