🔰ハッカーは「通信の途中」を狙っている🔯ミカと教授のサイバーセキュリテイ🖥️第12回

中間者攻撃――「通信の途中に誰かが座っていたらどうなるのか」

ミカ「教授、ここまでずっと『ハッカーはどこから入るのか』を勉強してきました」
教授「入力欄、パスワード、Cookie、サーバー、マルウェア……いろいろ出てきたな」
ミカ「今日は中間者攻撃ですか。今度はどこから入るのです？」
教授「入らないこともある」
ミカ「またですか」
教授「今日は通信している二人の間に座る」
ミカ「私と教授の間に？」
教授「そうだ。ミカが私に『明日の授業は休みですか』と送ったとする」
ミカ「教授は『休みです』と返信する」
教授「ところが途中に攻撃者がいて、私の返事を『授業はあります。レポートも提出してください』と書き換えたら？」
ミカ「その攻撃者だけは絶対に許しません」
教授「セキュリティよりレポートのほうが怖いらしいな」

これは何を狙う攻撃なのか

ミカ「中間者攻撃とは、その名のとおり通信の真ん中へ入る攻撃ですか」
教授「そうだ。英語ではMan-in-the-Middle Attack、MITMと呼ばれる」
ミカ「何を盗むのです？」
教授「通信内容を盗み見る場合もあれば、内容を書き換える場合もある。さらに、利用者とサーバーの双方に対して相手本人であるかのように振る舞う場合もある」
ミカ「私は銀行と通信しているつもり」
教授「銀行もミカと通信しているつもり」
ミカ「しかし実際には？」
教授「ミカ → 攻撃者 → 銀行」
ミカ「攻撃者が通訳みたいに真ん中にいる」
教授「ただし信用してはいけない通訳だ」
ミカ「勝手に翻訳も書き換える？」
教授「『10万円送金』を『100万円送金』にするような通訳なら、すぐ解雇したい」

なぜ成立するのか

ミカ「でもインターネットの通信は、相手へ直接届くのではないのですか」
教授「インターネットでは、通信はさまざまな機器やネットワークを経由して届く」
ミカ「ルーターやWi-Fiアクセスポイントなどですね」
教授「そうだ。そして攻撃者が、通信経路の一部を支配したり、利用者を偽の通信経路へ誘導したりすると、中間に入り込む余地が生まれる」
ミカ「例えば？」
教授「代表的なイメージは、偽のWi-Fiアクセスポイントだ」
ミカ「ホテルで『Hotel_Free_WiFi』という名前が見えたら？」
教授「本物とは限らない」
ミカ「名前だけなら誰でも付けられますね」
教授「攻撃者が本物そっくりのWi-Fiを用意し、利用者がそこへ接続すれば、通信が攻撃者の管理する機器を経由する可能性がある」
ミカ「無料Wi-Fiだと思って入ったら、有料なのは通信料ではなく個人情報だった」
教授「今日はミカのほうが冴えているな」

身近な例に置き換える

ミカ「今回も現実世界で例えてください」
教授「郵便で考えよう」
ミカ「手紙ですね」
教授「ミカが銀行へ『住所変更をお願いします』という手紙を出す」
ミカ「郵便局が届けます」
教授「ところが途中に悪い郵便配達員がいて、封筒を開ける」
ミカ「読まれます」
教授「内容をコピーする」
ミカ「情報漏えい」
教授「さらに住所を書き換える」
ミカ「改ざん」
教授「そして新しい封筒へ入れて銀行に届ける」
ミカ「銀行は私から届いたと思ってしまう」
教授「その一連の行為が中間者攻撃のイメージだ」
ミカ「では対策は？」
教授「手紙の内容を、本人と銀行にしか読めない方法で暗号化する」
ミカ「途中の配達員が封筒を開けても意味不明」
教授「さらに、『本当に銀行へ送っているのか』を確認する仕組みも必要だ」
ミカ「暗号化だけでなく、相手の身元確認ですね」
教授「そこが重要だ」

