Executive Summary
Summary | |
---|---|
Title | IP-in-IP protocol routes arbitrary traffic by default |
Informations | |||
---|---|---|---|
Name | VU#636397 | First vendor Publication | 2020-06-02 |
Vendor | VU-CERT | Last vendor Modification | 2020-09-30 |
Severity (Vendor) | N/A | Revision | M |
Security-Database Scoring CVSS v3
Cvss vector : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L | |||
---|---|---|---|
Overall CVSS Score | 5.3 | ||
Base Score | 5.3 | Environmental Score | 5.3 |
impact SubScore | 1.4 | Temporal Score | 5.3 |
Exploitabality Sub Score | 3.9 | ||
Attack Vector | Network | Attack Complexity | Low |
Privileges Required | None | User Interaction | None |
Scope | Unchanged | Confidentiality Impact | None |
Integrity Impact | None | Availability Impact | Low |
Calculate full CVSS 3.0 Vectors scores |
Security-Database Scoring CVSS v2
Cvss vector : (AV:N/AC:L/Au:N/C:N/I:N/A:P) | |||
---|---|---|---|
Cvss Base Score | 5 | Attack Range | Network |
Cvss Impact Score | 2.9 | Attack Complexity | Low |
Cvss Expoit Score | 10 | Authentication | None Required |
Calculate full CVSS 2.0 Vectors scores |
Detail
OverviewIP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device. DescriptionIP-in-IP encapsulation is a tunneling protocol specified in RFC 2003 that allows for IP packets to be encapsulated inside another IP packets. This is very similar to IPSEC VPNs in tunnel mode, except in the case of IP-in-IP, the traffic is unencrypted. As specified, the protocol unwraps the inner IP packet and forwards this packet through IP routing tables, potentially providing unexpected access to network paths available to the vulnerable device. An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses. This unexpected Data Processing Error (CWE-19) by a vulnerable device can be abused to perform reflective DDoS and in certain scenarios used to bypass network access control lists. Because the forwarded network packet may not be inspected or verified by vulnerable devices, there are possibly other unexpected behaviors that can be abused by an attacker on the target device or the target device's network environment. ImpactAn unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls. SolutionApply updatesThe CERT/CC recommends that you apply the latest patch provided by the affected vendor that addresses this issue. Review the vendor information below or contact your vendor or supplier for specific mitigation advice. If a device has the ability to disable IP-in-IP in its configuration, it is recommended that you disable IP-in-IP in all interfaces that do not require this feature. Device manufacturers are urged to disable IP-in-IP in their default configuration and to require their customers to explicitly configure IP-in-IP as and when needed. Disable IP-in-IPUsers can block IP-in-IP packets by filtering IP protocol number 4. Note this filtering is for the IPv4 Protocol (or IPv6 Next Header) field value of 4 and not IP protocol version 4 (IPv4). Proof of Concept (PoC)A proof-of-concept originally written by Yannay Livneh is available in the CERT/CC PoC respository. Detection Signature (IDS)This Snort IDS rule looks for any IP-in-IP traffic, whether intentional or not seen at upstream network path of a vulnerable device. This Snort or Suricata rule can be modified to apply filters that ignore sources and destinations that are allowed by policy to route IP-in-IP traffic.
AcknowledgementsThanks to Yannay Livneh for reporting this issue to us. This document was written by Vijay Sarvepalli. |
Original Source
Url : https://kb.cert.org/vuls/id/636397 |
CWE : Common Weakness Enumeration
% | Id | Name |
---|---|---|
100 % | CWE-290 | Authentication Bypass by Spoofing |
CPE : Common Platform Enumeration
Alert History
Date | Informations |
---|---|
2020-09-30 21:17:43 |
|
2020-06-24 17:17:28 |
|
2020-06-17 17:17:27 |
|
2020-06-17 00:17:29 |
|
2020-06-12 21:17:37 |
|
2020-06-12 17:17:28 |
|
2020-06-05 17:17:25 |
|
2020-06-04 17:17:26 |
|
2020-06-03 05:28:10 |
|
2020-06-03 05:17:26 |
|
2020-06-02 13:27:58 |
|
2020-06-02 13:17:25 |
|