Mailsploitは何が脅威なのかを考えてみる その2
SendGridエバンジェリストの @nakansukeです。
その1では、
- メールのFromにはエンベロープFrom, ヘッダFromの2種類があること
- ヘッダFromは送信者が自由に設定可能であるため簡単になりすましが実現可能なこと
- SPFやDKIMという認証技術ができたこと
- とはいえSPFやDKIMはヘッダFromのなりすましを完全には防ぐことはできないこと
と紹介しました。その2ではSPF/DKIMを応用した最新の認証技術DMARCを紹介し、本題のMailsploitの何が脅威なのかを説明したいと思います。
DMARCとは??
DMARCはSPFとDKIMを更に進めた認証の仕組みで、SPFおよびDKIMの認証に失敗した際に、そのメールをどのように処理すればよいかを送信側が制御します。SPF/DKIMはあくまでも送信側ドメインのDNSに送信元の妥当性を検証するための情報を宣言してあるだけでしたが、DMARCはさらに、認証にした場合にこのメッセージは捨ててください、といったことまで記載することができるようになっています。
DMARCのイメージ
DMARCの何がうれしいのか
SPF/DKIMでは、認証に失敗したときの受信可否の判断は受信側が行なっていましたが、DMARCの場合は送信側がそれを決めることが可能です。ポリシーを非常に厳しくする(SPF/DKIMの認証に失敗した場合はメッセージを破棄させる)ことで、第三者からのなりすましを強力に防ぐことが可能になります。
DMARCレコードは、_dmarc.example.comにtxtレコードとして以下のような値を設定します。(DMARCはヘッダFromのドメインを検証する仕組みです)
v=DMARC1; p=quarantine; fo=1; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=none
DMARCのポリシーはpタグで指定し、以下のようにレベル分けがされています
- 未認証メールを受け取ったときに受信サーバで取るべきアクションについて、特に規定しない(p=none)
- 未認証メールは、受信サーバで隔離する(p=quarantine)
- 未認証メールは完全に拒否し、受信しない(p=reject)
という順に厳しくなっています。米国の大手メールサービス提供者である、AOLやYahoo!(yahoo.comのことで、yahoo.co.jpとは別物です)では最も厳しい設定がされています。つまり、AOLやYahoo!のプラットフォーム以外からaol.comやyahoo.comをヘッダFromに指定してメールを出すことは不可能になっているということです。
つまり、DMARCは自分のドメインを利用して第三者がメールを送信することを防ぐことが可能な仕組みであるといえます。
日本でも利用者が多いGmailやHotmail(その他MSのメールサービス含む)もそう遠くない未来にrejectに設定変更すると明言しています。(本当はもうとっくになっている予定でしたがやはり影響範囲が大きすぎるためか延期に延期を重ねています)
DMARC周りは、このあたりでも詳しく説明しているので、興味がある方はぜひご覧ください。
今回のMailsploitが脅威なのは、このようにDMARCポリシーで第三者からのメール送信を一切禁止しているドメインをFromに指定して(いるように見せかけて)メールを送ることが可能な点にあります。
Mailsploitの攻撃対象
ヘッダFromは、DisplayName <example@example.com>
という形で、単純にメールアドレスだけでなく、DisplayNameをセットで付けることが可能です。多くのメールクライアントではこのDisplayNameを差出人情報として表示します。
通常メールを送るときは非ASCII文字を使用して送信するときにはエンコードして送信し、メールクライアントがデコードして人間が読むことができる形式の文字にして表示します。Mailsploitは多くのメールクライアントに存在するデコード後の文字列処理に関する脆弱性を突きます。
例えば、iOSのメールアプリの場合は、ヘッダFromにヌルバイト文字が含まれていると、それ以降の文字をスキップするという仕組みになっています。
エンコードされたヘッダFrom : ?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
デコードされたヘッダFrom : potus@whitehouse.gov\0(potus@whitehouse.gov)@mailsploit.com
脆弱性のあるメールクライアントでの表示例 : potus@whitehouse.gov
(引用元:mailsploit.com)
つまり、
hoge@hoge.com(ヌルバイト文字)fuga@fuga.com
と指定すると、実際のヘッダFromはfuga@fuga.comであるのに、受信者にはhoge@hoge.comからメールが来たように見えます。これがMailsploitを利用したなりすましです。
Mailsploitの恐ろしいところ
その1でも説明したとおり、メールはもともと簡単になりすましをすることが可能で、SPFやDKIMの認証をpassしたなりすましも可能でした。ではMailsploitのなりすましの何が恐ろしいのでしょうか。
それは、DMARCでSPF/DKIMの認証に失敗したときにメールを破棄する(p=reject)厳しい設定にしているドメインのメールになりすますことが可能な点にあると思います。これはMailsploit以外では実現できませんでした。
たとえば、yahoo.comではp=rejectになっているので、yahoo以外の環境からyahooのアドレスをFromに指定して送信することはできません。つまり、Fromがyahoo.comのアドレスであれば、そのアドレスは確実にyahoo.comから送信されたものであり第三者がなりすましたものではないことが保証されることを意味しています。しかしMailsploitを使用することで(厳密にはヘッダFromではないですが)送信元としてyahoo.comのアドレスが指定できるようになってしまうため、無条件にyahoo.comのメールを信じていた場合には注意が必要になります。
※Mailsploitの脆弱性をつくことで、コードインジェクション型の攻撃も可能なクライアントもあるようですが、本記事ではとりあえずなりすましの部分にのみフォーカスをあてています。
対処方法
JPCERT/CCでは以下の方法を推奨しています。
- 対応済みのメールクライアントを利用する
- 不審なメールはメールヘッダーを確認する
- PGP/GPG などの仕組みを利用する
正直なところPGP/GPGやS/MIMEといったエンドツーエンドで暗号化が可能な方式を採用するのは、現在の普及率からみても現実的ではないので、安全なメールクライアントを利用し、少しでも怪しいと思われるメールはヘッダを確認する、という対応が必要だと思います。
まとめ
ということで、まとめると以下のようになります。
- メールはその仕組み上なりすましが容易に実現できる
- SPF/DKIMはどのドメインを認証しているのか注意が必要
- DMARCで厳しいポリシーにすれば自分のドメインの悪用を防ぐことが可能
- しかしMailsploitへの対処が済んでいないメールクライアントだとDMARCをスルーすることができる
- 怪しかったらヘッダを確認しましょう
SendGridのサポートを続けてもう4年になりますが、SPFもDKIMも正しく理解されているケースは結構稀です。日頃利用しているメールの周りで使われている技術はどんなものなのか、改めて確認してみるとどうでしょうか。
ではでは。