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