CVE-2005-0039
CVSS6.4
发布时间 :2005-05-10 00:00:00
修订时间 :2016-10-17 23:07:30
NMCOPS    

[原文]Certain configurations of IPsec, when using Encapsulating Security Payload (ESP) in tunnel mode, integrity protection at a higher layer, or Authentication Header (AH), allow remote attackers to decrypt IPSec communications by modifying the outer packet in ways that cause plaintext data from the inner packet to be returned in ICMP messages, as demonstrated using bit-flipping attacks and (1) Destination Address Rewriting, (2) a modified header length that causes portions of the packet to be interpreted as IP Options, or (3) a modified protocol field and source address.


[CNNVD]IETF IPSEC协议封装安全负载漏洞(CNNVD-200505-937)

        IPSec是IETF(因特网工程任务组)提出的IP安全标准,它在IP层对数据包进行高强度的加密和验证,使安全服务独立于各种应用程序。
        IPSec协议的设计和实现上存在某些问题,攻击者可能利用此漏洞获取敏感信息。

- CVSS (基础分值)

CVSS分值: 6.4 [中等(MEDIUM)]
机密性影响: [--]
完整性影响: [--]
可用性影响: [--]
攻击复杂度: [--]
攻击向量: [--]
身份认证: [--]

- CPE (受影响的平台与产品)

产品及版本信息(CPE)暂不可用

- OVAL (用于检测的技术细节)

未找到相关OVAL定义

- 官方数据库链接

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0039
(官方数据源) MITRE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0039
(官方数据源) NVD
http://www.cnnvd.org.cn/vulnerability/show/cv_cnnvdid/CNNVD-200505-937
(官方数据源) CNNVD

- 其它链接及资源

http://marc.info/?l=bugtraq&m=111566201610350&w=2
(UNKNOWN)  BUGTRAQ  20050509 NISCC Vulnerability Advisory IPSEC - 004033
http://securitytracker.com/id?1015320
(UNKNOWN)  SECTRACK  1015320
http://www.kb.cert.org/vuls/id/302220
(UNKNOWN)  CERT-VN  VU#302220
http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html?lang=en
(UNKNOWN)  MISC  http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html?lang=en
http://www.securityfocus.com/archive/1/407774
(UNKNOWN)  HP  SSRT5957
http://www.securityfocus.com/bid/13562
(UNKNOWN)  BID  13562
http://www.vupen.com/english/advisories/2005/0507
(UNKNOWN)  VUPEN  ADV-2005-0507
http://www.vupen.com/english/advisories/2005/2806
(UNKNOWN)  VUPEN  ADV-2005-2806

- 漏洞信息

IETF IPSEC协议封装安全负载漏洞
中危 设计错误
2005-05-10 00:00:00 2005-10-20 00:00:00
远程  
        IPSec是IETF(因特网工程任务组)提出的IP安全标准,它在IP层对数据包进行高强度的加密和验证,使安全服务独立于各种应用程序。
        IPSec协议的设计和实现上存在某些问题,攻击者可能利用此漏洞获取敏感信息。

- 公告与补丁

        目前厂商还没有提供补丁或者升级程序,我们建议使用此软件的用户随时关注厂商的主页以获取最新版本:
        http://www.ietf.org/

- 漏洞信息 (F39123)

ipsec.niscc.txt (PacketStormID:F39123)
2005-08-07 00:00:00
 
advisory,protocol
CVE-2005-0039
[点击下载]

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.

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

- 漏洞信息

16455
Multiple Vendor IPSec ESP Multiple Method Communication Compromise

- 漏洞描述

- 时间线

2005-05-09 Unknow
Unknow Unknow

- 解决方案

Products

Unknown or Incomplete

- 相关参考

- 漏洞作者

Unknown or Incomplete

- 漏洞信息

IETF IPSEC Protocol Encapsulating Security Payload Vulnerability
Design Error 13562
Yes No
2005-05-09 12:00:00 2009-07-12 02:06:00
These attacks were reported by NISCC.

- 受影响的程序版本

IETF RFC 2406: IPSEC
HP Tru64 5.1 B-3
HP Tru64 5.1 B-2 PK4
HP HP-UX B.11.23
HP HP-UX B.11.11
HP HP-UX B.11.00
Hitachi GR2000-BH
Hitachi GR2000-2B+
Hitachi GR2000-2B
Hitachi GR2000-1B

- 漏洞讨论

A vulnerability affects certain configurations of IPSec.

When IPSec is configured to employ Encapsulating Security Payload (ESP) in tunnel mode with confidentiality only, where Authentication Header (AH) is not being used to provide packet integrity protection, certain attacks against the IPSec protocol are possible.

Reports indicate that these attacks may also potentially be possible against IPSec when AH is in use, but only under certain unspecified configurations.

The reported attacks take advantage of the fact that no ESP packet payload integrity checks exist when ESP is configured in the vulnerable aforementioned manner.

This issue may be leveraged by an attacker to reveal plaintext IP datagrams and potentially sensitive information. Information harvested in this manner may be used to aid in further attacks.

This BID will be updated as further information is made available.

- 漏洞利用

The discoverer of this issue reports that a reliable exploit was created to leverage this issue. This exploit is not believed to be public.

- 解决方案

Hitachi GR2000-B Series routers are affected by this vulnerability. Hitachi has advised affected users to use the AH protocol workaround to mitigate this issue.

HP has released advisory SSRT5957, along with fixes to address this issue. Please see the referenced advisory for further information.

HP has released advisory HPSBUX02079 and fixes to address this issue. Please see the referenced advisory for details.


HP Tru64 5.1 B-2 PK4

HP Tru64 5.1 B-3

- 相关参考

 

 

关于SCAP中文社区

SCAP中文社区是国内第一个以SCAP为主题的中文开放社区。了解更多信息,请查阅[关于本站]

版权声明

CVE/CWE/OVAL均为MITRE公司的注册商标,它们的官方数据源均保存在MITRE公司的相关网站