英NISCC(National Infrastructure Security Co-ordination Centre)は現地時間5月9日,IPSecに見つかった脆弱性を公表した。通信を暗号化していても完全性 (Integrity) 保護を設定していない場合には,通信内容を第三者に知られる恐れがある。IPSecの仕様に関する脆弱性なので,IPSecを使用するすべての製品が影響を受ける可能性がある。対策は完全性保護を設定することなど。

【5月11日追記】当初,本記事では「JP Vendor Status Notes」サイトの表記に従い,「integrity protection」を「安全性保護」と訳しておりましたが,「integrity」は「完全性」と訳される場合が多く,また,同サイトでも5月11日付けで「完全性」に変更したので,本記事でも「完全性」に変更いたしました。なお,「JP Vendor Status Notes」とは,情報処理推進機構(IPA)とJPCERTコーディネーションセンター(JPCERT/CC)が共同運営している,脆弱性情報を提供するポータル・サイトです。【以上,5月11日追記】

 IPSecとは,TCP/IPにセキュリティ機能を付加するプロトコルの枠組み。IP層(ネットワーク層)で通信のセキュリティを確保する。IPSecを使用すれば,通信内容の暗号化や改ざん防止などを実現できる。そのIPSecに今回脆弱性が見つかった。暗号化を施していても,特定の設定の場合――完全性 (Integrity) 保護を設定していない場合――には,復号した内容(平文の通信内容)を攻撃者に知られる可能性がある。

 具体的には,完全性 (Integrity) 保護を設定せずにトンネリング・モードのESP(Encapsulating Security Payload)を利用している環境において,以下の3種類の攻撃によって通信内容を知られる可能性があるという。(1)「Destination Address Rewriting」,(2)「IP Options」,(3)Protocol Field――である。ここで,ESPとはIPパケットを暗号化するプロトコル,トンネリング・モードとは,IPパケットをヘッダーごと暗号化するモードのことである。

 詳細についてはNISCCなどの情報を参照してほしいが,大雑把に言うと,(1)は2点間(例えば,セキュリティ・ゲートウエイ同士)でやり取りされているIPSecパケットの送信先アドレス(destination address)を書き換えて(改ざんして),復号した後のパケットを攻撃者に送信させる攻撃である。(2)(3)については,送信元アドレス(source address)などを改ざんして,復号した後のパケットをICMPのエラー・メッセージとして攻撃者に“返送”させる攻撃である。

 いずれも,改ざんされていないかどうかをチェックする完全性保護を有効にしていれば防げる。このためNISCCでは,ESPを使う際に機密性(Confidentiality)保護と完全性 (Integrity) 保護の両方を設定することを対策として勧めている。

 IPSec対応製品ベンダー各社も情報を公開しているので参考にしたい。例えば,国内ではアライドテレシスが情報を公開している。今後は他ベンダーからも情報が公開されると考えられるので,現在利用している製品のベンダーのサイトや,ベンダー情報を記載している「JP Vendor Status Notes」「US-CERT Vulnerability Note」などをチェックしたい。

◎参考資料
NISCC Vulnerability Advisory IPSEC - 004033(英NISCC)
NISCC-004033 IPSec通信の設定に存在する脆弱性(JP Vendor Status Notes)
IPsec configurations may be vulnerable to information disclosure(米US-CERT)
セキュリティ・脆弱性について(アライドテレシス)

(勝村 幸博=IT Pro)