Mailsploit とは
Mailsploit とは、送信元メールアドレス偽装が可能となる、メールクライアント側の脆弱性を突いた攻撃のことで、2017年12月7日にWebで公開されました。
そもそも送信元メールアドレス偽装は簡単
メール送信はご存知の通り、SMTP プロトコルを使って行います。送信元メールアドレスは基本的に返信したいときに使われる情報ですので、SMTPプロトコル自体では受信時に『送信元メールアドレスが偽装されているかどうか』は気にしません。
SMTP では、送信元メールアドレスを記述する場所が2か所あります。1つは、TCP コネクションを確立した後、"HELO" コマンドの後に "MAIL FROM"コマンドで通知するメールアドレスで、『エンベロープFROM』とも呼ばれます。もう1つは、コンテンツヘッダのFROM: の行で通知するメールアドレスで、『ヘッダFROM』とも呼ばれます。
『ヘッダFROM』はメールクライアントから見たときに＜差出人＞として表示される情報です。メール本文と同じような位置付けであり、SMTP 通信においては使われません。それゆえ簡単に偽装ができます。
一方『エンベロープFROM』は SMTP 通信の送信元として取り扱われます。例えば宛先メールアドレスが存在しなかった場合などでエラーメールが返ってくる場合は、『エンベロープFROM』宛になります。しかし他は『ヘッダFROM』と変わらない位置付けなので、同様に簡単に偽装ができましたが、最近では後述する SMTP AUTH や DKIM、SPF/SenderID といった送信元ドメイン認証技術により使われる情報となりました。
下図では、yahoo.com のメールサーバから、nesuke.com のメールアドレスを騙って送信する例を示します。
メールアドレス偽装を防ぐ技術
送信側で偽装メールアドレスを止める対策
昔はメール送信時に送信元メールアドレスが正しいかどうかの認証は行っていませんでした。それゆえ、自分のメールアドレスを勝手に騙られるのはよくある話でした。今は、メールクライアントからメールサーバへの SMTP においては、SMTP AUTHという認証を行うことにより、送信元メールアドレスを使うのにも認証が必要となりました。
また、昔は自分のドメイン外のメールアドレスを中継してしまう（いわゆるオープンリレー）設定をしてしまっているメールサーバも多々見られ、スパムメールの踏台になってしまうケースもありました。今は、自ドメインから宛先ドメインへの直パスで SMTP リレーするのが原則となっています。
受信側で偽装メールアドレスを止める対策(2つの送信ドメイン認証技術)
しかし送信側の対策もまだまだ完璧ではありません。SMTP AUTH 以外を受け付けてしまうメールサーバは存在しますし、これからも意図してか意図せずか、作られ続けるでしょう。そこで受信側での対策も求められました。現在、対策としては DKIM と SPF/SenderID の2つの送信元ドメイン認証技術があります。
1. DKIM (RFC4871 , RFC5672) の概要とメリット・デメリット
DKIM とは Domain Keys Identified Mail の略で、Yahoo が提唱していた "Domain Keys" と、Cisco が提唱していた "IIM(Identified Internet Mail)"が統合されて出来た規格です。
例えば、送信元メールアドレス yahoyaho@yahoo.com から宛先メールアドレス sanfran@cisco.com へメール送信する場合を考えます。このとき、@yahoo.com のメールサーバに秘密鍵を配置、yahoo.com ドメインを管理する DNS サーバのTXTレコードに公開鍵を配置します。これにより、cisco.com のメールサーバで、送信元が確かに "@yahoo.com" だという確認ができます。
具体的には、メール送信時に @yahoo.com のメールサーバでメール本文を秘密鍵でハッシュ化し、それをメールに付け加えて @cisco.com のメールサーバへ送ります。
yahoo.com の公開鍵は例えば以下コマンドで確認できます。
DKIM の最大のメリットは、エンベロープFROMが正しいことを確認できる上に、ヘッダ内が改竄されていないことも確認できるため、エンベロープFROMとヘッダFROMが一致するかどうかを検証することで、両方の正当性を確認できることです。
しかし設定に手間がかかるのがデメリットです。
2. SPF/SenderID (RFC4408 , RFC4406) の概要とメリット・デメリット
SPFとは Sender Policy Framework の略で、Meng Wong 氏により提唱されたメール認証技術です。また、その上位互換である SenderIDとは、Microsoft が提唱していた "Caller-ID for Email" と "SPF" が統合されて出来た規格です。
仕組みとしてはどちらも共通で、『SMTPのTCPコネクションの送信元IPアドレス』と『送信元メールアドレスのドメイン管理DNSサーバのTXTレコードに含まれるIPアドレス』が合致するかどうかを確認します。
先の例と同様、送信元メールアドレス yahoyaho@yahoo.com から宛先メールアドレス sanfran@cisco.com へメール送信する場合を考えます。このとき、@yahoo.com のメールサーバの送信元IPをあらかじめ、yahoo.com ドメインを管理する DNS サーバのTXTレコードにSPF/SenderIDの設定をしておきます。
すると yahoo.com のメールサーバが cisco.comのメールサーバへSMTPセッションを確立し、『送信元メールアドレスはyahoyaho@yahoo.comですよ』と伝えてきたタイミングで、yahoo.com のDNSサーバのTXTレコードを取得してSMTP送信元IPと比較することで、送信元メールアドレスの正当性を確認できます。
yahoo.com の場合は yahoo.com の TXTレコードを調べると、『_spf.mail.yahoo.comのTXTレコードを見ろ』と書いてあり、該当レコードを調べると、『yahoo.com を逆引きしたもの、もしくはyahoo.netを逆引きしたものであれば正しいと認証しろ。他のIPから来ることもあるから、その他のIPについては正しいとも不正とも判断するな。』 と書いてあります。
yahoo.com のSPF情報は以下コマンドで確認できます。
SPF/SenderIDのメリットは、実装が簡単なところですが、デメリットとして、確認できるのはエンベロープFROMのみです。
DKIM と SPF/SenderID の両方を実装するという選択肢
メールはその性質から、なかなか思い切って切り捨てることが難しいです。DKIM も SPF/SenderID も認証されたならば確実に正しいと言えますが、認証できなかったものは全て不正かというとそうも言い切れません。
なので yahoo.com の実装のように、DKIM と SPF/SenderID を両方実装し、正しいと確認できる機会を増やしていくことが大事なのかもしれません。それがやがて、全てを正しく認証できる時代へと繋がる気がします。
Mailsploit では何をするのか
Mailsploit は、DKIM による『ヘッダFROM』の偽装メール防止技術をすり抜ける攻撃です。これはメールクライアントが、RFC1342 (1992年に制定) を正しく実装していないことに起因していますが、すり抜けられ方は、メールクライアントによってまちまちです。
今回の攻撃発見者の以下サイトでは、iOS と MacOS の例が紹介されています。
https：／／www.mailsploit.com/index ← ドメイン廃止
送信メールサーバのエンコード
送信側メールサーバでは、ヘッダFromを以下のように書きます。ポイントは『=?utf-8?Q?=00?=』の箇所で、これはNULLをエンコードしたものになります。
base64_encode()関数を使ってエンコード後の文字列が入ると次のようになります。@ は ASCII ですが、@ が消えています。これを SMTP で送信します。
受信メールサーバのデコード
デコードすると以下のようになります。これをメールとしてファイルに保存します。
iOS (iPhone) の解釈
iPhone では \0(=NULL) を読み込むと、以降を無視してしまいます。そのため、
と解釈します。
MacOS の解釈
MacOS では \0 を読み込むと、それ以前を無視し、それ以降で最初の正しいメールアドレスを読み込み、処理をストップしてしまいます。そのため、
と解釈します。
このように、メールクライアント側で『@mailsploit.com』を認識できなくなってしまいます。なので mailsploit.com の DNS サーバの TXT レコードに mailsploit.com ドメインの DKIM 公開鍵を格納しておけば、メール偽装が完成します。メールサーバの DKIM をすり抜けた後、メールクライアントではそのような防御が出来ないからです。
これが mailsploit 攻撃の概要です。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント