CVE-2020-10136: IP-in-IP Packet Processing Vulnerability Could Lead to DDoS, Network Access Bypass and Information Disclosure

IP-in-IP packet processing, a protocol used for tunneling by numerous vendors, contains a vulnerability that may lead to DDoS, information leakage and bypass of network access controls.

Background

On June 2, the CERT Coordination Center (CERT/CC) released vulnerability note VU#636397 detailing an unauthenticated vulnerability in the IP encapsulation within IP (IP-in-IP) protocol. The original disclosure is credited to Yannay Livneh, a cybersecurity researcher on the Enigmatos team.

How IP-in-IP protocols work

The IP-in-IP protocol, outlined in RFC2003, provides a mechanism to encapsulate one IP datagram within another IP datagram for tunneling, which allows for communication between two IP networks that do not have a native routing path. This process includes both an inner and outer IP header. The inner header, which contains the original Source Address of the sender and Destination Address of the recipient, remains unchanged throughout the journey with the exception of a decremented time to live (TTL). The outer IP header identifies the endpoints of the tunnel using the Source Address and the Destination Address. These encapsulated datagrams are decapsulated at an intermediate destination node to reveal the original IP datagram before being sent to the Destination Address highlighted in the inner IP header. The use of IP-in-IP encapsulation can be identified in packets that have an IP protocol header value of 4.

Analysis

CVE-2020-10136 is an IP-in-IP processing vulnerability that could allow an unauthenticated attacker to route traffic through exposed interfaces on vulnerable devices, which may result in a reflected distributed denial of service (DDoS), information leakage and the bypass of network access controls (NACs). The vulnerability exists due to an unexpected Data Processing Error, which may result in vulnerable devices not correctly inspecting and verifying forwarded packets that could have originated from a malicious source or been intended for a malicious destination. Yannay’s original disclosure included two scenarios in which his code could be used to exploit this vulnerability:

Scenario 1: Spoof Mode

In spoof mode, an attacker would send a crafted malicious IP-in-IP packet to VULNERABLE_MACHINE_IP, which would then replay a packet to a VICTIM_IP. As the VULNERABLE_MACHINE_IP is a valid trusted source, the packet would not be blocked by any anti-spoofing countermeasures. A scenario like this allows for packets to be sent en masse, demonstrating how a DDoS attack could be achieved.

Image Source: CERT/CC GitHub Repository

Scenario 2: Bypass Mode

In bypass mode, an attacker would send a crafted malicious IP-in-IP packet to a VULNERABLE_MACHINE_IP, which would decapsulate the packet and forward the inner IP packet to the VICTIM_IP with the source IP address of the DATA_COLLECT_IP. The attacker can use the VULNERABLE_MACHINE_IP as a forwarding point to gather information from the DATA_COLLECT_IP by having the VICTIM_IP send queries for enabled protocols, such as SNMP to DATA_COLLECT_IP.

Image Source: CERT/CC GitHub Repository

Proof of concept

The original proof of concept (PoC) created by Livneh has been added to the CERT/CC GitHub repository.

Solution

At the time this blog was published, CERT/CC has confirmed that the following four vendors are affected by this vulnerability:

• Hewlett Packard Enterprise
• Digi International
• Treck
• Cisco

Cisco released an advisory for CVE-2020-10136 on June 1 for NX-OS Software. A comprehensive list of affected vendors and their impacted product/versions can be found on the CERT/CC advisory with their respective statements. This list will continue to be updated by CERT/CC as the vendors respond. We recommend that the latest patches are applied to affected products as highlighted by the individual vendors’ responses.

If circumstances do not allow for the application of the advised patches, CERT/CC recommends that users disable IP-in-IP on any devices and interfaces where it is not required. If IP-in-IP must be enabled, packets using IP protocol 4 should be filtered. This does not mean filtering for IPv4 packets, but rather packets with an IP protocol header value of 4.

Identifying affected systems

A list of Tenable plugins to identify this vulnerability will appear here as they’re released.

Get more information

• CERT/CC IP-in-IP Advisory (VU#636397)
• Proof of Concept - CERT/CC GitHub Repository
• Cisco NX-OS Software Unexpected IP in IP Packet Processing Vulnerability Advisory
• RFC2003 IP-in-IP

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.