DDOS using CoAP

That CoAP can be used in malicious DDOS attacks is news but at the same time it is not. Already when the CoAP RFC was published it came with a Security Section with that caveat in mind, being UDP a choice made to process message faster and scale better. Today, CoAP is now deployed widely enough to be more than noticeable by malicious attackers as shown in 1 , 2 , 3 and 4.

As CoAP becomes more mainstream, it is likely that there will be more attacks taking advantage of misconfigured endpoints. In fact CoAP has already been "occasionally used as a basis of DDOS attacks, with increasing frequency, reaching 55Gbps on average, and with the largest one clocking at 320Gbps". Apparently the attacks are short-lived, lasting on average "just over 90 seconds" and feature around 100 packets per second.

An attack of 320Gbps is already huge, since as we saw On DDOS Attacks Mirai clocked at 600Gbps. It is thus not unlikely that a 1Tbps attack using CoAP may occur relatively soon. The current peak volume clocked in an attack is of some 1.7Tbps of malicious traffic.

As a danish researcher at RVAsec points out, the CoAP protocol was not yet mainstream back in 2017, but the number of visible CoAP endpoints has increased rapidly from about 6500 to 220000 between november 2017 and may 2018, to more than 738041 in October 2018.

That number has decreased as devices are being patched and today we would find about 436854 running :~$ shodan count port:5683, out of which 305051 are in China. There are of course orders of magnitude more endpoints that are not openly visible on the Internet.

These attacks are based on the two vulnerabilities of UDP-based protocols mentioned in the previous section.

IP Address Spoofing

There are two main types of transports on the Internet, TCP and UDP. TCP is connection oriented, which means that it is bidirectional between sender and receiver. In TCP there is a handshake -the famous three-way handshake- so that both sender and receiver confirm that they are able to communicate and that they are in sync. In UDP however there is no handshake and know explicit acknowledgment of the communication, information flows in one direction.

UDP then is vulnerable to IP spoofing, which consists on forging the header of the IP packet so that the IP address of the sender is different from that of the machine who sent it, being instead that of the victim machine. The receiver of the packet -another victim- will send the response to the spoofed address. In CoAP every server is expected to reply to some GET requests to specific resources, making it easy to guess which is the payload that the request has to contain.

Due to the lack of handshake in UDP, RFC 7252, Section 11.4, warns that there are some message types that can be spoofed on unsecured CoAP networks. They can range from simple, like a RST or an ACKin response to a CON message which would cause an error in the communication, to disruptive when spoofing a multicast request (cause CoAP does support multicast) for a target node. This may result in a DOS to a victim or in the congestion/collapse of the network.

Moreover under this attack, a constrained node with limited total energy available may exhaust that energy much more quickly than planned (battery depletion attack).

Amplification

As it is explained on RFC, 7252 Section 11.3, CoAP responses might be - and usually are - larger than their request. Think for example GET /.well-known/core that returns links to all resources, or a query to a complex sensor that returns a large JSON payload. I can imagine that if the Observe option is 0 then notifications to the victim would be sent automatically, increasing the length of the attack. Also if the crafted request asks for text-based ct the response would be larger than binary ones.

The RFC then states: "This is particularly a problem in nodes that enable NoSec access, are accessible from an attacker, and can access potential victims (e.g., on the general Internet), as the UDP protocol provides no way to verify the source address given in the request packet".

CoAP Amplification Factor

The table below is inspired from Dennis Radd presentation contains some common UDP protocols used on DDOS, the total number of endpoints available on Shodan (available at April 2019) out of which an unknown (to me) percentage will be open for an attack. The request size and amplification factor is taken from the presentation and from CISA.

The amplification factor means represents the effort for an attacker, for example in CoAP a request of 21 bytes without the UDP header of size can yield a response of 21*16= 336 bytes. The target for the attacker is to use the minimum effort for the maximum attack factor. An attacker who has access to a 1 Mbps link could on average reach 16 Mbps and up to 97 Mbps per endpoint.

Exploring Vulnerable Endpoints

Shodan and nmap are the preferred tools to find out about existing vulnerable CoAP endpoints, however the usability of the first one is limited without a paid account.

Some of Shodan's most basic commands are:

There is also a web interface that allows for searching, for example CoAP endpoints. Looking a bit more on a couple of aleatory searched hosts shows two CoAP endpoints that potentially are discoverable over the Internet and vulnerable to UDP-based attacks. We can search them by issuing :~$ shodan host 120.212.XXX.XXX

As we saw in the section Finding your CoAP devices CoAP has an in-built discovery mechanism, thus sending a GET request message to the /.well-known/core resource might show information. Indeed, for example:

• The node in Novgorod shows the available resources, examples of the expected payloads and the interaction methods.

• Similarly the node in Nanchang exposes network information, interfaces and all resources available, some even related to control information and the expected content-formats or passwords.

If we were interested which type of devices are these , it is easy to perform an nmap scan to find out that several other TCP ports are also open, indicating that at least a portion of the devices are gateways with a dozen other services.

Solutions

As we other DDOS attacks, some solutions are already at hand, some outlined in RFC 4732, others on RFC 7252 and on draft-irtf-t2trg-iot-seccons. The guidelines to be followed when implementing and deploying CoAP networks that help prevent and palliate DOS attacks would be:

• Avoiding the use of NoSec mode, using instead any of the other secure modes.
• Avoid exposing CoAP endpoints to the wider Internet if they don't need to.
• Using a randomized token value.
• When using CON messages we can detect unexpected ACK RST from the deceived endpoint. However it is costly and not always feasible.
• Verify every now and then that observations are still valid by sending a CON from the observed CoAP resource.
• Limiting the response rate can also palliate the problem.
• Routers and middleboxes have high bandwidth, which is a scarce resource in the case of constrained networks. That will be a mitigating factor, making CoAP nodes less attractive for this attack.
• Large amplification factors should not be provided if the request is not authenticated.
• CoAP servers should not accept multicast requests that can not be authenticated in some way
• Ensure all default passwords are changed to strong passwords.
• Update IoT devices with security patches as soon as patches become available.
• Network operators could prevent the leakage of packets with forged source addresses by following the guidelines of RFC 2827.

Nevertheless, as it is pointed out in Another 10 years:

The Internet of Things will continue to be a market place where the compromises between price and quality will continue to push us on to the side of cheap rather than secure.

Bonus: Richard Thieme - Staring into the Abyss