WHITE PAPER: White Paper 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み powered by Symantec

Size: px

Start display at page:

Download "WHITE PAPER: White Paper 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み powered by Symantec"

えみたもん
5 years ago
Views:

1 WHITE PAPER: White Paper 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み powered by Symantec

2 Copyright 2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは Symantec Corporation または関連会社の米国およびその他の国における登録商標ですその他の会社名製品名は各社の登録商標または商標です合同会社シマンテックウェブサイトセキュリティは本書の情報の正確さと完全性を保つべく努力を行っていますただし合同会社シマンテックウェブサイトセキュリティは本書に含まれる情報に関して ( 明示黙示または法律によるものを問わず ) いかなる種類の保証も行いません合同会社シマンテックウェブサイトセキュリティは本書に含まれる誤り省略または記述によって引き起こされたいかなる ( 直接または間接の ) 損失または損害についても責任を負わないものとしますさらに合同会社シマンテックウェブサイトセキュリティは本書に記述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず特に本書に記述されている製品またはサービスが既存または将来の知的所有権を侵害しないという保証を否認します本書は本書の読者に対し本書の内容に従って作成された機器または製品の作成使用または販売を行うライセンスを与えるものではありません最後に本書に記述されているすべての知的所有権に関連するすべての権利と特権は特許商標またはサービスマークの所有者に属するものでありそれ以外の者は特許商標またはサービスマークの所有者による明示的な許可承認またはライセンスなしにはそのような権利を行使することができません合同会社シマンテックウェブサイトセキュリティは本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます 2

3 CONTENTS 1. はじめに 4 2.DigiNotar 事件報告書と考察事件のあらまし侵入のタイムラインと被害状況インフラの脆弱性に関する考察 7 3. 再発防止のための認証局の取り組み BASELINE REQUIREMENTS DNS-BASED AUTHENTICATION OF NAMED ENTITIES(DANE) CERTIFICATE AUTHORITY AUTHORIZATION(CAA) CERTIFICATE TRANSPARENCY(CT) 8 4. おわりに 9 3

4 1. はじめに公開鍵暗号の技術を用いたセキュリティ基盤である公開鍵基盤 (PKI:Public Key Infrastructure) において認証局は発行したデジタル証明書の公開鍵が正当であることを保証するという役割を果たしていますデジタル証明書の信頼性を担保する根源とも言える認証局は不正に証明書を手に入れるようとする侵入者によってしばしば攻撃対象として狙われます 2011 年から 2012 年に掛けて認証局 (CA) を標的としたハッキング事件が立て続けに発生しました年 3 月イギリスの認証局からGmail Skype Mozilla Microsoftアップデートなどの偽造証明書が発行される事件が発生 2011 年 8 月オランダの認証局 DigiNotar 社から531 枚以上の偽造証明書が発行された 2011 年 11 月東南アジアの認証局から強度の低い鍵長を使用しているなどの深刻な欠陥がある 22 件の証明書が発行されたことが判明 2012 年 12 月 *.google.com への不正なワイルドカード証明書が発行されていることが Google 社によって発見されブロックされた 2011 年 8 月にトルコの認証局が誤って中間 CA 証明書を発行したことが原因であることが判明巧妙な中間者攻撃を可能にする不正な SSL サーバ証明書発行事件が立て続けに起きたことは当時大きなニュースになりましたこれらの事件に共通することは SSL サーバ証明書そのものではなくそれらを発行している認証局の運用体制に問題があったということですこのホワイトペーパーではこれらの事件の中で最も影響が大きかった DigiNotar 社の事件にスポットライトを当て事件の詳細と再発防止のための認証局の取り組みを紹介いたします 1: 詳細は偽 SSL サーバ証明書発行事件から見る認証局の役割参照 4

