Case Studies and Lessons Learned from SSL/TLS Certificate Verification Vulner...JPCERT Coordination Center
?
The document discusses the vulnerabilities associated with SSL/TLS certificate verification, highlighting that many applications fail to validate SSL certificates, making them susceptible to man-in-the-middle attacks. It presents case studies of various applications where certificate verification failures occurred and details the implications of these vulnerabilities. Additionally, the document explains the processes involved in certificate verification, such as checking the authenticity and ensuring the proper certificate path.
The document discusses secure coding practices for Android app development. It begins with an introduction that notes the growing number of Android users and prevalence of Android vulnerabilities reported in news headlines. The document then covers various categories of Android app security issues and explores examples of specific vulnerabilities, including unintended activity exposure, local servers accessible to other apps, and unintended content provider exposure. Root causes and solutions are provided for each vulnerability along with references for developers. The goal is to help developers learn from real-world examples and avoid common vulnerabilities through secure coding techniques.
1. Copyright?2013 JPCERT/CC All rights reserved.
「Javaアプリケーション脆弱性事例調査資料」について
この資料は、Javaプログラマである皆様に、脆弱性を身
近な問題として感じてもらい、セキュアコーディングの
重要性を認識していただくことを目指して作成していま
す。
「Javaセキュアコーディングスタンダード
CERT/Oracle版」と合わせて、セキュアコーディングに
関する理解を深めるためにご利用ください。
JPCERTコーディネーションセンター
セキュアコーディングプロジェクト
secure-coding@jpcert.or.jp
1
Japan Computer Emergency Response Team
Coordination Center
電子署名者 : Japan Computer Emergency Response Team Coordination Center
DN : c=JP, st=Tokyo, l=Chiyoda-ku, email=office@jpcert.or.jp, o=Japan
Computer Emergency Response Team Coordination Center, cn=Japan
Computer Emergency Response Team Coordination Center
日付 : 2013.09.30 16:17:37 +09'00'
8. Copyright?2013 JPCERT/CC All rights reserved.
サーバ証明書検証に関する情報
8
■RFC5280: Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile
(http://tools.ietf.org/html/rfc5280)
SSL証明書の検証内容として以下のような項目を挙げ、
検証に関するアルゴリズムを定義している。
(Section6. Certification Path Validation)
1.発行元の認証機関(CA)が信頼されているCAであることを確認する
2.現在の日付が有効期間内にあるかどうかを確認する
3.現時点において、証明書が失効していないことを確認する
4.発行元CAの公開キーにより、送信者のデジタル署名を検証する
5.サーバーの証明書のドメイン名がサーバー自体のドメイン名と一致
するかどうかを確認する
この資料では、5. のドメイン名(ホスト名)を
検証する処理を中心に見ていく。
注意!!
9. Copyright?2013 JPCERT/CC All rights reserved.
サーバ証明書の記載内容
サーバ証明書には、以下のような情報が含まれる。
9
項目名 記載内容
CN サーバ名(ドメイン含む) www.jpcert.or.jp
OU 運営団体の部署名 System Administration Group
O 運営団体名 Japan Computer Emergency Response Team Coordination Center
L 運営団体の所在(市区町村) Chiyoda-ku
ST 運営団体の所在(都道府県) Tokyo
C 運営団体の所在(国名) Japan
—証明書の有効期間
—証明書を発行した証明機関(CA)のパス
※CNには1つのホストしか記述できないため、複数ホスト(バーチャルホス
ト)運用を想定した拡張フィールド subjectAltName も用意されており、
CNフィールドよりも優先される。
10. Copyright?2013 JPCERT/CC All rights reserved.
中間者による攻撃を予防するために、クライアントは、これをサーバーの
証明書メッセージ中に示されたサーバーの身元に照らしてチェックしなけ
ればなりません(MUST)。
(中略)
証明書の Subject フィールドにある(最も具体的)な Common Name フィー
ルドを使用しなければなりません(MUST)。
the client MUST check it against the server's identity as presented in the
server's Certificate message, in order to prevent man-in-the-middle attacks.
(中略)
the (most specific) Common Name field in the Subject field of the certificate
MUST be used.
サーバ証明書の検証内容
10
RFC 2818 「HTTP Over TLS」 では以下のように記載されている。
English
日本語
RFC では「証明書のCN(またはsubjectAltName)の値」と
「ホスト名」の一致を検証することが必須、とされている。
11. Copyright?2013 JPCERT/CC All rights reserved.
脆弱性が悪用された場合のリスク
SSLサーバの成りすましが可能
それによりSSL通信の中間者攻撃(Man-In-The-
Middle 攻撃)が可能
—SSL通信内容の傍受、改ざんが可能。
11
26. Copyright?2013 JPCERT/CC All rights reserved.
サーバ証明書検証に関する参考情報(1)
26
■RFC5280: Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile
(http://tools.ietf.org/html/rfc5280)
SSL証明書の検証内容として以下のような項目を挙げ、
検証に関するアルゴリズムを定義している。
(Section6. Certification Path Validation)
1.発行元の認証機関(CA)が信頼されているCAであることを確認する
2.現在の日付が有効期間内にあるかどうかを確認する
3.現時点において、証明書が失効していないことを確認する
4.発行元CAの公開キーにより、送信者のデジタル署名を検証する
5.サーバーの証明書のドメイン名がサーバー自体のドメイン名と一致
するかどうかを確認する
(再掲)
27. Copyright?2013 JPCERT/CC All rights reserved.27
■Microsoft「SSL ハンドシェイクでのサーバー認証プロセスに関する説明」より
http://support.microsoft.com/kb/257587/ja
SSL を有効にしたクライアントでは、以下の手順を実行してサーバーの身元を認証します。
1. 現在の日付が有効期間内にあるかどうかを確認します。
2. 発行元の認証機関(CA)が信頼されている CA であることを確認します。
3. 発行元 CA の公開キーにより、送信者のデジタル署名を検証します。
4. サーバー証明書のドメイン名がサーバー自体のドメイン名と一致するかどうかを確認し
ます。
■Google「Browser Security Handbook」より
http://code.google.com/p/browsersec/wiki/Part2
ここでは以下を不正な証明書として扱っている。
? 信頼される機関によってサインされていない
? 期限切れ
? ドメイン名と合致しない
(引用、原文そのまま)
invalid certificates (not signed by a trusted entity, expired, not matching the
current domain, or suffering from any other malady)
サーバ証明書検証に関する参考情報(2)
28. Copyright?2013 JPCERT/CC All rights reserved.
CWE: Common Weakness Enumeration
28
? CWE-295: Improper Certificate Validation
?全般的な話、証明書を正しく検証していない
? CWE-296: Improper Following of a Certificate's Chain of Trust
?証明書チェーンを正しく検証していない
?CWE-298: Improper Validation of Certificate Expiration
?期限が切れているかを正しく検証していない
?CWE-299: Improper Check for Certificate Revocation
?証明書が無効になっていないかを正しく検証していない
http://cwe.mitre.org/