前回は、BlackHatで紹介されたSSLサーバー証明書の対象ホスト名を格納するCN(common name)属性の処理の不具合を突いた脆弱性について紹介しました。
今日は、実際にテストサーバーを立ち上げてブラウザで接続するとどうなるのか試してみます。
手持ちの状態のTest Suiteでは、証明書識別名のオブジェクト識別子について
(1) オブジェクト識別子のサブ識別子で大きな整数を指定すると桁が溢れる(機知のバグ)
(2) X.690に違反して0x80でパディングしてエンコードすることができない。
といった状態でした。
RDNの属性タイプを表す方法として以下のサポートを追加して、テストコードを追加しました。
(1) CN, OU, O, C, serialNumberなど属性タイプを名前で指定できる。(現行)
(2) 1.2.3.4 のように十進カンマ区切りでOIDを指定できる。(現行、桁溢れのバグ)
(3) #550403 のように16進数で属性タイプを指定できる。(機能追加)
SSLサーバーのホスト名に以下の2つを仮定して発行します。
本来ならばCN(2.5.4.3=0x550403)であるようなOIDを、騙すためのニセのCN(CN')の作り方としては以下の2つで行います。
(1) 末尾"3"をX.690に違反して0x80(複数可)でパディングする(0x05048003)
(2) 末尾"3"を64bit整数で桁あふれした後"3"となる値とする。
方法(2)については、桁溢れする数を"0x010000000000000003"(9バイト)として、これをビット表現にし末尾より7ビットで分割してこれをバイトとし、末尾を除き8ビット目を1とし、"2.5.4."の部分を連結すると、0x82808080808080808003となります。
OpenSSLのコマンドではどのように証明書の識別名が表示されるのか確認してみたいと思います。
CNモドキはちゃんと区別して表示されているようです。CNは2.5.4.3なんですが、0x80パディングされたものとはきちんと区別しています。(18446744073709551619は0x010000000000000003の10進数表現です。)
�，皚△睇充┥紊亘榲�のCNと区別できています。しかしながら�△任蓮�OBJECT IDENTIFIER '2 5 4 3'となってしまっており、整数の桁溢れが起きていることがわかります。
ちゃんと正しくSSL接続できてますんで、これは問題無し。
それでは、次にX.690に違反して0x80でパディングしてあるニセCNのURL "https://www.good-bank.com/" に接続してみます。
おお、ちゃんと警告出ますね。エライ。
おお、ちゃんとダイアログまで、、、メッセージにも嘘が無くて好感が持てます。ちなみに証明書はこんな感じで表示されます。
ニセCNについて、文字化けのように表示されているので、まぁ、怪しいとわかります。
64bit整数桁あふれする場合でも、表示は同じだったので、キャプチャは割愛します。
先週あたりにWindows Updateした、ほぼ最新だと思うIE8でニセCNのURLに接続してみました。
一切警告なくニセCNのサイトに接続できてしまいますね。
証明書ダイアログで観てみるとX.690違反の0x80パディングでも整数桁溢れでも表示上はCN(common name)であるとして表示されてしまいます。
今日の時点で最新だと思うGoogle Chrome 2.0.172.43で同様に接続してみました。
こちらも警告なく接続できてしまいます。
証明書もwww.good-bank.com用で問題ないことになっちゃってますね。
この他にOpera for Windows 9.50 build10063でも試してみたんですが、Opera自体がDNSで引けないホストは表示ができないような気がするんです(ローカルPCのhttp://192.168.1.133/等でも接続不能)。そのためテストできませんでした。
と、、、思ったら単に余計なプロキシが設定されていただけでした。すみません。疑ってゴメンヨ。気を取り直して接続してみます。まずは、(怪しいけど)正しいHTTPS接続。
まぁ、安全です(笑)。
次にニセCNのサイトに接続してみます。
ちゃんと親切な警告がでます。もうちょっと色が変わったりインパクトがある警告だといいんですけどね。
これも、どっちのニセCNでも結果は同じでした。
Operaの最新版は現時点で9.64だそうで、ちょっと古いやつですが、ニセCN OID問題についてはちゃんと対応されているってことで、、、
rubyとhttpclient2のモジュールでも試してみました。OpenSSLベースですが、ニセCNサイトに接続するとちゃんとエラーになってくれます。
以上、こんな感じで実験報告でした。
ではでは
※注意：この記事のウィンドウキャプチャ画像は、余計な部分、空白などを除くためにトリミングしたり、空白の削除等の加工をしています。
今日は、実際にテストサーバーを立ち上げてブラウザで接続するとどうなるのか試してみます。
Challenge PKI Test Suite(改)の機能追加
手持ちの状態のTest Suiteでは、証明書識別名のオブジェクト識別子について
(1) オブジェクト識別子のサブ識別子で大きな整数を指定すると桁が溢れる(機知のバグ)
(2) X.690に違反して0x80でパディングしてエンコードすることができない。
といった状態でした。
RDNの属性タイプを表す方法として以下のサポートを追加して、テストコードを追加しました。
(1) CN, OU, O, C, serialNumberなど属性タイプを名前で指定できる。(現行)
(2) 1.2.3.4 のように十進カンマ区切りでOIDを指定できる。(現行、桁溢れのバグ)
(3) #550403 のように16進数で属性タイプを指定できる。(機能追加)
証明書の生成
SSLサーバーのホスト名に以下の2つを仮定して発行します。
CN=www.evil3.jp: 悪意のある攻撃者が本当に所持しているドメインのホスト
CN'=www.good-bank.com: 詐欺対象のホスト
本来ならばCN(2.5.4.3=0x550403)であるようなOIDを、騙すためのニセのCN(CN')の作り方としては以下の2つで行います。
(1) 末尾"3"をX.690に違反して0x80(複数可)でパディングする(0x05048003)
(2) 末尾"3"を64bit整数で桁あふれした後"3"となる値とする。
方法(2)については、桁溢れする数を"0x010000000000000003"(9バイト)として、これをビット表現にし末尾より7ビットで分割してこれをバイトとし、末尾を除き8ビット目を1とし、"2.5.4."の部分を連結すると、0x82808080808080808003となります。
OpenSSL 0.9.8kではどう見える？
OpenSSLのコマンドではどのように証明書の識別名が表示されるのか確認してみたいと思います。
■コマンド
% openssl x509 -in 証明書 -noout -text
■OID末尾"3"が0x8003の場合(X.690違反のゼロパディング)
Subject: C=JP, O=Evil-CN-OID, CN=www.evil3.jp/2.5.4.3=www.good-bank.com
■OID末尾"3"が0x82808080808080808003(64bit整数桁溢れ)
Subject: C=JP, O=Evil-CN-OID, CN=www.evil3.jp/2.5.4.18446744073709551619=www.good-bank.com
CNモドキはちゃんと区別して表示されているようです。CNは2.5.4.3なんですが、0x80パディングされたものとはきちんと区別しています。(18446744073709551619は0x010000000000000003の10進数表現です。)
dumpasn1での表示
■本物のCN(common name)の表示
SEQUENCE {
#06 03 55 04 03
OBJECT IDENTIFIER commonName (2 5 4 3)
#13 0C 77 77 77 2E 65 76 69 6C 33 2E 6A 70
PrintableString 'www.evil3.jp'
}
■ニセのCN��(X.690違反の0x80パディング)
SEQUENCE {
#06 04 55 04 80 03
OBJECT IDENTIFIER '2 5 4 3'
#13 11 77 77 77 2E 67 6F 6F 64 2D 62 61 6E 6B 2E 63 6F 6D
PrintableString 'www.good-bank.com'
}
■ニセのCN��(64ビット整数桁溢れ)
SEQUENCE {
#06 0C 55 04 82 80 80 80 80 80 80 80 80 03
OBJECT IDENTIFIER '2 5 4 3'
#13 11 77 77 77 2E 67 6F 6F 64 2D 62 61 6E 6B 2E 63 6F 6D
PrintableString 'www.good-bank.com'
}
�，皚△睇充┥紊亘榲�のCNと区別できています。しかしながら�△任蓮�OBJECT IDENTIFIER '2 5 4 3'となってしまっており、整数の桁溢れが起きていることがわかります。
まずは正式な(悪い人の)URLに接続
ちゃんと正しくSSL接続できてますんで、これは問題無し。
FireFox 3.5.2でニセCNのホストに接続
それでは、次にX.690に違反して0x80でパディングしてあるニセCNのURL "https://www.good-bank.com/" に接続してみます。
おお、ちゃんと警告出ますね。エライ。
おお、ちゃんとダイアログまで、、、メッセージにも嘘が無くて好感が持てます。ちなみに証明書はこんな感じで表示されます。
ニセCNについて、文字化けのように表示されているので、まぁ、怪しいとわかります。
64bit整数桁あふれする場合でも、表示は同じだったので、キャプチャは割愛します。
Internet Explorer 8でニセCNのホストに接続
先週あたりにWindows Updateした、ほぼ最新だと思うIE8でニセCNのURLに接続してみました。
一切警告なくニセCNのサイトに接続できてしまいますね。
証明書ダイアログで観てみるとX.690違反の0x80パディングでも整数桁溢れでも表示上はCN(common name)であるとして表示されてしまいます。
Google Chrome 2でニセCNサイトに接続
今日の時点で最新だと思うGoogle Chrome 2.0.172.43で同様に接続してみました。
こちらも警告なく接続できてしまいます。
証明書もwww.good-bank.com用で問題ないことになっちゃってますね。
Opera 9.5で接続
この他にOpera for Windows 9.50 build10063でも試してみたんですが、Opera自体がDNSで引けないホストは表示ができないような気がするんです(ローカルPCのhttp://192.168.1.133/等でも接続不能)。そのためテストできませんでした。
と、、、思ったら単に余計なプロキシが設定されていただけでした。すみません。疑ってゴメンヨ。気を取り直して接続してみます。まずは、(怪しいけど)正しいHTTPS接続。
まぁ、安全です(笑)。
次にニセCNのサイトに接続してみます。
ちゃんと親切な警告がでます。もうちょっと色が変わったりインパクトがある警告だといいんですけどね。
これも、どっちのニセCNでも結果は同じでした。
Operaの最新版は現時点で9.64だそうで、ちょっと古いやつですが、ニセCN OID問題についてはちゃんと対応されているってことで、、、
ruby + httpclient2
rubyとhttpclient2のモジュールでも試してみました。OpenSSLベースですが、ニセCNサイトに接続するとちゃんとエラーになってくれます。
/usr/lib/ruby/1.8/openssl/ssl.rb:123:in `post_connection_check': hostname was not match with the server certificate (OpenSSL::SSL::SSLError)
以上、こんな感じで実験報告でした。
ではでは
※注意：この記事のウィンドウキャプチャ画像は、余計な部分、空白などを除くためにトリミングしたり、空白の削除等の加工をしています。
関連記事
- Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(2009.08.29)
- Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(続き1)(2009.09.01)>
