OpenPGPとS/MIMEに脆弱性、適切な実装をしていないクライアントが原因 21
クライアント側で対応できそうだ 部門より
OpenPGPとS/MIMEで、復号したテキストを攻撃者が取得可能な脆弱性が発見されたとして、使用を一時中止するよう呼びかけられている。脆弱性は「EFAIL」と名付けられ、特設サイトで情報が公開された(EFFの記事[1]、[2]、Ars Technica、論文PDF)。
EFAILでは、攻撃者が中間者攻撃などにより取得した暗号化電子メールを用い、この暗号文を含むHTMLメールを元の送信者または受信者に送り付ける。このHTMLメールは暗号文がimgタグのsrcの一部(http://攻撃者のサーバー/暗号文)となるように細工されており、メッセージを読むと復号されたテキストが攻撃者のサーバーに送られるという仕組みだ。
S/MIMEが暗号化に使用するCBCモードとOpenPGPが暗号化に使用するCFBモードでは暗号鍵を知らなくても暗号ブロックの順番入れ替えや削除、挿入が可能であり、これによりメッセージを細工する。Mozilla ThunderbirdとApple Mail、iOS Mailではこういった細工は不要で、3パートの電子メールメッセージで2番目のパートに暗号文を配置し、最初と最後のパートに分割して配置したimgタグで挟むだけで平文が取得できたそうだ。
CBC/CFBモードで改変が可能になるのはS/MIMEとOpenPGPの仕様上の問題であり、正しく実装しているクライアントはすべて脆弱性があると特設サイトでは説明している。これに対しGnuPGのFAQページを管理するRobert J. Hansen氏は、暗号文を改変可能な問題の対策として、GnuPGでは18年近く前から改変が検出された場合やMDC(改変検出コード)がない場合に警告を出していると述べ、警告を無視するクライアントの問題だと反論。脆弱性なしとされたProtonMailもこれに同調している。なお、テストされたOpenPGPをサポートするクライアント28本のうち、攻撃が成功したのは10本にとどまる。
なお、この脆弱性は公表予定とされた日の前日に各所からリークが発生し、その結果予定日よりも早く公表されることになっていたという。
特設サイトの日本語訳 (スコア:5, 参考になる)
特設サイトを日本語訳した。
https://qiita.com/rana_kualu/items/f92a3a10b7b872ba36cd [qiita.com]
コメントで適切な指摘してくれた人 [srad.jp]がいるので、誰かプラスモデしてあげてください。
Thunderbirdの情報 (スコア:4, 参考になる)
PGPは、Enigmail 2.0 (2018/3/25リリース)以降で修正済み。
よって、EFF推奨のEnigmailの無効化ではなく、バージョンアップするべき。
S/MIMEは、修正予定のThunderbird 52.8が出るまでの間、HTMLメールを無効にすれば緩和できるそうです。
https://twitter.com/kitagawa_takuji/status/996205252230594560 [twitter.com]
Re: (スコア:0)
別にHTMLメールを無効にしなくても、リモートコンテンツのロードを無効にすればOKでしょ。
そもそもリモートを許可してると、スパマーなんかにメールアドレスの存在や開封までがバレてしまう。
セキュリティ的にも無効にしておくべきだと思ってるけど、どのメールアプリもデフォルトで有効なのかな。
Re: (スコア:0)
少なくともThunderbirdはデフォルトでブロックするはず
https://support.mozilla.org/ja/kb/remote-content-in-messages [mozilla.org]
つーか任意コード実行なんかだったらともかく、この脆弱性で代替手段すら提示せず直ちに使用中止しろというのがそもそも意味わからない。別に平文メールより危険になるわけでもないのに。
Re: (スコア:0)
いや、過去のメールをけしかけられるとデコードして送信しちゃう(発症したら)
なので、うかつな状況だと平文よりタチが悪い
# 平文が安全、という意味ではない、念のため。
あとTo/Cc(/Bcc)された誰かがひっかかるだけでいいので、最悪の阻止で当座禁止、と言いたくなるのはわかる。(他の人のはメールクライアントがどれなのか不明だからね、Tbが対処されたからって、他のクラアントがされてなければそこから抜けるので...)
...と思うがどうだろう
Re: (スコア:0)
平文メールを開いたときにも同等の攻撃は可能(ていうかはるかに容易)だから、使用を中止する理由にはまったくならない。
Re: (スコア:0)
結果だけでなく当事者の認識の違いは重要だと思うが。
Re: (スコア:0)
例えば、過去に攻撃者が盗聴などによって暗号化メールを入手済みだったとして、
今まではそれを解読するには何十年というCPU時間をかけて解読する必要があった。
これからはこの脆弱性のおかげで一瞬で解読できるようになった。
過去に盗聴した暗号化メールをそのまま被害者本人に送りつければ、
被害者本人のメールクライアントが自動的に解読して返信してくれるようになった。
それがEFAIL。
Re: (スコア:0)
でも、「過去に盗聴した暗号化メール」を将来的に復号するために保存しておく、という組織って世界でも限られてそう。
そんな目先の利益にならないものを大量に保存できるとこなんて、米中露あたりのサイバー監視組織くらいじゃね。
それか、民間でもピンポイントでターゲット絞って盗聴してるんかねぇ。
/PGP脆弱性待ちファイル/2018/5/17/JP/xxxxxx.eml
/TLS脆弱性待ちファイル/2018/5/17/US/xxxxx.html
とか管理してるのかな。
Re: (スコア:0)
戦時中の暗号解読のノウハウを漏れ聞くだけで、暗号文の収集は暗号解読に置いて非常に重要だったことが容易に分かる。
脆弱性を知って初めて手を出すようなやつはそりゃ収集してないだろうが、
本気で暗号解読の意思を持っていたやつなら収集していると思うべき。
Re: (スコア:0)
攻撃者が平文でメールを入手できるなら解読の必要すらないわけで。使用を続けたほうが平文より危険になる事例でなければ直ちに使用を中止する理由にまったくならないのは理解できる?
# どうしてこんな見当外れのクソリプばっかつくんだ
Re: (スコア:0)
使用を禁止されたから平文で送ろう!
という高いセキュリティ意識を持っているのだから大丈夫でしょう。
その他のセキュリティ意識の低い方々を救済するためにも中止するのは妥当ですね。
「適切」の定義 (スコア:1)
タイトル
OpenPGPとS/MIMEに脆弱性、適切な実装をしていないクライアントが原因
本文
CBC/CFBモードで改変が可能になるのはS/MIMEとOpenPGPの仕様上の問題であり、正しく実装しているクライアントはすべて脆弱性があると特設サイトでは説明している。
別途チェックをするのは「より適切」だけど、仕様バグに忠実な実装を「適切でない」とするのは心情的に辛いなぁ。
それって仕様を作った側の落ち度まで実装側に押しつけることになるもん。
ProtonMailって何だ? (スコア:1)
と思って調べてみたら、スイス発祥の安全な電子メール [protonmail.com]らしい。
あとでアカウント作ってみよう。
Wikipediaによると [wikipedia.org]、「ProtonMailは無料で利用できるが制限があり、代金を支払うことで制限を緩くすることができる。無料アカウントの場合、保存容量が500MB、1日あたりの送信制限が150通、1時間あたりの送信制限が50通で受信に制限はない。」とのこと。
俺の使い方では無料で使えそう。
シンプルだな (スコア: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タグの途中ですら使えますからね、コメントアウトできない理由がない。