Let's Encryptの証明書、不正広告攻撃に悪用される 41
ストーリー by headless
let's-malvertise 部門より
let's-malvertise 部門より
Trend Microによると、昨年12月下旬に急増した不正広告(malvertising)攻撃で、マルウェアをホストするサーバーへの通信を暗号化するためにLet's Encryptの発行したサーバー証明書が使われていることが確認されたそうだ。Let's Encryptは無料でDV証明書を発行するサービスで、12月3日にパブリックベータへ移行している(TrendLabs Security Intelligence Blogの記事、
The Registerの記事、
InfoWorldの記事)。
攻撃は不正な広告を用いてAngler Exploit Kitをホストするサイトに誘導し、ネットバンキングをターゲットにしたトロイの木馬をインストールさせるというもの。主に日本のユーザーが攻撃の対象となっており、Trend Microでは昨年9月に確認された不正広告攻撃の続きとみている。
攻撃者はdomain shadowingの手法を用いて正規のドメインにサブドメインを作成し、自分の制御下にあるサーバーに割り当てる。このサブドメインとの通信がLet's Encryptが発行したサーバー証明書で暗号化されていたとのこと。
DV証明書では申請するドメインが申請者の制御下にあるかどうかだけを確認するため、暗号化されているサイトが必ずしも安全なサイトとは限らない。Gartnerは2017年までにネットワークを通じた攻撃の半数がSSL/TLSを使用すると予測している。
Let's Encryptは証明書を発行する前にGoogleのSafe Browsing APIを用いてドメインが悪用されていないか確認しているが、発行後の確認は行っていない。Trend Microのブログ記事では発行後にドメインの悪用が確認された場合、認証局が証明書を取り消すべきだと主張する。
一方、Let's Encryptのサービスを提供するInternet Security Research Group(ISRG)のJosh Aas氏は発行後の取り消しについて、効果的でなく現実的でもないとしている。今回の攻撃で使われた証明書を取り消すことはないが、問題のサイトは停止されるだろうとも述べているとのことだ。
攻撃は不正な広告を用いてAngler Exploit Kitをホストするサイトに誘導し、ネットバンキングをターゲットにしたトロイの木馬をインストールさせるというもの。主に日本のユーザーが攻撃の対象となっており、Trend Microでは昨年9月に確認された不正広告攻撃の続きとみている。
攻撃者はdomain shadowingの手法を用いて正規のドメインにサブドメインを作成し、自分の制御下にあるサーバーに割り当てる。このサブドメインとの通信がLet's Encryptが発行したサーバー証明書で暗号化されていたとのこと。
DV証明書では申請するドメインが申請者の制御下にあるかどうかだけを確認するため、暗号化されているサイトが必ずしも安全なサイトとは限らない。Gartnerは2017年までにネットワークを通じた攻撃の半数がSSL/TLSを使用すると予測している。
Let's Encryptは証明書を発行する前にGoogleのSafe Browsing APIを用いてドメインが悪用されていないか確認しているが、発行後の確認は行っていない。Trend Microのブログ記事では発行後にドメインの悪用が確認された場合、認証局が証明書を取り消すべきだと主張する。
一方、Let's Encryptのサービスを提供するInternet Security Research Group(ISRG)のJosh Aas氏は発行後の取り消しについて、効果的でなく現実的でもないとしている。今回の攻撃で使われた証明書を取り消すことはないが、問題のサイトは停止されるだろうとも述べているとのことだ。
想定の範囲内であって問題視されるべきではない (スコア:5, 興味深い)
ISRG エグゼクティブ・ディレクターのJosh Aas氏はこういった事態が発生することを予め想定しており、Let's Encrypt のオープンベータ開始から1ヶ月以上前に フィッシング詐欺やマルウェアとの戦いにおける認証局の役割 [letsencrypt.jp]（原文は The CA's Role in Fighting Phishing and Malware [letsencrypt.org]）というブログ記事を書いてます。
長いので要約すると、
といった感じ。
ちなみに、Let's Encrypt が証明書取得時に参照している Google のセーフブラウジングAPIは誤検出が極めて多く、それに対する対応も不十分（人件費をケチっていて誤検出のクレームに対応する人間が殆どいないと思われる）で、Webサイト所有者がクレームを送っても放置されることが日常茶飯事です。
ベクターなんかは長期的に誤検出されて大きなダメージを受けた [impress.co.jp]し、「security.srad.jp」が誤検出されていた時期もありました。
Google セーフブラウジングAPIは、Google Chrome や Firefox で標準で有効となっており誤検出≒検閲 となるのですから、技術的に自動判定の誤検出がやむを得ないとしても、Webサイト所有者からのクレームに迅速に対応すべきだと思います。それがコスト的にできないのであれば、無責任に検閲となるようなAPIを提供すべきではないと思います。特に Google は営利企業で、Google Chrome は自社の広告収益増加のために自社サービスへの誘導を目的に配布しているようなものですから、無責任な対応は非難されるべきです。
DV証明書というのは、単に通信が暗号化されていることと、当該ドメイン名の所有者と通信を行っていることを証明するものなのですから、フィッシングやらマルウェアやらの対応をさせるのはお門違いだと思います。そういったことをするのは、セキュリティ対策ソフトの役目なので、証明書発行時の Google セーフブラウジングAPIのチェックも止めて良いと思います。
大手CAが誤認させるような宣伝をして証明書を販売していた時期があった影響か、未だに SSL/TLS による暗号化が行われている ＝ 安全なWebサイト といった誤解をしている人がいますが、それが間違いであることは明白です。
Re:想定の範囲内であって問題視されるべきではない (スコア:1)
しいていえば、DV、OV、EVという分類以外にWeb、メール、コード署名みたい分類の1つとして、本体Webのみ用みたいなサブ区分があればいいのかなと思う。
このタイプならたとえば、元ページ以外の埋め込みの外部ドメインならNGになる、とかなら比較的問題を減らせると思うんだが、どうだろう。
# というか、トラッフィック負担とか安全性保障を考えると、信頼できる広告会社のEV以外は弾きたい所
M-FalconSky (暑いか寒い)
Re:想定の範囲内であって問題視されるべきではない (スコア:1)
Re: (スコア:0)
証明書の件については「そもそもDV証明書を過度に信頼するユーザが間違ってる」って論なのに、
GoogleのセーフブラウジングAPIについては「Googleが悪い」って言ってるのがちょっと、筋が通ってないんじゃないかと思う。
DV証明書のような「仕様に基づく限界をユーザは理解しなければならない」という考えをベースにするスタンスなら、
Googleセーフブラウジングだって、Googleはユーザになにも保証してないのだから、過度に信頼するユーザが悪い。
逆に、企業にはそれなりに責任って物がある、というスタンスでいうなら、
一般ユーザの、SSL証明書に対する過度な信頼は大手CA局のせいであって、
DV証明書に本来の技術で対応できる以上の信頼を寄せてしまう一般ユーザは何も悪くない。
Re:想定の範囲内であって問題視されるべきではない (スコア:3)
Google セーフブラウジングAPIの「誤検出」というのは、Google セーフブラウジングAPIを採用しているブラウザのユーザーが不利益を受けるだけでなく、Webサイトのオーナーに冤罪をふっかることになります。意図してそのサービスを利用しているユーザー以外のWebサイトオーナーが不利益を受け、事実上の検閲になり得るので、誤検出≒冤罪への対応が不十分な Google が悪いと考えています。
また、DV証明書は悪質なサイトでないことを証明するものではないので悪質なサイトに対処する必要はありませんが、Google セーフブラウジングAPIはマルウェアやフィッシングを検出するための機能なので、誤検出を迅速に修正するのは本来の業務の範囲であるべきです。仮に、誤検出をしてしまうまでは仕方ないとしても、誤検出に対するクレームにまともに人間が対応する窓口が無いのは問題です。
確かに、おっしゃる通り、諸悪の根源は「一般ユーザー」ではなく、（EV証明書ができる前の）過去の大手認証局の宣伝だと思います。
# DV証明書に過剰な信頼を寄せることはユーザーにとって不利益（皮肉なことにも EV証明書を高額で売りたい今現在の大手認証局にとっても不利益）なので、誤った認識は修正されるべきですが。
Re:想定の範囲内であって問題視されるべきではない (スコア:1)
EV証明書にしても登記簿や戸籍みたいなものですよね。
その組織の実在を証明するのが目的であって、善良か悪徳かについては何も言っていない。
DV証明書に至っては、トイレのドアをノックしてノックが返ってきたら、その個室に人がいる程度の事しか分からない。
いずれにせよ、その相手を信用するかどうかはユーザーが自分で判断する以外にない。当たり前の話ですね。
Re: (スコア:0)
元コメに対して、ユーザに責任転嫁してGoogleを弁護するのは、さすがに無理があるだろ。
単に手続きに従って発行しているだけの証明書と、積極的なネット検閲であるGoogle Safe Browsingは同列には扱えない。
この件でLet's Encryptには何の瑕疵もないが、合法なサイトを誤判定して閲覧を妨げ、サイトに損害を与えるのは、Googleに瑕疵がある。
そりゃ技術的にはオフにできるけど、ChromeとFirefoxでデフォルトで適用されており、
誤判定のリスクもオフにする方法も明確に表示されていない状態で、「ユーザの選択だ」というのは、
サービス提供業者の肩を持ち過ぎだ。
Re: (スコア:0)
犯罪者やテロリストを取り締まるのはソフトウェアランセンスではないって考え方と似てますね。
感情的に許せない人が多そうなのも似てる。
Re: (スコア:0)
>DV証明書というのは、単に通信が暗号化されていることと、当該ドメイン名の所有者と通信を行っていることを証明するものなのですから、
それなら認証局である必要ないだろ。オレオレ証明書と変わらん。
認証局ってのは最初からドメインがある程度信用できる事を確信した上で証明書を発行することを前提に仕様が組まれてるんだよ・
Re: (スコア:0)
> 認証局ってのは最初からドメインがある程度信用できる事を確信した上で証明書を発行することを前提に仕様が組まれてるんだよ・
ドメインで何をやっているかなんて、考慮せずに証明書は発行されます。
ぶっちゃけ、管理者ユーザに届くメールアドレスがあって、証明書の発行手数料を支払ってもらえれば
証明書は発行されます。
認証局で発行された証明書とおれおれ証明書の違いは、発行した証明書の正当性が、第三者によって保証されるか否かだけです。
おれおれ証明書を使ってサイトを運営しても、セキュリティは低下しません。
ただ、証明書が改ざんされていないことや、秘密鍵が漏洩されていないことを自ら保証しないといけませんがね。
Re: (スコア:0)
Google叩こうとしてるロジックがAppleの完全否定になってるってことだけはわかった
ネットワークインフラ、不正広告攻撃に悪用される (スコア:1)
と同じレベルのどうでもいいニュース
DV証明書なんてLet's Encryptがなくても無料で誰でも取れるし…
あかん、これは (スコア:0)
akiraaniが「ほらな、だからVerisignとCybertrust以外は信用するなってことだよ」と勝利宣言にくる流れだ
うーん (スコア:0)
企業の情シスやってると「なんでもかんでもSSLにすんな」って思っちゃう
もちろん様々な対策を組み合わせて使ってるうちの１つでしかないけど、とは言え「プロキシサーバーで通信内容チェックしてExploit等は遮断する」みたいなのが使えなくなるからねー
Re: (スコア:0)
SSLだからってプロキシサーバーで内容チェックができないわけじゃないでしょ
その場合プロキシサーバーが証明書の検証をしないといけないけど
Re: (スコア:0)
技術的にできるできないで言えば可能だが、実際それやると負荷で大変なことになるよ
# 社内プロキシ2台立ててるけど、以前HTTPSの中身チェックやろうと見積もり出したら「負荷分散のため同等品があと4台必要」になった
Re: (スコア:0)
証明書を検証することとExploitを遮断することは無関係なんですが。
Re:うーん (スコア:2)
Exploitを遮断するためにTLSの通信の中身を覗くなら、当然ながら覗こうとするプロキシサーバー側がTLSの端となる必要があり、その結果を本来のクライアントに中継する必要があります。Exploitでないからといってプロキシサーバーが証明書を検証せずにクライアントに渡せば、それ自体が別の重大な脆弱性です。
「証明書を検証することとExploitを遮断すること」に直接的な関係がないからといって、あなたは本当にそんな対応をするんですか？
Re: (スコア:0)
最近はhttpsを復号化できるゲートウェイ機器が多いけど、
必ず「有効にすると高負荷になる」と脅されるね……。
早く低負荷で復号化できるようにならないかな。
まあ負荷以外に、ユーザへ証明書警告が出る旨を周知する
のも手間なんだけど。
Re: (スコア:0)
httpsは地球環境に優しくないな...
Re: (スコア:0)
そういえば、ちょうどタイミングよくこんなストーリーが: Firefox、一部のウイルス対策製品の影響でSHA-1対応を一時的に復活 [security.srad.jp]
悪用? (スコア:0)
どこが悪用なんでしょうか?
よく分かりませんでした。
「正規のドメイン」というのが他人のドメインということですか?
Re:悪用? (スコア:1)
なんでもかんでも「不正」「悪用」の一言で済ますから誤解が発生する、という典型例だな。
サーバの管理者権限を盗まれたわけでもなし、
証明機関の機密鍵が漏れたわけでもなし、
TrendMicroは証明機関に責任を押しつけすぎだ。
Re: (スコア:0)
そうは言っても、まあ実際、何について「悪用」と言っているのかは大まかには妄想できるよね？
軽度なアスペの俺でも、これくらいならちゃんと察せるぜ。
もちろん、もし世の中の人間全員が技術的に厳密な世界で生きているのであれば
そりゃ厳密には「どこが悪用なのか」とツッコミ入るけどなｗ
Re: (スコア:0)
で、結局何が悪用なんですか?
「正規のドメイン」というのが他人のドメインということ?
他人のドメインのサブドメインの署名書を取得できる?
分かってるつもりってのが一番危ないんじゃ…
「レジストラ」や「レジストラの代理店」のアカウントを乗っ取られた後の話 (スコア:3)
Domain Shadowing [cisco.com] という攻撃方法は、「レジストラ」や「レジストラの代理店」のアカウント、例えば eNom とか お名前.com とか VALUE DOMAIN のアカウントを乗っ取り、正規のドメインに対してサブドメイン（自分のサイトのAレコードを登録）を作りまくって悪用する手口です。
レジストラのアカウントを乗っ取った以上は、サブドメイン以外を書き換えることも技術的には可能ですが、あえてサブドメインの追加のみに留めるているのはドメインの正規所有者に乗っ取られたことを気が付きにくくするためだと思います。サブドメインを勝手に追加しても、正規のサイトにはそのままアクセスできるので、乗っ取り行為の発覚を遅らせる効果があります。
ちなみに、Let's Encrypt ユーザーガイド（Webroot プラグイン） [letsencrypt.jp]によると、サブドメインに対する証明書を取得する場合、サブドメインのドキュメントルート以下に認証ファイルが設置できれば問題無いようです。
ということは、レンタルサーバに契約するとレンタルサーバ会社所有のドメインのサブドメインの使用権が与えられるようなケースの場合、レンタルサーバ契約者がレンタルサーバ会社所有のドメインのサブドメインで Let's Encrypt の証明書を取得できる仕様なようです。権限不足でレンタルサーバ上で Let's Encrypt クライアントが動作しない場合でも、Manual プラグインを使用すれば他のマシンでクライアントを実行できる（認証ファイルのみ手動で設置する）ので、同様に証明書が取得できてしまいます。
他の認証局のDV証明書だと、sub.example.com の証明書を取得する場合でも、
などへの認証用ファイルの設置を要求されるケースが多いので、一般的な認証局のDV証明書とは異なる仕様なようです。
Let's Encrypt は「ドメイン所有者」ではなく「ドメインやサブドメインの実質的な使用者」を認証するという考えなのでしょうね。
Re:「レジストラ」や「レジストラの代理店」のアカウントを乗っ取られた後の話 (スコア:1)
DNS CAAで拒否できるのでは？と書こうと思いましたが、そもそも乗っ取られた状況だとAだけでなくCAAも書き換えできるから、あまり意味がないですかね。
＃なお、Let's EncryptはCAAを見るようだ。Certs for subdomains without the domain owner's permission - Issuance Policy - Let's Encrypt Community Support [letsencrypt.org]には、“Let's Encrypt supports the CAA standard”という回答がある。
Re:悪用? (スコア:2, 参考になる)
他人のドメインのサブドメインを不正に取得している。
不正に取得したサブドメインにLet's Encryptを使用して証明書をつけている(悪用している)。
証明書の取得自体は悪用じゃないけど、取得した証明書を悪用している。
下手なたとえはあまりしたくないけど、包丁を使って食材を切れば「正規の利用」だけど、それで人を脅したり刺したりしたら「
悪用」。
# で、TrendMicroは悪用が確認されたら取り消すべき(包丁のたとえなら回収かな)と提言し、Let's Encrypt側はそれはあまり意味がないと言っている
これでわかりましたか？
Re: (スコア:0)
そうなんだ。ありがとう。サブドメインのハイジャックか。
しかし、大まかに妄想したり察したりしている人はいつも大丈夫なんだろうか?
Re: (スコア:0)
どこかの誰かが著作権を侵害する形で映画のデータやらをYouTubeにアップロードしたら、「YouTubeの悪用」だろ?
他に表現しようもないから、そう聞いた側が何が起こってるかを正しく把握せにゃならん。
Re: (スコア:0)
レジストラのアカウントを乗っ取った行為に対して「DNSの悪用」って言うのは同意できるけど
Youtubeに映画を上げた時に「windows/chrome/インターネットの悪用」って言うかなあ
Re: (スコア:0)
>Youtubeに映画を上げた時に「windows/chrome/インターネットの悪用」って言うかなあ
何でもかんでも一般化して広げて行くと、「犯罪者は空気中の酸素を悪用」に行き着いてしまうので程度の問題だ、というのには同意。
そこでなぜ、DNSよりも特化したサービスである証明書の発行サービスを、より一般的な方向に例えて考えようとして混乱してるのかが不可解。
結論ありきで認識をねじ曲げてしまっているんではないか?
悪用なんてされ得ないから悪くないんだ、というように無理矢理考えても歪みが生じるだけ。
悪用されうるサービスは、ちゃんと悪用され得ると認める。そうしないと、適切な対応を取るべき、という議論に発展しない。
Let's Encryptに関していえば、今の運用で妥当だと多くの人が認識して支持して、この手の難癖を無視できる状態であれば良いだけ。
そりゃタダのものを使いますわ (スコア:0)
Let's Encryptが無かったら金払ってDV証明書を買うだけのこと。
CA局にもランク付けが必要 (スコア:0)
発行元を厳格に審査している認証局
悪用されても仕方ありませんと考えている認証局
とかによって接続するときにブラウザ側で画面に表示して欲しい。
今の証明書はco.jpドメインとru,cnドメインが同じ扱いって感じだし。
Re:CA局にもランク付けが必要 (スコア:2)
まずは、Let's Encryptからの証明書を認めないようブラウザの設定を変えましょう。
co.jpドメインとru,cnドメインの区別については、ブラウザアドオンで出来るはず。
Re: (スコア:0)
その三つは同格ですよ。
Re:CA局にもランク付けが必要 (スコア:1)
co.jpは日本国内に登記された会社などが取得できる属性型JPサブドメインのひとつなので、ruとかcnとかみたいなccTLDと同格なはずがありません。汎用jpと間違えた？あ、それともDV証明書ならどこに出るものも同格という意味？
ruとかcnとか、あとUTC+08:00とかGB2312とか、正直なんかそれだけで不吉な予感。
ところで、元コメントの
発行元を厳格に審査している認証局
って、皮肉じゃなくてどうやって見分けるんでしょうかね。認証局を認証するメタ認証局？
「EV-SSL証明書なら大丈夫」ってセールスが捗りそう。
Jubilee
Re: (スコア:0)
常識的に発行元を厳格に審査している認証局はってのは
とりあえずCPSを見ればわかるはずですけど。
Let's EncryptってCPS自体を作成してるかも怪しいですが。
Re: (スコア:0)
Let's EncryptのCPSはこれでしょうか？http://cps.root-x1.letsencrypt.org/ [letsencrypt.org]（中身は読んでいない）
Re: (スコア:0)
高いから沢山取れない→狙いすました任意のコモンネームを使えない
だけでは？
Re: (スコア:0)
アドレスバーが緑になることで簡単に判別できますよ