HTTPSは何を守っているのか

ミカ「そこでHTTPSですね」
教授「そうだ。ブラウザでWebサイトへ接続するとき、HTTPSではTLSという仕組みを使って通信を暗号化する」
ミカ「鍵マークが出るやつですね」
教授「現在のブラウザでは表示方法は変わってきているが、重要なのは通信が暗号化され、接続先の正当性を証明書によって確認する仕組みがあることだ」
ミカ「つまり途中で通信を見られても？」
教授「適切にTLSが使われていれば、通信内容を簡単には読めない」
ミカ「書き換えるのも難しくなる」
教授「そうだ」
ミカ「ではHTTPSなら絶対安全？」
教授「そこまで言ってはいけない」
ミカ「また教授の『絶対はない』ですね」
教授「HTTPSは通信路を守る重要な仕組みだ。しかし、利用者自身が偽サイトへアクセスしていたら？」
ミカ「あ……」
教授「偽サイト自身がHTTPSを使っていることもある」
ミカ「鍵マークがあるから本物、とは限らない」
教授「そのとおり。暗号化されていることと、相手が信用できることは同じではない」

公衆Wi-Fiで何が怖いのか

ミカ「カフェやホテルのWi-Fiでは、何に注意すればよいですか」
教授「まず、接続先の名前だけで判断しないことだ」
ミカ「『Free_WiFi』が三つ並んでいたら？」
教授「私はコーヒーだけ飲んで帰りたくなる」
ミカ「仕事になりません」
教授「本当に利用するなら、施設が案内している正式なSSIDを確認する」
ミカ「重要なサービスへログインする場合は？」
教授「HTTPSを確認し、可能なら信頼できるモバイル回線や自分のテザリングを使う方法もある」
ミカ「VPNは？」
教授「信頼できるVPNを適切に使えば、公衆Wi-FiからVPNサーバーまでの通信を暗号化できる。ただし『VPNという名前が付いていれば何でも安全』ではない」
ミカ「無料VPNを片っ端から入れるのは？」
教授「鍵を守るために、知らない人へ玄関の鍵を預けるようなことになりかねない」
ミカ「無料という言葉が、また危険になってきました」

中間者攻撃で何が盗まれるのか

ミカ「成立すると何が起きるのですか」
教授「暗号化されていない通信であれば、通信内容を盗み見られる可能性がある」
ミカ「ユーザー名やパスワードも？」
教授「通信方法によっては対象になり得る」
ミカ「Cookieも？」
教授「適切に保護されていないCookieなら、セッション乗っ取りにつながる可能性もある」
ミカ「第7回のセッションハイジャックにつながりました」
教授「そうだ」
ミカ「ほかには？」
教授「通信の改ざんもある。利用者がダウンロードしようとしているファイルを別のものに差し替える、表示内容を書き換える、といった危険も考えられる」
ミカ「私はAを頼んだのに途中でBになる」
教授「中間者が荷物を開けて入れ替えるようなものだ」

「暗号化されていないHTTP」が危険な理由

ミカ「昔はHTTPのサイトも多かったですね」
教授「今でも残っていることはある」
ミカ「HTTPだと？」
教授「通信内容が暗号化されないため、通信経路上から内容を読み取られたり改ざんされたりするリスクが高くなる」
ミカ「だからWebサイトはHTTPSにする」
教授「そうだ。特にログイン情報や個人情報を扱うサイトでHTTPというのは論外に近い」
ミカ「会社のホームページでも？」
教授「問い合わせフォームがあるなら当然重要だ。さらに現在はサイト全体をHTTPSにするのが基本的な考え方だ」
ミカ「トップページは秘密情報がないからHTTPでもいい？」
教授「通信改ざんという観点から考えても、そう単純ではない」
ミカ「Webサイト全部を安全な通信へ」
教授「そう考えたほうが分かりやすい」

証明書の警告を無視してはいけない

