2 ポイント 投稿者 GN⁺ 2024-04-05 | 1件のコメント | WhatsAppで共有

コボルドの手紙

  • HTMLメールを技術的に扱わなければならない人は、クライアントごとに実装が食い違うせいで仕事を辞めたくなったり、すべてのメールクライアントに火をつけたくなったりする瞬間に至ったことがあるはず。
  • HTMLメールは単なる苛立ちの原因であるだけでなく、深刻なセキュリティリスクにもなり得る。
  • 上司が多額の送金を指示するメールを転送してきたと想像してみると、CEO詐欺について聞いたことがあるので、そのメールが本当に上司から来たものか確認する。
  • メールが実際に上司からのもので、会社でそうした運用をしているなら、暗号署名まで付いているかもしれない。
  • それでもまだ確信が持てず、上司に電話してメールの真正性を確認する。
  • 上司が確認してくれたので、送金する。
  • しかし、これが詐欺でなかったなら、この記事はここで終わっていただろう。

Thunderbird

  • この問題は2024年3月5日にMozillaへ報告され、予定している公開日と次の節の草案は2024年3月20日にMozillaへ送られた。
  • 考えられる緩和策は議論されたが、実装は後日になる予定。
  • Thunderbirdでこれを悪用するのは簡単。Thunderbirdはメールを `

` で囲むだけで、それ以外は変更しない。

  • メールを転送すると、引用されたメールはさらに別の `

` で囲まれ、DOM内で1段下へ移動する。

  • これを踏まえると、次のような概念実証が得られる:

      .kobold-letter {
        display: none;
      }
      .moz-text-html>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.

  • メールには、常に見えるテキストと、display: none; で隠されたテキストが含まれている。
  • メールを転送すると、隠されていたテキストが突然、新しい受信者にだけ見えるようになる。

Outlook Web

  • この問題は2024年3月5日にMicrosoftへ報告され、予定している公開日と次の節の草案は2024年3月20日にMicrosoftへ送られた。
  • Microsoftは2024年3月26日に即時対応を取らないことを決定し、報告をクローズした。
  • Outlook Web (OWA) では状況はやや複雑。メールは `

` で囲まれるが、正確なクラス名は変わる可能性がある。

  • メールのCSSがウェブメーラーのスタイルに影響しないように、Outlookはメール内のすべてのidとclassの先頭に x_ を付け、CSSを調整する。
  • これを踏まえると、次のような概念実証が得られる:

      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.

  • メールをOWAで表示すると、CSSは次のようになる:

  • メールを転送した後、コボルドの手紙はさらに別の `` で囲まれ、CSSも再び更新される。

Gmail

  • この問題は2024年3月5日にGoogleへ報告され、予定している公開日と次の節の草案は2024年3月20日にGoogleへ送られた。
  • Gmailは技術的にはコボルドの手紙に対して脆弱ではない。メールを転送するときに、すべてのスタイルを削除するため。
  • メールを転送する際、CSSが削除されるまでの間は、CSSで隠されたコボルドの手紙が自動的に現れる。

以前の研究

  • このような可能性があることは、驚くべきことでも新しいことでもない。
  • 類似の問題は過去にも報告されている。

展望

  • ユーザーは、HTMLメールを完全に無効化するか、制限付きモードで表示することで、コボルドの手紙を緩和できる。
  • メールクライアント側では緩和策の実装が難しい。`` の使用を防げば問題は解決できるかもしれないが、メールのエコシステムですでに存在する多くのソリューションを壊す可能性がある。
  • 残念ながら、近い将来にメールクライアントが堅牢な緩和策を実装すると期待するのは現実的ではない。