5 2.DigiNotar 事件報告書と考察 2.1 事件のあらまし DigiNotar 社は 1998 年にオランダで創業された認証局 (CA) で SSL サーバ証明書やオランダの電子政府のための証明書を発行していました同社は 2011 年 6 月と 7 月に掛けて外部ネットワークから攻撃を受け認証局の管理をする 8 つのサーバ ( リテール向け証明書管理用サーバ EVSSL 証明書管理用サーバ特定顧客用ルート証明書を管理するサーバ等 ) 全てがハッキングされましたその結果後の 2011 年 8 月に実行される大規模な中間者攻撃に使われる google.com ドメインに対する不正な SSL サーバ証明書を発行することになりました発行された不正な SSL サーバ証明書は実際に Gmail サービスのユーザを対象とする中間者攻撃に利用されイランのユーザの通信が侵害されることになりましたこの事件に関して調査依頼を受けた Fox-IT 社は詳細レポートを 2012 年 8 月に作成しました 2 以下の事件の経緯ではこのレポートに沿って事件の概略をご紹介いたします 2.2 侵入のタイムラインと被害状況以下は 2011 年 6 月 17 日から発生した侵入者による DigiNotar 社への一連の侵入のタイムラインを図示したものです 6.17 DMZ-ext-net の Web サーバの一部が陥落踏み台としての不正利用開始 DMZ-ext-net 6.17 Office-net の SQL サーバ陥落の痕跡 6.18 内部ネットワークから外部の攻撃者サーバへの接続発生 DMZ-int-net 7.01 CA サーバ群が接続する Secure-net の一部が陥落 7.10 証明書の不正発行が成功 Public-CA 198 枚 Relation-CA 85 枚 7.18 証明書の不正発行 ( 追加 ) Public-CA 124 枚 Other Segment Office-net Secure-net 7.19 DigiNotar が証明書の不正発行を検知把握した証明書を失効専門家を雇い (7.25) 調査等実施 7 月末には事件収束と認識 7.20 証明書の不正発行 ( 追加 ) Public-CA 124 枚 7.24 DMZ-ext-net で最後の活動痕跡 Admin-net 侵入のタイムライン 2: Symantec Data Loss Prevention: 保存場所や使用場所に左右されずに機密データを検出監視保護する統合ソリューションです 5

6 DigiNotar 社のネットワークは 24 のセグメントに分けられ認証局のサーバは外部のインターネットと接続する DMZ とは別のセグメントに分けられていたのですがこのインターネットに面する DMZ 環境をはじめとしてそれぞれのセグメント上の脆弱性を突かれて 2011 年 6 月から 7 月にかけて徐々に侵入されて行ったことが分かります Fox-IT 社のレポートが発行された 2012 年 8 月時点で識別された不正発行の証明書は 531 枚でしたが実態としてはログが改ざんされた可能性があるためどのような証明書が何枚不正発行されていたか正確にはわかっていません不正な証明書発行は 2011 年 7 月 10 日から DigiNotar が発見した範囲で不正な証明書を OCSP 3 を利用して失効させる作業が完了した 2011 年 9 月 1 日まで続き *.google.com などのワイルドカード証明書が発行されたことから google.com ドメイン配下にある多くのサブドメインでも不正な証明書が使える状態になっていました Common Name 発行数 Common Name 発行数 * 1 Comodo Root CA 20 *.*.org 1 CyberTrust Root CA 20 *.10million.org 2 DigiCert Root CA 21 *.android.com 1 Equifax Root CA 40 *.aol.com 1 friends.walla.co.il 8 *.azadegi.com 2 GlobalSign Root CA 20 *.balatarin.com 3 login.live.com 17 *.comodo.com 3 login.yahoo.com 19 *.digicert.com 2 my.screenname.aol.com 1 *.globalsign.com 7 secure.logmein.com 17 *.google.com 26 Thawte Root CA 45 *.JanamFadayeRahbar.com 1 twitter.com 18 *.logmein.com 1 VeriSign Root CA 21 *.microsoft.com 3 wordpress.com 12 *.mossad.gov.il *.mozilla.org *.RamzShekaneBozorg.com *.SahebeDonyayeDigital.com *.skype.com *.startssl.com *.thawte.com *.torproject.org *.walla.co.il *.windowsupdate.com *.wordpress.com addons.mozilla.org azadegi.com 16 判明した範囲での不正に発行された証明書のコモンネーム一覧その後こうして不正に発行された証明書と DNS キャッシュポイズニングによる DNS キャッシュの不正書き換えを組み合わせて Gmail のユーザに対して MITM( 中間者 ) 攻撃が仕掛けられたと考えられていますウェブブラウザからサーバに証明書の有効性をリアルタイムに確認することを要求する OCSP リクエストがこの証明書が失効されるまでに約 30 万の IP アドレスから発行されていることがわかりました IP アドレスは例えば企業ネットワークから Proxy を通じてインターネットにアクセスする場合など代表する IP アドレスに統合されているケースも多いので実際には 30 万より多くのユーザが中間者攻撃を受けていた可能性があります OCSP リクエストの 9 割以上はイラン国内からのものでした 3: デジタル証明書の有効性をリアルタイムで確認するプロトコル 6

