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-06-24
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

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.

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

TypeDescriptionCount
Application 1
Os 256

Alert History

If you want to see full details history, please login or register.
0
1
2
3
4
5
6
7
8
9
10
Date Informations
2020-06-24 17:17:28
  • Multiple Updates
2020-06-17 17:17:27
  • Multiple Updates
2020-06-17 00:17:29
  • Multiple Updates
2020-06-12 21:17:37
  • Multiple Updates
2020-06-12 17:17:28
  • Multiple Updates
2020-06-05 17:17:25
  • Multiple Updates
2020-06-04 17:17:26
  • Multiple Updates
2020-06-03 05:28:10
  • Multiple Updates
2020-06-03 05:17:26
  • Multiple Updates
2020-06-02 13:27:58
  • Multiple Updates
2020-06-02 13:17:25
  • First insertion