Alert: Digi Devices Affected by Ripple20 Can Be Used in Reflection Attacks

Alert: Digi Devices Affected by Ripple20 Can Be Used in Reflection Attacks

julho 28, 2020 | Adeline Zhang

Executive Summary

In recent years, more and more protocols that may cause UDP reflection attacks have come into our sight, such as CoAP[1], Ubiquiti[2], WS-Discovery[3], OpenVPN[4], and a certain DVR protocol[5]. These attack patterns are different from DNS, SSDP, NTP, Memcached, and other reflection attacks that are well familiar to us, posing certain challenges to distributed denial-of-service (DDoS) attack protection.

In June 2020, JSOF, an Israel-based cybersecurity company, revealed that 0-day vulnerabilities in the Treck TCP/IP protocol stack might affect hundreds of millions of devices globally. After analyzing the published whitepapers, we find that the devices produced by Digi, one of the affected vendors, use the Advanced Digi Discovery Protocol (ADDP) for device discovery. ADDP uses 224.0.5.128 as a multicast address and 2362 as its port. But during implementation, ADDP also supports unicast. Besides, it is possible to spoof source IP addresses of UDP packets. Therefore, Digi devices are at risk of being used for reflection attacks.

In order to understand the potential scale of ADDP reflection attacks, we surveyed the ADDP service exposed on the Internet based on information from NSFOCUS Threat Intelligence (NTI).

More than 5000 IP addresses worldwide deliver the ADDP service and are exposed to the risk of being exploited for DDoS attacks. These IP addresses involve multiple Digi products, such as Connect WAN 3G, ConnectPort WAN VPN, ConnectPort X4, and Connect ME4 9210.

The USA, Italy, Poland, Chile, and Spain have the most exposed ADDP-enabled devices, with the USA ranked No. 1, home to 43% of such devices.

The length of an ADDP detection packet is 14 bytes. Most response packets have a length of more than 100 bytes, with an average length of 126 bytes. Therefore, the average bandwidth amplification factor is 9.

As a vulnerable protocol suitable for reflection attacks, ADDP has not drawn attackers’ attention. It has two major potential risks: One is that it can be used for DDoS attacks, and the other is that it can be used to discover Digi devices, which may, in turn, be used for Ripple20-related attacks.

ADDP Overview

Ripple20[7] is a series of 0-day vulnerabilities discovered by the JSOF[8] research lab in the widely-applied low-level TCP/IP software database developed by Treck Inc. In June 2020, JSOF published a technical whitepaper[9] on CVE-2020-11896 and CVE-2020-11898 included in Ripple20. The CVE-2020-11896 whitepaper contains a proof of concept (PoC) on a Digi Connect ME 9210 device. After that, we immediately analyzed Digi Connect ME 9210 and found that apart from remote code execution (RCE), the ADDP protocol used in Digi Ethernet modules is also prone to reflection attacks.

Digi International Inc.[10] (Digi for short) is an Internet of Things (IoT) solution provider that was founded in 1985. Digi boasts a variety of products ranging from radio frequency modems to gateways. Digi Connect ME is a series of Ethernet modules designed by Digi and preloaded with Digi plug-and-play firmware. In order to fulfil the plug-and-play function, Digi designed the Advanced Digi Discovery Protocol (ADDP) which is similar to the Simple Service Discovery Protocol (SSDP). The UDP-based ADDP is used to discover Digi ConnectPort X products on local area networks (LANs). Such a discovery protocol usually supports multicast and unicast simultaneously. In addition, it is possible to spoof source IP addresses of UDP packets. Therefore, such service exposed to the Internet is prone to be used for reflection attacks.

ADDP uses 224.0.5.128 as a multicast address and 2362 as its port. In general, an ADDP frame[11] can be divided into four parts: protocol header, data packet type, total payload length, and payload. A typical ADDP device discovery packet is as follows:

Figure 1.1 Example of an ADDP discovery packet

The protocol header indicates the protocol type. ADDP uses fixed characters in protocol headers. There are three kinds of protocol header in the UDP scanning plug-in[12] of ZMap: DIGI (“0x44 0x49 0x47 0x49”), DVKT, and DGDP.

The data packet type indicates the function of the data packet and occupies 2 bytes:

  • 0x0001: discovery request
  • 0x0002: discovery response
  • 0x0003: static network configuration request
  • 0x0004: static network configuration response
  • 0x0005: reboot request
  • 0x0006: reboot response
  • 0x0007: DHCP network configuration request
  • 0x0008: DHCP network configuration response

The total payload length occupies 2 bytes.

A payload is the actual intended message of data frames. Usually, an ADDP device discovery packet has a payload length of 6 bytes and fixed contents “0xFF 0xFF 0xFF 0xFF 0xFF 0xFF”, as shown in Figure 1.1.

Different from a device discovery packet, the response of such a packet bears a payload format of field type + payload length + payload content. Possible fields[13] are as follows:

  • 0x01: 6 byte MAC address
  • 0x02: 4 byte IP address
  • 0x03: 4 byte netmask
  • 0x04: string network name
  • 0x05: {UNSEEN} domain
  • 0x06: {UNSEEN} hardware type
  • 0x07: 1 byte hardware revision
  • 0x08: string firmware
  • 0x09: string result message
  • 0x0a: 1 byte result flag – see “Result Flags”
  • 0x0b: 4 byte IP gateway
  • 0x0c: 2 byte Configuration error code – see “Configuration Errors”
  • 0x0d: string device name
  • 0x0e: 4 byte real port number
  • 0x0f: 4 byte DNS IP
  • 0x10: 1 byte DHCP enabled Boolean flag
  • 0x11: 1 byte error code
  • 0x12: 1 byte serial port count
  • 0x13: 4 byte encrypted real port number
  • 0x1a: device ID

