【投稿者コメント】(追記に付き再掲載)
【キーワード】
[多要素認証でも危険]､[顔指紋認証PIN安全]､[偽メール偽URL注意]
【件名】
｢Office365のアカウントを多要素認証すら回避して乗っ取るAiTMフィッシング攻撃が1万以上の組織を標的にしていたとMicrosoftが公表／｢多要素認証(電話､SMS､認証アプリ等)｣では安心出来ない／｢FIDO2セキュリティキー｣や｢証明書ベースの認証｣や｢Windows Hello for Business｣なら安心／とにかく｢偽メールの添付ファイルや偽URLのクリック厳禁！｣を遵守せよ｣
【投稿本文】
【１】ログイン画面で､｢多要素認証(電話､SMS､認証アプリ等)｣で､正規サイトと端末ユーザの間で､別経路(別の通信手段)で認証すれば､必ず安全とは言い切れない！
通常､スマホやPCのログイン画面の｢多要素認証(電話､SMS､認証アプリ等)｣は､正規サイトと端末ユーザの間で､別経路(別の通信手段)でやり取りされる｡
ゆえに､多くの方は､スマホ等へのSMSへ送信されるセキュリティコードをキーインしたり､認証アプリで認証さえすれば､安全にパスワードが入力出来て､ログイン認証出来てしまうと思われるだろう｡
ところが､下記の【以下転載】の報告に示す如く､上記の様に､端末ユーザが正規サイトからの｢多要素認証｣に応答しても､攻撃者は正しいID/Passwordに加えて､認証成功の状態を保持したセッションCookieまで､入手出来てしまい､この盗んだセッションCookieを使って､ログイン画面に不正侵入出来てしまう｡(添付図５及び添付図６参照)
一般に､このセッションCookieを盗んで攻撃する手口･手法を｢Pass-The-Cookie｣攻撃と云い､その具体的な手法が｢AiTM(Adversary in The Middle)フィッシング｣だ｡(添付図４～添付図６参照)
【２】ログイン画面の､｢多要素認証(電話､SMS､認証アプリ等)｣を無効にする｢AiTM(Adversary in The Middle)フィッシング｣攻撃とは？
この｢AiTM(Adversary in The Middle)フィッシング｣の具体的手順は次の通りだ｡
①まず､添付図４の様な､フィッシング偽メールに記載した偽URLをクリックさせて､偽装サイトの｢フィッシングサイト｣へ誘導する｡(添付図４及び添付図５参照)
②端末ユーザが偽サイトに気づかずに､ユーザIDやパスワードや｢多要素認証｣を入力すると､これらの機密情報が格納された｢セッションCookie｣が横取りされてしまう｡(添付図５及び添付図６参照)
③攻撃者は､正規のユーザIDやパスワードや｢多要素認証｣データを知らずとも､この盗んだ｢セッションCookie｣を使って､ログイン正規登録者として､ログイン画面に侵入出来てしまう｡(添付図６参照)
【３】ログイン画面の､｢多要素認証｣を無効にする｢AiTMフィッシング｣攻撃を防御する方法は？／｢偽メールの添付ファイルや偽URLのクリック厳禁！｣を遵守せよ！
それじゃ､正規端末ユーザと正規サーバの中間に介在して､｢セッションCookie｣を盗んで攻撃する｢AiTMフィッシング｣から防御出来る､他の｢認証方法｣はないのかと云うと､
次の端末ユーザ自身の固有情報(生体固有情報)や端末固有情報を使う認証方式なら､｢AiTMフィッシング｣攻撃から回避出来る｡(添付図７参照)
・｢FIDO2セキュリティキー｣：
→(例)Windows11の｢設定／アカウント／サインインオプション／セキュリティキー｣等
・｢証明書ベースの認証｣
→(例)証明書ベースの認証を使用したOffice365のログイン画面等
・｢Windows Hello for Business｣
→(例)Windows11の｢設定／アカウント／サインインオプション｣の｢顔認証｣や｢指紋認証｣や｢PIN｣等
ここで､なじみのある認証方式は､｢顔認証｣や｢指紋認証｣や｢PIN｣等だろう！
いくら､通信経路上に｢フィッシングサイト｣を設けて､｢セッションCookie｣を横取りしたところで､｢顔認証｣や｢指紋認証｣や｢PIN｣は､｢セッションCookie｣へは格納されずに､処理の都度､直接､正規ユーザの端末情報(PIN)や正規ユーザ固有情報(顔､指紋情報)と照合するから､攻撃者の端末情報や攻撃者の固有情報とは一致しないから､不正侵入出来ない！
◇
それじゃ､使用するログイン画面の認証方式が､上記の安全な認証方式の｢FIDO2セキュリティキー｣や｢証明書ベースの認証｣や｢Windows Hello for Business｣を採用していない場合はどうすべきか？
この｢AiTMフィッシング｣攻撃を成立させない為には､偽URL等をクリックして､偽サイトの｢フィッシングサイト｣へ誘導されなければよい！
従って､従来からの有効な安全対策である､｢偽メールの添付ファイルや偽URLのクリック厳禁！｣を遵守すればよい！
これらの偽メールに記載された偽URLの偽サイトは､httpsの鍵マーク付きだから､URL欄の鍵マークは信用出来ない！
さらに､偽メールの偽URLや偽サイトのURL欄のURLアドレスのドメインは詐称しているから､ドメインが正規のものか否かで､真偽が判定出来るが､煩雑ゆえ､とにかく､メールのURLや添付ファイルはクリックしないに限る！
毎日､多量に到来する不審メール､偽メールは､無視して､即､削除するに限る！
ログイン画面には､必ず､お気に入り等へ記録･登録した正規のURLから入り､SNSやブログやメール等に記載されたURLをクリックしてアクセスしてはならない！
最近､糞Microsoftが性悪ChatGPTを盛んに喧伝しているから､海外の攻撃者に依る､性悪ChatGPTを悪用した､精緻な日本語偽メール攻撃が増えるから､とにかく､身に覚えのない､不審メールは､問答無用で､即､削除だ！
【追 記 １】(2023年3月20日)
『ネット銀行システムのログイン認証方式は､｢AiTMフィッシング｣攻撃の危険性にさらされているから､即､｢ネット銀行システム｣を使用した｢振り込み処理｣は停止すべきだ！／IT機器と外部サーバーとの通信状況は常に監視すべし！』
当方が､iPhone_13_Proを初めて使い出したのは､つい1年前の2022年2月だ！
なぜ､スマホ導入にためらっていた､逡巡していたのかと云うと､現在､ログイン画面の｢多要素認証｣の主流を占める､｢電話､SMS､認証アプリ等に依る認証方式｣を破る､今回報告した｢AiTMフィッシング｣攻撃等を懸念していたので､スマホに依る｢金銭処理｣や｢ネット決済｣や｢ネット銀行システム｣等は､論外と思っていたからだ！
世の中に未だ､カーナビやGPSやスマホが無い時期から､モバイルシステム開発の先鞭を付けた頃から､モバイルシステムの脆弱性は､十分に承知していたから､デスクトップPCの使用に留めており､PCでも､金銭処理やネット決済やネット銀行システム等は､一切､使用せずに､キャッシュカード処理と銀行窓口処理の｢アナログ処理｣に限定している！
アナログ処理に限定しておれば､キャッシュ･ディスペンサー･システム＝銀行オンラインシステムや銀行支店を乗っ取らない限り､攻撃は不可能だからだ！
◇◇◇
<<ITリスク回避は､アナログ限定に限る！→糞共が手が出せない！>>
併せて､
<<スマホ､タブレット､PCは､未使用時に電源OFFとすべし→攻撃の機会を与えない！>>
※不正Scriptで遠隔起動を図っても､WiFi／モバイル回線を切って､バッテリを外して､電源プラグを外す｢アナログ対処｣には無効だ！
→IT機器は､未使用時はWiFiをOFF(電源プラグを抜く)にすればよい！
→通信機能を使わぬ時は､WiFiを｢機内モード｣にしてOFFにすれば､糞Microsoftや糞GoogleにPC個人情報を抜かれる･窃盗されるのも防げる！
スマホ､タブレット､PCを24時間､365日､電源ONにしたままの方もいると云うが､それじゃ､夜間就寝時や外出時に､誰がIT機器への不正侵入や攻撃を監視･察知･防御すると云うのか？！
防御万全のウィルス対策ソフトやセキュリティ機能等は有り得ないのに､なぜ？！
IT機器が電源ONなら､IT機器と外部との通信状況を監視･察知･不正防御しない事には､安心して使えないだろうに？！
<<怪しい通信は､成りすましでも､異常な通信は､片っ端から､即､ぶち切る！に限る！>>
<<WiFiも含めて､つないだIT機器は､じぇーんぶ(ALL)！>>
<<成りすましも含めて､リソース消費モニターの正当性を監査した上で､異常なリソース消費を表示するタスク･プロセスも､即､停止させる！>>
◇◇◇
現時点で､都銀や地銀や信金等のネット銀行システムのログイン認証方式が､｢AiTMフィッシング｣攻撃に耐性がある､｢FIDO2セキュリティキー｣や｢証明書ベースの認証｣や｢Windows Hello for Business｣方式へ変更になったとは承知していない！
ゆえに､現在は､ネット銀行システムのログイン認証方式は､｢AiTMフィッシング｣攻撃の危険性にさらされている！
こう云うお寒い､危険な状況でも､平然と､ネット銀行システムを使用して､振り込み処理や決済処理をされている方の気が知れない？！
少なくとも､即刻､ネット銀行システムを使用した､振り込み処理だけでも､即､止めるべきと思うが？・・・
敢えて､大きなリスクを冒(おか)して､｢ネット銀行システム｣を使用した､｢振り込み処理｣等を行う意味･理由が判らない？！
【追 記 ２】(2023年3月20日)
『｢銀行オンラインシステム｣等の｢国の基幹システム｣に対するサイバーテロ対策は万全なのか？／全ての銀行が一斉に不正引き出し攻撃を受けて､預金残高総額がゼロになれば｢銀行崩壊･経済崩壊→日本滅亡｣だ！』
最近､某都銀を含めて､多くの銀行は､人件費･支店維持費削減の為に､大掛かりな支店の統廃合を進めて､預金顧客へ､ネット銀行システムへの移行を迫っている！
こう云う状況を踏まえると､正規社員の銀行員以外の､不特定多数の預金者やその成りすまし共が､ミッションクリティカル(業務に致命的な影響のある重要業務要素･システム)な重要､かつ､危険な､基幹システムの｢銀行オンラインシステム｣へアクセスさせる事自体が穏当な､常識的な､普通な事なのか､とても､疑わしい！
約10年前に､ベーターベースに接続された｢オンラインシステム｣へアクセスするWebシステムに於いて､端末から､SQL(データーベース照会言語)の脆弱性を突く攻撃で､データを格納したデータベースに不正侵入出来て､データベースのデータを不正改竄･不正削除する攻撃が多数､発生した事があった！
現在でも､｢ネット銀行システム｣で使用しているWebアプリ開発言語やデータベース･アクセス言語や通信アプリ等に､全く､脆弱性が無いとは云えず､自由に｢セッションCookie｣を捏造出来る様に､攻撃者が､もし､公開･周知されていない｢AiTMフィッシング｣の様な､新規の脆弱性を発見して､悪用した場合は､正規預金ユーザに成りすまして､｢銀行オンラインシステム｣の中核･基本部･カーネルまで､侵攻して､カーネルにバッチ型の不正送金Scriptを埋め込んだ場合は､自由に､選択した口座から､自由な金額を不正送金出来てしまう攻撃も予見される！
この様な攻撃に対する耐性･防御性能が保証･検証されていない限り､正規社員の銀行員以外の､不特定多数の預金者やその成りすまし共に､｢ネット銀行システム｣を経由した｢銀行オンラインシステム｣へアクセス･接続･使用させる事は､即刻､停止すべきだろう！
これまで､｢銀行オンラインシステム｣に関わる､外部からの攻撃･事件･被害が発生しても､銀行は予防措置は何ら実行せずに､事件･攻撃の発生後に､後手後手で､対応する事を続けている！
ある日､突然､一斉に､全ての銀行に於いて､大掛かりな､大規模な､巨額不正送金事件が頻発し出して､預金残高"総額"がゼロになるまで､攻撃を防御･抑制･停止させる事が出来ない様な事態が発生したら・・・・
→｢銀行崩壊･経済崩壊→日本滅亡｣だから､国防安全措置＝対テロ対策として､北鮮等からの国の重要基幹システム(銀行オンライン･銀行間決済システム･省庁システム･自治体システム等)や重要インフラシステム(原発･防衛･警察･消防･病院／医療･電力･ガス･通信･水道･鉄道／航空／道路管制等)へのサイバーテロ攻撃の耐性･防御性能は十分か？・・・
【追 記 ３】(2023年3月20日)
『知らぬ間に銀行口座から不正出金された事件の実例が､2020年9月に露呈した｢不正オンライン決済事件｣だ！／次なる新たな銀行口座不正出金事件発生の恐れも強い！』
こう云う懸念を｢荒唐無稽な､思い込み！｣と云うなかれ！
なぜなら､2020年9月には､オンライン決済など､一度も､見た事も､触った事もないと云う御老人の預金口座から､｢ドコモ口座｣や｢ゆうちょ銀行｣や｢Kyash｣や｢PayPay｣や｢メルペイ｣等の｢決済サービス｣経由での､不正出金事件が発生しており､
この事件の端緒となったドコモ口座は､メールアドレスだけで作成出来る｢dアカウント｣に連携するもので､SMSや個人認証無しに作成出来て､その上で､ドコモ口座に銀行口座を登録して送金をして決済に利用出来た｡
なぜ､身元確認がなくても､誰でもドコモ口座を作成出来たのか､それは､｢チャージをする為に銀行口座と連携する事｣自体を｢本人確認(身元確認)｣とした為だった｡
この認証方法は､犯罪収益移転防止法施行規則に則った手法だが､この時､一部の銀行では｢口座番号｣｢口座名義｣｢キャッシュカード暗証番号｣と云う少ない情報で口座確認を行った｡
こうした一部銀行の脆弱なセキュリティーに加えて､ドコモ口座の作成が容易だった事から､2019年10月から2020年9月10日までに143件､2676万円(9月15日0時時点)と云う被害につながった｡
要するに､既存口座所有者に成りすました犯罪者が､本人確認が無い事を悪用して､勝手に､｢ドコモ口座｣や｢ゆうちょ銀行｣等に口座を開設して､その偽装口座へ､勝手に､既存の被害者の他行口座を紐付けして､｢ドコモ口座｣や｢ゆうちょ銀行｣の偽装口座から､不正に払い出しした事件だ｡(添付図８参照)
KyashやPayPayらはアカウント登録時にSMS認証を用いていたが､これでは不十分だった｡SMS認証は､あくまで｢SMSが受信出来る端末を持っている人だけがアカウントを作成出来て､その端末でログインする｣事を確認する為の機能だ｡身元を確認する機能はなく､｢メールアドレスでアカウントを作成する｣事よりも少し手間が増えるだけに過ぎない｡
KyashもPayPayも､口座連携による本人確認を行っており､これが身元確認代わりになっていたが､この身元確認をする銀行側の機能が脆弱だったので､他人の口座を登録してチャージが出来てしまった｡
事件の原因の1つは､ドコモ口座やKyash､PayPayと云った決済サービスが､悪用すれば｢誰でも身元を隠してアカウントを作成出来る｣点だ｡他人に成りすまして作成する事が可能なので､｢自分はその決済サービスを使っていない｣と云う人も被害者になった｡
もう1つの原因が､｢銀行口座からチャージする際には､身元確認が必要だが､その確認が脆弱だった｣と云う点だ｡
<<本来､他人に成りすましても､身元確認をすれば別人だと判明して銀行口座からチャージは出来ないはずだが､他人に成りすました状態でも､身元確認をすり抜けて他人の銀行口座に接続して､勝手に銀行口座から預金を引き出せてしまった｡>>
つまり､被害者からすれば､｢使った事のない決済サービスに､勝手に自分の銀行口座が連携して預金が不正に引き出された｣訳だ｡
さきほどから､｢ネット銀行システムの振り込み処理機能を停止せよ！｣と云っている様に､今､何も知らない人が確実に被害を防止するには､｢銀行のWeb口座･振リ込み･受付サービスを停止する｣事ぐらいしか被害を防ぐ手立てはない｡
この｢ドコモ口座･ゆうちょ銀行等､オンライン決済不正事件｣の原因は､まともな｢本人確認＝認証処理｣を怠った点であった事は､今回の認証方式の脆弱性を突く､｢AiTMフィッシング｣攻撃事件と相通ずる点があるので､｢ネット銀行システムの振り込み処理機能｣が稼働･存在している以上は､認証に関わる新たな脆弱性を悪用する､新たな攻撃事件が発生してもおかしくはない！
<<｢銀行がいい加減な認証方式を続けるのなら､災(わざわい)の元(もと)の｢ネット銀行システムの振り込み処理｣は止めろ！｣と云っている！>>
【注】本稿で記載した､アプリ､ソフト､サービス､ハードウェア､URL､操作手順､記載内容の完全性･網羅性を保証するものではありません｡使用･導入･採用は自己責任となります｡
【以下転載】
https://gigazine.net/news/20220713-microsoft-aitm-fishing
｢Office365のアカウントを多要素認証すら回避して乗っ取るAiTMフィッシング攻撃が1万以上の組織を標的にしていたとMicrosoftが公表｣
GIGAZINE 2022年07月13日 15時00分
Microsoftのセキュリティ研究チームが、HTTPSプロキシ技術を使ってOffice 365アカウントを乗っ取る大規模なフィッシング攻撃キャンペーンである「Adversary-in-the-Middle(AiTM)」が確認できたと発表しました。この攻撃は多要素認証を回避することが可能で、2021年9月以来1万以上の組織が標的になっているとのことです。
From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud - Microsoft Security Blog
https://www.microsoft.com/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/
2021年のMicrosoft Digital Defense Reportによると、メールで偽サイトに誘導してアカウントや個人情報を詐取しようとするフィッシング攻撃の報告数が2019年から2020年にかけて2倍に増えています。そのため、アカウントへのログインで、パスワードだけではなく所持情報や生体情報などを組み合わせて認証を行う多要素認証の採用が推奨されています。
今回Microsoftのセキュリティ研究チームが発表したAiTMフィッシングでは、攻撃者は悪意のあるHTML添付ファイルを含むメールを標的に送信します。このメールはボイスメール通知を装い、添付ファイルを開かせ、攻撃者が偽装した不正なOffice 365のログインページにリダイレクトさせます。
添付図１_AiTMフィッシング攻撃を行う偽サイトへ誘導する偽メールの事例
悪意のあるメールを開かせてリンクを踏ませるというのはフィッシング攻撃でよくある手口ですが、このAiTMフィッシングでは、フィッシング用の偽装ウェブサイト自体がプロキシとして機能し、正規のOffice 365ログインページからコンテンツをリアルタイムで取得するというのがポイント。フィッシングページは、HTTPS対応でMicrosoftの純正サービスであるかのように装ったドメインでホストされています。
添付図２_偽サイトのログイン画面の事例
攻撃者は偽装サイトにアクセスするユーザーからのHTTPパケットを、あらかじめ用意したプロキシサーバーに展開します。標的のユーザーからは従来のサイトにアクセスしているように見えますが、実際は偽装サイトにアクセスしながら、セッションCookieなどのデータを詐取されてしまいます。
添付図３_攻撃者が偽装サイトに誘導して､PCユーザのセッションCookie等のデータを詐取する手口･手法
セッションCookieは、認証済みのユーザーがウェブサイトで再度認証しなくてもセッションを続けられるようにするためにサーバー側が発行するCookieです。Microsoftのセキュリティ研究チームによると、実際に侵害されたアカウントが偽装サイトにサインインしてしまった後、攻撃者が詐取したセッションCookieを使用してOutlook Onlineの認証に成功した形跡が見られたと報告しています。通常、Office 365の認証には多要素認証が必要ですが、認証済みのセッションCookieを使うことで、多要素認証を回避して不正なアクセスを実現したというわけです。こうしたAiTMフィッシング攻撃には、Evilginx2やModlishka、Muraenaといったオープンソースのフィッシング攻撃ツールが使われていたとのこと。
ただし、すべての多要素認証がAiTMフィッシングで回避されるわけではなく、FIDO2準拠で生体情報あるいは物理セキュリティキーを使う認証方法であればセッション情報を詐取されることはないとMicrosoftは述べており、多要素認証を設定しておく方がアカウントの盗難に対するセキュリティが高くなるとしています。
また、認証に対する条件付きアクセスポリシーを有効にし、受信メールやアクセスしたウェブサイトをスキャンする高度なフィッシング対策を行い、疑わしいアクティビティや異常なサインインを継続的に監視するように訴えています。