ミカ「ブラウザで『この接続ではプライバシーが保護されません』みたいな警告が出ることがあります」
教授「重要な警告だ」
ミカ「『詳細設定』から無理やり進めることもできますが」
教授「なぜ警告が出ているか分からない状態で、重要なサービスへ進むべきではない」
ミカ「でも会議の5分前です」
教授「攻撃者は会議時間を考慮してくれない」
ミカ「教授より厳しい」
教授「証明書のエラーは、設定ミスの場合もあれば、接続先の確認に問題がある場合もある。少なくともパスワードやカード情報を入力する前に立ち止まるべきだ」
ミカ「セキュリティシリーズで何度も出てきますね」
教授「急いでいるときほど止まる」
ミカ「仕事術の記事にもなりそうです」

安全な範囲で仕組みを確認する

ミカ「今回も攻撃方法を試さず、仕組みだけ確認しましょう」
教授「黒板に三人を書く」
ミカ「左にミカ」
教授「右に銀行サーバー」
ミカ「真ん中に教授」
教授「なぜ私が攻撃者なんだ」
ミカ「説明役なので」
教授「仕方ない。正常な通信なら、ミカと銀行が安全な暗号化通信を行う」
ミカ「攻撃者が途中に入ろうとする」
教授「しかしTLSが正しく機能し、証明書も正しく検証されれば、攻撃者が銀行になりすますのは難しくなる」
ミカ「証明書の確認を無視したら？」
教授「防御を自分で弱くすることになる」
ミカ「つまりブラウザの警告にも意味がある」
教授「ブラウザは時々うるさいが、理由があってうるさい」
ミカ「会社の上司にも同じことが言えますか」
教授「それは情報セキュリティの範囲外だ」

プログラマーはどう防ぐか

ミカ「開発者側の対策をお願いします」
教授「まず、通信をHTTPSにする」
ミカ「TLSですね」
教授「古い暗号方式や安全性の低い設定を使わず、適切なTLS設定を維持する」
ミカ「証明書は？」
教授「有効な証明書を使い、期限切れを防ぐ」
ミカ「プログラムから外部APIへ接続するときも？」
教授「証明書の検証を無効化してはいけない」
ミカ「開発中によくある『証明書エラーが邪魔だから検証をOFF』は？」
教授「開発時の一時的措置が、本番環境へ残ると危険だ」
ミカ「エラーを消したらセキュリティまで消えた」
教授「以前も似た授業をした気がするな」
ミカ「セキュリティ機能をOFFにすると、エラーは減るけれど事故が増える」
教授「名言として黒板に書いておこう」

HSTSとは何か

ミカ「ほかにWeb側の防御はありますか」
教授「HSTSという仕組みもある」
ミカ「また略語ですか」
教授「HTTP Strict Transport Security。ブラウザに対して、『このサイトとはHTTPSだけで通信してください』と伝える仕組みだ」
ミカ「利用者が間違えてHTTPでアクセスしても？」
教授「適切に設定されていれば、ブラウザがHTTPS利用を強制する方向に働く」
ミカ「SSL strippingのように、暗号化されない通信へ誘導される攻撃への対策にもなる？」
教授「そういう目的で重要だ」
ミカ「Web開発者は、HTMLとCSSだけでは済みませんね」
教授「Webサイトは見た目だけ作れば完成、という時代ではない」

DNSも信用の一部

ミカ「URLを正しく入力しても、別の場所へ連れて行かれることはありますか」
教授「DNSが攻撃されれば、その可能性を考えなければならない」
ミカ「インターネットの住所録ですね」
教授「そうだ。ただしHTTPSでは、接続先の証明書を検証することで、DNSだけを書き換えられても簡単になりすませないようにする仕組みがある」
ミカ「いくつもの防御が重なっている」
教授「DNS、TLS、証明書、ブラウザ、認証。セキュリティは一つの仕組みに依存しない」
ミカ「また多層防御」
教授「最小権限君に続いて、多層防御君もレギュラー入りだ」

プログラマーが覚えておきたい基本