GN⁺の意見

  • この記事はHTMLメールの脆弱性を示しており、特にメールが転送される際に内容が変化し得る「コボルドの手紙」攻撃について説明している。これはメール利用者にセキュリティへの警戒心を促す重要な情報。
  • メールクライアントがCSSを扱う方法によってセキュリティ脆弱性が生じ得ることを示しており、ユーザーと開発者の双方にセキュリティへの注意を促している。
  • この種の攻撃は、ユーザーが信頼する送信元から来たように見えるため、特に危険。これはメールによるコミュニケーションでは常に警戒が必要であることを強調している。
  • 技術的な観点では、メールクライアント開発者はこのような攻撃を防ぐためにCSS処理方式を改善する必要がある。しかしそれは既存のメールデザインや互換性の問題を引き起こし得るため、適切なバランスを見つけることが重要。
  • この記事は新しい技術やオープンソースに関するものではないが、メールセキュリティ関連技術を導入する際に考慮すべき点を提示している。メールクライアント開発者は、ユーザーの安全性を高めつつ使いやすさを維持できる方法を模索する必要がある。

1件のコメント

 
GN⁺ 2024-04-05
Hacker Newsの意見
  • “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”

    • このコメントは、メールによる送金依頼に疑いが生じたとき、単に「このメールを送りましたか」と尋ねるのではなく、「本当にこのように送金してほしいのか」のように具体的に確認すべきだという点を強調している。こうした会話によって攻撃が失敗する可能性が高まるという意見を示している。また、記事で説明されている攻撃シナリオが成功するには非常に特定的で限定的な状況が必要だと指摘し、このような複雑な攻撃が実際に成功する可能性に疑問を呈している。
  • The other day I was discussing the design for an "update" email that our designer was putting together...

    • このコメントは、メールデザインに関する体験談を共有している。デザイナーが作成したメールのグラフィックヘッダーのせいで、件名を見るためにスクロールしなければならない問題を指摘し、メールが転送されるとモバイル版からデスクトップ版に変換されることへの驚きを表している。メールにCSSが使われていること自体が不要だと批判し、Markdownのようなシンプルなテキストマークアップが導入されていない現状に不満を示している。
  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • このコメントは、メールではHTMLの代わりにMarkdownやそれに類するシンプルなテキストマークアップを使うべきだと主張している。そうすれば、メールクライアントがリッチテキストとして表示するかプレーンテキストとして表示するかを判断しやすくなり、ユーザーが必要とする大半の書式設定をサポートできると説明している。マーケティングメールで使われる高度なHTMLは重要ではないという意見を示している。
  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

    • このコメントは、HTMLメールを生成するよう任された開発者が、Outlookの異なるレンダリングのせいで気が狂ってしまうかもしれない、という冗談を交えつつ、メールを使った攻撃は興味深いと述べている。
  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • このコメントは、メールでスタイルシートを許可せず、タグ上のインラインstyle属性だけを使うことで問題を解決できるのではないかと提案している。メールクライアントにスタイルシートをインラインスタイルへ自動変換する段階を含めれば、使い勝手が向上する可能性があると主張している。
  • HTML in email shouldn't be as big of a nightmare as it is.

    • このコメントは、メールにおけるHTMLがここまで大きな悪夢であるべきではないと述べている。すべてのメールクライアントがテキストかHTMLかを確認し、HTMLであればレンダリングエンジンをWebKitに切り替えれば、問題は簡単に解決できるはずだと主張している。こうした標準が提案されたことがあるのか疑問を呈している。
  • Some possible mitigations from the top of my head (maybe ineffective):

    • このコメントは、メールを使った攻撃を緩和するためのいくつかの方法を挙げている。隠された要素への警告や、転送時にメッセージの見た目を計算し、大きく異なる場合は確認を求めることなどがその例である。
  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

    • このコメントは、HTMLメールのセキュリティリスクについてブログ記事を書いたと述べている。HTMLメールの仕様は古く、セキュリティ上の考慮がほとんどなく、安全なHTMLメールはHTMLのサブセットであるべきだが、そのサブセットが何であるかを誰も定義していないように見えるため、セキュリティ欠陥が絶えず発生していると指摘している。
  • This is really clever!

    • このコメントは、HTMLメールでCSSを使い、メッセージが転送された後にのみ特定のテキストが見えるようにする手法は非常に巧妙だと称賛している。その結果、検証済みメールの信頼性に対する大きな脅威になり得ると述べている。また、メールクライアントがメール内容を追加のHTMLタグで囲み、CSSやクラス名を変更することについて疑問を示している。メールクライアントがHTMLメールのレンダリングにサンドボックス化されたiframeを使わない理由にも疑問を呈している。