var-200505-0908
Vulnerability from variot
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. IPSec Confidentiality when communicating (Confidentiality) Protection only, integrity (Integrity) A vulnerability has been discovered that occurs when protection is not set. ESP Keys used (AES , DES , Triple-DES) Occurs regardless of the version or key size. The vulnerability was encrypted IPSec For communication bit-flipping By using the technique IP header ( Source address, header length, protocol field ) It is abused by tampering with the data inside. After data has been tampered with, it is sent to the sender ICMP There is a possibility that the communication contents will be acquired by receiving the error message.IPSec As a result, it is possible that important information is acquired. A vulnerability affects certain configurations of IPSec. 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.
Bist Du interessiert an einem neuen Job in IT-Sicherheit?
Secunia hat zwei freie Stellen als Junior und Senior Spezialist in IT- Sicherheit: http://secunia.com/secunia_vacancies/
TITLE: HP Tru64 UNIX IPsec Tunnel ESP Mode Encrypted Data Disclosure
SECUNIA ADVISORY ID: SA16401
VERIFY ADVISORY: http://secunia.com/advisories/16401/
CRITICAL: Less critical
IMPACT: Exposure of sensitive information
WHERE:
From remote
OPERATING SYSTEM: HP Tru64 UNIX 5.x http://secunia.com/product/2/
DESCRIPTION: HP has acknowledged a vulnerability in HP Tru64 UNIX, which can be exploited by malicious people to disclose certain sensitive information.
The vulnerability affects the following supported versions: * HP Tru64 UNIX 5.1B-3 * HP Tru64 UNIX 5.1B-2/PK4
SOLUTION: Apply ERP kits.
PROVIDED AND/OR DISCOVERED BY: NISCC
ORIGINAL ADVISORY: HP SSRT5957: http://itrc.hp.com/service/cki/docDisplay.do?docId=HPSBTU01217
NISCC: http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html
About: This Advisory was delivered by Secunia as a free service to help everybody keeping their systems up to date against the latest vulnerabilities.
Subscribe: http://secunia.com/secunia_security_advisories/
Definitions: (Criticality, Where etc.) http://secunia.com/about_secunia_advisories/
Please Note: Secunia recommends that you verify all advisories you receive by clicking the link. Secunia NEVER sends attached files with advisories. Secunia does not advise people to install third party patches, only use those supplied by the vendor.
Unsubscribe: Secunia Security Advisories http://secunia.com/sec_adv_unsubscribe/?email=packet%40packetstormsecurity.org
. Some configurations using AH to provide integrity protection are also vulnerable. 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). 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. 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. 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.
-
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.
-
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:
-
This is the recommended solution.
-
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.
-
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
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. 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.
SOLUTION: The vendor recommends configuring ESP to use both encryption and authentication (see vendor's advisory for more information)
Show details on source website{
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#",
"affected_products": {
"@id": "https://www.variotdbs.pl/ref/affected_products"
},
"configurations": {
"@id": "https://www.variotdbs.pl/ref/configurations"
},
"credits": {
"@id": "https://www.variotdbs.pl/ref/credits"
},
"cvss": {
"@id": "https://www.variotdbs.pl/ref/cvss/"
},
"description": {
"@id": "https://www.variotdbs.pl/ref/description/"
},
"exploit_availability": {
"@id": "https://www.variotdbs.pl/ref/exploit_availability/"
},
"external_ids": {
"@id": "https://www.variotdbs.pl/ref/external_ids/"
},
"iot": {
"@id": "https://www.variotdbs.pl/ref/iot/"
},
"iot_taxonomy": {
"@id": "https://www.variotdbs.pl/ref/iot_taxonomy/"
},
"patch": {
"@id": "https://www.variotdbs.pl/ref/patch/"
},
"problemtype_data": {
"@id": "https://www.variotdbs.pl/ref/problemtype_data/"
},
"references": {
"@id": "https://www.variotdbs.pl/ref/references/"
},
"sources": {
"@id": "https://www.variotdbs.pl/ref/sources/"
},
"sources_release_date": {
"@id": "https://www.variotdbs.pl/ref/sources_release_date/"
},
"sources_update_date": {
"@id": "https://www.variotdbs.pl/ref/sources_update_date/"
},
"threat_type": {
"@id": "https://www.variotdbs.pl/ref/threat_type/"
},
"title": {
"@id": "https://www.variotdbs.pl/ref/title/"
},
"type": {
"@id": "https://www.variotdbs.pl/ref/type/"
}
},
"@id": "https://www.variotdbs.pl/vuln/VAR-200505-0908",
"affected_products": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/affected_products#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"model": "ipsec",
"scope": "eq",
"trust": 1.6,
"vendor": "nissc",
"version": "1.0"
},
{
"model": null,
"scope": null,
"trust": 0.8,
"vendor": "cisco",
"version": null
},
{
"model": "router",
"scope": "eq",
"trust": 0.8,
"vendor": "allied telesis",
"version": "(ipsec all products that support )"
},
{
"model": "ax2000r series",
"scope": "eq",
"trust": 0.8,
"vendor": "alaxala",
"version": null
},
{
"model": "seil/neu",
"scope": "eq",
"trust": 0.8,
"vendor": "internet initiative",
"version": "atm 1.10 (pogo) ~ 1.39 (smith grind)"
},
{
"model": "seil/neu",
"scope": "eq",
"trust": 0.8,
"vendor": "internet initiative",
"version": "ver. 1.x 1.52 (inkknot) ~ 1.93 (harness)"
},
{
"model": "seil/neu",
"scope": "eq",
"trust": 0.8,
"vendor": "internet initiative",
"version": "ver. 2.x 2.00 (belay) ~ 2.27 (ridge)"
},
{
"model": "seil/plus",
"scope": "eq",
"trust": 0.8,
"vendor": "internet initiative",
"version": "1.00 (snappy) ~ 1.51 (swisssingle)"
},
{
"model": "seil/turbo",
"scope": "eq",
"trust": 0.8,
"vendor": "internet initiative",
"version": "1.00 (union) ~ 1.51 (riodell)"
},
{
"model": "hp-ux",
"scope": "eq",
"trust": 0.8,
"vendor": "hewlett packard",
"version": "11.00"
},
{
"model": "hp-ux",
"scope": "eq",
"trust": 0.8,
"vendor": "hewlett packard",
"version": "11.11"
},
{
"model": "hp-ux",
"scope": "eq",
"trust": 0.8,
"vendor": "hewlett packard",
"version": "11.23"
},
{
"model": "rt series",
"scope": null,
"trust": 0.8,
"vendor": "yamaha",
"version": null
},
{
"model": "fitelnet-f series",
"scope": "eq",
"trust": 0.8,
"vendor": "furukawa electric",
"version": "fitelnet-f30 (fitelnet-f40 or f100 when grouped with )"
},
{
"model": "fitelnet-f series",
"scope": "eq",
"trust": 0.8,
"vendor": "furukawa electric",
"version": "fitelnet-f40"
},
{
"model": "mucho series",
"scope": "eq",
"trust": 0.8,
"vendor": "furukawa electric",
"version": "mucho-ev"
},
{
"model": "mucho series",
"scope": "eq",
"trust": 0.8,
"vendor": "furukawa electric",
"version": "mucho-ev/pk"
},
{
"model": "ip38x series",
"scope": null,
"trust": 0.8,
"vendor": "nec",
"version": null
},
{
"model": "ix1000 series",
"scope": null,
"trust": 0.8,
"vendor": "nec",
"version": null
},
{
"model": "ix2000 series",
"scope": null,
"trust": 0.8,
"vendor": "nec",
"version": null
},
{
"model": "ix3000 series",
"scope": null,
"trust": 0.8,
"vendor": "nec",
"version": null
},
{
"model": "ix5000 series",
"scope": null,
"trust": 0.8,
"vendor": "nec",
"version": null
},
{
"model": "qx series",
"scope": "eq",
"trust": 0.8,
"vendor": "nec",
"version": "qx-r"
},
{
"model": "gr2000",
"scope": "eq",
"trust": 0.8,
"vendor": "hitachi",
"version": "(b_model) (route-os6bsec"
},
{
"model": "gr2000",
"scope": "eq",
"trust": 0.8,
"vendor": "hitachi",
"version": "route-os8bsec applying equipment )"
},
{
"model": "rfc ipsec",
"scope": "eq",
"trust": 0.3,
"vendor": "ietf",
"version": "2406:"
},
{
"model": "tru64 b-3",
"scope": "eq",
"trust": 0.3,
"vendor": "hp",
"version": "5.1"
},
{
"model": "tru64 b-2 pk4",
"scope": "eq",
"trust": 0.3,
"vendor": "hp",
"version": "5.1"
},
{
"model": "hp-ux b.11.23",
"scope": null,
"trust": 0.3,
"vendor": "hp",
"version": null
},
{
"model": "hp-ux b.11.11",
"scope": null,
"trust": 0.3,
"vendor": "hp",
"version": null
},
{
"model": "hp-ux b.11.00",
"scope": null,
"trust": 0.3,
"vendor": "hp",
"version": null
},
{
"model": "gr2000-bh",
"scope": null,
"trust": 0.3,
"vendor": "hitachi",
"version": null
},
{
"model": "gr2000-2b+",
"scope": null,
"trust": 0.3,
"vendor": "hitachi",
"version": null
},
{
"model": "gr2000-2b",
"scope": null,
"trust": 0.3,
"vendor": "hitachi",
"version": null
},
{
"model": "gr2000-1b",
"scope": null,
"trust": 0.3,
"vendor": "hitachi",
"version": null
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#302220"
},
{
"db": "BID",
"id": "13562"
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"configurations": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/configurations#",
"children": {
"@container": "@list"
},
"cpe_match": {
"@container": "@list"
},
"data": {
"@container": "@list"
},
"nodes": {
"@container": "@list"
}
},
"data": [
{
"CVE_data_version": "4.0",
"nodes": [
{
"cpe_match": [
{
"cpe22Uri": "cpe:/h:allied_telesis_k.k.:router",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:alaxala:ax2000r",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:hp:hp-ux",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:yamaha:rt",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:furukawa_electric:fitelnet-f",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:furukawa_electric:mucho",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:nec:ip38x",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:nec:ix1000",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:nec:ix2000",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:nec:ix3000",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:nec:ix5000",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:nec:qx",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/h:hitachi:gr2000",
"vulnerable": true
}
],
"operator": "OR"
}
]
}
],
"sources": [
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
}
]
},
"credits": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/credits#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "NISCC albatross@tim.it",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
}
],
"trust": 0.6
},
"cve": "CVE-2005-0039",
"cvss": {
"@context": {
"cvssV2": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV2"
},
"cvssV3": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/"
},
"severity": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/cvss/severity#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/severity"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"cvssV2": [
{
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "NONE",
"author": "nvd@nist.gov",
"availabilityImpact": "NONE",
"baseScore": 6.4,
"confidentialityImpact": "PARTIAL",
"exploitabilityScore": 10.0,
"id": "CVE-2005-0039",
"impactScore": 4.9,
"integrityImpact": "PARTIAL",
"severity": "MEDIUM",
"trust": 1.8,
"vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N",
"version": "2.0"
}
],
"cvssV3": [],
"severity": [
{
"author": "nvd@nist.gov",
"id": "CVE-2005-0039",
"trust": 1.0,
"value": "MEDIUM"
},
{
"author": "CARNEGIE MELLON",
"id": "VU#302220",
"trust": 0.8,
"value": "4.32"
},
{
"author": "NVD",
"id": "CVE-2005-0039",
"trust": 0.8,
"value": "Medium"
},
{
"author": "CNNVD",
"id": "CNNVD-200505-937",
"trust": 0.6,
"value": "MEDIUM"
}
]
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#302220"
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"description": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/description#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "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. IPSec Confidentiality when communicating (Confidentiality) Protection only, integrity (Integrity) A vulnerability has been discovered that occurs when protection is not set. ESP Keys used (AES , DES , Triple-DES) Occurs regardless of the version or key size. The vulnerability was encrypted IPSec For communication bit-flipping By using the technique IP header ( Source address, header length, protocol field ) It is abused by tampering with the data inside. After data has been tampered with, it is sent to the sender ICMP There is a possibility that the communication contents will be acquired by receiving the error message.IPSec As a result, it is possible that important information is acquired. A vulnerability affects certain configurations of IPSec. \nReports indicate that these attacks may also potentially be possible against IPSec when AH is in use, but only under certain unspecified configurations. \nThe reported attacks take advantage of the fact that no ESP packet payload integrity checks exist when ESP is configured in the vulnerable aforementioned manner. \nThis 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. \nThis BID will be updated as further information is made available. \n\n----------------------------------------------------------------------\n\nBist Du interessiert an einem neuen Job in IT-Sicherheit?\n\n\nSecunia hat zwei freie Stellen als Junior und Senior Spezialist in IT-\nSicherheit:\nhttp://secunia.com/secunia_vacancies/\n\n----------------------------------------------------------------------\n\nTITLE:\nHP Tru64 UNIX IPsec Tunnel ESP Mode Encrypted Data Disclosure\n\nSECUNIA ADVISORY ID:\nSA16401\n\nVERIFY ADVISORY:\nhttp://secunia.com/advisories/16401/\n\nCRITICAL:\nLess critical\n\nIMPACT:\nExposure of sensitive information\n\nWHERE:\n\u003eFrom remote\n\nOPERATING SYSTEM:\nHP Tru64 UNIX 5.x\nhttp://secunia.com/product/2/\n\nDESCRIPTION:\nHP has acknowledged a vulnerability in HP Tru64 UNIX, which can be\nexploited by malicious people to disclose certain sensitive\ninformation. \n\nThe vulnerability affects the following supported versions:\n* HP Tru64 UNIX 5.1B-3\n* HP Tru64 UNIX 5.1B-2/PK4\n\nSOLUTION:\nApply ERP kits. \n\nPROVIDED AND/OR DISCOVERED BY:\nNISCC\n\nORIGINAL ADVISORY:\nHP SSRT5957:\nhttp://itrc.hp.com/service/cki/docDisplay.do?docId=HPSBTU01217\n\nNISCC:\nhttp://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html\n\n----------------------------------------------------------------------\n\nAbout:\nThis Advisory was delivered by Secunia as a free service to help\neverybody keeping their systems up to date against the latest\nvulnerabilities. \n\nSubscribe:\nhttp://secunia.com/secunia_security_advisories/\n\nDefinitions: (Criticality, Where etc.)\nhttp://secunia.com/about_secunia_advisories/\n\n\nPlease Note:\nSecunia recommends that you verify all advisories you receive by\nclicking the link. \nSecunia NEVER sends attached files with advisories. \nSecunia does not advise people to install third party patches, only\nuse those supplied by the vendor. \n\n----------------------------------------------------------------------\n\nUnsubscribe: Secunia Security Advisories\nhttp://secunia.com/sec_adv_unsubscribe/?email=packet%40packetstormsecurity.org\n\n----------------------------------------------------------------------\n\n\n. Some configurations using AH to provide integrity protection are also vulnerable. Some configurations using AH to provide integrity protection are also vulnerable. \n\nImpact\n- - ------\nIf exploited, it is possible for an active attacker to obtain the plaintext version of the IPsec-\nprotected communications using only moderate effort. \n\nSeverity \n- - --------\nThis is rated as high. \n\nSummary\n- - -------\nIP Security (IPsec) is a set of protocols developed by the Internet Engineering Task Force (IETF) \nto support secure exchange of packets at the IP layer; IPsec has been deployed widely to implement \nVirtual Private Networks (VPNs). Some configurations using \nAH to provide integrity protection are also vulnerable. In these configurations, an attacker can \nmodify sections of the IPsec packet, causing either the cleartext inner packet to be redirected or \na network host to generate an error message. In the latter case, these errors are relayed via the \nInternet Control Message Protocol (ICMP); because of the design of ICMP, these messages directly \nreveal segments of the header and payload of the inner datagram in cleartext. An attacker who can \nintercept the ICMP messages can then retrieve plaintext data. The attacks have been implemented and \n\ndemonstrated to work under realistic conditions. \n\n[Please note that revisions to this advisory will not be notified by email. All \nsubscribers are advised to regularly check the UNIRAS website for updates to this notice.]\n\nDetails\n- - -------\nCVE number: CAN-2005-0039\n\nIPsec consists of several separate protocols; these include:\n\n * Authentication Header (AH): provides authenticity guarantees for packets, by attaching strong \n\n cryptographic checksum to packets. \n\n * Encapsulating Security Payload (ESP): provides confidentiality guarantees for packets, by \n encrypting packets with encryption algorithms. ESP also provides optional authentication \nservices\n for packets. \n\n * Internet Key Exchange (IKE): provide ways to securely negotiate shared keys. \n\nAH and ESP has two modes of use: transport mode and tunnel mode. However, without some form of integrity protection, CBC-mode encrypted \ndata is vulnerable to modification by an active attacker. \n\nBy making careful modifications to selected portions of the payload of the outer packet, an \nattacker can effect controlled changes to the header of the inner (encrypted) packet. The modified \ninner packet is subsequently processed by the IP software on the receiving security gateway or the \nendpoint host; the inner packet, in cleartext form, may be redirected or certain error messages \nmay be produced and communicated by ICMP. Because of the design of ICMP, these messages directly\nreveal cleartext segments of the header and payload of the inner packet. If these messages can be \nintercepted by an attacker, then plaintext data is revealed. \n\nAttacks exploiting these vulnerabilities rely on the following:\n\n * Exploitation of the well-known bit flipping weakness of CBC mode encryption. \n \n * Lack of integrity protection for inner packets. \n\n * Interaction between IPsec processing and IP processing on security gateways and end hosts. \n\n \nThese attacks can be fully automated so as to recover the entire contents of multiple \nIPsec-protected inner packets. Destination Address Rewriting\n\n * An attacker modifies the destination IP address of the encrypted (inner) packet by bit-\n flipping in the payload of the outer packet. \n * The security gateway decrypts the outer payload to recover the (modified) inner packet. \n * The gateway then routes the inner packet according to its (modified) destination IP address. \n * If successful, the \"plaintext\" inner datagram arrives at a host of the attacker\u0027s choice. \n\n2. IP Options\n\n * An attacker modifies the header length of the encrypted (inner) packet by bit-flipping in the \n\n payload of the outer packet. \n * The security gateway decrypts the outer payload to recover the (modified) inner packet. \n * The gateway then performs IP options processing on the inner packet because of the modified \n header length, with the first part of the inner payload being interpreted as options bytes. \n * With some probability, options processing will result in the generation of an ICMP \"parameter \n\n problem\" message. \n * The ICMP message is routed to the now modified source address of the inner packet. \n * An attacker intercepts the ICMP message and retrieves the \"plaintext\" payload of the inner \n packet. \n\n3. Protocol Field\n\n * An attacker modifies the protocol field and source address field of the encrypted (inner) \n packet by bit-flipping in the payload of the outer packet. \n * The security gateway decrypts the outer payload to recover the (modified) inner packet. \n * The gateway forwards the inner packet to the intended recipient. \n * The intended recipient inspects the protocol field of the inner packet and generates an ICMP\n \"protocol unreachable\" message. \n * The ICMP message is routed to the now modified source address of the inner packet. \n * An attacker intercepts the ICMP message and retrieves the \"plaintext\" payload of the inner \n packet. \n\nThe attacks are probabilistic in nature and may need to be iterated many times in a first phase in \norder to be successful. Once this first phase is complete, the results can be reused to efficiently\nrecover the contents of further inner packets. \n\nNaturally, the attacker must be able to intercept traffic passing between the security gateways in \norder to mount the attacks. For the second and third attacks to be successful, the attacker must be \n\nable intercept the relevant ICMP messages. Variants of these attacks in which the destination of \nthe ICMP messages can be controlled by the attacker are also possible. \n\nSolution\n- - --------\nAny of the following methods can be used to rectify this issue:\n\n1. This is the recommended \nsolution. \n\n2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done \ncarefully: for example, the configuration where AH in transport mode is applied end-to-end and \ntunnelled inside ESP is still vulnerable. \n\n3. Remove the error reporting by restricting the generation of ICMP messages or by filtering \nthese messages at a firewall or security gateway. \n\nVendor Information\n- - ------------------\nA list of vendors affected by this vulnerability is not currently available. Please visit the web \nsite in order to check for updates. \n\nCredits\n- - -------\nThe NISCC Vulnerability Team would like to thank all vendors for their co-operation with \nthe handling of this vulnerability. \n\nContact Information\n- - -------------------\nThe NISCC Vulnerability Management Team can be contacted as follows:\n\nEmail\t vulteam@niscc.gov.uk \n Please quote the advisory reference in the subject line\n\nTelephone +44 (0)870 487 0748 Ext 4511\n Monday - Friday 08:30 - 17:00\n\nFax\t +44 (0)870 487 0749\n\nPost\t Vulnerability Management Team\n NISCC\n PO Box 832\n London\n SW1P 1BG\n\nWe encourage those who wish to communicate via email to make use of our PGP key. This is \navailable from http://www.niscc.gov.uk/niscc/publicKey2-en.pop. \n\nPlease note that UK government protectively marked material should not be sent to the email \naddress above. \n\nIf you wish to be added to our email distribution list please email your request to \nuniras@niscc.gov.uk. \n \nWhat is NISCC?\n- - --------------\nFor further information regarding the UK National Infrastructure Security Co-ordination Centre, \nplease visit http://www.niscc.gov.uk/. \n \nReference to any specific commercial product, process, or service by trade name, trademark \nmanufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or \nfavouring by NISCC. The views and opinions of authors expressed within this notice shall not \nbe used for advertising or product endorsement purposes. \n\nNeither shall NISCC accept responsibility for any errors or omissions contained within this \nadvisory. In particular, they shall not be liable for any loss or damage whatsoever, \narising from or in connection with the usage of information contained within this notice. \n\nC 2005 Crown Copyright \n\u003cEnd of NISCC Vulnerability Advisory\u003e\n \n \n\nAcknowledgements\n\nUNIRAS wishes to acknowledge the contributions of NISCC Vulnerability Team for the information contained in this Briefing. \nUpdates\n\nThis advisory contains the information released by the original author. 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. \nLegal Disclaimer\n\nReference 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. \n\nNeither 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. \nFIRST\n\nUNIRAS 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. \n\nSOLUTION:\nThe vendor recommends configuring ESP to use both encryption and\nauthentication (see vendor\u0027s advisory for more information)",
"sources": [
{
"db": "NVD",
"id": "CVE-2005-0039"
},
{
"db": "CERT/CC",
"id": "VU#302220"
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"db": "BID",
"id": "13562"
},
{
"db": "PACKETSTORM",
"id": "39223"
},
{
"db": "PACKETSTORM",
"id": "39123"
},
{
"db": "PACKETSTORM",
"id": "42158"
}
],
"trust": 2.88
},
"external_ids": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/external_ids#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"db": "CERT/CC",
"id": "VU#302220",
"trust": 3.5
},
{
"db": "NVD",
"id": "CVE-2005-0039",
"trust": 2.8
},
{
"db": "BID",
"id": "13562",
"trust": 2.7
},
{
"db": "SECUNIA",
"id": "17938",
"trust": 1.7
},
{
"db": "VUPEN",
"id": "ADV-2005-2806",
"trust": 1.6
},
{
"db": "VUPEN",
"id": "ADV-2005-0507",
"trust": 1.6
},
{
"db": "SECTRACK",
"id": "1015320",
"trust": 1.6
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714",
"trust": 0.8
},
{
"db": "BUGTRAQ",
"id": "20050509 NISCC VULNERABILITY ADVISORY IPSEC - 004033",
"trust": 0.6
},
{
"db": "HP",
"id": "SSRT5957",
"trust": 0.6
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937",
"trust": 0.6
},
{
"db": "SECUNIA",
"id": "16401",
"trust": 0.1
},
{
"db": "PACKETSTORM",
"id": "39223",
"trust": 0.1
},
{
"db": "PACKETSTORM",
"id": "39123",
"trust": 0.1
},
{
"db": "PACKETSTORM",
"id": "42158",
"trust": 0.1
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#302220"
},
{
"db": "BID",
"id": "13562"
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"db": "PACKETSTORM",
"id": "39223"
},
{
"db": "PACKETSTORM",
"id": "39123"
},
{
"db": "PACKETSTORM",
"id": "42158"
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"id": "VAR-200505-0908",
"iot": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/iot#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": true,
"sources": [
{
"db": "VARIoT devices database",
"id": null
}
],
"trust": 0.5714286
},
"last_update_date": "2024-11-23T23:13:31.884000Z",
"patch": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/patch#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"title": "HPSBUX02079",
"trust": 0.8,
"url": "http://www2.itrc.hp.com/service/cki/docDisplay.do?docId=c00572922"
},
{
"title": "HPSBUX02079",
"trust": 0.8,
"url": "http://h50221.www5.hp.com/upassist/itrc_japan/assist2/secbltn/HP-UX/HPSBUX02079.html"
},
{
"title": "NV05-018",
"trust": 0.8,
"url": "http://www.nec.co.jp/security-info/secinfo/nv05-018.html"
},
{
"title": "IPsec\u306e\u8106\u5f31\u6027\u306b\u3064\u3044\u3066",
"trust": 0.8,
"url": "http://www.rtpro.yamaha.co.jp/RT/FAQ/IPsec/NISCC-004033.html"
},
{
"title": "[\u5f71\u97ff\uff1a\u6975\u5c0f] IPsec\u901a\u4fe1\u306e\u8a2d\u5b9a\u306b\u5b58\u5728\u3059\u308b\u8106\u5f31\u6027",
"trust": 0.8,
"url": "http://www.seil.jp/seilseries/news/snote/_snote_20050510.html"
},
{
"title": "IPsec\u901a\u4fe1\u306e\u8a2d\u5b9a\u306b\u5b58\u5728\u3059\u308b\u8106\u5f31\u6027\u306e\u554f\u984c\u306b\u3064\u3044\u3066",
"trust": 0.8,
"url": "http://www.furukawa.co.jp/fitelnet/topic/ipsec_attacks.html"
},
{
"title": "IPsec(ESP)\u306e\u8106\u5f31\u6027\u306b\u3064\u3044\u3066",
"trust": 0.8,
"url": "http://www.allied-telesis.co.jp/support/list/faq/vuls/vulsall.html"
},
{
"title": "AX-VU2005-04",
"trust": 0.8,
"url": "http://www.alaxala.com/jp/support/security/ICMP-20051226.html"
},
{
"title": "HCVU000000003",
"trust": 0.8,
"url": "http://www.hitachi-cable.co.jp/infosystem/support/security/HCVU000000003.html"
},
{
"title": "\u300cIPSec\u901a\u4fe1\u306e\u8a2d\u5b9a\u306b\u5b58\u5728\u3059\u308b\u8106\u5f31\u6027\u300d\u5bfe\u7b56\u306b\u3064\u3044\u3066",
"trust": 0.8,
"url": "http://www.hitachi.co.jp/Prod/comp/network/notice/IPsec_ESP.html"
}
],
"sources": [
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
}
]
},
"problemtype_data": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/problemtype_data#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"problemtype": "NVD-CWE-Other",
"trust": 1.0
}
],
"sources": [
{
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"references": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/references#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"trust": 2.7,
"url": "http://www.kb.cert.org/vuls/id/302220"
},
{
"trust": 2.4,
"url": "http://www.securityfocus.com/bid/13562"
},
{
"trust": 1.6,
"url": "http://jvn.jp/niscc/niscc-004033/index.html"
},
{
"trust": 1.6,
"url": "http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html?lang=en"
},
{
"trust": 1.6,
"url": "http://www.securityfocus.com/archive/1/407774"
},
{
"trust": 1.6,
"url": "http://securitytracker.com/id?1015320"
},
{
"trust": 1.6,
"url": "http://secunia.com/advisories/17938"
},
{
"trust": 1.0,
"url": "http://www.vupen.com/english/advisories/2005/0507"
},
{
"trust": 1.0,
"url": "http://www.vupen.com/english/advisories/2005/2806"
},
{
"trust": 1.0,
"url": "http://marc.info/?l=bugtraq\u0026m=111566201610350\u0026w=2"
},
{
"trust": 0.8,
"url": "http://www.niscc.gov.uk/niscc/docs/re-20050509-00385.pdf?lang=en"
},
{
"trust": 0.8,
"url": "http://www.ietf.org/ids.by.wg/ipsec.html"
},
{
"trust": 0.8,
"url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2005-0039"
},
{
"trust": 0.8,
"url": "http://www.cpni.gov.uk/products/vulnerabilitydisclosures/default.aspx?id=va-20050509-00385.xml"
},
{
"trust": 0.8,
"url": "http://nvd.nist.gov/nvd.cfm?cvename=cve-2005-0039"
},
{
"trust": 0.8,
"url": "http://www.cpni.gov.uk/docs/re-20050509-00385.pdf?lang=en"
},
{
"trust": 0.8,
"url": "http://www.cyberpolice.go.jp/important/2005/20050512_115848.html"
},
{
"trust": 0.6,
"url": "http://www.frsirt.com/english/advisories/2005/2806"
},
{
"trust": 0.6,
"url": "http://www.frsirt.com/english/advisories/2005/0507"
},
{
"trust": 0.6,
"url": "http://marc.theaimsgroup.com/?l=bugtraq\u0026m=111566201610350\u0026w=2"
},
{
"trust": 0.4,
"url": "http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html"
},
{
"trust": 0.3,
"url": "http://r.your.hp.com/r/c/r?1.1.hx.dc.w2b6a.cbxvqq...dsyu.1mpe.30mxaf"
},
{
"trust": 0.3,
"url": "http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-10.txt"
},
{
"trust": 0.3,
"url": "http://r.your.hp.com/r/c/r?1.1.hx.dc.w2b6a.c5v00m...de36.1ku8.2din6i"
},
{
"trust": 0.3,
"url": "/archive/1/407774"
},
{
"trust": 0.3,
"url": "/archive/1/399539"
},
{
"trust": 0.2,
"url": "http://secunia.com/secunia_security_advisories/"
},
{
"trust": 0.2,
"url": "http://secunia.com/advisories/16401/"
},
{
"trust": 0.2,
"url": "http://secunia.com/sec_adv_unsubscribe/?email=packet%40packetstormsecurity.org"
},
{
"trust": 0.2,
"url": "http://secunia.com/about_secunia_advisories/"
},
{
"trust": 0.1,
"url": "http://secunia.com/product/2/"
},
{
"trust": 0.1,
"url": "http://www.itrc.hp.com/service/patch/patchdetail.do?patchid=t64kit0026161-v51bb26-es-20050804"
},
{
"trust": 0.1,
"url": "http://secunia.com/secunia_vacancies/"
},
{
"trust": 0.1,
"url": "http://itrc.hp.com/service/cki/docdisplay.do?docid=hpsbtu01217"
},
{
"trust": 0.1,
"url": "http://www.itrc.hp.com/service/patch/patchdetail.do?patchid=t64kit0026133-v51bb25-es-20050801"
},
{
"trust": 0.1,
"url": "http://www.niscc.gov.uk/niscc/publickey2-en.pop."
},
{
"trust": 0.1,
"url": "http://www.niscc.gov.uk/."
},
{
"trust": 0.1,
"url": "https://nvd.nist.gov/vuln/detail/cve-2005-0039"
},
{
"trust": 0.1,
"url": "http://www1.itrc.hp.com/service/cki/docdisplay.do?docid=c00572922"
},
{
"trust": 0.1,
"url": "http://secunia.com/advisories/17938/"
},
{
"trust": 0.1,
"url": "http://secunia.com/product/138/"
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#302220"
},
{
"db": "BID",
"id": "13562"
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"db": "PACKETSTORM",
"id": "39223"
},
{
"db": "PACKETSTORM",
"id": "39123"
},
{
"db": "PACKETSTORM",
"id": "42158"
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"sources": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#",
"data": {
"@container": "@list"
}
},
"data": [
{
"db": "CERT/CC",
"id": "VU#302220"
},
{
"db": "BID",
"id": "13562"
},
{
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"db": "PACKETSTORM",
"id": "39223"
},
{
"db": "PACKETSTORM",
"id": "39123"
},
{
"db": "PACKETSTORM",
"id": "42158"
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"sources_release_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_release_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2005-05-09T00:00:00",
"db": "CERT/CC",
"id": "VU#302220"
},
{
"date": "2005-05-09T00:00:00",
"db": "BID",
"id": "13562"
},
{
"date": "2007-04-01T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"date": "2005-08-12T06:45:33",
"db": "PACKETSTORM",
"id": "39223"
},
{
"date": "2005-08-07T06:26:59",
"db": "PACKETSTORM",
"id": "39123"
},
{
"date": "2005-12-09T15:12:42",
"db": "PACKETSTORM",
"id": "42158"
},
{
"date": "2005-05-10T00:00:00",
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"date": "2005-05-10T04:00:00",
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"sources_update_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_update_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2005-07-06T00:00:00",
"db": "CERT/CC",
"id": "VU#302220"
},
{
"date": "2009-07-12T14:06:00",
"db": "BID",
"id": "13562"
},
{
"date": "2007-04-01T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2005-000714"
},
{
"date": "2005-10-20T00:00:00",
"db": "CNNVD",
"id": "CNNVD-200505-937"
},
{
"date": "2024-11-20T23:54:16.640000",
"db": "NVD",
"id": "CVE-2005-0039"
}
]
},
"threat_type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/threat_type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "remote",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
}
],
"trust": 0.6
},
"title": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/title#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "IPsec configurations may be vulnerable to information disclosure",
"sources": [
{
"db": "CERT/CC",
"id": "VU#302220"
}
],
"trust": 0.8
},
"type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "Design Error",
"sources": [
{
"db": "BID",
"id": "13562"
},
{
"db": "CNNVD",
"id": "CNNVD-200505-937"
}
],
"trust": 0.9
}
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.