[Openswan Users] FW: NISCC Vulnerability Advisory IPSEC - 004033

[Ryley Breiddal]

Hello everyone,

I received the vulnerability notice below from bugtraq, among other sources.
I was curious if anyone can decipher whether Openswan is exposed to the flaw
in default/normal configurations.  The notice makes reference to "integrity
protection" within ESP (as opposed to via AH).  Would the "integrity
protection" be in using MD5/SHA-1 for ESP?  If so, would that mean that most
Openswan tunnels are not vulnerable?

Thanks,


Ryley Breiddal
PresiNET Systems

albatross at tim.it wrote:
> 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 at niscc.gov.uk
>            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 at niscc.gov.uk.
> 
> 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.