NISCC Vulnerability Advisory IPSEC - 004033
Abstract: 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.
Vendors affected:
Operating Systems affected:
Applications/Services affected: IPSEC
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.
Contact Information
- - -------------------
The NISCC Vulnerability Management Team can be contacted as follows:
Email vulteam@xxxxxxxxxxxx
Please quote the advisory reference in the subject line
Telephone +44 (0)870 487 0748 Ext 4511
Monday - Friday 08:30 - 17:00
Fax +44 (0)870 487 0749
Post Vulnerability Management Team
NISCC
PO Box 832
London
SW1P 1BG
We encourage those who wish to communicate via email to make use of our PGP
key. This is
available from http://www.niscc.gov.uk/niscc/publicKey2-en.pop.
Please note that UK government protectively marked material should not be sent
to the email
address above.
If you wish to be added to our email distribution list please email your
request to
uniras@xxxxxxxxxxxxx
What is NISCC?
- - --------------
For further information regarding the UK National Infrastructure Security
Co-ordination Centre,
please visit http://www.niscc.gov.uk/.
Reference to any specific commercial product, process, or service by trade
name, trademark
manufacturer, or otherwise, does not constitute or imply its endorsement,
recommendation, or
favouring by NISCC. The views and opinions of authors expressed within this
notice shall not
be used for advertising or product endorsement purposes.
Neither shall NISCC accept responsibility for any errors or omissions contained
within this
advisory. In particular, they shall not be liable for any loss or damage
whatsoever,
arising from or in connection with the usage of information contained within
this notice.
C 2005 Crown Copyright
<End of NISCC Vulnerability Advisory>
Acknowledgements
UNIRAS wishes to acknowledge the contributions of NISCC Vulnerability Team for
the information contained in this Briefing.
Updates
This advisory contains the information released by the original author. Some of
the information may have changed since it was released. If the vulnerability
affects you, it may be prudent to retrieve the advisory from the canonical site
to ensure that you receive the most current information concerning that problem.
Legal Disclaimer
Reference to any specific commercial product, process, or service by trade
name, trademark manufacturer, or otherwise, does not constitute or imply its
endorsement, recommendation, or favouring by UNIRAS or NISCC. The views and
opinions of authors expressed within this notice shall not be used for
advertising or product endorsement purposes.
Neither UNIRAS or NISCC shall also accept responsibility for any errors or
omissions contained within this briefing notice. In particular, they shall not
be liable for any loss or damage whatsoever, arising from or in connection with
the usage of information contained within this notice.
FIRST
UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST)
and has contacts with other international Incident Response Teams (IRTs) in
order to foster cooperation and coordination in incident prevention, to prompt
rapid reaction to incidents, and to promote information sharing amongst its
members and the community at large.