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

White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

Page 1: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

WH

ITE PA

PER

:

powered by Symantec

White Paper

認証局におけるハッキング事件の原因と認証局業界の新しい取り組み

Page 2: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

2

Copyright ©2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは、Symantec Corporation または関連会社の米国およびその他の国における登録商標です。その他の会社名、製品名は各社の登録商標または商標です。

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

合同会社シマンテック・ウェブサイトセキュリティは、本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます。

Page 3: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

3

CONTENTS

1.はじめに 4

2.DigiNotar事件報告書と考察 52.1事件のあらまし 5

2.2侵入のタイムラインと被害状況 5

2.3インフラの脆弱性に関する考察 7

3.再発防止のための認証局の取り組み 73.1BASELINEREQUIREMENTS 7

3.2DNS-BASEDAUTHENTICATIONOFNAMEDENTITIES(DANE) 7

3.3CERTIFICATEAUTHORITYAUTHORIZATION(CAA) 8

3.4CERTIFICATETRANSPARENCY(CT) 8

4.おわりに 9

Page 4: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

4

1.はじめに

公開鍵暗号の技術を用いたセキュリティ基盤である公開鍵基盤(PKI:Public Key Infrastructure)において、認証局は、発行したデジタル証明書の公開鍵が正当であることを保証するという役割を果たしています。デジタル証明書の信頼性を担保する根源とも言える認証局は、不正に証明書を手に入れるようとする侵入者によって、しばしば攻撃対象として狙われます。

2011 年から 2012 年に掛けて、認証局(CA)を標的としたハッキング事件が立て続けに発生しました※ 1。

▪▪ 2011年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 サーバ証明書発行事件から見る認証局の役割』参照

Page 5: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

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 社への一連の侵入のタイムラインを図示したものです。

Other

Segment

DMZ-int-net

DMZ-ext-net

Office-net

Admin-net

Secure-net

インターネット

6.17 DMZ-ext-netのWebサーバの一部が陥落、踏み台としての不正利用開始

6.17 Office-netのSQLサーバ陥落の痕跡

6.18 内部ネットワークから外部の攻撃者サーバへの接続発生

7.01 CAサーバ群が接続するSecure-netの一部が陥落

7.10 証明書の不正発行が成功 Public-CA 198枚、Relation-CA 85枚

7.18 証明書の不正発行(追加) Public-CA 124枚

7.19 DigiNotarが証明書の不正発行を検知。把握した証明書を失効、専門家を雇い(7.25)調査等実施。7月末には事件収束と認識

7.20 証明書の不正発行(追加) Public-CA 124枚

7.24 DMZ-ext-netで最後の活動痕跡

侵入のタイムライン

※2: Symantec Data Loss Prevention:保存場所や使用場所に左右されずに機密データを検出、監視、保護する統合ソリューションです。 http://www.symantec.com/ja/jp/business/data-loss-prevention

Page 6: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

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 2 www.10million.org 8*.mozilla.org 1 www.balatarin.com 16*.RamzShekaneBozorg.com 1 www.cia.gov 25*.SahebeDonyayeDigital.com 1 www.cybertrust.com 1*.skype.com 22 www.Equifax.com 1*.startssl.com 1 www.facebook.com 14*.thawte.com 6 www.globalsign.com 1*.torproject.org 14 www.google.com 12*.walla.co.il 2 www.hamdami.com 1*.windowsupdate.com 3 www.mossad.gov.il 5*.wordpress.com 14 www.sis.gov.uk 10addons.mozilla.org 17 www.update.microsoft.com 4azadegi.com 16

判明した範囲での不正に発行された証明書のコモンネーム一覧

その後、こうして不正に発行された証明書と、DNS キャッシュポイズニングによる DNS キャッシュの不正書き換えを組み合わせて、Gmail のユーザに対して MITM(中間者)攻撃が仕掛けられたと考えられています。ウェブブラウザからサーバに証明書の有効性をリアルタイムに確認することを要求する OCSPリクエストが、この証明書が失効されるまでに約 30 万の IP アドレスから発行されていることがわかりました。IP アドレスは、例えば企業ネットワークから Proxy を通じてインターネットにアクセスする場合など、代表する IP アドレスに統合されているケースも多いので、実際には 30 万より多くのユーザが中間者攻撃を受けていた可能性があります。OCSPリクエストの 9割以上はイラン国内からのものでした。

※ 3: デジタル証明書の有効性をリアルタイムで確認するプロトコル

Page 7: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

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 への対応完了を宣言しました※ 6。

3.2 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が前提になります。

※ 4: 原文: https://cabforum.org/Baseline_Requirements_V1_1.pdf※ 5: ブラウザなどのアプリケーションに、信頼されたルート証明機関としてルート証明書が配布されていることによって信頼されている証明書のこと※ 6: www.symantec.com/connect/blogs/why-are-certfication-authoritybrowser-baseline-requirements-so-important※ 7: DANE と SSL/TSL での実装に関しては datatracker.ietf.org/wg/dane/ 参照

Page 8: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

8

TLSAレコード

公開鍵情報

www.abc.com

DNSルートサーバ 対象DNSサーバ

ウェブサーバ

①証明書の公開鍵情報を TLSAとして登録

③ウェブサーバの証明書と TLSAを照合

②TLSAレコードを取得DNSゾーン管理者

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 で定義

Page 9: White Paper 認証局におけるハッキング事件の原因 …White Paper : 認証局におけるハッキング事件の原因と認証局業界の新しい取り組み 3 CONTENTS

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

9

合同会社シマンテック・ウェブサイトセキュリティhttps://www.jp.websecurity.symantec.com/〒104-0028 東京都港区赤坂1-11-44赤坂インターシティTel:0120-707-637E-mail:[email protected]

Copyright ©2014 Symantec Corporation. All rights reserved.シマンテック(Symantec)、ノートン(Norton)、およびチェックマークロゴ(the Checkmark Logo)は米国シマンテック・コーポレーション(Symantec Corporation)またはその関連会社の米国またはその他の国における登録商標、または、商標です。その他の名称もそれぞれの所有者による商標である可能性があります。製品の仕様と価格は、都合により予告なしに変更することがあります。本カタログの記載内容は、2014年4月現在のものです。

ログサーバ

ウェブサーバウェブサイト利用者のウェブブラウザ

ドメイン所有者

①Proof を登録

②Proof と証明書を提供③ブラウザがウェブサーバの Proof とログサーバの Proof を照合

認証局

監視

Certificate Transparency の仕組み

新しい 3 つの方法いずれも実装にハードルがあり、どの方法がいつまでに採用されるかは確定していませんが、認証局としても DigiNotar事件に危機感を持ち、再発防止のための取り組みを進めようとしています。

4.おわりに

このホワイトペーパーでは、証明書に関わる最近の事件、特に DigiNotar 社の事件に関して経緯を説明し、解決策として、認証局が業界としてルール化しようとしている幾つかの試みを紹介しました。DigiNotar 社の事件は、SSL サーバ証明書の欠陥ではなく、DigiNotar社の運用体制の不備や脆弱性の存在によって引き起こされました。 シマンテックグループは事故の再発を防ぐための対策を喫緊の課題と捉え、技術面、運用面での改善を継続的に行って対処を進めています。