社内勉強会資料

1. プロフェッショナルSSL/TLS
4章
2017/5/8
光成滋生

2. • 本質的な欠陥
• すべてのCAが任意のホスト名の証明書を発行できること
• ドメイン所有者に承認を得る必要がない
• 攻撃対象
• CAの検証プロセス
• ドメインの正当な所有者と思わせて証明書を発行させる
• CAのセキュリティ
• CAを乗っ取れば任意の証明書を発行可能
PKIに対する攻撃
2 / 12

3. • 2001, VeriSign
• Microsoft詐称者にコード署名証明書を発行
• VeriSignが失効したが証明書にCRL配布ポイントが指定されて
いなかった
• Microsoftはこれを明示的に排除するアップデートで対応
• 2008, Thawte
• Mike ZusmanがMicrosoftのlogin.live.comの証明書を取得
• @live.comの電子メールを自由に登録できた
• Thawteはsslcertificates@live.comをドメイン名の認証に利用
• 2015, live.fiで同様のことが発生
過去の事例1
3 / 12

4. • 2008, StartCom
• Mike ZusmanがStartComのドメイン名検証を迂回
• payla.com, verisign.comの証明書を取得
• 著名なドメインをチェックする多重防御により直ちに失効
• 2008, CertStart
• Eddy NiggがCertStartがドメイン名を検証せずに証明書を発行
していることを発見
• startcom.org, mozilla.orgの証明書を取得
• 2008, RapidSSL
• Alex Sotirovらが任意のWebサイトの証明書に署名できる偽造
CA証明書を取得
• 当時まだMD5を証明に使っていたCAがいた
• 安全のために証明書は期限切れのものを作成
過去の事例2
4 / 12

5. • 選択プレフィクス衝突攻撃
• 事前に決めた先頭部分に対して衝突ブロックを配置
• その後ろは同一のデータを追加する
• 「SHA-1のはなし」参照
• https://www.slideshare.net/herumi/googlesha1
RapidSSLの攻撃詳細
プレフィクス プレフィクス
証明書A 証明書B
near-collision
blocks
near-collision
blocks
サフィックス サフィックス
=
=
≅
5 / 12

6. • 証明書に含まれる情報
• CSR
• 失効時刻
• シーケンス番号
• 公開鍵
• 手順
• 公開鍵より前の情報はプレフィクス(固定されている)
• 公開鍵の部分に衝突ブロックをいれる
• 公開鍵のあとに追加される情報は二つの証明書で同一になる
ように調整
• X.509v3にあるComment欄にデータを配置
• 片方の衝突ブロックを使ったものをCAに送り本物の証
明を作ったあともう一つの衝突ブロックに入れ換える
衝突する証明書の構成方法
6 / 12

7. • RapidSSLの状況
• 失効時刻
• 証明書の発行処理が自動化されていてCSRを送信して証明書
が生成されるまで6秒
• 失効時刻を予測可能
• シーケンス番号
• 1ずつ増えるタイプだった
• 1回取得してすぐもう1回取得したときの番号は予測可能
• 再発行が無料
• 演算コスト
• 200台のPlayStation 3を利用して衝突を生成
• EC2で2万ドル程度
• うまくやれば2千ドルらしい
プレフィクスの予測方法
7 / 12

8. • 2011, Instant SSL ; ComodoのRA
• セキュリティを破られてgoogle.comやlogin.yahoo.comなどの
7個のWebサイトに対して9個の証明書が発行
• 数時間で全て失効される
• RSを攻撃対象とする脅威モデルを考慮していなかった
• 2011, StartCom
• 攻撃を受けて証明書の発行を1週間停止
• 2011, DigiCert Sdn. Bhd.
• 512ビットRSAの証明書を発行していた
• 使用方法の制限がなかった
• 鍵拡張用途で制限していなかった
• 失効情報がなかった
事例続き
8 / 12

9. • 時系列
• 6月 Webサーバが攻撃を受ける
• 7月 内部にまで侵入し不正な証明書を取得
• 侵入に気がついてシステムをクリーンアップ
• 情報公開せず
• 8月 ルートCA証明書がすべて失効
• 9月 自己破産 / 犯行声明
• どうやってポート80と443以外をブロックしていてリバース
VNCもダイレクトモードの VNC も許可していないファイア
ウォール越しにリモートデスクトップ接続を張ったのか
• 発見の経緯
• Gmailが警告
• 公開鍵ピンニングでMITMを検知
20011, DigiNotar
9 / 12

10. • マルウェア（20MB）
• ネットワークアナライザ, マイクの有効か, ファイル検索
• SQLite, Luaなどが組み込まれていた
• Windows Updateサーバの振りをする
• 「更新」で悪意あるコードを埋め込む
• Microsoft社のコード署名をつける
• Microsoftのシステムのミス
• 下位CA証明書をコード証明書に使えた
• 証明書にMD5を使っていた
• RapidSSLの攻撃と同様の手法
• ただし時間はミリ秒単位の正確さが必要
• MD5の衝突アルゴリズムは既存文献にない手法
2012, Flame
10 / 12

11. • 2012, TURKTRUST
• 公開鍵ピンニングで発覚
• MITM機能を持つファイアウォールに誤って重要なCA証明書
をインポート?
• ファイアウォールが偽のWebサイト証明書を発行
• 2013, ANSSI
• 公開鍵ピンニングで発覚
• 下位CA証明書がMITM機能つきファイアウォールで利用され
• さまざまなドメイン名に対する署名が生成された
• 2014, インド情報工学センター
• 下位CAが侵害される
事例続き
11 / 12

12. • 2015, Gogo
• 航空機内WiFi接続サービスで不正な証明書を有効にさせる
• 2015, 広告挿入ソフトウェアSuerfish on Lenovo PC
• OSのルート証明書ストアに無断でルート証明書を追加
• 全トラフィックをローカルプロキシにリダイレクト
• 全システムで同一のルート証明書・TLS1.1を強制
• 同様のものは少なくとも十数類ある
• 2017, Symantec
• 下位CAが不正に証明書を発行
• EV証明書を無効にする提案 by Google
• https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ
• 外部CAによる再審査と運営の改善を提案 by Symantec
• https://www.symantec.com/connect/blogs/symantec-ca-proposal
事例続き
12 / 12