パスワードを忘れた? アカウント作成
12647264 story
暗号

Let's Encryptの証明書、不正広告攻撃に悪用される 41

ストーリー by headless
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氏は発行後の取り消しについて、効果的でなく現実的でもないとしている。今回の攻撃で使われた証明書を取り消すことはないが、問題のサイトは停止されるだろうとも述べているとのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ISRG エグゼクティブ・ディレクターのJosh Aas氏はこういった事態が発生することを予め想定しており、Let's Encrypt のオープンベータ開始から1ヶ月以上前に フィッシング詐欺やマルウェアとの戦いにおける認証局の役割 [letsencrypt.jp](原文は The CA's Role in Fighting Phishing and Malware [letsencrypt.org])というブログ記事を書いてます。

    長いので要約すると、

    • 詐欺サイトに対しても平等にDV証明書を発行して良いという考え方もあるし、そうすべきではないという考え方もあるよね。色々な意見があることは承知している。
    • 技術的な観点からすると、DV証明書は公開鍵がそのドメインに属することを明白にしているに過ぎず、サイトのコンテンツの内容や運営者が誰であるかについては一切言及していない。
    • でも、アンチフィッシングやアンチマルウェアの働きをしたり、広くコンテンツを取り締まったりする立場にない。そもそも、認証局には、Webサイトのコンテンツを継続してチェックする能力がない。
    • Webページ固有のフィッシング詐欺やマルウェアの有無に関するステータスの表示機能は、ブラウザのUIに組み込まれているんだから、それで良いのでは? ブラウザの機能ならなぜブロックしたのかといった情報を適切に表示したりできるし、ブラウザに任せた方が良い。
    • 哲学的な観点・道徳的な観点からすると、認証局がネット上の言論や存在の門番となってしまったら、認証局のミス(悪意のないミスやそれ以外のミス)が検閲となってしまう。これは、おそらく、認証局の役割としては適切ではない。
    • Let's Encryptが、フィッシング詐欺サイトやマルウェア配布サイトであるかどうかのステータスを(Google のセーフブラウジングAPIで)チェックするのは、DV証明書の場合でさえ、認証局が完全にアンチフィッシングとアンチマルウェアの努力を放棄することに、多くの人たちがまだ慣れていないから。

    といった感じ。

    ちなみに、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サイト といった誤解をしている人がいますが、それが間違いであることは明白です。

    • しいていえば、DV、OV、EVという分類以外にWeb、メール、コード署名みたい分類の1つとして、本体Webのみ用みたいなサブ区分があればいいのかなと思う。

      このタイプならたとえば、元ページ以外の埋め込みの外部ドメインならNGになる、とかなら比較的問題を減らせると思うんだが、どうだろう。

      # というか、トラッフィック負担とか安全性保障を考えると、信頼できる広告会社のEV以外は弾きたい所

      --
      M-FalconSky (暑いか寒い)
      親コメント
    • 批判する側はLet's Encryptが想定した範囲内だと理解したうえで問題視しているわけで、Let's Encrypt側の想定の範囲内だから「問題視すべきではない」ということもないでしょう。
      親コメント
    • by Anonymous Coward

      証明書の件については「そもそもDV証明書を過度に信頼するユーザが間違ってる」って論なのに、
      GoogleのセーフブラウジングAPIについては「Googleが悪い」って言ってるのがちょっと、筋が通ってないんじゃないかと思う。

      DV証明書のような「仕様に基づく限界をユーザは理解しなければならない」という考えをベースにするスタンスなら、
      Googleセーフブラウジングだって、Googleはユーザになにも保証してないのだから、過度に信頼するユーザが悪い。

      逆に、企業にはそれなりに責任って物がある、というスタンスでいうなら、
      一般ユーザの、SSL証明書に対する過度な信頼は大手CA局のせいであって、
      DV証明書に本来の技術で対応できる以上の信頼を寄せてしまう一般ユーザは何も悪くない。

      • DV証明書のような「仕様に基づく限界をユーザは理解しなければならない」という考えをベースにするスタンスなら、
        Googleセーフブラウジングだって、Googleはユーザになにも保証してないのだから、過度に信頼するユーザが悪い。

        Google セーフブラウジングAPIの「誤検出」というのは、Google セーフブラウジングAPIを採用しているブラウザのユーザーが不利益を受けるだけでなく、Webサイトのオーナーに冤罪をふっかることになります。意図してそのサービスを利用しているユーザー以外のWebサイトオーナーが不利益を受け、事実上の検閲になり得るので、誤検出≒冤罪への対応が不十分な Google が悪いと考えています。

        また、DV証明書は悪質なサイトでないことを証明するものではないので悪質なサイトに対処する必要はありませんが、Google セーフブラウジングAPIはマルウェアやフィッシングを検出するための機能なので、誤検出を迅速に修正するのは本来の業務の範囲であるべきです。仮に、誤検出をしてしまうまでは仕方ないとしても、誤検出に対するクレームにまともに人間が対応する窓口が無いのは問題です。

        一般ユーザの、SSL証明書に対する過度な信頼は大手CA局のせいであって、
        DV証明書に本来の技術で対応できる以上の信頼を寄せてしまう一般ユーザは何も悪くない。

        確かに、おっしゃる通り、諸悪の根源は「一般ユーザー」ではなく、(EV証明書ができる前の)過去の大手認証局の宣伝だと思います。

        # DV証明書に過剰な信頼を寄せることはユーザーにとって不利益(皮肉なことにも EV証明書を高額で売りたい今現在の大手認証局にとっても不利益)なので、誤った認識は修正されるべきですが。

        親コメント
        • by Anonymous Coward on 2016年01月11日 15時13分 (#2947522)

          EV証明書にしても登記簿や戸籍みたいなものですよね。
          その組織の実在を証明するのが目的であって、善良か悪徳かについては何も言っていない。
          DV証明書に至っては、トイレのドアをノックしてノックが返ってきたら、その個室に人がいる程度の事しか分からない。
          いずれにせよ、その相手を信用するかどうかはユーザーが自分で判断する以外にない。当たり前の話ですね。

          親コメント
      • by Anonymous Coward

        元コメに対して、ユーザに責任転嫁してGoogleを弁護するのは、さすがに無理があるだろ。

        単に手続きに従って発行しているだけの証明書と、積極的なネット検閲であるGoogle Safe Browsingは同列には扱えない。
        この件でLet's Encryptには何の瑕疵もないが、合法なサイトを誤判定して閲覧を妨げ、サイトに損害を与えるのは、Googleに瑕疵がある。
        そりゃ技術的にはオフにできるけど、ChromeとFirefoxでデフォルトで適用されており、
        誤判定のリスクもオフにする方法も明確に表示されていない状態で、「ユーザの選択だ」というのは、
        サービス提供業者の肩を持ち過ぎだ。

    • by Anonymous Coward

      犯罪者やテロリストを取り締まるのはソフトウェアランセンスではないって考え方と似てますね。
      感情的に許せない人が多そうなのも似てる。

    • by Anonymous Coward

      >DV証明書というのは、単に通信が暗号化されていることと、当該ドメイン名の所有者と通信を行っていることを証明するものなのですから、
      それなら認証局である必要ないだろ。オレオレ証明書と変わらん。

      認証局ってのは最初からドメインがある程度信用できる事を確信した上で証明書を発行することを前提に仕様が組まれてるんだよ・

      • by Anonymous Coward

        > 認証局ってのは最初からドメインがある程度信用できる事を確信した上で証明書を発行することを前提に仕様が組まれてるんだよ・

        ドメインで何をやっているかなんて、考慮せずに証明書は発行されます。
        ぶっちゃけ、管理者ユーザに届くメールアドレスがあって、証明書の発行手数料を支払ってもらえれば
        証明書は発行されます。

        認証局で発行された証明書とおれおれ証明書の違いは、発行した証明書の正当性が、第三者によって保証されるか否かだけです。
        おれおれ証明書を使ってサイトを運営しても、セキュリティは低下しません。
        ただ、証明書が改ざんされていないことや、秘密鍵が漏洩されていないことを自ら保証しないといけませんがね。

    • by Anonymous Coward

      Google叩こうとしてるロジックがAppleの完全否定になってるってことだけはわかった

  • by Anonymous Coward on 2016年01月11日 13時32分 (#2947493)

    と同じレベルのどうでもいいニュース
    DV証明書なんてLet's Encryptがなくても無料で誰でも取れるし…

  • by Anonymous Coward on 2016年01月11日 10時13分 (#2947438)

    akiraaniが「ほらな、だからVerisignとCybertrust以外は信用するなってことだよ」と勝利宣言にくる流れだ

  • by Anonymous Coward on 2016年01月11日 10時18分 (#2947439)

    企業の情シスやってると「なんでもかんでもSSLにすんな」って思っちゃう

    もちろん様々な対策を組み合わせて使ってるうちの1つでしかないけど、とは言え「プロキシサーバーで通信内容チェックしてExploit等は遮断する」みたいなのが使えなくなるからねー

    • by Anonymous Coward

      SSLだからってプロキシサーバーで内容チェックができないわけじゃないでしょ
      その場合プロキシサーバーが証明書の検証をしないといけないけど

      • by Anonymous Coward

        技術的にできるできないで言えば可能だが、実際それやると負荷で大変なことになるよ

        # 社内プロキシ2台立ててるけど、以前HTTPSの中身チェックやろうと見積もり出したら「負荷分散のため同等品があと4台必要」になった

      • by Anonymous Coward

        証明書を検証することとExploitを遮断することは無関係なんですが。

        • by monaoh (12125) on 2016年01月11日 11時54分 (#2947465)

          Exploitを遮断するためにTLSの通信の中身を覗くなら、当然ながら覗こうとするプロキシサーバー側がTLSの端となる必要があり、その結果を本来のクライアントに中継する必要があります。Exploitでないからといってプロキシサーバーが証明書を検証せずにクライアントに渡せば、それ自体が別の重大な脆弱性です。

          「証明書を検証することとExploitを遮断すること」に直接的な関係がないからといって、あなたは本当にそんな対応をするんですか?

          親コメント
    • by Anonymous Coward

      最近はhttpsを復号化できるゲートウェイ機器が多いけど、
      必ず「有効にすると高負荷になる」と脅されるね……。
      早く低負荷で復号化できるようにならないかな。

      まあ負荷以外に、ユーザへ証明書警告が出る旨を周知する
      のも手間なんだけど。

      • by Anonymous Coward

        httpsは地球環境に優しくないな...

    • by Anonymous Coward

      そういえば、ちょうどタイミングよくこんなストーリーが: Firefox、一部のウイルス対策製品の影響でSHA-1対応を一時的に復活 [security.srad.jp]

  • by Anonymous Coward on 2016年01月11日 10時35分 (#2947443)

    どこが悪用なんでしょうか?
    よく分かりませんでした。
    「正規のドメイン」というのが他人のドメインということですか?

    • by Anonymous Coward on 2016年01月11日 10時59分 (#2947453)

      なんでもかんでも「不正」「悪用」の一言で済ますから誤解が発生する、という典型例だな。

      サーバの管理者権限を盗まれたわけでもなし、
      証明機関の機密鍵が漏れたわけでもなし、
      TrendMicroは証明機関に責任を押しつけすぎだ。

      親コメント
    • by Anonymous Coward

      そうは言っても、まあ実際、何について「悪用」と言っているのかは大まかには妄想できるよね?
      軽度なアスペの俺でも、これくらいならちゃんと察せるぜ。

      もちろん、もし世の中の人間全員が技術的に厳密な世界で生きているのであれば
      そりゃ厳密には「どこが悪用なのか」とツッコミ入るけどなw

      • by Anonymous Coward

        で、結局何が悪用なんですか?
        「正規のドメイン」というのが他人のドメインということ?
        他人のドメインのサブドメインの署名書を取得できる?

        分かってるつもりってのが一番危ないんじゃ…

        • 「正規のドメイン」というのが他人のドメインということ? 他人のドメインのサブドメインの署名書を取得できる?

          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 の証明書を取得する場合でも、

          • http(s)://example.com/key
          • http(s)://www.example.com/key

          などへの認証用ファイルの設置を要求されるケースが多いので、一般的な認証局のDV証明書とは異なる仕様なようです。

          Let's Encrypt は「ドメイン所有者」ではなく「ドメインやサブドメインの実質的な使用者」を認証するという考えなのでしょうね。

          親コメント
        • Re:悪用? (スコア:2, 参考になる)

          by Anonymous Coward on 2016年01月11日 13時44分 (#2947494)

          他人のドメインのサブドメインを不正に取得している。
          不正に取得したサブドメインにLet's Encryptを使用して証明書をつけている(悪用している)。

          証明書の取得自体は悪用じゃないけど、取得した証明書を悪用している。

          下手なたとえはあまりしたくないけど、包丁を使って食材を切れば「正規の利用」だけど、それで人を脅したり刺したりしたら「
          悪用」。

          # で、TrendMicroは悪用が確認されたら取り消すべき(包丁のたとえなら回収かな)と提言し、Let's Encrypt側はそれはあまり意味がないと言っている

          これでわかりましたか?

          親コメント
          • by Anonymous Coward

            そうなんだ。ありがとう。サブドメインのハイジャックか。

            しかし、大まかに妄想したり察したりしている人はいつも大丈夫なんだろうか?

    • by Anonymous Coward

      どこかの誰かが著作権を侵害する形で映画のデータやらをYouTubeにアップロードしたら、「YouTubeの悪用」だろ?
      他に表現しようもないから、そう聞いた側が何が起こってるかを正しく把握せにゃならん。

      • by Anonymous Coward

        レジストラのアカウントを乗っ取った行為に対して「DNSの悪用」って言うのは同意できるけど
        Youtubeに映画を上げた時に「windows/chrome/インターネットの悪用」って言うかなあ

        • by Anonymous Coward

          >Youtubeに映画を上げた時に「windows/chrome/インターネットの悪用」って言うかなあ

          何でもかんでも一般化して広げて行くと、「犯罪者は空気中の酸素を悪用」に行き着いてしまうので程度の問題だ、というのには同意。

          そこでなぜ、DNSよりも特化したサービスである証明書の発行サービスを、より一般的な方向に例えて考えようとして混乱してるのかが不可解。
          結論ありきで認識をねじ曲げてしまっているんではないか?

          悪用なんてされ得ないから悪くないんだ、というように無理矢理考えても歪みが生じるだけ。
          悪用されうるサービスは、ちゃんと悪用され得ると認める。そうしないと、適切な対応を取るべき、という議論に発展しない。

          Let's Encryptに関していえば、今の運用で妥当だと多くの人が認識して支持して、この手の難癖を無視できる状態であれば良いだけ。

  • by Anonymous Coward on 2016年01月11日 10時53分 (#2947451)

    Let's Encryptが無かったら金払ってDV証明書を買うだけのこと。

  • by Anonymous Coward on 2016年01月11日 17時08分 (#2947550)

    発行元を厳格に審査している認証局
    悪用されても仕方ありませんと考えている認証局

    とかによって接続するときにブラウザ側で画面に表示して欲しい。

    今の証明書はco.jpドメインとru,cnドメインが同じ扱いって感じだし。

    • まずは、Let's Encryptからの証明書を認めないようブラウザの設定を変えましょう。
      co.jpドメインとru,cnドメインの区別については、ブラウザアドオンで出来るはず。

      親コメント
    • by Anonymous Coward

      その三つは同格ですよ。

      • co.jpは日本国内に登記された会社などが取得できる属性型JPサブドメインのひとつなので、ruとかcnとかみたいなccTLDと同格なはずがありません。汎用jpと間違えた?あ、それともDV証明書ならどこに出るものも同格という意味?

        ruとかcnとか、あとUTC+08:00とかGB2312とか、正直なんかそれだけで不吉な予感。

        ところで、元コメントの

        発行元を厳格に審査している認証局

        って、皮肉じゃなくてどうやって見分けるんでしょうかね。認証局を認証するメタ認証局?

        「EV-SSL証明書なら大丈夫」ってセールスが捗りそう。

        --
        Jubilee
        親コメント
        • by Anonymous Coward

          常識的に発行元を厳格に審査している認証局はってのは
          とりあえずCPSを見ればわかるはずですけど。
          Let's EncryptってCPS自体を作成してるかも怪しいですが。

        • by Anonymous Coward

          高いから沢山取れない→狙いすました任意のコモンネームを使えない

          だけでは?

    • by Anonymous Coward

      アドレスバーが緑になることで簡単に判別できますよ

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...