7 2.3 インフラの脆弱性に関する考察以上のような DigiNotar 社の事件の経緯を見ると幾つかの教訓が浮かび上がってきますまず前述のとおり侵入口となったインターネットに繋がる DMZ 上に脆弱性のあるサーバが存在していたことが第 1 の問題です Fox-IT のレポートによると 2 台のウェブサーバに脆弱性のあるソフトウェアが利用されていたという指摘がなされていますそこから認証局のサーバが存在するネットワークにリモートデスクトッププロトコル経由で侵入を許してしまいました第 2 に監視運用体制の問題も浮き彫りになりましたハッキングされたサーバと同一サーバのみにログが保管されていたためログが一緒に改ざんされた可能性があり被害の範囲が即時に把握できない状態に至りましたこのようにいくつかの管理体制の不備が事件の範囲特定と適切な対応を遅らせる結果となりました DigiNotar 社はこの事件の後ブラウザソフトウェアにおける信頼されるルート認証局のリストから削除されることになり最終的には事業継続の困難から倒産することになりました DigiNotar 社の事件は認証局の運用体制に大きな課題を投げかけましたが他の認証局もこの事件を受けて再発防止のための新たな枠組みを模索し始めました次にそれらの再発防止の試みをご紹介して行きます 3. 再発防止のための認証局の取り組み冒頭でご紹介した DigiNotar 社などの認証局の事件に共通しているのは運用体制の不備や人為的なミスから引き起こされていることであり SSL サーバ証明書そのものあるいはこれを用いた SSL/TLS 通信の技術や安全性に問題があったのではないということです以降これまで大きくは取り上げられなかった運用体制の強化やミスを防ぐための仕組みが世界中の認証局とブラウザベンダーの業界団体である CA ブラウザフォーラムで議論され始めましたそれらの試みには既に導入されたものとまだ議論中のものもありますがここでは代表的なものを紹介します 3.1 Baseline Requirements Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates ( パブリック証明書の発行および管理に関する基本要件以下 Baseline Requirements) 4 はパブリック証明書 5 を発行保守および失効する際に認証局が使用する基準を示すもので 2011 年 11 月にバージョン 1.0 が調印され 2012 年 7 月に発効しました調印した認証局は標準化された証明書のプロファイル情報を含めるといった技術的なルールのみならず認証業務の手順証明書のステイタスチェック従業員のトレーニングデータの保管監査など多岐にわたるルールを順守して運用する必要があります DigiNotar 事件で運用体制が問題の焦点であったことから認証局の運用体制を厳しくチェックする内容となっていますシマンテックグループでは CA ブラウザフォーラムのメンバーとして 2012 年 12 月に Baseline Requirements への対応完了を宣言しました DNS-based Authentication of Named Entities(DANE) 次にハッキングや人為的ミスなどで不正な証明書が発行されてしまうことを防ぐことを目的として 2013 年 3 月時点で CA ブラウザフォーラムにおいて議論されている 3 つの方法論を紹介します DANE は IETF(Internet Engineering Task Force) のメーリングリストで議論が始まった仕組みで現在プロトコルの策定に向けた議論が行われています 7 DANE を運用するにはウェブサイトを運営するドメイン名の DNS ゾーン管理者が SSL サーバ証明書や公開鍵等の情報をドメイン名との関連付けを担保する目的で DNS サーバに登録することが求められますブラウザが https 接続を行う際にこの DNS サーバに登録された TLSA と呼ばれるリソースレコードと実際の接続先であるウェブサーバから受け取る SSL サーバ証明書の情報を比較することで証明書の情報が DNS ゾーン管理者が意図した通りのものであることを保証することが出来ますウェブサーバ上の証明書の正当性を担保する手段としてブラウザ上に予め搭載された認証局のルート証明書へのチェーンを検証する従来の手段に代って DANE では DNS を通じてこれを確認する仕組みであることから DNS そのものの正当性をより厳格に保証する DNSSEC が前提になります 7 4: 原文 : 5: ブラウザなどのアプリケーションに信頼されたルート証明機関としてルート証明書が配布されていることによって信頼されている証明書のこと 6: 7:DANE と SSL/TSL での実装に関しては datatracker.ietf.org/wg/dane/ 参照

