Published:
10 May 2005
Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2005.0374 -- UNIRAS ALERT - 15/05
NISCC Vulnerability Advisory IPSEC - 004033
10 May 2005
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: IPsec
Publisher: UNIRAS
Impact: Access Privileged Data
Access: Remote/Unauthenticated
CVE Names: CAN-2005-0039
Original Bulletin:
http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html
- --------------------------BEGIN INCLUDED TEXT--------------------
- ---------------------------------------------------------------------------------
UNIRAS (UK Govt CERT) ALERT - 15/05 dated 09.05.05 Time: 12:00
UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre)
- ---------------------------------------------------------------------------------
UNIRAS material is also available from its website at www.uniras.gov.uk and
Information about NISCC is available from www.niscc.gov.uk
- ---------------------------------------------------------------------------------
Title
=====
NISCC Vulnerability Advisory IPSEC - 004033
Detail
======
NISCC Vulnerability Advisory 004033/NISCC/IPSEC
Vulnerability Issues with IPsec Configurations
Version Information
- -------------------
Advisory Reference 004033/NISCC/IPSEC
Release Date 9 May 2005
Last Revision 9 May 2005
Version Number 1.0
What is affected?
- -----------------
Potentially any configuration of IPsec that uses Encapsulating Security Payload (ESP) in tunnel
mode with confidentiality only, or with integrity protection being provided by a higher layer
protocol. Some configurations using AH to provide integrity protection are also vulnerable.
Impact
- ------
If exploited, it is possible for an active attacker to obtain the plaintext version of the IPsec-
protected communications using only moderate effort.
Severity
- --------
This is rated as high.
Summary
- -------
IP Security (IPsec) is a set of protocols developed by the Internet Engineering Task Force (IETF)
to support secure exchange of packets at the IP layer; IPsec has been deployed widely to implement
Virtual Private Networks (VPNs).
Three attacks that apply to certain configurations of IPsec have been identified. These
configurations use Encapsulating Security Payload (ESP) in tunnel mode with confidentiality only,
or with integrity protection being provided by a higher layer protocol. Some configurations using
AH to provide integrity protection are also vulnerable. In these configurations, an attacker can
modify sections of the IPsec packet, causing either the cleartext inner packet to be redirected or
a network host to generate an error message. In the latter case, these errors are relayed via the
Internet Control Message Protocol (ICMP); because of the design of ICMP, these messages directly
reveal segments of the header and payload of the inner datagram in cleartext. An attacker who can
intercept the ICMP messages can then retrieve plaintext data. The attacks have been implemented and
demonstrated to work under realistic conditions.
[Please note that revisions to this advisory will not be notified by email. All
subscribers are advised to regularly check the UNIRAS website for updates to this notice.]
Details
- -------
CVE number: CAN-2005-0039
IPsec consists of several separate protocols; these include:
* Authentication Header (AH): provides authenticity guarantees for packets, by attaching strong
cryptographic checksum to packets.
* Encapsulating Security Payload (ESP): provides confidentiality guarantees for packets, by
encrypting packets with encryption algorithms. ESP also provides optional authentication services
for packets.
* Internet Key Exchange (IKE): provide ways to securely negotiate shared keys.
AH and ESP has two modes of use: transport mode and tunnel mode. With ESP in tunnel mode, an IP
packet (called the inner packet) is encrypted in its entirety and is used to form the payload of
a new packet (called the outer packet); ESP typically uses CBC-mode encryption to provide
confidentiality. However, without some form of integrity protection, CBC-mode encrypted
data is vulnerable to modification by an active attacker.
By making careful modifications to selected portions of the payload of the outer packet, an
attacker can effect controlled changes to the header of the inner (encrypted) packet. The modified
inner packet is subsequently processed by the IP software on the receiving security gateway or the
endpoint host; the inner packet, in cleartext form, may be redirected or certain error messages
may be produced and communicated by ICMP. Because of the design of ICMP, these messages directly
reveal cleartext segments of the header and payload of the inner packet. If these messages can be
intercepted by an attacker, then plaintext data is revealed.
Attacks exploiting these vulnerabilities rely on the following:
* Exploitation of the well-known bit flipping weakness of CBC mode encryption.
* Lack of integrity protection for inner packets.
* Interaction between IPsec processing and IP processing on security gateways and end hosts.
These attacks can be fully automated so as to recover the entire contents of multiple
IPsec-protected inner packets.
In more detail, the three identified attacks on ESP in tunnel mode when integrity protection is not
present work as follows:
1. Destination Address Rewriting
* An attacker modifies the destination IP address of the encrypted (inner) packet by bit-
flipping in the payload of the outer packet.
* The security gateway decrypts the outer payload to recover the (modified) inner packet.
* The gateway then routes the inner packet according to its (modified) destination IP address.
* If successful, the "plaintext" inner datagram arrives at a host of the attacker's choice.
2. IP Options
* An attacker modifies the header length of the encrypted (inner) packet by bit-flipping in the
payload of the outer packet.
* The security gateway decrypts the outer payload to recover the (modified) inner packet.
* The gateway then performs IP options processing on the inner packet because of the modified
header length, with the first part of the inner payload being interpreted as options bytes.
* With some probability, options processing will result in the generation of an ICMP "parameter
problem" message.
* The ICMP message is routed to the now modified source address of the inner packet.
* An attacker intercepts the ICMP message and retrieves the "plaintext" payload of the inner
packet.
3. Protocol Field
* An attacker modifies the protocol field and source address field of the encrypted (inner)
packet by bit-flipping in the payload of the outer packet.
* The security gateway decrypts the outer payload to recover the (modified) inner packet.
* The gateway forwards the inner packet to the intended recipient.
* The intended recipient inspects the protocol field of the inner packet and generates an ICMP
"protocol unreachable" message.
* The ICMP message is routed to the now modified source address of the inner packet.
* An attacker intercepts the ICMP message and retrieves the "plaintext" payload of the inner
packet.
The attacks are probabilistic in nature and may need to be iterated many times in a first phase in
order to be successful. Once this first phase is complete, the results can be reused to efficiently
recover the contents of further inner packets.
Naturally, the attacker must be able to intercept traffic passing between the security gateways in
order to mount the attacks. For the second and third attacks to be successful, the attacker must be
able intercept the relevant ICMP messages. Variants of these attacks in which the destination of
the ICMP messages can be controlled by the attacker are also possible.
Solution
- --------
Any of the following methods can be used to rectify this issue:
1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution.
2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done
carefully: for example, the configuration where AH in transport mode is applied end-to-end and
tunnelled inside ESP is still vulnerable.
3. Remove the error reporting by restricting the generation of ICMP messages or by filtering
these messages at a firewall or security gateway.
Vendor Information
- ------------------
A list of vendors affected by this vulnerability is not currently available. Please visit the web
site in order to check for updates.
Credits
- -------
The NISCC Vulnerability Team would like to thank all vendors for their co-operation with
the handling of this vulnerability.
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
If you believe that your computer system has been compromised or attacked in
any way, we encourage you to let us know by completing the secure National IT
Incident Reporting Form at:
http://www.auscert.org.au/render.html?it=3192
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQCVAwUBQoAEkih9+71yA2DNAQJz0gP/YjWY07kutVZInBNF/xpvaJizPHARgMF6
uye40cHkMcDnvg7AWd9lp6vaffkulxTSrkhsFWf8Y2fuYFnTDweeLOilMuA0nUby
JGPwEefILChbjZh4ug9kN5RdXZ8wWPrGmTN3ou0qDxTUbxe5mSyZrEcwGXIT8tyY
YEi5pb9wnlQ=
=BGeq
-----END PGP SIGNATURE-----