search menu icon-carat-right cmu-wordmark

CERT Coordination Center

IPsec configurations may be vulnerable to information disclosure

Vulnerability Note VU#302220

Original Release Date: 2005-05-09 | Last Revised: 2005-07-06

Overview

The IPsec Encapsulating Security Payload protocol used in tunneling mode may be vulnerable to multiple attacks when confidentiality mode is used without integrity protection, or in certain cases where integrity protection is provided by higher-level protocols.

Description

The IP Security (IPsec) protocol suite are IETF standards commonly used to provide secure networking facilities at the Internet Protocol level such as the establishment of Virtual Private Networks (VPNs).

Within the IPsec suite, the Encapsulating Security Payload (ESP) protocol provides confidentiality for packets by applying encryption algorithms, along with several other services. The Authentication Header (AH) protocol can be used to complement the ESP functionality with integrity protection. Both the ESP and AH protocols can be used in either "Transport" or "Tunneling" mode. When Cipher Block Chaining (CBC) encryption, which has a well-known set of flaws allowing bit-flipping attacks, is used by ESP in tunneling mode to provide confidentiality guarantees without proper integrity protection for inner (tunneled) packets, attackers may be able to perform the following attacks:

Destination Address Rewriting: The destination IP address of the inner, encrypted packet is modified in a bit-flipping attack. Intermediate gateways may then route the inner packet to the modified destination address once the inner packet is recovered.

IP Options modification: The header length and source address of the inner packet is modified by performing a bit-flipping attack on the outer payload. Once the modified inner packet is recovered, the structure of the packet may be affected in such a manner that an Internet Control Message Protocol (ICMP) Parameter Problem message is generated and sent to the source address of the inner packet along with the plaintext payload. This may be intercepted, leading to a recovery of the original inner packet plaintext payload.

Protocol Field modification: In a similar manner to the IP Options modification attack, the protocol field and source address of the inner packet are modified in a bit-flipping attack against the outer packet payload. An invalid or unusable value in the protocol field may then cause a system which is processing a recovered inner packet to generate an ICMP Protocol Unreachable message. This ICMP message is then sent back to the (modified) source address with the plaintext payload of the inner packet, which may be intercepted in order to recover the plaintext.

These attacks involve an amount of probabilistic success, but any successful attacks disclose information which makes future attacks more efficient. This may allow for automated plaintext recovery with a minimal amount of effort. The underlying problem is the use of CBC mode encryption used for confidentiality, which is susceptible to known attacks that allow the encrypted data to be modified in a known manner. If integrity protection is not applied in a proper fashion to this encrypted data, the change may be undetected and accepted as authentic packet(s).

Impact

An unauthenticated remote attacker that is able to intercept and modify IPsec (and ICMP, for some scenarios) communications between security gateways may be able to recover plaintext of the IPsec communications between them.

Solution

For vendor-specific solutions, please see your vendor's information regarding this issue.


Suggested workarounds include

- configuring ESP to use both confidentiality and integrity protection. This is the recommended workaround.
- using the Authentication Header (AH) protocol to provide integrity protection along with ESP in a manner which is not vulnerable.
- restricting ICMP error reporting with network filters or firewalls.

Vendor Information

302220
 

View all 86 vendors View less vendors


CVSS Metrics

Group Score Vector
Base
Temporal
Environmental

References

Acknowledgements

Thanks to NISCC for reporting this vulnerability, who in turn also credit JPCERT/CC with assistance in coordination efforts.

This document was written by Ken MacInnis based primarily on information from NISCC.

Other Information

CVE IDs: CVE-2005-0039
Severity Metric: 4.32
Date Public: 2005-05-09
Date First Published: 2005-05-09
Date Last Updated: 2005-07-06 18:06 UTC
Document Revision: 17

Sponsored by CISA.