Vulnerability Note VU#302220
IPsec configurations may be vulnerable to information disclosure
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.
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:
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).
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.
For vendor-specific solutions, please see your vendor's information regarding this issue.
Systems Affected (Learn More)
|Vendor||Status||Date Notified||Date Updated|
|Cisco Systems Inc.||Affected||09 May 2005||17 May 2005|
|Check Point||Not Affected||09 May 2005||10 May 2005|
|F5 Networks||Not Affected||09 May 2005||13 May 2005|
|IBM||Not Affected||09 May 2005||10 May 2005|
|Netfilter||Not Affected||09 May 2005||10 May 2005|
|Nortel Networks||Not Affected||09 May 2005||10 May 2005|
|Wind River Systems Inc.||Not Affected||09 May 2005||10 May 2005|
|3Com||Unknown||09 May 2005||11 May 2005|
|Alcatel||Unknown||09 May 2005||11 May 2005|
|Apple Computer Inc.||Unknown||09 May 2005||11 May 2005|
|Aruba Networks||Unknown||09 May 2005||11 May 2005|
|AT&T||Unknown||09 May 2005||11 May 2005|
|Avaya||Unknown||09 May 2005||11 May 2005|
|Avici Systems Inc.||Unknown||09 May 2005||11 May 2005|
|Borderware||Unknown||09 May 2005||11 May 2005|
CVSS Metrics (Learn More)
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.
- CVE IDs: CAN-2005-0039
- Date Public: 09 May 2005
- Date First Published: 09 May 2005
- Date Last Updated: 06 Jul 2005
- Severity Metric: 4.32
- Document Revision: 13
If you have feedback, comments, or additional information about this vulnerability, please send us email.