8 DANE の仕組み (TLSA レコードに公開鍵情報を登録する場合 ) 3.3 Certificate Authority Authorization(CAA) CAA 8 は同様に DNS のリソースレコードを用いてドメイン名所有者が自社のドメイン名に対して SSL サーバ証明書を発行することを許可する認証局の名称を明示的に特定する仕組みです例えば DigiNotar 社がハッキングされ悪意を持つ第三者が *.google. com というドメイン名を含む不正な証明書を発行しようとした場合にもこのドメインの所有者である Google 社が予め DNS サーバ上の google.com に紐づくリソースレコード (CAA レコード ) に Diginotar 社の認証局の名称を定義していなければ証明書を発行することは出来ません DANE との違いは CAA は証明書を発行する主体である認証局が DNS 上の CAA レコードに記載される権限 (Authorization) 情報を証明書発行前に確認することで不正な証明書の発行を事前に防ぐ手立てであるのに対して DANE はブラウザ上での証明書検証時に DNS ゾーン管理者が登録した証明書や公開鍵の情報との一致を確認することで事後にエンドユーザを脅威から守る手立てであると言えます 3.4 Certificate Transparency(CT) CT は認証局が証明書を発行する都度全ての証明書発行の証跡を第三者の監査ログに記載する仕組みです主にウェブサイトの運営者やドメイン名の管理者がその監査ログサーバを確認することで自分のドメインに対して不正な証明書やポリシー外の認証局からの証明書が発行されていないかを検証することができますそれにより利用者が不正に発行された証明書を信頼することを防止します第三者が運営する外部のログサーバに証明書情報が公開されるということから客観的であると言える反面この監査ログサーバを誰が管理するのかという課題を解消することが困難と考えられていますまた CAA のように事前に不正な証明書の発行を防ぐ仕組みと異なり事後にこれを検知する仕組みであることからこうした事件への対策として単独では十分でなく他の手段と組合わせて活用することが求められると考えられます 8:CAA に関しては tools.ietf.org/html/draft-ietf-pkix-caa-15 で定義 8

9 Proo インサー認証局ウェブサイトのウェブブラウブラウウェブサーの Proo とサーの Proo 合ウェブサー Proo と証書 Certificate Transparency の仕組み新しい 3 つの方法いずれも実装にハードルがありどの方法がいつまでに採用されるかは確定していませんが認証局としても DigiNotar 事件に危機感を持ち再発防止のための取り組みを進めようとしています 4. おわりにこのホワイトペーパーでは証明書に関わる最近の事件特に DigiNotar 社の事件に関して経緯を説明し解決策として認証局が業界としてルール化しようとしている幾つかの試みを紹介しました DigiNotar 社の事件は SSL サーバ証明書の欠陥ではなく DigiNotar 社の運用体制の不備や脆弱性の存在によって引き起こされましたシマンテックグループは事故の再発を防ぐための対策を喫緊の課題と捉え技術面運用面での改善を継続的に行って対処を進めています 9 Copyright 2014 Symantec Corporation. All rights reserved. シマンテック (Symantec) ノートン (Norton) およびチェックマークロゴ (the Checkmark Logo) は米国シマンテックコーポレーション (Symantec Corporation) またはその関連会社の米国またはその他の国における登録商標または商標ですその他の名称もそれぞれの所有者による商標である可能性があります製品の仕様と価格は都合により予告なしに変更することがあります本カタログの記載内容は 2014 年 4 月現在のものです合同会社シマンテックウェブサイトセキュリティ東京都港区赤坂赤坂インターシティ Tel : websales_jp@symantec.com

全てのパートナー様に該当する可能性のある重要なお知らせです 2015 年 8 月 28 日パートナー各位合同会社シマンテックウェブサイトセキュリティ SSL サーバ証明書における階層構造オプションの追加および DNS Certification Authority Authorizatio

全てのパートナー様に該当する可能性のある重要なお知らせです 2015 年 8 月 28 日パートナー各位合同会社シマンテックウェブサイトセキュリティ SSL サーバ証明書における階層構造オプションの追加および DNS Certification Authority Authorizatio 全てのパートナー様に該当する可能性のある重要なお知らせです 2015 年 8 月 28 日パートナー各位合同会社シマンテックウェブサイトセキュリティ SSL サーバ証明書における階層構造オプションの追加および DNS Certification Authority Authorization(CAA) 対応について平素より弊社製品の販売支援をいただき誠にありがとうございますこのたび弊社では