我らかく戦えり 第3回「銀の弾丸を追い求めず、あの手この手を駆使してなりすまし対策を」 | ScanNetSecurity
2024.04.18(木)

我らかく戦えり 第3回「銀の弾丸を追い求めず、あの手この手を駆使してなりすまし対策を」

攻撃と防御の非対称性はこの世界では周知の事実。不利は承知の上で、それぞれの特徴を踏まえて、DMARC をはじめとする複数のなりすまし対策を組み合わせていくことが重要だ

脆弱性と脅威 脅威動向
PR
 新型コロナウイルスが猛威を振るい続けていますが、何か一つ「これさえやっておけば大丈夫」という対策は残念ながら存在しません。ワクチン接種は大きく感染リスクを下げてくれますが、だからといって 100 %感染は予防できるわけではありません。なるべく人混みを避け、マスクを付け、手洗い、うがいをして感染予防に努めるといった基本的な対策を積み上げることが重要です。

 これと同じことが、日々私たちを悩ませるなりすましメール対策にも言えるでしょう。過去の記事で紹介してきた DMARC が重要な対策の 1 つであることは間違いありませんが、かといってそれだけでなりすましメールをすべて見破り、対処できるわけではありません。ということで再び TwoFive の加瀬 正樹 氏に、複数あるなりすましメール対策、それぞれの特徴と包括的な対策の必要性について尋ねてみました。

●一度ならず二度三度と目にしたはず、あの手この手の「なりすまし」

 スパムメールにフィッシングメール、マルウェアを添付したメールなど、我々の元には日々多くの迷惑メール・攻撃メールが届く。その大半が、信頼できる企業や人物からのメールに見せかけてユーザーをだます、なりすましメールの姿を取っている。

 この「なりすまし」の手法はけっして一つではない。インターネットメールやそれを支える DNS の仕様そのものが、ビジネス活用や配信サービスの利用などさまざまな使い方を想定して柔軟な設定を許容していることの裏返しとして、サイバー攻撃者や詐欺師らが素性を隠し、さまざまな形でなりすましを行えてしまうのが実情だ。その対策として、SPF や DKIM、そして DMARC といった送信ドメイン認証技術が生まれてきたが、だからといってすべてのなりすましメールに対抗できるわけではない。

なりすまし全体DMARC は “銀の弾丸” ではない。DMARC は正当なメールドメインのなりすましには効果的だが、他のさまざまな攻撃に対しては有効ではない。
なりすまし全体
DMARC は “銀の弾丸” ではない。
DMARC は正当なメールドメインのなりすましには効果的だが、
他のさまざまな攻撃に対しては有効ではない。

 古くからある代表的ななりすまし手法の 1 つが、Webメールやメールアプリの画面に表示される「差出人情報」として、攻撃者がなりすまししたい偽の情報を表示するものだ。これは、メールのヘッダー情報のうち「From」フィールドに偽の情報を記してユーザーをだます手法だが、DMARC はまさに、この手法に対抗するための技術だ。

 だが同じ Fromフィールドでも、メールアドレス部分ではなく、送り主の名前や所属を記述できる部分、いわゆる「display-name」が詐称されてしまうと、DMARC では対処が難しい。

 「display-name は自由に宣言でき、企業名やブランド名を表示するのにも使われています。ですが同時に、無関係な第三者の名前を騙ってなりすましを行うことも非常に容易です。実はこの方法は、DMARC では対策のスコープ外になっています」(加瀬氏)

