アカウント名:
パスワード:
攻撃手段としては単純で攻撃者が先に思いついていて実行していても不思議ではない。国なら中間者攻撃は当然出来るし、公衆Wi-Fiでも比較的容易。普通はサーバーまで暗号化されてるけど、エンドツーエンド暗号化は中間経路が信用できなくても大丈夫なのが強み。とはいえ、多少怪しいメールが届くことになるから多数実行されていれば既に報告がありそうな感じはあるけど。
単純に切り替えのタイミングでタグを閉じればよかったんだろうか。地味に面倒な処理だからXML標準でそういう仕様があれば便利だろうなとは思った人は多いだろうな(HTML可の掲示板作るときとか)。
結構話題になった割にsradに来るのはちょっと遅かったと思った。そしてこれは日記 [srad.jp]の方に付けたコメントの書き直し。
direct exfiltrationの根本原因は、メーラーがメール内に存在しない外部リソースを簡単に読むことと、マルチパートでセキュリティレベルが異なるコンテンツを混在して処理した事ですかね。それこそ、暗号化されたパートは別メール的な感じで処理しないといけないのに、混在した挙句に合成したらそりゃあかん。ログインフォームはHTTPSページなのに、広告がHTTPだから、中間者攻撃でID/PASSが漏洩するよ的なミス。
1番目の外部リソースを簡単に読むことに関して、イメージ埋め込みはハイパーリンクにして、リンク先サーバーがどっかにリダイレクトして証拠隠滅も可能なので外部リソース読み込みしないだけでは対策不足ですかね。
2番目は意外と対応が面倒な気がしますが、そもそもちゃんとしないとダメだよね。前後を好き勝手に改変可能ってことは文意をまるっと変えることすらできるかもしれない。しかしクライアントがちゃんとしてなければ暗号化されてるから真と思い込ませられるソーシャルハック的な手法にも応用できそう。
アイデアとしてはそっちが先なのかな？
2番目については、gnupgの反論の通りmdcをメールクライアントが確認すればいいだけ。あと、今回の攻撃は、事前に盗んだ暗号文を持っていることが条件だってこと解ってる？
MDCがどの程度今回の脆弱性に役立つのかわからないのですが、OpenPGPだろうとGunPGだろうと、メーラーのマルチパートに入っていた暗号文の扱いがタコいといいたいのです。※ 警告無視してエンドユーザーが続行したら結局MDCでエラー検出しようが意味ないし。
「敵の潜水艦を発見！」という暗号文を盗んで「ダメだ！」という内容にするために、+ ＜！－－= 「敵の潜水艦を発見！」+ －－＞+ 「ダメだ！」と改ざんされた場合、EFAIL脆弱性を持つクライアントは「ダメだ！」と表示してしまう。# なんせ、HTMLタグの途中ですら使えますからね、コメントアウトできない理由がない。
こんな物をメーラーが受信したとき、メーラーはそもそも暗号化されていない追加分と暗号化されていたオリジナルを別物として扱わないといけないのに、EFAILの脆弱性を持つクライアントは混在して文書表示している訳です。この脆弱性、文面流出がセンセーショナルに報道されてますけど、文面の信頼性という意味でも致命的な物なんです。確認してませんが、悪意ある添付ファイル1個増やしても該当メーラーでは見分けつかないのでは？
後、メールサーバーから盗まないでも複数受信可能(※GunPGで暗号化しても、CC/BCC機能を使えます)で送られた人物には暗号文と復号化後の文面が解りますので、作文可能です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
シンプルだな (スコア:0)
攻撃手段としては単純で攻撃者が先に思いついていて実行していても不思議ではない。
国なら中間者攻撃は当然出来るし、公衆Wi-Fiでも比較的容易。
普通はサーバーまで暗号化されてるけど、エンドツーエンド暗号化は中間経路が信用できなくても大丈夫なのが強み。
とはいえ、多少怪しいメールが届くことになるから多数実行されていれば既に報告がありそうな感じはあるけど。
単純に切り替えのタイミングでタグを閉じればよかったんだろうか。
地味に面倒な処理だからXML標準でそういう仕様があれば便利だろうなとは思った人は多いだろうな(HTML可の掲示板作るときとか)。
結構話題になった割にsradに来るのはちょっと遅かったと思った。
そしてこれは日記 [srad.jp]の方に付けたコメントの書き直し。
Re: (スコア:0)
direct exfiltrationの根本原因は、メーラーがメール内に存在しない外部リソースを簡単に読むことと、マルチパートでセキュリティレベルが異なるコンテンツを混在して処理した事ですかね。
それこそ、暗号化されたパートは別メール的な感じで処理しないといけないのに、混在した挙句に合成したらそりゃあかん。
ログインフォームはHTTPSページなのに、広告がHTTPだから、中間者攻撃でID/PASSが漏洩するよ的なミス。
1番目の外部リソースを簡単に読むことに関して、イメージ埋め込みはハイパーリンクにして、リンク先サーバーがどっかにリダイレクトして証拠隠滅も可能なので外部リソース読み込みしないだけでは対策不足ですかね。
2番目は意外と対応が面倒な気がしますが、そもそもちゃんとしないとダメだよね。
前後を好き勝手に改変可能ってことは文意をまるっと変えることすらできるかもしれない。
しかしクライアントがちゃんとしてなければ暗号化されてるから真と思い込ませられるソーシャルハック的な手法にも応用できそう。
アイデアとしてはそっちが先なのかな？
Re: (スコア:0)
2番目については、gnupgの反論の通りmdcをメールクライアントが確認すればいいだけ。
あと、今回の攻撃は、事前に盗んだ暗号文を持っていることが条件だってこと解ってる？
Re:シンプルだな (スコア:0)
MDCがどの程度今回の脆弱性に役立つのかわからないのですが、OpenPGPだろうとGunPGだろうと、メーラーのマルチパートに入っていた暗号文の扱いがタコいといいたいのです。
※ 警告無視してエンドユーザーが続行したら結局MDCでエラー検出しようが意味ないし。
「敵の潜水艦を発見！」
という暗号文を盗んで
「ダメだ！」という内容にするために、
+ ＜！－－
= 「敵の潜水艦を発見！」
+ －－＞
+ 「ダメだ！」
と改ざんされた場合、
EFAIL脆弱性を持つクライアントは「ダメだ！」と表示してしまう。
# なんせ、HTMLタグの途中ですら使えますからね、コメントアウトできない理由がない。
こんな物をメーラーが受信したとき、メーラーはそもそも暗号化されていない追加分と暗号化されていたオリジナルを別物として扱わないといけないのに、EFAILの脆弱性を持つクライアントは混在して文書表示している訳です。
この脆弱性、文面流出がセンセーショナルに報道されてますけど、文面の信頼性という意味でも致命的な物なんです。
確認してませんが、悪意ある添付ファイル1個増やしても該当メーラーでは見分けつかないのでは？
後、メールサーバーから盗まないでも複数受信可能(※GunPGで暗号化しても、CC/BCC機能を使えます)で送られた人物には暗号文と復号化後の文面が解りますので、作文可能です。