Amplification Attacks Using the Constrained Application Protocol (CoAP)

Amplification Attacks using CoAP In a Denial-of-Service (DoS) attack, an attacker sends a large number of requests or responses to a target endpoint. The denial-of-service might be caused by the target endpoint receiving a large amount of data, sending a large amount of data, doing heavy processing, or using too much memory, etc. In a Distributed Denial-of-Service (DDoS) attack, the request or responses come from a large number of sources. In an amplification attack, the amplification factor is the ratio between the total size of the data sent to the target and the total size of the data received from the attacker. Note that in the presence of intermediaries, the size of the data received by the target might be different than the size of the data sent to the target and the size of the data received from the attacker might be different than the size of the data sent from the attacker. In the attacks described in this section, the attacker sends one or more requests, and the target receives one or more responses. An amplification attack alone can be a denial-of-service attack on a CoAP server by making it send a large amount of data. But often amplification attacks are combined with the attacker spoofing the source IP address of the targeted victim. By requesting as much information as possible from several servers an attacker can multiply the amount of traffic and create a distributed denial-of-service attack on the target. When transported over UDP, the CoAP NoSec mode is susceptible to source IP address spoofing. The amplification factor and the bandwidth depend on the layer in the protocol stack that is used for the calculation. The amplification factor and bandwidth can e.g., be calculated using whole IP packets, UPD payloads, or CoAP payloads. The bandwidth decreases and the amplification factor typically increases higher up in the protocol stack. The bandwidth should be calculated using the layer that is considered to be under attack. The following sections give examples of different theoretical amplification attacks using CoAP.

Simple Amplification Attacks An amplification attack using a single response is illustrated in . If the response is c times larger than the request, the amplification factor is c.

Amplification attack using a single response | Code: 0.01 (GET) | | GET | Uri-Path: random quote | | | |<------------+ Code: 2.05 (Content) | | 2.05 | Payload: "just because you own half the county | | | doesn't mean that you have the power | | | to run the rest of us. For twenty- | | | three years, I've been dying to tell | | | you what I thought of you! And now... | | | well, being a Christian woman, I can't | | | say it!" ]]> An attacker can increase the bandwidth by sending several GET requests. An attacker can also increase or control the amplification factor by creating or updating resources. By creating new resources, an attacker can increase the size of /.well-known/core. An amplification attack where the attacker influences the amplification factor is illustrated in .

Amplification Attacks using Observe Amplification factors can be significantly worse when combined with observe and group requests . As a single request can result in multiple responses from multiple servers, the amplification factors can be very large. An amplification attack using observe is illustrated in . If each notification response is c times larger than the registration request and each request results in n notifications, the amplification factor is c n. By registering the same client several times using different Tokens or port numbers, the bandwidth can be increased. By updating the observed resource, the attacker may trigger notifications and increase the size of the notifications. By using conditional attributes an attacker may increase the frequency of notifications and therefore the amplification factor. The maximum period attribute pmax indicates the maximum time, in seconds, between two consecutive notifications (whether or not the resource state has changed). If it is predictable when notifications are sent as confirmable and which Message ID are used the acknowledgements may be spoofed.

Amplification Attacks using Group Requests An amplification attack using a group request is illustrated in . The group request is sent over multicast or broadcast and in this case a single request results in m responses from m different servers. If each response is c times larger than the request, the amplification factor is c m. Note that the servers usually do not know the variable m.

Amplification attack using multicast | | Code: 0.01 (GET) | | '----->| Token: 0x69 | | GET | | Uri-Path: | | | | |<------------+ | Code: 2.05 (Content) | | 2.05 | | Token: 0x69 | | | | Payload: { 1721 : { ... | | | | |<---------------+ Code: 2.05 (Content) | | 2.05 | | Token: 0x69 | | | | Payload: { 1721 : { ... | | | | .... .... ]]> An amplification attack using a multicast request and observe is illustrated in . In this case a single request results in n responses each from m different servers giving a total of n m responses. If each response is c times larger than the request, the amplification factor is c n m.

MITM Amplification Attacks TLS and DTLS without Connection ID validate the IP address and port of the other peer, binds them to the connection, and do not allow them to change. DTLS with Connection ID allows the IP address and port to change at any time. As the source address is not protected, an MITM attacker can change the address. Note that an MITM attacker is a more capable attacker then an attacker just spoofing the source address. It can be discussed if and how much such an attack is reasonable for DDoS, but DTLS 1.3 states that "This attack is of concern when there is a large asymmetry of request/response message sizes." . DTLS 1.2 with Connection ID requires that "the receiver MUST NOT replace the address" unless "there is a strategy for ensuring that the new peer address is able to receive and process DTLS records" but does not give more details than that. It seems like the receiver can start using the new peer address and test that it is able to receive and process DTLS records at some later point. DTLS 1.3 with Connection ID requires that "implementations MUST NOT update the address" unless "they first perform some reachability test" but does not give more details than that. OSCORE does not discuss address updates, but it can be assumed that most servers send responses to the address it received the request from without any reachability test. A difference between (D)TLS and OSCORE is that in DTLS the updated address is used for all future records, while in OSCORE a new address is only used for responses to a specific request. An MITM amplification attack updating the client's source address in an observe registration is illustrated in . This attack is possible in OSCORE and DTLS with Connection ID. The server will send notifications to the Victim until it at some unspecified point requires an acknowledgement . In DTLS 1.2 the reachability test might be done at a later point. In OSCORE a reachability test is likely not done.

MITM Amplification attack by updating the client's source address in a observe registration request S----->| Code: 0.01 (GET) | GET | | | Observe: 0 | | | | Uri-Path: humidity | | | | |<------------D <----+ Reachability test (DTLS) +-----------> S----->| | | | | .... .... .... | | | | | |<------------+ Code: 2.05 (Content) | | | 2.05 | Observe: 263712 | | | | Payload: "68 %" | | | | | |<------------+ Code: 2.05 (Content) | | | 2.05 | Observe: 263713 | | | | Payload: "69 %" .... .... .... ]]> Where 'S' means the MITM attacker is changing the source address of the message and 'D' means the MITM attacker is changing the destination address of the message. An MITM amplification attack updating the server's source address is illustrated in . This attack is possible in DTLS with Connection ID. In DTLS 1.2 the reachability test might be done at a later point.

MITM Amplification attack by updating the server's source address in a response | Code: 0.01 (POST) | POST | | | Uri-Path: video | | | | |<-----S <-----------| Code: 2.01 (Created) | | | 2.01 | | | | | +----> D------------>| Reachability test (DTLS) |<-----S <-----------+ | | | | .... .... .... | | | | +------------>| | Code: 0.01 (POST) | POST | | | Uri-Path: video | | | | Payload: survailance_1139.hevc | | | | +------------>| | Code: 0.01 (POST) | POST | | | Uri-Path: video | | | | Payload: survailance_1140.hevc .... .... .... ]]>