ミカ「今回もまとめてください」
教授「七つにしよう」
・Webサービスは原則としてHTTPSを使用する
・TLSを適切に設定し、安全性の低い古い方式を使わない
・証明書の検証を無効化しない
・証明書の有効期限や設定を継続的に管理する
・HSTSなどを利用し、HTTPS利用を徹底する
・CookieにはSecureなど適切な属性を設定する
・重要な通信では相手の正当性と通信経路の両方を確認する
ミカ「今回のキーワードは『暗号化』ですね」
教授「それだけでは足りない」
ミカ「相手の確認も必要」
教授「そうだ。秘密に話すことと、正しい相手に話していることの両方が必要だ」

経営者・利用者はどう防ぐか

ミカ「利用者は？」
教授「重要なサービスへアクセスするときは、URLを確認する。証明書警告を安易に無視しない。公衆Wi-Fiでは特に慎重にする」
ミカ「モバイル回線やテザリングも活用する」
教授「そうだ」
ミカ「会社では？」
教授「社内Wi-Fiを適切に管理し、来客用ネットワークと業務用ネットワークを分離する」
ミカ「社員が勝手にアクセスポイントを設置したら？」
教授「シャドーITの問題にもなる」
ミカ「会社のWi-Fiパスワードを受付に大きく貼るのは？」
教授「来客用ならまだしも、業務ネットワークのものなら考え直してほしい」
ミカ「『Wi-Fi: company1234』とホワイトボードに？」
教授「ハッカーより先に掃除業者が覚えるだろう」

「社内LANだから安全」ではない

ミカ「社内の通信なら安心では？」
教授「以前のSSRFでも似たことを言ったな」
ミカ「『内部だから信用するな』」
教授「そのとおり。社内ネットワークへ一台でも侵害された端末が入れば、内部通信を狙われる可能性を考える必要がある」
ミカ「だからWi-Fiの認証、端末管理、ネットワーク分離なども必要」
教授「そうだ」
ミカ「会社の中だから全部平文でもいい、ではない」
教授「重要な通信は内部でも暗号化する方向が望ましい」
ミカ「ゼロトラストにつながりますね」
教授「『場所ではなく、相手と通信を確認する』という考え方だ」

中間者攻撃が教えること

ミカ「今日のテーマは、今までとは少し違いますね」
教授「どう違う？」
ミカ「攻撃者がサーバーそのものに侵入しなくてもいい」
教授「そうだ」
ミカ「利用者のパソコンにも必ずしも侵入しない」
教授「その間を狙う」
ミカ「つまり、両方が安全でも通信路が危険なら問題が起きる」
教授「それが中間者攻撃の重要な視点だ」
ミカ「家と銀行が頑丈でも、現金輸送車を途中で奪われたら意味がない」
教授「非常に分かりやすい」
ミカ「セキュリティは点ではなく線まで守る」
教授「今日一番のまとめだ」

ミカと教授の一言で締める

ミカ「教授、中間者攻撃を一言で説明してください」
教授「二人だけで通信しているつもりの間に第三者が入り、通信を盗み見たり書き換えたりする攻撃だ」
ミカ「防御の基本は？」
教授「通信を暗号化する」
ミカ「それだけ？」
教授「相手が本物か確認する」
ミカ「つまり？」
教授「秘密の会話をするだけでなく、話している相手の顔も確認しなさい」
ミカ「では教授、今チャットしている相手が本当に教授か確認します」
教授「どうする？」
ミカ「今日のレポート提出期限は？」
教授「明日だ」
ミカ「本物ですね」
教授「そんな認証方法をシステムに実装するなよ」

次回予告

第13回　DDoS攻撃――「侵入しなくても、店の入口を客で埋めれば営業は止められる」

ミカ「今度は情報を盗まないのですか」
教授「盗まなくても会社は困らせられる」
ミカ「どうするのです？」
教授「大勢で入口へ押しかける」
ミカ「サイバー攻撃というよりバーゲンセールですね」
教授「違いは、誰も買い物をする気がないことだ」