Vulnerability Note VU#302220

IPsec configurations may be vulnerable to information disclosure

Original Release date: 09 May 2005 | Last revised: 06 Jul 2005

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.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
Cisco Systems Inc.Affected09 May 200517 May 2005
Check PointNot Affected09 May 200510 May 2005
F5 NetworksNot Affected09 May 200513 May 2005
IBMNot Affected09 May 200510 May 2005
NetfilterNot Affected09 May 200510 May 2005
Nortel NetworksNot Affected09 May 200510 May 2005
Wind River Systems Inc.Not Affected09 May 200510 May 2005
3ComUnknown09 May 200511 May 2005
AlcatelUnknown09 May 200511 May 2005
Apple Computer Inc.Unknown09 May 200511 May 2005
Aruba NetworksUnknown09 May 200511 May 2005
AT&TUnknown09 May 200511 May 2005
AvayaUnknown09 May 200511 May 2005
Avici Systems Inc.Unknown09 May 200511 May 2005
BorderwareUnknown09 May 200511 May 2005
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

Credit

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: 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

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.