【魚拓】二要素認証はもはや安全ではない、GmailやOutlookなどEメールに関する新たな警告（Forbes JAPAN） - Yahoo!ニュース
上記の記事は過剰に不安をあおっているなぁと感じた。こういうのがyahooニュースに出てしまう現実。
大本の記事は以下のようだ。
ただどちらも事実はちゃんと書かれている。ここは同意
- フィッシング攻撃を行うためのキットが安価に出回っているため参入障壁は下がっている
- 2FAはフィッシングを迂回できる（※2FAはフィッシング対策のための認証手法ではないので当然な話です）
- 罠サイトには注意しましょう
ただやっぱり不安を煽りすぎだし、結局自社製品の宣伝をしているのでそういうことな気がする。（あと多分、御社の製品じゃフィッシング攻撃は防げないんじゃないですかね…どういう方法かは知らないですが、それができるならブラウザの標準機能にしますって…）
そもそも2FAはフィッシング攻撃を防ぐ目的の認証手法ではないですからね。（では何の目的があるか？考えてみてください！）
パスキー(≒FIDO2)が対策になるといっているのは、「オリジンとフィッシングサイトの区別」ができる点を含むためだからでしょう。逆に言えばオリジンとフィッシングサイトの区別ができないなら確かに2FAだろうがMFAだろうがパスキーだろうが突破できる攻撃パターンもある。DNSスプーフィングとTLS証明書のなりすましのたった2つの攻撃ができれば、オリジンに完全に成り済ませるため、こういった攻撃をされてはどうしようもありません。ほら「パスキーも突破された！！Webの崩壊！！！！」という記事を書いてくれてもいいんですよ。
しかし通常、これらができることは今どきは現実的ではありません。攻撃を成立させるための準備がまず大変です。言うは易し行うは難しです。実際の窃盗事件でもあまりにも用意周到すぎたら感嘆し面白おかしく脚色され映画化される。それぐらいの攻撃であり、そこまでされたらお手上げなのです。
フィッシング攻撃というのは、正規のドメインに成り済ませない時点で幼稚なレベルなものなんですが、他の攻撃と比べると準備のしやすく（Webサービスを公開するだけだから）、その割に人間なら騙せる確率があるから、流行っているわけです。
ユーザができる対応
そんなわけでフィッシングサイトに勝ちたい貴方のために。その方法を授けましょう。
ユーザができる現実的な対応は以下でしょう。
- パスワードマネージャでパスワードを管理する
- 目的: オリジンとフィッシングサイトの区別できる仕組みを持っているため、フィッシングサイトに耐性がある
- 目的: より強度の高いパスワードを現実的な負荷で使うため
- 同じパスワードを使わない
- 目的: 流出時の芋づる式に攻撃されないようにするため
- パスワードマネージャで自動生成させるだけでよく、現実的な負荷で運用できる
- 2段階認証(2FA)・多要素認証(MFA)を行う
- 目的: パスワード流出しても攻撃を受けないようにするため
- アプリ認証(Google Authenticator, Microsoft Authenticator等)があればそれで
- https://datatracker.ietf.org/doc/html/rfc6238というデファクトスタンダードと呼べる実装があり各サービスはこれを採用していることが多いため、1個入れれば様々なサービスで使えます
- 残念ながら自前のモバイルアプリをインストールさせるものもありますが…（例:Steam）
- 次点でメール認証があればそれで
- SMS認証は後述する理由でいまいちなんですが、提供されている仕組みが他にないなら使ってください。（サービス提供側はそれを理由に、あなたは充分な対策をしていなかったと言い訳する可能性さえあります。）
- よくあるのは「合言葉」や「秘密の質問」ですが、これらは記憶に頼るので、2FA, MFAとしては不適切ではあります。サービス提供側が残念です
これだけやっておけば充分です。フィッシングに勝つだけが目的なら1だけなんですが、他も行うとより安全なのでやってください。
後はネットリテラシーの問題です。変なWi-Fiを使わない。変なURLを踏まない、むやみに入力しないようにしましょう。URLで誘導してくる系はだいぶ怪しいと疑うのがいいです。フィッシング攻撃の大変なところは罠サイトにどうやって踏ませるかも1つなので。
パスキー(≒FIDO2)も使えるなら使っていきましょう。上記を全部自動的に満たしてくれるので強固です。サービス側が提供できていない、物理的な窃盗があったら不安とか、紛失時のリスクとか、まだプラクティスが定まっていない感がありますが（私が知らないだけだと思います）
次から次へと色々出てきて面倒だな、と思われますが、より良い方法は後から出てくるものですから仕方がありません。
あとはユーザ登録で上記の対応の障壁になるサービスは 使わない というのも手です。ググれば出る、AIに聞けば実装が出てくる今の時代、これぐらいのこともできないのは挨拶ができないのと一緒です。
（サービス提供側の話も書こうと思ったけど面倒になったので、徳丸本を読んだりNIST SP 800-63を見たり、OpenID Connectを採用して認証の大変な部分をIdPに任せたりしていい感じにやってください）
以降はおまけ。攻撃手法の話。
おまけ:攻撃手法
攻撃手法色々あるようだけど、結局どういうのがあり、どれだけ現実的なの？という話。
雑に言えば、めちゃくちゃたくさんあるし、視点を変えればどれも現実的。だけど、1個成功させるだけではあまり意味がないことが多く、攻撃を組み合わせるのが一般的です。また一言で「～攻撃」といっても奥深いものです。
もちろんクリティカルヒットで1発KOな攻撃もありますが、こういうのは影響度が大きくつまりマジでヤバいので防衛策が練られています。色々めんどくさいなーというのは防衛策を1個1個やってるからだと思っても良いかもしれません。
攻撃を知ると、防衛策の必要性を実感できたり、意識できなかったところが意識できるようになります。攻撃、知ろう！（提案）
DNSスプーフィング
めちゃくちゃ雑に言えば、正規のDNSサーバよりも先に不正な応答を流し込み、正規ドメインになりすます方法である。そのためには同じネットワークに参加しなくてはならない。これがそもそも難易度が高い（後述するMITMもこの攻撃を成立させるための一環でもある）
DNSSECが普及すれば、TLSの攻略を含めなくてはならなくなり難易度があげられることができるが、残念ながらまだまだ現実的ではない。
DNS系は他の攻撃もある。DNSキャッシュポイズニングや、ドメインテイクオーバーなど。DNSは今のインターネットの根本的な存在なので、ここの脆弱性は結構インパクトが大きい。あとDNSサーバを運用している人が悪意を持ったら簡単にできる。
TLS証明書のなりすまし
なりすませるのは以下のいずれか。もしくは相当する何か。
どれもやられると今のWebの安全性を根底から覆るレベルなので、現実的ではない。
特に3つ目の「正規のCA証明書で不正なサーバ証明書を発行」は事例もあり、このために強制的に証明書を失効させる仕組み(CRL:証明書失効リスト)がある。
逆を言えば、これらができるとTLSは突破できるので、どう仕込むかが手腕を問われる。（でもクライアント側に仕込めるならキーロガー仕込んだほうが速いという話もありけり）
MITM
MITMは様々なレイヤで行えるが、とにかく通信を傍受するために「中継器を置く」ことで始める。
- L1レベル: 物理線に流れる信号を傍受（光ファイバかRJ45ケーブルの間に中継器を置く）
- L2-L4レベル: パケットを傍受（ルータとハブの間に中継器を置く、中継器をWI-FIのAPとして振舞わせて利用させる）
- L7レベル: HTTPSのリクエストを傍受’（プロキシサーバに成りすます、詐欺サイトに流す）
L2-L4は例えば「WiFiを無料で使えますー」とさせて使わせれば簡単にできる。信用できないSSIDを選んで接続しないようにしましょうね。ただ傍受できても通信はTLS暗号化されてることが多くほとんど中身が読めないので、そこはどうにかする必要がある。（上記のTLS証明書のなりすましを参考）
L7レベルは通常はHTTPプロキシを経由させる仕込みが必要であり、そもそもそれができるならキーロガーでも仕込むだろう。（試すだけならBurp suiteで体験しましょう）
めちゃくちゃ雑なMITMは詐欺サイトに誘導する方法。いわゆる（低レベルな）フィッシングサイトで、適当なドメインで、リクエストを全部記録しながらオリジンに横流しし、レスポンスを全部記録しながらクライアントに横流しするだけのもの。凄いお粗末。
しかし、これは他の手法と比べ攻撃のしやすさは段違いである。Webに公開して、URLを踏ませて、正規オリジンのリクエストとレスポンスを傍受するだけでよい。他の攻撃手法と違って正規の手順でWebにサービスを公開するのとまったく同じなので簡単なのだ。あとはメールでもSMSでもゲーム内チャットでもSteamチャットでもSlackでもDiscordでもSNSでも2chの掲示板でもURLを張って獲物がかかるのを待つだけでよい。そして不安を煽る、配達持ち帰りを装う等をして成功率を高めようとしてくる。
SMSを狙った攻撃
SMSは盗聴や、SIMスワッピング（所有者を偽って電話番号を別のSIMに割り当てる）に脆弱であるという話があったので追記。実際その通りです。
Microsoftでも「https://jpazureid.github.io/blog/azure-active-directory/it-s-time-to-hang-up-on-phone-transports-for-authentication/」という記事を出しており、具体的な脅威は想像しやすいでしょう。
また、SMSを含む認証機に対する脅威について、 https://pages.nist.gov/800-63-3/sp800-63b.html#81-authenticator-threats が詳しくかかれており、特に「Endpoint Compromise」はSMSにおける脅威としても記載されています。
ということで、2FA,MFAとしてのSMS認証もあまりよくないということがわかりました。
でも設定しないよりはマシです。それしか提供してないサービスもあるので、その場合は設定してください。
その他いろいろ
攻撃はいっぱいある。
アプリの脆弱性をつくというのも手である。例えばCGIの脆弱性で外部HTTPリクエストヘッダにPROXY: xxxとすると HTTP_PROXYを環境変数に仕込むせいで、CGIアプリケーション内でHTTP通信を発生させるとライブラリによっては任意のプロキシを経由させ通信を傍受できる攻撃があった。リクエストを盗み見てAPIキーを奪ったり、レスポンスを改ざんして振る舞いを変えたりといったことが容易にできることになる。2FAとかに使えるんか？というとさっぱりわかりません。脆弱性は見つかってからが本番でそれを創意工夫で悪いことに使うわけですな。ちなみにこれが発見され修正されたのは比較的最近だったりする(2016年あたり)。というのも、環境変数 HTTP_PROXYがあればプロキシを使うように設定するHTTPライブラリというのは今ではよくある設定なのだが、CGI最盛期はそもそも外部とHTTPでデータ連携なんかすることはない規模のWebアプリが普通だったし、そもそもHTTPヘッダを大文字にしてHTTP_をつけて環境変数に設定するなんていうCGIの仕様をHTTPライブラリは知る由もないから、攻撃につながるとは思わなかったのだろう。現在ではCGI自体あまり使われなくなったのでもう気にすることもないですが、こういう食べ合わせの悪さや失敗などを経験し、プラクティスを学び、今どきのWebアプリは強固になっていっている（気がします）。
ソーシャルエンジニアリングは特に幅広いですね。物理的に盗み見る（ショルダーハッキングとか）はわかりやすいですね。通勤電車でConfidentialなパワポを開いてるおじさんたち。お元気ですか？脆弱ですよ？ 他にも電磁波を傍受して映っているものを類推するとか、なんならその会社に攻撃をするために営業を装うとか正攻法で潜り込むとか物理的な攻撃を含めていろいろあります。いっぱいあります。悪いことはたくさんありますしできちゃいます。
後はいつだって人間が一番脆弱。気を引き締めてやっていきましょう。