類似ドメイン見た目を正当なメールドメインに似せたり、あたかも存在しそうなサブドメインを取得して DMARC などの認証を回避する手法。Homograph Domain Spoofing、またはCousin Domain Spoofing という。
類似ドメイン
見た目を正当なメールドメインに似せたり、
あたかも存在しそうなサブドメインを取得して DMARC などの認証を回避する手法。
Homograph Domain Spoofing、またはCousin Domain Spoofing という。

 もう 1 つ、古典的だがよくあるなりすまし手法は、著名なドメイン名に似せたドメイン、いかにも存在しそうなドメインを取得してユーザーの目をだます方法だ。おそらく皆さんも一度や二度、いや何度も目にしたことがあるだろう。たとえば、なりすましをしたいドメイン名が「amazon.co.jp」ならば、「anazon.co.jp」「amaz0n.jp」のように紛らわしいドメイン名を使ったり、「amazon.co.jp.attacker.com」「xxxxx.go.jp.attacker.com」のようにあたかも存在しそうなサブドメインを使ったり、時にはキリル文字など見た目がそっくりな別の言語を用いるなど、あの手この手が存在する。URL 全体が表示されないスマートフォンなどでは特に注意が必要だ。

 これらは「類似ドメイン」や「ホモグラフドメインスプーフィング」と呼ばれている。自社ブランドの類似ドメインを予防的に取得するといっても限りがある上、技術的にはそのドメイン名に紐付けられた正規の IPアドレスから送信されることから、SPF、DMARC など送信ドメイン認証を回避して送られてしまう。

 さらに、正規ユーザーのアカウントを乗っ取って偽メールを送信する方法もある。フィッシングや遠隔操作マルウェアなど何らかの方法で ID とパスワードを盗み取ってそのままログインし、本人の知らない間に詐欺メールを送信したり、転送設定を付け加えたりする方法で、英語では「EAC(Email Account Compromise)」などとも呼ばれる。

 この場合、なにせ本人のアカウントがそのまま使われ、正規のメールサーバ経由で送られるため、外形的に偽物かどうかを判定することはほぼ困難だ。「請求書の送付先が変更になった」といったもっともらしい理由を付けて巨額の金銭を奪う、BEC(ビジネスメール詐欺)にもたびたび悪用されている。

 JPAAWG(Japan Anti-Abuse Working Group)のワーキンググループが行った調査によると、送信ドメイン認証では対処できないこの手のなりすましメールは無視できない数に上っており、特に類似ドメイン/ホモグラフドメインスプーフィングを用いたなりすましメールが目立つという。

●DMARC をかいくぐるなりすまし手法に対する対策は?

 攻撃者側はさまざまななりすまし手法を駆使し、受信者がどれか一つでも引っかかってくれればペイできる可能性がある。一方守る側は、複数の手法それぞれに対処していく必要があり、最初から分の悪い勝負であることは事実だ。ただ、攻撃と防御の非対称性はこの世界では周知の事実。不利は承知の上で、それぞれの特徴を踏まえて、DMARC をはじめとする複数のなりすまし対策を組み合わせていくことが重要だと加瀬氏は言う。

 まず、Webメールやメールソフト、スマートフォンのメールアプリなどでできるいくつかの対策を見てみよう。

 たとえば、Fromフィールドの display-name の詐称リスクを緩和するには、DMARC や S/MIME(Secure / Multipurpose Internet Mail Extensions)といった手段で差出人情報の認証を行い、その結果信頼できる場合にのみ display-name を表示するように設定する方法がある。過去に何度かメールをやりとりした相手、すでにアドレス帳に登録され登録名も一致する相手からの正しいメールのみ、display-name を表示する設定にすることも有効だ。

Webメール、メールアプリの対策例ドメインレピュテーション・ブランドアイコン表示 / 公式マーク・DMARC + BIMI・S/MIME 電子署名のマーク
Webメール、メールアプリの対策例
ドメインレピュテーション
・ブランドアイコン表示 / 公式マーク
・DMARC + BIMI
・S/MIME 電子署名のマーク

 次に、類似ドメインやホモグラフドメインスプーフィングへの対策だが、攻撃者が紛らわしいドメイン名を取得した上で、そのドメイン名について送信ドメイン認証技術に対応してしまうと、DMARC だけでなりすましを見破るのは難しい。この場合は、そのドメイン名が信頼できるものかどうか、世界中の観測ポイントの情報を元にさまざまな角度から解析した「レピュテーション情報」を参照し、その結果に基づいてユーザーの目に見える表示を変えるといった手法が考えられる。

 「不審なメールを見分けられるようにする」だけでなく、「正しいメールがそれと分かるようにする」というアプローチもある。2021 年 8 月現在標準規格化が進められている「BIMI(Brand Indicators for Message Identification)」が代表例だが、他にも NTTドコモやヤフーといった事業者も、公式のメールアドレスから送られたメールについてはブランドアイコンを表示し、ユーザーの視認性を高める取り組みを開始した。S/MIME を用いて送信者のメールアドレスが正しいかどうかを確認するのも、昔からあるが確実な方法の 1 つだ。

