RE: NISCC Vulnerability Advisory IPSEC - 004033
- From: "Troy Radtke" <TRadtke@xxxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Mon, 9 May 2005 13:47:30 -0500
Thanks Tom. Good bathroom reading while I install SBS2k3 tonight....
Looks like it might be interesting enough to hook up the traffic sniffer
at home see what it all turns out like.....
-----Original Message-----
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx]
Sent: Monday, May 09, 2005 12:34 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: NISCC Vulnerability Advisory IPSEC - 004033
http://www.ISAserver.org
Hi Troy,
Yes... Here's an meat:
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.
Tom
www.isaserver.org/shinder
Tom and Deb Shinder's Configuring ISA Server 2004
http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
-----Original Message-----
From: Troy Radtke [mailto:TRadtke@xxxxxxxxxxxx]
Sent: Monday, May 09, 2005 12:29 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: NISCC Vulnerability Advisory IPSEC - 004033
http://www.ISAserver.org
Can get the link to work (stupid DNS on this end) Is this a flaw in the
protocol itself or ???
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
World of Windows Networking: http://www.windowsnetworking.com
Leading Network Software Directory: http://www.serverfiles.com
No.1 Exchange Server Resource Site: http://www.msexchange.org
Windows Security Resource Site: http://www.windowsecurity.com/
Network Security Library: http://www.secinf.net/
Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
tradtke@xxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
Other related posts:
