SkipNavigation
US-CERT
American Flag
  Vulnerability
Notes
Database

Search Vulnerability Notes

Vulnerability Notes Help Information


 
 View Notes By
  Name

ID Number

CVE Name

Date Public

Date Published

Date Updated

Severity Metric



 Other Documents
  Technical Alerts

Technical Bulletins

Alerts

Security Tips

 

Vulnerability Note VU#302220

IPsec configurations may be vulnerable to information disclosure

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.

I. 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).

II. 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.

III. 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

VendorStatusDate Updated
3ComUnknown11-May-2005
AlcatelUnknown11-May-2005
Apple Computer Inc.Unknown11-May-2005
Aruba NetworksUnknown11-May-2005
AT&TUnknown11-May-2005
AvayaUnknown11-May-2005
Avici Systems Inc.Unknown11-May-2005
BorderwareUnknown11-May-2005
CerticomUnknown11-May-2005
Charlotte's Web NetworksUnknown11-May-2005
Check PointNot Vulnerable10-May-2005
Chiaro NetworksUnknown11-May-2005
Cisco Systems Inc.Vulnerable17-May-2005
ClavisterUnknown11-May-2005
Computer AssociatesUnknown11-May-2005
ConnectivaUnknown11-May-2005
Cray Inc.Unknown11-May-2005
Data ConnectionUnknown11-May-2005
DebianUnknown11-May-2005
DlinkUnknown11-May-2005
EMC CorporationUnknown11-May-2005
EngardeUnknown11-May-2005
eSoftUnknown11-May-2005
Extreme NetworksUnknown11-May-2005
F-SecureUnknown11-May-2005
F5 NetworksNot Vulnerable13-May-2005
FortinetUnknown11-May-2005
Foundry Networks Inc.Unknown11-May-2005
FreeBSDUnknown11-May-2005
FreeS/WANUnknown11-May-2005
FujitsuUnknown11-May-2005
Global Technology AssociatesUnknown11-May-2005
Hewlett-Packard CompanyUnknown11-May-2005
HitachiUnknown11-May-2005
HyperchipUnknown11-May-2005
IBMNot Vulnerable10-May-2005
ImmunixUnknown11-May-2005
Ingrian NetworksUnknown11-May-2005
IntelUnknown11-May-2005
Internet Initiative Japan (IIJ)Unknown11-May-2005
Internet Security Systems Inc.Unknown11-May-2005
IntotoUnknown11-May-2005
Juniper NetworksUnknown13-May-2005
KAME ProjectUnknown11-May-2005
LinksysUnknown11-May-2005
Lucent TechnologiesUnknown11-May-2005
LuminousUnknown11-May-2005
MandrakeSoftUnknown11-May-2005
Microsoft CorporationUnknown11-May-2005
MontaVista SoftwareUnknown11-May-2005
Multi-Tech Systems Inc.Unknown11-May-2005
MultinetUnknown11-May-2005
NEC CorporationUnknown11-May-2005
NetBSDUnknown11-May-2005
NetfilterNot Vulnerable10-May-2005
Network ApplianceUnknown11-May-2005
NextHopUnknown11-May-2005
NISTUnknown11-May-2005
NokiaUnknown11-May-2005
Nortel NetworksNot Vulnerable10-May-2005
NovellUnknown11-May-2005
OpenBSDUnknown11-May-2005
Openwall GNU/*/LinuxUnknown11-May-2005
QNXUnknown11-May-2005
Red Hat Inc.Unknown11-May-2005
Redback Networks Inc.Unknown11-May-2005
Riverstone NetworksUnknown11-May-2005
SafeNetUnknown11-May-2005
SCO LinuxUnknown11-May-2005
SCO UnixUnknown11-May-2005
Secure Computing CorporationUnknown11-May-2005
SecureWorksUnknown11-May-2005
SequentUnknown11-May-2005
SGIUnknown11-May-2005
SonicWALL Inc.Unknown13-May-2005
Sony CorporationUnknown11-May-2005
SSH Communications SecurityUnknown11-May-2005
StonesoftUnknown11-May-2005
Sun Microsystems Inc.Unknown11-May-2005
SuSE Inc.Unknown11-May-2005
Symantec CorporationUnknown11-May-2005
TurboLinuxUnknown11-May-2005
UnisysUnknown11-May-2005
WatchGuardUnknown11-May-2005
Wind River Systems Inc.Not Vulnerable10-May-2005
ZyXELUnknown11-May-2005

References


http://www.niscc.gov.uk/niscc/docs/re-20050509-00385.pdf?lang=en
http://jvn.jp/niscc/NISCC-004033/index.html
http://www.ietf.org/ids.by.wg/ipsec.html

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

Date Public05/09/2005
Date First Published05/09/2005 12:39:30 PM
Date Last Updated07/06/2005
CERT Advisory 
CVE NameCAN-2005-0039
US-CERT Technical Alerts 
Metric4.32
Document Revision13

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

 
Page Corner Image
Copyright 2005 Carnegie Mellon University
Disclaimers and copyright information
Get Adobe Reader Get Adobe Reader