「フリーWi-Fiで機密情報を作業していたら全部抜かれた」というケースで現実にありうる脅威を説明せよ

スタバでMacを開くエンジニア @MacopeninSUTABA

我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z

拡大

徳丸 浩 @ockeghem

これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 twitter.com/MacopeninSUTAB…

徳丸 浩 @ockeghem

答え合わせ: フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか qiita.com/ockeghem/items… #Qiita @ockeghemより twitter.com/ockeghem/statu…

徳丸 浩 @ockeghem

そういえば、FirefoxにはHTTPSオンリーモードという便利な機能がありますね。後で追記しようと思います。

np @np_nl

@ockeghem 別の方も書かれていますがルーターのdns観点はないでしょうか。dns poisoning、dns pharmingなど。 後は催眠術でユーザーを誘導する、でしょうか。

徳丸 浩 @ockeghem

@np_nl MITMの状況では、DNSサーバーは攻撃者がコントロールできますので、DNSに対する攻撃は不要です。単に設定するだけです。

np @np_nl

@ockeghem 私の理解を確認したいのですが、mitmではない状況下で、dns(ip)レベルで別サイトに誘導されてもクライアント(ブラウザ)が誘導先の443/tcpに接続してhttps接続を開始し、そのプロセスの中で偽サイトが否かの検証が行われるためなりすましは成立しない、で良いでしょうか。

徳丸 浩 @ockeghem

@np_nl はい、通常はそうなります。

np @np_nl

@ockeghem 有難うございます。

徳丸 浩 @ockeghem

バズったので宣伝。セキュリティYouTuberやっています。記事で参照した動画は、ちゃんとカフェのWi-FIでキャプチャとって、偽APと偽Captive Portalを自作して、と手間をかけてやっています。 youtube.com/@websecstudy

Norihiko Kanoh @Kuma_34

@ockeghem ちょっと大掛かりになりますが、DNS Spoofingという脅威がまず入口として一番危険かと思います。 proofpoint.com/jp/threat-refe…

USHITO Hiroyuki / kes @iso2022jp

Evil Twin は簡単に立てられるし、世の中には HSTS/HTTPS RR 非対応どころか非 TLS の HTTP サイトが大量にあるので、公衆 Wi-Fi には気を付けて…… twitter.com/ockeghem/statu…

USHITO Hiroyuki / kes @iso2022jp

Chrome で Always use secure connections をオンにするとアクセスできないサイトだらけになるんよな。

USHITO Hiroyuki / kes @iso2022jp

ローカル開発にオレオレ証明書を使っているプロジェクトがあり、そういうプロジェクトで証明書エラーを無視する習慣が付きやすい。MITM 成立させやすくなるので、この点に関しては一般ユーザーよりエンジニアの方が危ないように思える。

USHITO Hiroyuki / kes @iso2022jp

最近は http://localhost/ や http://any.localhost/ が trustworthy origin となり Secure Context 扱いになってる。なので localhost に限っては HTTP でも HTTPS 同等の Web API の開発ができるから、できる限りオレオレ証明書の廃止を進めていきたい。

德薙零己 @rtokunagi

@ockeghem Man-in-the-middleアタックの危機 通信を第三者が傍受する可能性 後ろから覗かれる そもそも自分が機密情報をベラベラと喋ってる というところを思い浮かべました。

德薙零己 @rtokunagi

@ockeghem そういえば、むかし連載していた漫画にそんなことをネタにしたなあと。 pic.twitter.com/aCU2IVhS1L

拡大

衛藤嵩史 CloudBCP @t_etor

@ockeghem WiFi環境のローカルネット間のパケットキャプチャは実演が超難しい。もう忘れちゃったけど、Wiresharkに普通に出てくるわけではない。わざわざ専用にセキュリティ緩くしたWiFiドングルとか買い集めてなんとか実演環境できたけど、、アプリでTLSしてれば普通のWiFiルータの設定ならそうそう抜かれること… twitter.com/i/web/status/1…

レフ @nico_LeftyG

@t_etor @ockeghem MacBookProであれば空間上の通信キャプチャが行えますので、専用のドングルがなくても通信の傍受は簡単に行えますよ。ただ、おっしゃるようにTLSによる暗号化が当たり前の昨今では盗聴だけではなく、トラップを仕掛けるなど、攻撃を仕掛けないと情報を抜き取るまでは難しそうですね。

衛藤嵩史 CloudBCP @t_etor

@nico_LeftyG @ockeghem そうなんですね、だいぶ前なので覚えてないですが、MBAでやった？ので苦労したのかもです。ありがとうございます。

ぼうさん / 外資IT魔法戦士 / Shumpei Kubo @_bou_3

@ockeghem @ryoukm Man in the Middle 攻撃とかですかね。

dabadaba @dabadab69892335

@ockeghem まず、通信内容については各アプリやVPNで暗号化をしているにも関わらず如何に抜くか。これは暗号化の終点が端末にない形を取るしかない。 次に端末内の情報については同一NW内から既知の脆弱性や設定不備を点くことで抜くか、Wifiアクセス時の認証サイトにてマルウェア踏ませることで突破。 他ある？

Hさぶろー @hsabu

@ockeghem 現実的にありそうなのはロックせずに離席してその間に仕込まれたかな。あとはフリーWifi利用に見せかけたログインページを仕込んでおくとか、パスワード使いまわしてたら簡単。