PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

あきたけあかさか
4 years ago
Views:

1 プロトコルの形式検証と脆弱性発見の現実 - Case of CCS Injection - 株式会社レピダム林達也 (@lef ) HAYASHI, Tatsuya / Lepidum Co. Ltd. "CRYPTREC シンポジウム 2015" (2015/3/20)

2 自己紹介業務領域名前林達也 ) 所属株式会社レピダム代表取締役 Internet Society Japan Chapter Online Identity WG チェア / プログラム委員 OpenID Foundation Japan 事務局長 Identity Conference ( #idcon ) オーガナイザー業務領域応用実用研究標準化支援アイデンティティプライバシー認証認可ソフトウェア & ネットワークセキュリティ, 脆弱性ネットワーク技術プログラミング言語処理系コンパイラ, インタプリタ, 言語設計各種コンサルテーション

3 Focus Area Lepidum Applied Research and Development Personal Data, Digital Identity and Privacy Secure and Safety Software Technology Web and Internet Technology De-Facto and Forum Standardization Keywords: Personal Data, Trust Framework, Privacy, ID Federation, Authentication/Authorization, Protocol Specification, * of Things(IoT, WoT), Software Defined Network, Autonomic Network, etc...

4 Projects Lepidum LACCOONS (Large-scale Automatic Configuration and Control Over Open Network for SvDI) HTTP Mutual Access Authentication Protocol (New protocol for preventing Phishing attacks against Web systems) IDzumo (Digital Identity Components) Skyeye (Wi-Fi Connect with AuthN/Z Components) Fail-Safe C (Memory-safe implementation of the full ANSI C language Compiler and libraries) Service Defined Network (SvDI)

5 Acknowledgement 暗号の専門家ではないので不正確な部分がある可能性があります発表者は脆弱性の発見者ではありません ( 発見者 : レピダム菊池正史 ) コードの細部等技術的に突っ込んだ点には回答出来ないかもしれませんがお許し下さい

6 Point of View 脆弱性発見者 ( 組織の経営者 ) の視点脆弱性対応者 ( 非サービス事業者 ) の視点エンジニア標準化策定者の視点基盤技術の脆弱性発見の意味脆弱性発見経験を踏まえて基盤技術の重要性瀬戸際ぎりぎりを歩くような危うさ適切な情報開示と共有事後より事前のリソースの投入

7 プロトコルの形式検証と脆弱性発見の現実 - Case of CCS Injection - CCS INJECTION の発見とその経緯

8 CCS Injection 脆弱性とは CCS = Change Cipher Spec TLS/SSL のメッセージ " ここから暗号を変えますよ!" CCS Injection 脆弱性 1. 中間者 ( 攻撃者 ) が CCS を挿入すると 2. OpenSSL が適切な検証をせず受理してしまい 3. 変なタイミングで暗号が変わって 4. 中間者が通信を完全に解読できる

9 通常の CCS 処理 (1) 最初は鍵はない?? クライアント暗号暗号サーバー

10 通常の CCS 処理 (2) PKI を使って鍵が交換される鍵鍵クライアント暗号暗号サーバー

11 通常の CCS 処理 (3) CCS メッセージを送って暗号を有効化鍵鍵 CCS クライアント暗号暗号サーバー CCS

12 通常の CCS 処理 (4) 暗号通信の開始鍵鍵クライアント暗号暗号サーバー

13 CCS Injection 攻撃 (1) 最初は鍵はない ( 同じ )?? クライアント暗号暗号サーバー

14 CCS Injection 攻撃 (2) 黒いところにいる攻撃者が CCS を送る?? CCS クライアント暗号暗号サーバー CCS

15 CCS Injection 攻撃 (3) 謎の鍵を使って暗号通信を開始してしまう?? クライアント暗号暗号サーバー

16 CCS Injection 攻撃 (4) 謎の鍵は初期値 0 から作られた自明なもの 0 0 クライアント暗号暗号サーバー

17 CCS Injection 攻撃 (5) 実際はこの後に PKI の処理が走ったり鍵交換の結果を検証するメッセージ等があるそれらの辻褄をうまく合わせるように改竄することで自明な鍵を維持したままハンドシェークを完了させることが出来た謎の鍵等を含め OpenSSL が本来想定している内部状態が異常になっているのでつじつま合わせには技術的な苦労が

18 発見の背景 (1) 元々 TLS/SSL の安全性に関するソフトウェア的な研究を行っていた NICT 通信プロトコルとその実装の安全性評価に関する研究開発 - 形式手法によるプロトコル実装の検証技術と形式仕様に基づく網羅的ブラックボックス検査技術の開発 - 平成 22~24 年度 ( 産業技術総合研究所 / レピダム ) 定理証明支援系 "Coq" 等を利用

19 発見の背景 (2) Internet Engineering Task Force (IETF) での HTTP や TLS に関係する標準化活動の中で Beast Attack や CRIME Attack の対応影響を間近に体験実際に CRIME Attack 公開時には HTTP Basic 認証への影響に気づいた為 PoC デモの作成を行い発見者との情報交換等も

20 発見の経緯社内のエンジニア ( 発見者の菊池 ) が状態機械の一番複雑な部分が ChangeCipherSpec における遷移だと考え既存実装 (OpenSSL) の動作を確認したところ検査が不適切であることに気づいた

21 発見者の初期モチベーションみんながバグ探し競争してるので効率的に探したい Coq もどこかで使いたいバグのありそうなモジュールを経験的に決めうちする意味不明なコードを理解する足がかりが欲しい

22 発見者の初期モチベーションみんながバグ探し競争してるので効率的に探したい Coqもどこかで使いたいしかしバグのありそうなモジュールを経験的に Coqを使うまでもなく決めうちする脆弱性発覚意味不明なコードを理解する足がかりが欲しい

23 Coq とは? 定理証明支援系 (formal proof management system) フランス国立情報学自動制御研究所 (INRIA) で開発されている (OCaml 等を開発している ) 命題と証明を記述すると " 証明が正しいこと " を自動で検証してくれる一部は自動での証明も行う " プログラミング Coq"

24 脆弱性実証コードの作成 ruby で 300 行くらい暗号プリミティブは openssl ライブラリを使用二日ほどで完成壊れた状態でハンドシェークを完了させるために細かな工夫 ( 試行錯誤 ) が必要結局 Coq のコードは 100 行ぐらいしかできなかった ( 継続したいのでスポンサーを募集しております )

25 CCS Injection Vulnerabilityの課題1 このバグはOpenSSLの最初のリリースから存在しており該当コードは 16年そのままだったしかも修正のチャンスも3回ほどあった (1) CVE new_cipherが設定されているときだけ ChangeCipherSpecを受理するようにしかしnew_cipherはServerHelloの段階で設定される為正しい実装にならなかった

26 CCS Injection Vulnerabilityの課題2 (2) CVE DTLSでいきなりChangeCipherSpecを受け取った場合に落ちる問題が修正されたがやはり正しい実装にならなかった (3) DTLS fragment retransmission bug (OpenSSL bug #1950) 更にDTLSにおいて運悪くパケットの順番が入れ替わってChangeCipherSpecを受け取った場合の検査が追加され DTLSでは正しい実装に未計算のマスターシークレットが暗号に使われた結果ランダムなメモリを読み出してハンドシェークが失敗すると分析されているが実はランダムなメモリではなく空のバイト列だったこれに気付いていれば攻撃の可能性が分かったはず

27 プロトコルの形式検証と脆弱性発見の現実 - Case of CCS Injection - 脆弱性発見とその報告公開

28 どこに報告すべきか? 日本語? 英語? OpenSSL?CERT? 正しく影響範囲が伝わるか? そもそも自分達の解析は正しいのか? 検証と社内統制

29 報告した後 0-day 攻撃の可能性も含め危機管理情報管理が必要に基本的には連絡を待つことしか出来ない他社他組織との相談等は事実上行えない箝口令を引かれているスタッフの危機感特にレスポンスがないと本当に報告プロセスは正しかったのか? 等の焦燥感影響範囲が大きい ( すぎる ) と適切な報告先の選択すら難しい

30 報告した後 0-day 攻撃の可能性も含め危機管理情報管理が必要に基本的には連絡を待つことしか出来ない他社他組織との相談等は事実上行えない本当につらいです箝口令を引かれているスタッフの危機感特にレスポンスがないと本当に報告プロセスは正しかったのか? 等の焦燥感影響範囲が大きい ( すぎる ) と適切な報告先の選択すら難しい

31 何があると良いのか? 各組織で身を切ってやる意味はない! 情報公開共有の基盤が必要レスポンスの早い専門組織とその枠組適切なガイドライン国内だけでなく国際的にも ( この状況でInternet of Things?!)

32 情報公開 (Blog サイト準備 ) ドメイン取得検討 ( ドメインドロップ対策も ) 広告の非掲載を徹底 ( 信頼の為 ) 是非の議論こういう反省点を共有したい (1) 負荷対策 CDN 検討検証 (CloudFront VS CloudFlare) キャッシュが有効なBlog 構成 CDNとBlogの動作検証サイト更新手順の確認情報収集管理体制の構築徹底 etc...

33 正確な情報公開のポリシーは? 誰かが明確に提示してくれるわけではない対外発表の機会と日程調整ネーミングが直接的すぎてDNS 更新すら危ぶむ羽目にルールやガイドはない良識で判断? 良識? 直後に Interop Tokyo で暗号通信に関する登壇がこういう反省点を共有したい (2)

34 公開当日公開時刻は不明なので手動確認! CERT を含め誰も発見者に教えてくれるわけではない取材お問い合わせ等メディア英語対応お客様ご相談 SNS The Guardian, New York Times, etc... 適切な取材とそうでない取材お取引先への調整 Blog を公開してなかったら耐えられなかった可能性が高い情報更新情報の更新などのキャッチアップ有識者からの連絡とそうでないものの分別

35 公開当日公開時刻は不明なので手動確認! CERT を含め誰も発見者に教えてくれるわけではない取材お問い合わせ等メディア英語対応お客様ご相談 SNS 全社体制! The Guardian, New York Times, etc... 適切な取材とそうでない取材お取引先への調整 ( 業務停止 ) Blog を公開してなかったら耐えられなかった可能性が高い情報更新情報の更新などのキャッチアップ有識者からの連絡とそうでないものの分別

36 FAQ その他なぜロゴを作ったのか? どのくらい儲かりました? エンジニア達のケア経営者的な苦悩

37 情報管理の重要性不要な危機感は煽りたくないでも必要なところには適切に情報が届いて欲しい準備が出来たら広域に対策をアナウンスしたい昨日とか今日の状況と比較してもらえると嬉しいです

38 脆弱性公開の厳しさ協力依頼も出来ないしもちろん誰も助けてなんてくれません変な会社だから出来たし企業組織だから耐えられた自負はあります

39 脆弱性公開の厳しさ協力依頼も出来ないしもちろん誰も助けてなんてくれませんそれでも変な会社だから出来たしやってよかったと企業組織だから耐えられた自負はあります思っています

40 プロトコルの形式検証と脆弱性発見の現実 - Case of CCS Injection - 暗号技術基盤の脆弱性と現実

41 CCS Injection 発見を踏まえて CCS Injection は偶然見つかったに等しい基盤技術の応用研究にもっと力を入れる必要がある国内には貢献できる能力を持つエンジニア研究者が山程いる信頼と安全のバランスが崩れている事例

43 TLS/SSL 関係のみ!

44 "The HTTPS-Only Standard" "All publicly accessible Federal websites and web services [1] only provide service over a secure connection. The strongest privacy protection currently available for public web connections is Hypertext Transfer Protocol Secure (HTTPS)."

45 国内の政府機関サイト日本政府機関 Web サイト (.go.jp) の TLS 対応状況について ( Next Internet Technology and Society Project ) "https で接続出来た機関は調査を行った 35 機関中 19 機関でしたしかし接続出来た機関のうち 10 機関は 404 や 403 エラーなどで正しく表示出来ませんでした " ( ) go.jp ドメインの HTTPS サイトの状況について私もみてみました (2015 年 3 月 4 日時点 ) " イベントで一時的に立ち上がってたサイトや停止したサーバーなどがありインターネットからアクセス可能な go.jp ドメインの HTTPS サイトは 882 中 722 であり今回は 722 の go.jp ドメインサイトを調査対象としました " ( )

46 Secure by Default (ex. Google Chrome) "Marking HTTP As Non-Secure" ( ) "gradually change their UX to display non-secure origins as affirmatively non-secure. " ( まだ試験版 (Canary) の話でさらに設定も必要 ) "Gradually sunsetting SHA-1" ( 09/gradually-sunsetting-sha-1.html )

48 インターネット基盤技術の課題信頼できる基盤技術とは? 我々はなにを信頼していたのか? なぜバラバラにやってるのか? サイロ化が一番いけない分野なのに

49 脆弱性発見時の課題 " 世界平和活動 " すぎる非効率すぎるコストがかかりすぎるあまりにもプロセスや体制が成熟していない

50 形式検証の重要性形式検証というプロセスそのものが重要最初から検証されていることが望ましい頭を少し使うだけで見つかるダメなサイクル仕様実装普及 ( 制御不能 ) パッチ仕様... 人間はスケールしないしかし後からでも手を動かすべき安全な領域を少しでも増やし未来に繋ぐ

51 実装の重要性実装してから仕様を書いて欲しいそうすれば実装が複雑で不具合が出そうな部分がわかるはず TLS ぐらいの複雑さのプロトコルを Coq でいじるには先に普通に実装した経験がないとつらいと思う

52 FREAK Attack の注目点発見者 :mitls Team 技術的工学的なアプローチで安全性向上が可能! "mitls is a joint project between Inria and Microsoft Research." mitls "A verified reference TLS implementation" ( ) F# による TLS 実装 "The technical report gives more details on the formal verification of mitls and its cryptographic model." "State-machine attacks [2015] Early CCS Attack and SMACK Attack are prevented as the typebased proof for mitls guarantees that its state machine conforms to its logical specification." ( )

53 今後の暗号通信の変化 TLS 1.3 (IETF TLS WG) "IP Stack Evolution Program" (IAB) "QUIC:Quick UDP Internet Connections" tcpcrypt (IETF TCPINC WG)

54 Heartbleed はひとつの例にすぎない Wrote in 2014/6 今後も同じようなことは高い確率で起きうる皆薄々知っていた "OpenSSL is written by monkeys" (2009) (peereboom.us) しかし皆とは実際には誰なのか?

60 CCS Injection 発見を踏まえて ( 再掲 ) CCS Injection は偶然見つかったに等しい基盤技術の応用研究にもっと力を入れる必要がある国内には貢献できる能力を持つエンジニア研究者が山程いる信頼と安全のバランスが崩れている事例

61 我々はどうするべきか? インターネットは想定を超えたスケールに成長してしまったかもしれない所与のものではなく改善し育て作り上げていく必要があるそしてもっと深刻になるべきその為には選択と集中適切なリソースの投入が必要

62 我々はどうするべきか? インターネットは想定を超えたスケールに成長してしまったかもしれない所与のものではなく改善し育て作り上げていく必要がある Let's Work!! そしてもっと深刻になるべきその為には選択と集中適切なリソースの投入が必要

63 Please contact

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション OpenSSL のバグを見つけた話菊池正史 @ 株式会社レピダム TLS タイムライン 2014 2 月 goto fail; goto fail; 4 月 Heartbleed みんなOpenSSLのバグを探し始める TLS タイムライン 2014 4 月 TLS タイムライン 2014 4 月 LibreSSL CCS Injection 発見 6 月 OpenSSL リリースたくさんのバグ修正