Skip to content ↓ | Skip to navigation ↓

News. Trends. Insights.

ご存知のとおり暗号化なくしてインターネットは成り立ちません。暗号化とは以前はSSLとして知られていたTLSのことです。もしインターネットにおいてプライベートな情報伝達ができなければEコマースなどは存在しなかったでしょう。きっと単なる悪い冗談を言い合う場でしかなかったはずです。

SSL/TLSは重要な技術にもかかわらず、軽視され続けてきた歴史があることも事実です。

合衆国政府の規制がFREAK (“Factoring RSA Export Keys”)を容認し、様々なダウングレード攻撃を可能としました。しかしながら、これらの攻撃が表面化されるまで無視されてきたという背景があります。先日開催されたAusCERTでは研究者Hanno Böck氏が1ページのスライドでとてもうまく表現していたので共有します。

Excerpted from Hanno Böck's THE BURDEN OF FAULTY AND OUTDATED TLS IMPLEMENTATIONS available https://www.dropbox.com/sh/mfbm5gbegm7glri/AACLDLbc1SBsb6ZT2gEzPkKMa/Hanno%60Bock_presentation.pdf?dl=0
参考 : Hanno Böck’s “THE BURDEN OF FAULTY AND OUTDATED TLS IMPLEMENTATIONS”

このスライドはSSL/TLSに関しての脆弱性のリストと数年後に発生した被害状況をまとめたものです。脆弱性への対応に従っていれば防ぐことも可能だったでしょう。このスライドからわかるように、コミュニティでは平均して12年前後も問題を認知していたにも関わらず、対策が講じられていなかったのです。攻撃によっては管理者がパニックになり、誤ったアップグレードで安全性を下げ、さらなる問題を引き起こすケースも見受けられました。

この脆弱性への対応の遅れは、暗号化に頼る人々を攻撃にさらしていたのです。軽視されたMD5ハッシュアルゴリズムの事例では、1993年および1996年に調査研究においてMD5圧縮の際にコリジョンが発生する可能性があることが実証されています。

約10年後の2004年に、大学の研究者がIBM p690クラスタを1時間利用して、同一のハッシュに二つの入力を設けることが可能であることを実証しました。暗号化作成者は、その後、コリジョンを引き起こすハッシュでX.509証明書を発行しつづけました。

CERT/CCは単に「MD5はコリジョン攻撃に対する脆弱性がある」と題されたVU#836068を公表しました。しかし、この情報は、MD5は暗号としての欠陥があり安全性が求められるアプリケーションで用いるべきではないという長年コミュニティで言われていたことと同じでした。

数年後、Flameとして知られているマルウェアが広範囲におよび猛威を振るいました。何年間も警告されていたにも関わらず、多くのシステムがMD5の依存から抜け出せないでいたのです。Flameを作成したハッカーは、証明書を捏造することでマルウェアがターゲットとするシステムに信頼させることに成功していたのです。

また、欠陥が知られているアルゴリズムに加えて、バグが頻発するソフトウェアとの相互運用において脆弱性が悪用されてきた過去もあります。たとえば、OpenSSLの開発の初期段階において、NetScape Version 2.01にはセッション再開時に関連するバグが存在したことがありました。特にSSLv2/v3互換性モードでの接続は、それ以降に異なるSSLv3特定のciphersuiteと再開されてしまうことが確認されたのです。

ワークアラウンド・オプションである「SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG」が、互換性の問題を回避するために追加されました。この (一般に「SSL_OP_ALL」の一部として有効化される) 選択肢は後に、悪意のあるクライアントが再開された接続において使用される暗号をダウングレードする様セッションキャッシュを操作できてしまうため、脆弱性として明らかにされたのです。このexport-gradeの暗号化を提供するサーバと組み合わされた脆弱性は、10年以上も多くのユーザが攻撃の危険にさらされたままであったことを意味します。

欠陥のあるSSL/TLSとの互換性を維持するという決定によって、多くの攻撃が実際に可能となってきたのです。不幸にも、実装は何度も我々が「version intolerance」と呼ぶものによって阻害されてきました。クライアントがサーバとTLS接続を始めると、最初にクライアントに送られるメッセージは、クライアントによってサポートされるTLSプロトコルの最高のバージョンの通知です。例えば、SSLv3は0x0300と表示され、 TLSv1.0は0x0301と、最新の標準であるTLSv1.2は0x0303と認識されました。

サーバは相互にサポートされた最高位のプロトコル仕様を示すServer-Helloで応答することが予想されます。もしサーバが応答確認で問題を検知すれば、(すなわち想定外の問題や、マッチする暗号がないなど) サーバはクライアントにTLSアラートを送るようになっています。しかし、インターネットにつながったTLSサービスのスキャンを研究者が行うと、1120万のホストが古いプロトコルへの修正にポジティブな反応を示し、そのうち17%が TLSv1.2のClient Helloに不適切なレスポンスを送ったことがわかりました。

これを詳しく分析すると、信頼された証明書を持つ21%ものサーバが無効なレスポンスを送っていたことがわかりました。 (この研究は「One Year of SSL Internet Measurement」というタイトルでACSAC ’12で発表) このversion intoleranceは主要なブラウザが「fallback dance」と呼ばれる動作を実行する事態につながったのです。

ユーザが壊れたサイトを見て動揺するのを防ぐため、ブラウザは安全性がより低いパラメータで連続的に接続を確立しようと試みるように設計されています。つまりこれはサーバがTLSv1.2のhelloに反応しなければ、ブラウザはTLSv1.1で再び試み、もし反応がなければ TLSv1.0で試みることを意味しています。

中間者攻撃を行おうとする攻撃者にとっては (TLSはこれに対して安全だと想定されています)、攻撃者が破ることができるセッションをブラウザが試みるまで、新しいプロトコルを試すだけで良いのです。ブラウザを提供するベンダーは、危険なフォールバックを禁止することでこの問題に対処しましたが、TLSv1.3 標準が正式に発表されるとともに再び問題が見つかる可能性が高いのです。

今後、一般消費者だけでなく企業のTLSスタックに満足しないように注意する必要があります。TLSの場合、動作するのと正しく動作するのでは雲泥の差があるのです。私の望みは、これらの問題について話し合うことで、より多くの人がきちんとテストされ標準化されたTLSの実装をすることです。

Title image courtesy of ShutterStock

元の記事はこちらからご覧いただけます。

Tripwireソリューション