パスワードを忘れた? アカウント作成
13122896 story
セキュリティ

GoDaddyのSSL証明書発行の際のドメイン所有者確認システムにバグ、証明書8,850件が失効 16

ストーリー by headless
失効 部門より
hylom 曰く、

ホスティングサービスやドメイン名取得代行、認証局などを手がける米GoDaddyは10日、SSL証明書発行の際のドメイン所有者確認システムのバグが判明したため、バグを修正し、発行済み証明書8,850件を失効させたことを明らかにした(GoDaddy Blog - The Garbageの記事徳丸浩の日記の記事ITmediaエンタープライズの記事)。

徳丸浩氏の日記が詳しいが、GoDaddyではSSL証明証発行申請者にランダムなコードを発行し、申請者がこのコードを含むファイルを対象ドメインのサーバーの指定位置に配置したことを確認することで、申請者をドメイン所有者として認証する仕組みを採用している。

しかし、修正前のシステムではWebサーバーのレスポンスコードを確認せず、コードをそのままファイル名にするよう指定していたため、サーバーの設定によってはファイルが設置されていないにもかかわらず、認証成功の扱いになることがある。たとえば、404エラーとともに「The requested URL /<コード>.html was not found on this server. 」というレスポンスが返された場合、レスポンスにコードが含まれるため、ファイルが設置されたものと認識してしまう。これにより、ファイルを設置しなくても証明書を入手することが可能だったという。

問題が発生しはじめたのは2016年7月29日とのことで、この期間に発行された証明書を失効させる手続きが取られたそうだ。

なお、この期間中に発行された証明書のうち、申請者を正しく認証しないまま発行された証明書は2%程度とのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2017年01月14日 14時02分 (#3144278)

    ファイルをおける人ってだけではドメイン管理者かはわからないでしょ?

    • だからそこがまずかった、という話

      # 置ける位置と内容がしっかりしてれば、「ドメイン管理者といえそう」といえるだろう条件はあるが、今回のこれは条件がずさんだった、と

      --
      M-FalconSky (暑いか寒い)
      親コメント
      • なお、「だれでも置けるだろ」というのは、さすがにそのドメインの管理(含む対外的影響:名誉毀損する記事とか違法データとかの意味で)という意味でまずいので、それやってるとこあったらそれはそれで別の問題な気がする。

        # トップから無条件なWikiになってるとか、root/admin/masterとかのアカウントが作れてトップ直下にページができちゃうとか

        限定された条件でWiki/アカウント作成/自動生成ページ/アップロードがあるんであって、ドメイン配下のコンテンツは基本ドメインのオーナーが管理の権限と責任がある、という想定自体はいちおうあっていいと思うので。

        --
        M-FalconSky (暑いか寒い)
        親コメント
      • by Anonymous Coward

        今回のは「ファイル置いてなくてもOK」とされてたって話。置ける位置も内容も問題なかった。その確認がずさんだった、と

        • 内容も良くない。
          徳丸氏の日記でも指摘されているが、ファイル名とその内容に同一のコードを含める設計はマズい。
          ファイル名とは別のコードをセットで発行して、それを確認すべきだ。

          親コメント
          • by Anonymous Coward

            >ファイル名とファイル中に記述する認証コードは別々に発行することで、仮にステータスのチェックが抜けていても脆弱性にならないような設計となります。このように、予防的な設計を心がけることが重要です。

            このケースで「エラーページにファイル名が含まれる」を事前に予想できるならば、当然ステータスのチェックはするだろう。それを予想できなかったことに本質がある以上、この「予防的な設計」の提言は何の意味もない。

            • by Anonymous Coward on 2017年01月16日 7時50分 (#3144863)

              エラーページでなくても、PHPか何かで、本文にURLのファイル名に相当する部分を入れて返す挙動であれば通ってしまうだろ。

              そもそも、リクエストに含まれないデータを検証しなくては、認証になってない。
              「山」に対して「川」と答えるから合言葉になる。「山」に対して〈『山』を含む応答があればOK〉、ではダメダメ。

              親コメント
              • by Anonymous Coward

                なるほど。つーことはファイル名と内容を別にすることこそが本質で、ステータス確認のほうが枝葉でしたか。
                いずれにせよ徳丸さんの指摘は間違っていることに。
                #多層防御みたいな考え方は信頼できない。不完全な防御を多層に積み重ねるより一カ所だけでも「本質的に正しく」対応できてればok。

              • by Anonymous Coward

                > ファイル名と内容を別にすることこそが本質で、ステータス確認のほうが枝葉でしたか。

                そう思う。この場合は内容こそが主だ。

      • by Anonymous Coward

        >だからそこがまずかった、という話

        違います!!

        ストーリーを読みなさい!!

        • すんません、ちょっと語弊がありましたね。

          置くというか、自動生成(エラーページ)やらのことも念頭にありましたが

          ここの
          1.レスポンスコード見てないこと(これも問題だとは理解してます)
          2.-1.サーバによっては、指定されたファイルが生成(それ自体はありかもしれませんが...)できる
          2.-2.ページの中身として確認する内容がファイル名と同じで、2.-1.と絡むとエラーページ内などにそれが記載されていることがあり、騙せてしまう。

          自分として1.はそもそもではあることは了解していました。

          が、それを回避される(成功ページとしてほんとうに作れてしまうこともある)パターンも別の所で例示されてたため、ちょっと意識からはずしてしまっていました。

          # まあ、任意にデータが設定できたら、いろいろ対応しても問題だし、自分の言及も大分アホだったな...

          --
          M-FalconSky (暑いか寒い)
          親コメント
    • by Anonymous Coward

      ドメインのWHOIS情報の中にキーを埋め込んでもらう方が信頼性高そう。
      無駄に個人情報ばらまく仕様なんだし、別の情報載せられるようにしてもいいじゃまいか。

      • by Anonymous Coward

        最低限ドメイン管理者かの確認は認証のための設定をしてもらうことですか、whoisの情報を修正できる人はそれに埋め込むのもありですね。
        ただ実際にはwhoisとドメイン管理者はべつですね。

        • by Anonymous Coward

          ドメイン管理者とは何かって話になるよなあ

  • by Anonymous Coward on 2017年01月14日 20時03分 (#3144448)

    コードサイニング証明書を他人に発行しちゃったら、色々できてまずいのは容易に想像できる。
    でも、SSL証明書を他人に発行してまずいことってあるのかな?実例を思いつかない。

    • by Anonymous Coward

      DNSポイズニングと併用すればフィッシングできるとか。

typodupeerror

アレゲは一日にしてならず -- アレゲ研究家

読み込み中...