JSSEC技術部会 スマートフォン・サイバー攻撃対策ガイド
第11回「フィッシングメール詐欺 Ⅱ」
~なりすまし対策強化 ― BIMIを用いたブランドロゴ表示による安全性強化~
JSSEC技術部会マルウェア対策WG
KDDI株式会社 本間 輝彰
背景
フィッシング(phishing)メール詐欺は、個人を狙うサイバー攻撃として高い脅威として認識されており、IPAが毎年発表している“情報セキュリティ10大脅威[1]”でも常にランクインしている状況です。また、JSSECが発表した“スマートフォン利用シーンに潜む脅威 Top10 2023[2]”においても、この脅威は第4位にランクインしています。
さらには、フィッシング対策協議会が公開しているフィッシング報告数[3]推移(図 1)によれば、フィッシングメールは年々増加しており、また、日本データ通信協会 迷惑メール相談センターが公表している要注意メール[4](図 2)の数についても同様に増加しています。その結果多くの被害が発生していると推測されます。
図 1 フィッシング報告数推移
図 2 要注意メール件数推移
JSSECでは、2022年6月にスマートフォン・サイバー攻撃対策ガイド「フィッシングメール詐欺[5]」(以下、サイバー攻撃対策ガイド・フィッシングメール詐欺)を発表し、フィッシングメール詐欺への対策をまとめました。また、このコラムでは、なりすましメールへの対策として注目されているBIMI(Brand Indicators for Message Identification)について詳しく解説しています。
また、フィッシングメールが増加する一方で、GoogleやYahoo(米国)はメール送信者に対する要求[6][7]を発表しています。これらの規制を考慮に入れ、メール送信者が注意すべき対策について詳しく説明しています。この対策が実施されていない場合、これらの企業はメールの受信を拒否すると表明しています。
フィッシング詐欺メールは増え続けており、攻撃方法もますます巧妙化しています。メール送信者は、自社ブランドを保護しつつ、ユーザーに安全なメールを提供するために、推奨される対策の導入が求められています。
フィッシング攻撃の流れと対策
フィッシング詐欺は、図 3 フィッシングを取り巻く、「情報」と「人」の相関図 示した流れにしたがって、以下の手順でユーザーを騙します。
- 攻撃者がユーザーにフィッシングメールを送信します
- ユーザーが気づかずにフィッシングメールのリンクをクリックします
- ユーザーがフィッシングサイトで個人情報を入力してしまいます
- 攻撃者が入力された個人情報を不正に利用し、金銭やそれに換金可能なものを入手します
図 3 フィッシングを取り巻く、「情報」と「人」の相関図
また、場合によっては、フィッシング詐欺は個人情報の搾取だけでなく、マルウェアのインストールに誘導することもあります。マルウェアをインストールすると、個人情報が盗まれるだけでなく、スミッシングSMSの送信など、botとして悪用される可能性もあります。
このようなフィッシング詐欺に対処するための主な対策方法は以下の通りです。
- メールにブランドロゴを表示する。これにより、ユーザーが該当ブランドを詐称したメールかどうかを判断できます。ただし、この対策を実施するには、メールの送受信元とメールアプリがBIMIに対応している必要があります。さらに、ユーザーがブランドロゴが表示されるメールが安全であると認識していることも必要です。
- メールに記載されたURLを直接クリックせず、代わりにメール送信元のサービスをブックマークしてそこからアクセスするか、メール送信元のサービスが提供するスマホアプリからアクセスする。これにより、フィッシングメールによる詐欺を回避できます。
- パスワードマネージャーにサービスのアカウント情報を登録しておく。これにより、もし誤ってフィッシングサイトにアクセスしても、自動ログインが行われずにフィッシングサイトであることに気づくことができます。さらに、FIDOやパスキーの利用により、安全性を更に高めることができます。
- クレジットカードの利用通知を登録しておく。これにより、カードが悪用された場合でも、利用通知を確認して早めに対処できます。
- フィッシング詐欺に遭った場合は、サービス提供元に連絡し、必要に応じてクレジットカードを停止するなどして被害の拡大を防ぐことができます。
しかし、これらの対策はフィッシングメールによる詐欺を完全に防ぐものではありません。攻撃者は、信頼が高いサービスを偽装したり、ユーザーの不安をあおったりすることで、人間の弱点を巧みに利用します。そのため、ユーザーはいつでもフィッシング詐欺に対処できるように、事前に十分な対策を行い、常に注意を払うことが重要です。
ブランドロゴ表示(BIMI)による対策とBIMIの普及状況
「サイバー攻撃対策ガイド・フィッシングメール詐欺」では、メールの仕様上存在する以下の2つの問題を説明しています。
- メールの送受信時に使用されるアドレスには、「Header From/To」(メールアプリ上に表示されるアドレス)と「Envelope From/To」(通信時に使用されるアドレス)の2つがあります。これらはそれぞれ異なるアドレスであっても問題ありません。そして、「Envelope To」が正しい場合には、メールの送信が可能です。
- 「ディスプレイネーム問題」と呼ばれるものでは、「Header From」に送信者の名前(ディスプレイネーム)を入れて送信すると、メールアプリ上では送信者アドレスが表示されずにディスプレイネームのみが表示されます。これらの仕様を悪用して、ディスプレイネームに詐称するサービスの名称を入れることで、送信者を偽装してメールを送信することが可能です。
前者の問題については、「送信ドメイン認証」という技術を導入することでなりすましを防ぐことは可能ですが、送信者が詐称元に似たドメインを取得し、送信ドメイン認証に対応してメールを送信すると、多くのユーザーはそのメールが偽装されていることを判断するのが困難になります。さらには、後者の攻撃手段を使用すると、ユーザーがメール送信元のドメインを認識しなくなるため、騙される可能性が高まります。
これらの問題を考慮すると、メールサービスには重大な課題が存在します。そのため、BIMIを用いたブランドロゴ表示による対策が期待されています。この対策を導入することで、ユーザーはブランドロゴの有無(図 6)を確認して、メールが安全かどうかを判断できるようになります。
図 4 BIMIによるブランドロゴ表示例
BIMIは、DMARC認証に成功したメールに対し、特定の条件※が満たされた場合にブランドロゴを表示する技術です。現在、この技術の標準化が進行中であり、GmailやiCloudメールなど[8]はすでにBIMIに対応しています。
送信者がBIMIをサポートし、同時に受信者もBIMIをサポートしている場合、受信者の画面ではメールのタイトルの隣などに、図6に示されているようなブランドロゴが表示されます。※BIMI導入時に求められるDMARCの主な認証条件
- SPF(Sender Policy Framework)のポリシーが「-all」または「~all」で宣言されていること。さらに、DMARC認証が「Pass」になる条件でSPFの認証結果も「Pass」であること。これは、Header FromとEnvelopeのドメイン、またはそのサブドメインの組織ドメインが一致する場合に適用されます。
- DKIM(Domain Keys Identified Mail)の認証結果が、DMARC認証で「Pass」になる条件で「Pass」であること。これは、dタグに記載されているドメインとHeader Fromのドメイン、またはそのサブドメインの組織ドメインが一致する場合に適用されます。つまり、第三者署名の利用は許可されません。
- DMARCのポリシーが、Header Fromと組織ドメインの両方で「p=reject」または「p=quarantine」であること。また、pctタグを設定する場合は「pct=100」であること。同様に、spタグを設定する場合には、「sp= reject」または「sp= quarantine」であることが必要です。
また、BIMIでロゴを表示するためには、VMC(Verified Mark Certificate)証明書の取得が必要です。現在、VMC証明書を発行できるのはDigiCertとENTRUSTの2社だけです。また、登録するロゴは、VMC発行元が認定した知的財産権機関で商標登録されているものでなければなりません。証明書の発行には、EVサーバ証明書と同等の厳格な審査が必要なため、信頼性のある企業や団体以外では取得が困難であり、フィッシング攻撃者による取得はほぼ不可能です。
ユーザーは、ブランドロゴが表示されるメールを安全とみなし、逆にロゴが表示されないメールをフィッシングメールなどの疑わしいメールと判断できます。BIMIは小さな画面でもロゴが十分に認識できるため、スマートフォン上でもロゴの有無でメールの安全性を確認できます。
BIMIが多くのサービスのメールで普及すれば、ユーザーはロゴが表示されないメールが不正の可能性が高いと認識できるようになります。これにより、「フィッシング攻撃の流れと対策」で説明した対策を施すことで、フィッシングメールによる詐欺被害を大幅に減らすことが期待できます。
BIMIの普及状況
BIMIを利用するためには、まずロゴを表示する組織のドメインがDMARCに対応し、そのDMARCポリシーが「reject」または「quarantine」に設定されている必要があります。しかし、日本のDMARC導入状況は他国と比較して大幅に遅れています。2024年1月の調査によれば、日経225企業の中でDMARCポリシーが「reject」または「quarantine」に設定されている企業はわずか8.4%に過ぎません(図 5参照)。したがって、BIMIの普及を促進する前に、まずはDMARCの普及を推進することが重要となります。
また、自社のブランドを保護する観点から、自社のドメインを詐称してメールを送信されることを防ぐ必要があります。これはDMARCを導入し、「reject」ポリシーを設定することで達成できます。この設定により、自社のドメインを詐称したメールは受信側で拒否されるため、セキュリティ面での利点も大きいと言えます。
図 5 各国のDMAR記述率[9]
メールサービスのBIMI対応について、GoogleのGmailが2020年6月に先駆けて対応を開始しました。その後、Appleは2022年9月のiOS14リリースに伴い、iCloudでの対応を始めました。さらに、日本国内ではKDDIが2023年12月からauメールでの対応を開始する予定です。これにより、国内で広く利用されているサービスにおいても段階的にBIMIの対応が進行しています。
また、メールアプリにおけるロゴ表示の対応は、GmailがBIMIに対応したことに伴い、GmailアプリおよびGmailのWebメールがロゴ表示に対応しました。その後、iOS14のリリースによりiOSメールアプリがロゴ表示に対応し、そしてauメールのBIMI対応に合わせて、Android版のauメールがロゴ表示に対応[10]しました。これにより、メールサービスがBIMIに対応するとともに、メールアプリでもロゴ表示が可能となっています。
さらに、送信側の対応は、フィッシングメールに利用されやすいブランドを中心に普及が進んでおり、特に、銀行・クレジット・EC系のサービスを中心に国内でも対応が始まりつつあり、下記サービスにてBIMIに対応していることが確認[11]できています。
楽天グループ[12] | 三井住友銀行[13] | auじぶん銀行[14] |
ソニー銀行[15] | JCB[16] | VIEWカード[17] |
MIカード[18] | 東急TOPカード[19] | Yahoo! JAPAN[20] |
BIMI対応時・対応後の課題
BIMIの導入には、DMARC/SPF/DKIMのすべてに対応していることが必要です。しかし、一部のドメインではDMARC/SPF/DKIMの設定に誤りが見られます。
特に、SPFレコードの記述ミスが多く見られ、日経225の銘柄を持つ企業でも、いくつかの企業で記述ミスが確認されています。具体的な例としては、includeで指定するドメインのSPFレコードが存在しないケースがあります。SPFの記述ミスがある場合、PermErrorと評価され、結果として、BIMIで必要とされるDMARCの認証基準が満たされず、ロゴが表示されない状態となります。
したがって、BIMIの導入だけでなく、送信ドメイン認証を導入する場合でも、導入後も認証が正しく行われているかを継続して確認することが重要です。特に、SPFレコードにincludeやredirectを設定している場合は、参照先の管理ミスや変更により問題が発生する可能性があるため、特に注意が必要です。
また、企業が自社のサービスメールを送信する際に、メール配信事業者のサービスを利用するケースも存在します。多くのメール配信事業者は DMARC/SPF/DKIM に対応していますが、サービス利用時の設定ミスにより、DMARC 認証が「Fail」となる可能性があります。これには、DKIM の署名をメール配信事業者の d タグを使用して送信するケース(以下、第三者署名)、または Envelope From アドレスにメール配信事業者が提供するアドレスを使用するケース(Header From のドメインと組織ドメインが異なる)などがあります。DMARC では、SPF または DKIM が「Pass」であれば、DMARC 認証も「Pass」となるため、一部のケースでは救済されます。しかし、ある事例では、DMARC ポリシーを「p=reject」と設定しながらも、DKIM の署名が第三者署名であり、Envelope From がメール配信事業者のアドレスとなっていました。結果として、このサービスからのメールは、DMARC に対応している受信先に送信した場合、受信が拒否される結果となります。したがって、DMARC ポリシーを公開していて、メール配信事業者を利用してメールを送信する際には、送信時の設定に十分注意することが必要です。また、メール配信事業者も、DMARC 認証が「Pass」しないような条件を設定する際には、利用者に対して警告を出すなどの対応が求められます。
Gmail、Yahooのメール送信者の要求について
GmailとYahooメールは、2024年2月1日から、メール送信業者に対する新たな要件を発表し、これに適合しない業者に対しては受信規制を行うと発表しました。
両社は送信者に対する要件や受信規制について協力し、メール送信業者に以下の条件を求めています。
前提条件
1日に5,000通以上の広告メールを送信する業者
要求条件
- 送信するメールのドメインに対して、送信ドメイン認証(SPF/DKIM/DMARC)を対応させ、メール送信を行うこと
- 登録したユーザに対して広告メールなどを送信するサービスは、簡単な解除機能を備えること。また、1日に5,000通以上送信する場合は、RFC 2369およびRFC 8058に対応したメール解除機能を備えること
Googleでは、メール送信業者向けにガイドライン[21]を発行しており、このガイドラインに従うことが推奨されています。一例として、メールを送信する際には、そのドメインのMXレコードとAレコードが存在することが求められます。これにより、メールのリプライなどが適切に行えるため、不正な送信元と誤解されることを防ぐことができます。
したがって、広告メールなどを送る業者は、適切な対応を行いメールを送信することが推奨されます。また、日本国内のメールサービスで問題なくても、海外で提供されるメールサービスでは、受信側が不適切と判断すれば、メールが拒否される可能性があるため、受信側のポリシーを理解した上で送信することが重要です。
[1] IPA 情報セキュリティ10大脅威 https://www.ipa.go.jp/security/10threats/index.html
[2] JSSEC スマートフォン利用シーンに潜む脅威 Top10 2023 https://www.ipa.go.jp/security/10threats/index.html
[3] 2023/08 フィッシング報告状況 https://www.antiphishing.jp/report/monthly/202308.html
[4] 迷惑メール相談センター 要優位メール https://www.dekyo.or.jp/soudan/contents/news/alert.html
[5] スマートフォン・サイバー攻撃対策ガイド「フィッシングメール詐欺 」 https://www.jssec.org/column/20220620.html
[6] New Gmail protections for a safer, less spammy inbox https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
[7] More Secure, Less Spam: Enforcing Email Standards for a Better Experience https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam
[8] BIMI Support Mailbox Provider https://bimigroup.org/bimi-infographic/
[9] 企業名から調査したドメインをもとにDMARCの記載有無を確認しているため、必ずしもメールを送信しているドメインではない可能性があるため、誤差を含んだ数字となります
[10] iPhoneにおけるauメールのロゴ表示は、iOSメールアプリにより実現している
[11] サービス元でBIMI対応の記述があるものとなり、他にも対応しているサービスは多数あります
[12] https://corp.rakuten.co.jp/security/anti-fraud/
[13] https://www.smbc.co.jp/notice/20230919_bimi.html
[14] https://www.jibunbank.co.jp/announcement/2024/0229_03.html
[15] https://moneykit.net/visitor/info/2024/01/31_01.html
[16] https://www.jcb.co.jp/trouble/phishing-mail/
[17] https://www.jreast.co.jp/card/security/risk_management.html
[18] https://www2.micard.co.jp/notice/201030notice.html
[19] https://www.topcard.co.jp/support/security/mail.html
[20] https://about.yahoo.co.jp/pr/release/2022/09/06a/
[21] https://support.google.com/a/answer/81126