通信経路上での ID/PW 保護・Webメールの利用(HTTPS 通信でパスワードを保護)・メールアプリの場合は、TLS に対応した設定(ポート番号)を利用。サーバ証明書の検証は ON
通信経路上での ID/PW 保護
・Webメールの利用(HTTPS 通信でパスワードを保護)
・メールアプリの場合は、TLS に対応した設定(ポート番号)を利用。サーバ証明書の検証は ON

 さらに、Webメールやメールアプリ以外でできる対策について見てみよう。これらは主に、パスワードなどのクレデンシャル情報を盗み取って行われる EAC への対策となる。

 1 つ目は、通信経路を暗号化して盗聴から保護することだ。今や Web通信は HTTPS で保護することが当たり前になりつつあり、Webメールも同様だ。サービス事業者側もその前提で機能を提供しているため、ユーザー側もうっかり平文で通信しないよう、HTTPS を有効化することが重要だ。また、メールアプリで POP3/IMAP4 を利用する場合も、サービス事業者やメールプロバイダーが提供している TLS で暗号化されたポート番号をきちんと指定することが重要になる。

 TLS で通信を行うということは、サーバ証明書で通信相手の身元をチェックし、中間者攻撃によって経路がねじ曲げられていないかどうか検証できることも意味するため、二重の意味で保護につながるだろう。

 また、あまり推奨されることではないが、複数のサービスで同一の ID とパスワードを使い回していると、どこか別のサービスが不正アクセスを受けて流出した情報が悪用される恐れがある。そんな場合に備え、OAuth に対応したメールサービスを利用するという手も、今後検討していくべきだろう。

 ただ、Gmail や Microsoft 365 など海外大手のサービスを除けば、まだ OAuth に対応したサービスは少ない。そんな場合には、たとえ最初のなりすましログインは許しても、その事実に素早く気付いて被害を最小限に抑える、事後に備えた対策を取るのが次善策だ。「防ぐことは困難でも、後から追跡できるようにしておく方がいいでしょう」(加瀬氏)

 具体的には、誰かがログインしたことをメールで通知してくれる「ログインアラート」の設定と、ログイン履歴や設定変更履歴の確認などが挙げられる。加瀬氏はさらに「もし、攻撃者が盗んだ ID とパスワードを使って転送設定を追加してしまった場合、たとえパスワードを変更してそれ以降のログインを防いだとしても、残っていた転送設定によってすべてのメールが攻撃者に筒抜けになってしまう恐れがあります」と指摘し、履歴の確認機能があればぜひ活用すべきだとした。

 また、徐々に広がりつつある二要素認証、二段階認証も自衛のためにぜひ活用すべきだ。残念ながらメールアプリ側での対応はまだ標準的とは言えないが、サービス提供側も積極的にこうした機能をサポートすべく、取り組む必要があるとした。

●各対策の強みや特徴を踏まえ、包括的な対策を

 このように DMARC だけでは対応しきれないさまざまななりすまし手法も、他の技術を組み合わせることである程度見破り、悪用を防ぐことができる。

 もちろん、各技術に一長一短があるのは事実だ。

 たとえば DMARC をはじめとする送信ドメイン認証技術は標準規格として仕様が固まっており、「Milter」拡張されたオープンソースソフトウェアを利用すれば導入が容易だが、電気通信事業法をはじめとする法律や利用規約との兼ね合いを慎重に見定める必要がある。またレピュテーションやフィルタリングの導入自体は簡単だが、ベンダーが提供するサービスがほとんどで、コストがかさむ可能性がある。多要素認証や OAuth、BIMI をはじめとするブランドアイコンの表示といった技術には期待が持てるが、サービス提供者側の本格的な実装となるとこれからという段階だし、S/MIME も技術自体は確立されているものの、使いやすさに難点がある。

 それぞれ長所もあれば課題もある技術だが、自分が利用する、あるいは提供するサービスの性質を踏まえながら、できるところから、あるいはリスクの高いところから取り入れることで、あの手この手でわれわれをだまそうとするなりすましメールに対抗していくことができるだろう。
《高橋 睦美》

関連記事

Scan PREMIUM 会員限定記事

もっと見る

Scan PREMIUM 会員限定記事特集をもっと見る

カテゴリ別新着記事

「経理」「営業」「企画」「プログラミング」「デザイン」と並ぶ、事業で成功するためのビジネスセンスが「セキュリティ」
「経理」「営業」「企画」「プログラミング」「デザイン」と並ぶ、事業で成功するためのビジネスセンスが「セキュリティ」

ページ右上「ユーザー登録」から会員登録すれば会員限定記事を閲覧できます。毎週月曜の朝、先週一週間のセキュリティ動向を総括しふりかえるメルマガをお届け。(写真:ScanNetSecurity 名誉編集長 りく)

×