コボルトレター：HTMLメールの危険性
(lutrasecurity.com)- Kobold letters は、HTMLメールが最初は無害に見えても、転送後に別の受信者にはフィッシング内容へ変わるようにする攻撃手法である
- 核心は、メールクライアントが許可する CSS と、転送過程で変わるDOM上の位置を利用し、特定の文言を隠したり再表示したりする点にある
- ThunderbirdとOutlook on the webは、DOM構造とCSSの書き換え方式のため、転送後に隠されていた文言が表示される可能性があり、Gmailは転送時にスタイルを削除することで、より単純な形の露出が可能になる
- Mozilla、Microsoft、Googleには2024年3月5日に問題が報告され、Microsoftは3月26日に即時対応なしで終了し、Googleは4月9日に修正作業中であることを確認した
- ユーザーはHTMLメールをオフにしたり制限モードで閲覧したりできるが、`` のブロックは既存のメールエコシステムにおける多くのユースケースを壊す可能性があり、クライアント側での緩和は容易ではない
攻撃シナリオと核心となるアイデア
- 管理者が転送したメールが、最初は無害な問い合わせメールのように見えても、転送後に新しい受信者にはフィッシングの依頼へ変わる可能性がある
- 受信者にとって送信者は知人であり、場合によっては暗号学的署名まで付いており、電話で転送の事実を確認してもだまされる可能性がある
- 元の受信者である管理者は、自分が転送したメールでフィッシング文言を見ていないため、転送の事実を確認しても攻撃に気づきにくい
Kobold lettersの動作方式
- ほとんどのメールクライアントはHTMLメールで CSSスタイリング を許可している
- メールが転送されると、元メールのDOM上の位置は通常変わり、攻撃者はこの変化を基準にCSSセレクタを適用する
- 攻撃者は、文脈に応じて表示されたり消えたりする要素をメールに入れられる
- 通常時は
display: none;で隠す - 転送後にDOM構造が変わると、
display: block !important;のようなルールで表示する
- 通常時は
- このような要素は通常は見えず、特定の状況でだけ現れ、フィッシングなどに悪用され得るため kobold letters と呼ばれる
- HTMLメールをサポートするメールクライアントやWebメール全般が影響を受ける可能性がある
Thunderbirdでの動作
- Thunderbird関連の問題はMozillaに2024年3月5日に報告され、2024年3月20日の公開予定日と草案が共有された
- 可能な緩和策は議論されたが、実装は後回しにされる予定である
- Thunderbirdはメールを `
` で囲み、それ以外はほとんど変更しない
- メールを転送すると、引用された元メールが再び `
` の中に入り、DOM上で1段階下へ移動する
- 例のCSSは
.kobold-letterをデフォルトで隠し、.moz-text-html>div>.kobold-letterの条件でのみ表示する - 元メールを見る人には常に表示される段落だけが表示されるが、転送メールを受け取った人には隠されていた段落が突然現れる
- 攻撃者はDOM内の相対位置を把握しCSSを制御できるため、メールの一部を隠したり表示したりして内容全体を変えられる
- kobold letterをオーバーレイのようにスタイリングすれば、転送者が元メールに追加したコメントまで置き換えられるため、フィッシングの機会がさらに増える
Outlook on the webでの動作
- Outlook on the webの問題はMicrosoftに2024年3月5日に報告され、2024年3月20日の公開予定日と草案が共有された
- Microsoftは2024年3月26日、即時の措置を取らないことにし、報告を終了扱いにした
- OWAはWebメールなので状況はより複雑で、メールは `
` のようなコンテナに入るが、正確なクラス名は変わる
- OutlookはメールのCSSがWebメールUIのスタイルに影響しないよう、idとclassの前に
x_を付け、CSSもあわせて調整する - 例では、元メールのCSSはOWAでの表示時に次のように変換される
.rps_78fa .x_kobold-letter {display:none}.rps_78fa > div > div > .x_kobold-letter {display:block!important}
- 転送後にはクラスが再び
x_x_kobold-letterのように変わり、CSSも再度更新される - 2つ目のルールでは
.rps_78faとdivの間の>が消えるため、複雑なセレクタを作る際にはこれを考慮する必要がある - OWAの調整は攻撃そのものを防ぐわけではないが、複数のクライアントで同時に動作するkobold letterを作る際には面倒な制約になる
Gmailでの動作
- Gmailの問題はGoogleに2024年3月5日に報告され、2024年3月20日の公開予定日と草案が共有された
- Googleは2024年4月9日に修正作業中であることを確認した
- Gmailはメールを転送するときにすべてのスタイルを削除するため、CSSセレクタで表示有無を文脈に応じて変える狭義のkobold lettersには技術的には脆弱ではない
- しかし、より単純な攻撃は可能である
- 元メールでCSSによりkobold letterを隠す
- 転送時にスタイルが削除されることで、隠された要素が自動的に表示される
- この方式は限定的であり、元では表示され、転送後には消えるという逆の動作はできない
- Gmailはメール送信前のエディタではまだCSSを削除しないため、転送者がコメントを書いている間も隠された段落は見えない
- 結果として送られるメールではスタイルが削除され、2つ目の段落が表示される
- Gmailがエディタ段階でCSSを削除すれば、転送者が送信前に攻撃を発見できるようになり、問題を緩和できる
既存の類似事例との違い
- HTMLメールでCSSにより返信・転送コンテンツが変わり得るという点は新しいものではない
- 過去にも類似した問題が報告されている
- Kobold lettersの違いは、特定の攻撃シナリオに焦点を当て、複数のメールクライアントをあわせて調べている点にある
- HTMLメールの危険性と、それを緩和するためのトレードオフについて議論が必要である
緩和策と限界
- ユーザーはHTMLメールを完全に無効化したり、Thunderbirdの「plain HTML」のような制限モードで閲覧したりできる
- メールクライアントが `` の使用を防げば問題を解決できるが、メールエコシステムにおける既存の多くのユースケースが壊れる可能性がある
- Gmailのように転送時にスタイルを削除する実装は、スタイル付きの企業ニュースレターを許可しつつ、HTMLメールの危険を制限する折衷案になり得る
- 近い将来、メールクライアントが強力な緩和策を実装すると期待するのは現実的ではない
- ユーザーは HTMLメールの危険性 を認識し、必要な予防措置を自ら取る必要がある
1件のコメント
Hacker News のコメント
「それでも確信が持てないので管理者に電話して、そのメールが本物か確認する。管理者がそうだと言うので送金する」という部分は、かなり大きな仮定のように感じる
普通は「このメールを送りましたか？」のように曖昧に聞くより、「本当にこういう形で送金しろということですか？」ともっと具体的に聞くはずで、そうすれば管理者は当然困惑し、その会話の中で攻撃が止まる可能性が高い
興味深い攻撃経路ではあるが、実際の成功可能性には疑問がある。記事は、この攻撃が成立するにはかなり具体的で狭い出来事の流れが必要だと描いているが、個人的にはあまり納得できない
フィッシングが実際に通用することは知っている。ただ、フィッシングに引っかかる人にはここまで精巧な攻撃は必要なく、むしろ攻撃者がここまで具体的な労力をかけると成功確率を狭めてしまう可能性もある。普通のフィッシングメールだけでも成功する可能性は高い
その役員たちの情報は LinkedIn や会社サイトで簡単に見つけられたし、しかもその事例はフィッシング対策研修のまさに例として挙げられていたのにそうだったので、驚くかもしれない
https://www.microsoft.com/en-us/research/publication/why-do-...
攻撃者は「現在出張中です。不明な点があれば私の個人携帯に電話してください……」のような文言を入れ、その後偽の音声で応答することもできる
標的に到達する良い方法は「二重転送」かもしれない。送信者が、管理者のメールを事務担当者の近くにいる社員へ転送する社員の役を演じ、その社員が誕生日のお祝い、あるいは病欠のお知らせのような理由で一見無害なメールをさらに転送すれば、実際の標的はメールの元の出所を把握しにくくなる
ほかにも、この「機能」をもっと創造的に悪用する方法は簡単に思いつく。たとえば、何も知らない人に問題のある内容を転送させたうえで脅迫する、といったことも可能だ
支払い依頼がメールで来るたびに担当者が毎回ラインマネージャーへ電話するわけではないだろうし、特に金額が小さく事前承認が不要な場合はなおさらだ
Google も、実際の作業がなかったのに誰かにお金を支払う詐欺に遭ったことがあったと記憶している。その事例には偽の請求書が含まれていたが、原理は同じだ
数日前、デザイナーが作った「アップデート」メールのデザインを見ていたら、最上部に置かれたばかげるほど大きなグラフィックヘッダーのせいで、スクロールしなければメールの件名テキストすら見えなかった
その後、別のバージョンを転送してフィードバックを求めたところ、突然フォントが少し小さくなったように見えると言って戸惑い、「あ、転送するとモバイル版ではなくデスクトップ版に変換されるんですね！」と言った
それを見て信じられず、ぼうぜんと見つめてしまった。これはメールなのに、「デスクトップ版」と「モバイル版」とはどういう意味なのか？ どうしてそんなものが成り立つのか？ 「変換」されるとはどういう意味なのか？ 単にコピーしているだけのはずだ。転送したときに「壊れる」という事実そのものが、このやり方がどれほど愚かかを示している。いったいなぜ自分のメールに CSS が入っている必要があるのか？
斜体程度を表現したいなら Markdown のようなはるかに単純な方式を採用すべきだったのに、いまだにそうなっていないのはおかしい。この状況を本気で改善しようという関心がどれほど少ないかを示している。すべて、ロゴやバナーをあらゆる場所に入れたがる奇妙な企業ニーズに合わせるためだけだ。HTML メールは本当にばかげている
[1] https://www.rfc-editor.org/rfc/rfc1896.txt
メールのリッチテキストには HTML ではなく、Markdown からインライン HTML を除いた形、あるいは似たような単純なテキストマークアップを使うべきだと長らく主張してきた
そうすれば、メールクライアントはリッチテキストとして表示するか、単なるプレーンテキストとして表示するかを簡単に決められ、一般ユーザーが必要とする大半の書式もサポートできる。太字、斜体、引用、インライン画像、コードブロック、見出しなどだ
非常に高度な HTML を使うマーケティングメールには向かないだろうが、そうした用途を気にする必要があるとは思わない
https://en.wikipedia.org/wiki/Enriched_text
https://www.rfc-editor.org/rfc/rfc1896.html
いまだにメールではハイパーリンクを張るサポートすらなく、最近それを直そうとした
https://pastebin.com/kHQs50xm
組織にとって本当のリスクは、HTMLメールを作れと任された開発者が正気を失い、サーバールームに閉じこもって「なんで Outlook のレンダリングが違うんだ」と叫びながら、すべてのハードウェアを破壊することだ。
もちろん真面目に言えば、これは非常に興味深い脆弱性だ。
スタイルシートは許可せず、タグの インライン style 属性だけを許可すれば直せるのでは？
使い勝手のために、メールクライアントがすべてのスタイルシートをインラインスタイルへ「コンパイル」する自動ステップを入れることもできる。
そうすれば高度な CSS セレクター、たとえば hover のようなものだけが壊れるはずだが、それが本当に必要なのかはよく分からない。
疑似クラスとメディアクエリは動かないだろうが、それらはセキュリティリスクになり得るし、主要なメールクライアントでもサポートされていない: https://www.caniemail.com/features/css-at-media/
さらに、すべての style 属性を殺すと、モバイル最適化とダークモードも一緒に死ぬ。メディアクエリはインライン化できないからだ。
通常、基本/デスクトップ向けスタイルはすでにコンパイルされてインライン化されており、モバイル端末で読みやすくするために
head内の style タグにメディアクエリのセレクターを置く。本当に賢い。
前提は、HTMLメールの CSS によって、あるテキストがメッセージを転送した後にだけ見えるようにできる、ということだ。これは 検証済みメールの信頼性に対する大きな脅威だ。
Thunderbird、Outlook、Gmail の例が示されており、素晴らしい仕事だ。
私はすべてのメールを mutt で読んでいるので、公式には「他人事」だ。
そこで別の点に文句を言うなら、Mozilla に報告した日付が 05.03.2024 になっている。リトルエンディアンの日付がアメリカ式のミドルエンディアンの日付より筋が通っていることには同意する。
しかし技術者なら、ISO 8601 日付形式である 2024-03-05 を、ハイフンの有無にかかわらず、使わないのは間違っていると思う :)
リトルエンディアンには、少なくとも他のすべての数字の書き方とは逆だという長所があるが、ミドルエンディアンはただ狂っている。もちろん、だからこそアメリカ人が使う方式でもある。
言及されている一部のメールクライアントが、メール本文を追加の HTML タグで包み、CSS とクラス名を変更しているのが見える。
なぜメールクライアントは HTMLメールをレンダリングするときに サンドボックス化された iframe を使わないのだろう。まだセキュリティリスクがあるのか？
転送する人がメールにさらにテキストを追加したい場合があるので、予想できる動作だ。
ただしメール内にウェブサイトへのリンクがあり、サンドボックス化された iframe が JavaScript を許可していない場合、その セキュリティコンテキストが iframe 内のリンクをクリックして開いたページにまで引き継がれ、ウェブサイトが JS を使えなくなった。
解決策は
allow-popups-to-escape-sandboxだったので、今では動作しない理由はなさそうだ。傷を治すと言って手足を切り落とすような典型的な解決策だ。問題は、この種のハックが幅を利かせることを許してきた メール標準化の不備にある。
HTML 全般がこうした懸念に弱いのは確かだ。それでも問題なく HTML を使っているメールは多い。この記事は、実際に遭遇した何かに対する個人的な苛立ちを、セキュリティ問題のように包み直したもののように読める。
頭に浮かぶ可能な緩和策はこうだが、効果はないかもしれない: 隠し要素に目立つ警告を出す、受信側・送信側の両方でラップする div の数をランダム化する、転送時に実際どう見えるかを計算し、大きく違う場合は確認を求める。
あるいは逆方向に処理する方が効果的かもしれない。他のクライアントの協力を必要としないからだ。
「なぜメールは組織にとって危険なのか」に直せばよい。
この記事は HTMLメールに固有の攻撃経路を示しているが、メールを通じた攻撃の大半は WhatsApp、Slack、Jira、Zoom、あるいは人々が外部とやり取りするあらゆるツールにも容易に移せる。