An example of an ADDP response packet is shown as follows. For the meaning of each field, see the preceding descriptions. We anonymized the fields regarding IP and MAC addresses.

DIGI\x00\x02\x00\x75\x01\x06\x00\x00\x00\x00\x00\x00\x02\x04\x00\x00\x00\x00\x03\x04\xff\xff\xfc\x00\x0b\x04\x00\x00\x00\x00\x04\x13Stylitis10-037E0222\x0D\x0fDigi Connect ME\x10\x01\x00\x07\x01\x00\x08\x1eVersion 82000856_F6 07/21/2006\x0e\x04\x00\x00\x03\x03\x13\x04\x00\x00\x04\x03\x12\x01\x01

Analysis of ADDP Exposure

In order to understand the potential scale of ADDP reflection attacks, we surveyed the ADDP service exposed on the Internet based on information sourced from NTI.

Unless otherwise indicated, all data provided in this chapter was obtained from a single-round global survey conducted in June 2020.

More than 5000 IP addresses worldwide use the ADDP service and are at risk of being exploited for DDoS attacks.

For fear of omission, we surveyed three types of detection packets in ZMap and thus obtained information about global exposure of the ADDP service as shown in Figure 2.1. When the protocol header is “DGDP”, no active device can be detected.

Global exposure of the ADDP service

Protocol Header of a Device Discovery PacketZMap Plug-In NameQuantity of Exposed Services
DIGIdigi1_2362.pkt4868
DVKTdigi2_2362.pkt896
DGDPdigi3_2362.pkt0

We analyzed the product model field in the banner of the ADDP service as shown in Figure 2.1. Those who are interested in knowing the mapping between model fields and specific models can visit the official website for more information. We will not go further here.

Figure 2.1 Distribution of exposed ADDP-enabled device models

The USA, Italy, Poland, Chile, and Spain have the most exposed ADDP-enabled devices, with the USA ranked No. 1, home to 43% of such devices. In contrast, China has only 39such devices exposed on the Internet.

Figure 2.2 Distribution of exposed ADDP-enabled devices by country

We analyzed the length of response packets and found that most response packets had a length of more than 100 bytes, with an average length of 126 bytes. Thus, the average bandwidth amplification factor (BAF)[6] stood at 9.

Sum-up

This article starts with an introduction to ADDP and then proceeds with an analysis of the exposure of ADDP on the Internet. As a vulnerable protocol suitable for reflection attacks, ADDP has not drawn attackers’ attention. It has two major potential risks: One is that it can be used for DDoS attacks, and the other is that it can be used to discover Digi devices, which may, in turn, be used for Ripple20-related attacks.

Protection recommendations:                         

Security vendors are advised to:

  • Add the ADDP scanning capability in scanning products to promptly discover security hazards in customers’ networks.
  • Add the ADDP traffic detection capability in protection products to promptly discover security threats in customers’ networks or add to these products threat intelligence concerning IP addresses that use the ADDP service to block connections from these IP addresses.

Device developers should have their devices respond to only ADDP discovery packets from multicast IP addresses and ignore those from unicast IP addresses. This will make it extremely difficult to exploit the ADDP service for launching reflection attacks.

Telecom carriers should follow the BCP 38 Network Ingress Filtering standard.

Watchdogs are advised to:

  • Monitor ADDP-related threats in networks and make them known to the public once discovering any.
  • Promote security assessment of the ADDP functionality in devices and forbid devices not up to the standard to be sold on the market.

Device users are advised to:

  • Disable the ADDP discovery function if that is unnecessary.
  • Deploy ADDP-enabled devices on LANs to maximize the difficulty of exploiting these devices.
  • If ADDP-enabled devices have to be deployed on the Internet, deploy routers (NAT functionality required) or protective security devices (such as firewalls) before ADDP-enabled devices to control external access to these devices.

Customers with the need of DDoS protection should purchase anti-DDoS products from security vendors that are capable of defending against ADDP reflection attacks. If existing products support customization of application-layer signatures, it is advisable to add signature-based rules to block such attacks.

References:

  • CoAP Attacks In The Wild, https://www.netscout.com/blog/asert/coap-attacks-wild
  • https://www.zdnet.com/article/over-485000-ubiquiti-devices-vulnerable-to-new-attack/
  • [3] ONVIF-based IoT devices used to launch DDoS reflection attacks, https://anquan.baidu.com/article/623
  • for amplified UDP reflection DDoS attacks, https://www.freebuf.com/vuls/215171.html
  • New Type of DVR UDP Reflection Attack Techniques Discovered in the Live Network, https://mp.weixin.qq.com/s/mCF3HiDDK1QdjvgOBGlaDA
  • Hell: Revisiting Network Protocols for DDoS Abuse, https://www.ndss-symposium.org/ndss2014/programme/amplification-hell-revisiting-network-protocols-ddos-abuse/
  • https://www.jsof-tech.com/ripple20/
  • https://www.jsof-tech.com/wp-content/uploads/2020/06/JSOF_Ripple20_Technical_Whitepaper_June20.pdf
  • https://www.digi.com/about-digi
  • https://github.com/zdavkeos/addp/blob/master/addp.py
  • https://github.com/zmap/zmap/blob/master/examples/udp-probes/digi1_2362.pkt
  • Advanced Digi Discovery Protocol Explained, http://qbeukes.blogspot.com/2009/11/advanced-digi-discovery-protocol_21.html