多数のメールソフトで発見された脆弱性「Mailsploit」

2017.12.25

セキュアプログラミングにとって最も基本的な理念は「取り込むデータを信用するな」です。


コンピュータプログラムは、ファイル、Cookie、音声コマンド、パスワードなど、外部からのさまざまなデータを使用しますが、本来使用してはならないデータを取り込んでしまった場合、深刻な問題が発生する可能性があります。


使用したデータに不具合が存在している場合や、プログラムを終了させたり攻撃に加担させたりする目的でハッカーが不正なデータを与えた場合など、プログラムは意図せず有害なものになってしまうことがあります。


どちらの場合でも、コンピュータプログラムの一生は、森の中を歩き回り、食べられるキノコを見つけようとするようなものです。残念ながら、食べると死ぬキノコはベーコン & グリルドトマトと一緒に食べると美味しそうに見えるものです。


コンピュータプログラムを長生きさせるには、疑い深くなる必要があります。つまり、安全であることが証明されるまでは、すべてのキノコは猛毒を持つタマゴテングタケだと思わなければなりません。


Mailsploit


電子メールは、メッセージ、添付ファイル、そしてメールの配信先、件名、送信者が設定されたヘッダーの 3 つで構成されています。


ほぼ「何でもあり」な添付ファイルとは異なり、ヘッダーは厳密なルールで管理されています。これは、有害なヘッダーを含んだ電子メールを識別しやすくするためのものです。たとえば From ヘッダーには、メッセージの作成者の名前と電子メールアドレスが含まれます。


先日、From ヘッダーに潜り込ませた不正な電子メールアドレスを使用して、スパム対策機能を迂回したり、場合によっては任意の攻撃コードを実行させたりする方法が発見されました。


セキュリティ研究者の Sabri Haddouche 氏が発見し、情報を公開したこの脆弱性は、数十種類の電子メールアプリケーションで何度も繰り返されてきたと思われるコーディングミスでした。


この脆弱性には Mailsploit(リンク先:英語) という名前が付けられました。


脆弱性は、Apple Mail (macOS、iOS、watchOS)、Mozilla Thunderbird、複数の Microsoft 電子メールクライアント、Yahoo! Mail、ProtonMail などの主要なものを含め、30 を超えるアプリケーションで発見されています。


メールアドレスという毒キノコを食べないために


電子メールで使用できる文字は ASCII 文字セットに限定されています。あなたの名前が Andrew であれば問題ありませんが、André であった場合は問題が発生します。なぜなら、ASCII でサポートされている 128 文字の中に、é は含まれていないからです。


éεэ などの英語以外の文字と絵文字なども From ヘッダーで表示できるようにする目的で、RFC-1342(リンク先:英語) が 1992 年に起草されました。


RFC-1342 では、Quoted-Printable または Base64 エンコーディングを使用することによって、128 個の ASCII 文字で数十万の非 ASCII 文字を表現する方法について詳しく説明しています (André は Quoted-Printable では Andr=C3=A9 になり、Base64 では QW5kcsOp になります)。


このようにラップされた状態でヘッダーが配信された場合、ラップを解除しなければ、送信者の名前を Andr=C3=A9 ではなく André と表示することができません。


Haddouche 氏が発見したのは、疑うことを全く知らないメールソフトだったようです。


残念ながら、ほとんどの電子メールクライアントと Web インターフェイスは、デコーディング後の文字列のサニタイズを適切な方法で行っていません。そのため、今回発見した電子メールのなりすまし攻撃が可能になっています。


正しくサニタイズされておらず、RFC-1342 ラッパーを使用できる場合、攻撃者は From ヘッダーを介してあらゆる種類の不正なペイロードをユーザーのメールソフトウェアに潜り込ませようとします。


Haddouche 氏が試したのがまさにこの攻撃方法です。


攻撃方法


Mailsploit の脆弱性が悪用された場合の影響は、プラットフォームによって異なります。


RFC-1342 ラッパーを介したコードインジェクション攻撃に対して、12 のメールクライアントが脆弱であることが明らかになっています。たとえば Hushmail では、電子メールアドレスの偽装および Web ベースクライアントへの任意の HTML と JavaScript の挿入(リンク先:英語)が可能であったため、ユーザーは DMARC による保護を迂回した偽の電子メールによるクロスサイトスクリプティング (XSS) 攻撃を受ける可能性がありました。


なお、Hushmail は報告を受けたその日のうちに脆弱性を修正しています。


その他のベンダーは迅速に対応したとは言えません。Haddouche 氏は、影響を受けるベンダー(リンク先:英語)が自身の脆弱性の報告に対してどのように回答したのかを詳しく記した Google ドキュメント(リンク先:英語)を公開しています。


最も注目を集めたのは、偽装対策の保護機能である DMARC を迂回できる点です。送信者が使用を許可されていないアドレスが電子メールの From ヘッダーに含まれていた場合、本来であれば DMARC などの保護機能によって配信は阻止されます。


しかし、Mailsploit を悪用すれば、使用が許可されていない電子メールアドレスを使用が許可されている電子メールアドレスで包むことができます。


たとえば、攻撃者の管理下にあるのは example.org だが、電子メールの送信元が example.com であるように偽装したいとします。


その場合の不正な From ヘッダーは、エンコードされる前は次のように表示されます。


From: fake@example.com\0(fake@example.com)@example.org

エンコード後に電子メールを送信すると、受信側のメール転送エージェント (MTA) では次のように解釈されます。


From: <some RFC-1342 encoded data>@example.org

DMARC によるチェックでは example.org の使用が許可されていることが分かります。したがって、この電子メールはスパムとして扱われません (これは正しい挙動です)。結果、メールは標的ユーザーの受信トレイに配信され、ユーザーのメールクライアントで表示されることになります。


続いて、RFC-1342 でエンコードされたデータがデコードされます。悪意のあるペイロードが正しくフォーマットされていれば (正しいフォーマットはアプリケーションごとに若干異なります)、受信した電子メールクライアントは騙されて、From フィールドに fake@example.com を使用してしまいます。


攻撃では通常、Null 文字 (上記の例では \0)、改行文字、またはこの 2 つの組み合わせが使用されます。これにより、メールクライアントはその後に続くヘッダー内のすべてのデータを破棄します。


結果、MTA が認証に使用するドメインと、メールクライアント表示するドメインが異なることになります。


対策


DMARC を迂回するのがこの攻撃の興味深い点であり、実環境で確認されていますが、アンチスパムエンジンを使用すれば検出は簡単です。


確かに DMARC によってセキュリティは強化されますが、決して万能ではありません。DMARC は SPF と DKIM(リンク先:英語) の両方に依存しているうえに、~all がデフォルトの SPF レコードのような設定が原因で、未知のメールを適切に判断することができません。また、Gmail などの正規サーバー上の不正なアカウントやハッキングされたアカウントから送信された偽メールが、DMARC のテストに合格することも珍しくありません。


電子メールのユーザーは、ソフトウェアアップデートが利用可能になり次第、適用してください。


プログラマーの方は、コーディングにシステムの他のパーツを使用しないでください。また、データがラップ/圧縮/エンコードされる場合には、解除後に必ずデータのサニタイズが行われるようにしてください。


引用元

おすすめの記事はこちら