wakatonoの戯れメモ

はてなダイアリーから引っ越してきました。

IPsec通信の設定に存在する脆弱性

セキュリティ

Vulnerability Issues with IPsec Configurationsを読んで。
JP Vendor Status Notesの記事経由でたどり着く。

前提は、

  • IPsecトンネルモード
  • ESPのみを用いている
  • 改ざんに関するチェックを実施していない（ESPを暗号化のみで使っている）

という感じ。で、脆弱性として挙げられてるのは以下のような感じ。

  • デスティネーションアドレスの偽装
    • 攻撃者は、暗号化された（inner）パケットのデスティネーションIPアドレスを、outerパケット（暗号化パケットをペイロードとして含むIPパケット）のペイロードをビットフリッピング（ビット反転）することで書き換える*1。
    • セキュリティゲートウェイは、（変更された）innerパケットを復号化する。
    • ゲートウェイは（変更された）（destination）IPアドレスにしたがってルーティングする。
    • もし成功してれば、プレーンテキストなデータが攻撃者が選んだホストに到達する。
  • IPオプション
    • 攻撃者は、暗号化された（inner）パケットのヘッダ長を、outerパケット（暗号化パケットをペイロードとして含むIPパケット）のペイロードをビットフリッピング（ビット反転）することで書き換える。
    • セキュリティゲートウェイは、（変更された）innerパケットを復号化する。
    • ヘッダ長が変更されているため、ゲートウェイは、innerパケットのペイロードのうち、（ヘッダ長が変更された結果）innerパケットのオプションバイトとして解釈される部分について処理する。
    • オプションの処理の結果が、ICMP "parameter problem"メッセージとして入ってくる可能性がある。
    • ICMPメッセージはinnerパケットの（改ざんされた）送信元アドレスにルーティングされる。
    • 攻撃者は、ICMPメッセージをとらえてinnerパケットの平文ペイロードを取得する。
  • プロトコルフィールド
    • 攻撃者はinnerパケットのプロトコルフィールドとソースアドレスフィールドを、ビットフリッピング（ビット反転）することで書き換える。
    • セキュリティゲートウェイは、（変更された）innerパケットを復号化する。
    • ゲートウェイは受信者にinnerパケットを転送する。
    • パケットの受信者はinnerパケットのプロトコルフィールドをチェックして、ICMP "protocol unreachable"メッセージを生成する。
    • ICMPメッセージは新たに変更されたinnerパケットのソースアドレスに対して送られる。
    • 攻撃者は、ICMPメッセージをとらえてinnerパケットの平文ペイロードを取得する。

追記：上記の対策（Vulnerability Issues with IPsec Configurationsより）

  • ESPの暗号化機能だけではなく、整合性チェック機能も使う
  • AHを使って整合性チェックを行う
  • ICMPエラーメッセージの送出を、ゲートウェイやFirewallレベルで制限する

*1:原文には入ってないけど、後の方を読んでると、「ソースアドレス」も書き換えるはず