【インフラストラクチャセキュリティ】Gumblarの再流行（Vol.4）

エンタープライズセキュリティ

注目記事

2010.4.8（木）16:15

　●SSLおよびTLSのrenegotiation機能の脆弱性を利用した中間者攻撃

―背景

　2009年11月、SSLおよびTLSプロトコルに中間者攻撃を成立させる可能性のある脆弱性がMarshRay、Steve Dispensa、Martin Rex によって公表されました。SSLとTLSは、IP層とアプリケーション層の間に位置し、アプリケーションデータの暗号化とデータの完全性を保証し、通信相手をX.509公開鍵証明書によって認証する機能を提供します。HTTP、SMTP、POPなどのアプリケーション層の通信プロトコルと合わせて用いられるため、本脆弱性は多くのアプリケーションやシステムに影響を及ぼします。

　特にHTTPS（HTTP over SSL）プロトコルは、多くのWebブラウザとWebサーバに実装されていますし、Marsh Rayらの報告でもHTTPSを用いた攻撃方法が例として紹介されています。さらに、これをTwitter APIに適用して攻撃者のTwitterアカウントにパスワード情報を投稿させる方法が公開されるなど、実際に悪用可能であることが示されました。HTTP以外のプロトコルへの適用可能性については、Thierry Zollerによって検討されています。FTPS、SMTPSは脆弱であり、EAPTLSは影響を受けないことが示されていますが、POPやLDAPなど影響を受けるかどうかが明らかになっていないアプリケーションプロトコルも残っています。

　本脆弱性は、SSLとTLSのプロトコル仕様そのものの問題に起因します。OpenSSLやApacheなどで修正が公開されていますが、その多くが問題となるrenegotiation機能を単に無効にするという修正です。根本的な対処のためには、現仕様を更新し、新仕様にあわせた実装に移行する必要があります。IETFもこの認識にあり、現在、対策を策定したRFC化を目指してインターネットドラフトが異例の速さで検討されています。本脆弱性は、TLSのすべてのバージョンのプロトコルに加えてSSLバージョン3.0にも影響します。SSLの仕様はIETFで策定されていませんが、新仕様ではTLSと同様に適用可能と記されています（当該ドラフト4.5節）。

―renegotiation機能を悪用した中間者攻撃

　SSLとTLSは、アプリケーションデータを安全に送受信する前に、ハンドシェイクプロトコルにて暗号アルゴリズムや鍵情報などを共有します。renegotiation機能は、クライアントとサーバの間で合意されたアルゴリズムや鍵情報などを更新するために利用されます。今回の報告では、renegotiation機能の仕様上の問題を利用すると、中間者攻撃により、SSLやTLSの通信に割り込むことが可能であることが示されました。具体的なケースとして、セッション途中でクライアント認証（公開鍵証明書を用いたクライアント認証）に切り替えるケースが指摘されています。

　HTTPSにおける攻撃の例を図-11に示します。この攻撃により、中間者である攻撃者は、クライアントとサーバ間での暗号化された通信に割り込むことができます。この結果、攻撃者のHTTPリクエストと正当なユーザによるリクエストを結合し、サーバに送信することが可能になります。このとき、正当なユーザのアプリケーションデータは暗号化されたままであり、攻撃者による改ざんやデータ搾取が行われない点に注意してください。攻撃者のリクエストと正当なユーザの既存のリクエストがHTTPCookie等で結び付けられる場合、サーバは一連のリクエストが同一ユーザによるものであると解釈し、攻撃者のリクエストを受領して処理する可能性があります。

―仕様の改変点

　次に、RFC化が予定されているインターネットドラフトでの改変点を紹介します。このドラフトでは、TLSの拡張タイプの値としての“renegotiation_info”と、本来ならば暗号アルゴリズムを表現するCipher Suiteの状態として"TLS_EMPTY_RENEGOTIATION_INFO_SCSV"が導入されています。renegotiation_info拡張を用いてrenegotiationを安全に行う実装であることを通信相手に宣言できます。具体的には、クライアントとサーバがともにハンドシェイクプロトコルで安全に共有した情報を保存しておきます。renegotiationを行う際にrenegotiation_info拡張を用いて、お互いしか知りえない情報を交換することで、それまで接続していた通信相手であることを確認します。また、renegotiation_info拡張を処理不能なTLS拡張と認識し、通信を中断する実装が存在するため、"TLS_EMPTY_RENEGOTIATION_INFO_SCSV"を用いる方法も準備されています。

―対策と後方互換性の問題

　このインターネットドラフトがRFC化され、新たに対策された実装が普及し今回の問題が解消されることが望まれますが、移行には時間がかかると考えられます。後方互換性の観点から現バージョンとの互換性を確保すべきですが、旧実装からrenegotiationが行われた場合、正しい相手からのリクエストであるかどうかを安全に確認する手段はありません。このため新実装では、旧実装からのrenegotiation要求を拒否することが推奨されています。これは、現在の一時的な対策に相当するもので、renegotiation機能を利用することはできません。つまり、安全にrenegotiationを行う必要がある利用形態では、新しい仕様がRFC化された後、クライアントとサーバで、ともに新仕様に対応した新しい実装を導入する必要があります。

※同記事はインターネットイニシアティブ（IIJ）の発行する「Internet Infrastructure Review」の転載記事である

執筆者：
齋藤衛（さいとうまもる）
IIJ サービス事業統括本部セキュリティ情報統括部部長。法人向けセキュリティサービス開発等に従事の後、2001年よりIIJグループの緊急対応チームIIJ-SECTの代表として活動し、CSIRTの国際団体であるFIRSTに加盟。Telecom-ISAC Japan、日本シーサート協議会、日本セキュリティオペレーション事業者協議会等、複数の団体の運営委員を務める。IIJ-SECTの活動は、国内外の関係組織との連携活動を評価され、平成21年度情報化月間記念式典にて、「経済産業省商務情報政策局長表彰（情報セキュリティ促進部門）」を受賞した。
土屋博英（ 1.2 インシデントサマリ）
土屋博英鈴木博志（ 1.3 インシデントサーベイ）
鈴木博志（ 1.4.1 Gumblarの再流行）
須賀祐治（ 1.4.2 SSLおよびTLS renegotiation機能の脆弱性を利用した中間者攻撃）
齋藤衛永尾禎啓（1.4.3 P2Pファイル共有ネットワークの調査技術）
IIJ サービス事業統括本部セキュリティ情報統括部

《RBB TODAY》