UDP protocol design makes it easy to hide the real origin of requests, making it the perfect candidate for DDoS amplification and leaving prevention as the only protection against these threats
Denial of Service (DoS) attacks are some of the oldest and most common cybersecurity problems. Rather than try to steal sensitive information, DoS attacks simply seek to destructively disrupted the targeted service. Over the last year we at SRLabs we have been monitoring internet traffic via honeypots and identified some recent trends and evolutions in the DoS field.
Currently, reflected Distributed DoS (Figure 1) attacks are the most common way to attempt to send large amounts of data to the target. This type of attack is UDP-based and consists of using an intermediate host by changing the source IP in the initial requests generated by the attacker to direct the server responses to the actual target (IP spoofing). That way, the attacker does not send requests directly to a target, but to an initial server that then directs its response to the actual target. Instead of directly generating the initial requests themselves, attackers usually leverage networks of previously compromised hosts that they control (botnets) to generate a high quantity of initial requests.
Hand in hand with reflected DDoS go amplification attempts. These are a variation of reflected DDoS attacks in that the intermediate host forms a reply that is bigger than the request made by the attacker. That is, the response packet is larger in size than the request packet.
To illustrate this technique, we can use one of the most requested ports in our honeypot and what hackers have been trying to accomplish by leveraging it. Port 19, usually related to the Chargen service, received more than 40 million requests, and was found open in 78,000 devices by Shodan.
Chargen is a legacy testing service that, in a traditional set up, accepts UDP connections, takes as little input as a character from the client request and sends a response with a list of printable characters of variable length, as shown in Figure 2. By spoofing the IP of the request, attackers can leverage this functionality and achieve an amplification of their requests targeting a third-party host.
For an amplification attempt to be successful the response must be significantly larger than the initial request. To achieve that, hackers keep searching for new services that present this behavior. This post contains an analysis with real data of some of these techniques and how we managed to identify attempts of exploiting them in our honeypot machines.
The simplest way to identify DDoS amplification attempts in our honeypots is to pay attention to the amount of traffic received on particular ports. In most cases, attackers send massive amounts of data in short time spans, which makes identifying them easy. This is volume-based DDoS identification.
By paying attention to this pattern, we managed to identify ports and services that were clearly being leveraged for targeting other systems with DoS attacks. Figure 3 shows the ten most requested UDP ports, where the ports on the highest positions were found to have traffic related to DDoS amplification attempts.
To give an idea of how massive these numbers are, after a year of registering data, the accumulated total requests registered on the top three UDP ports is higher than the total of TCP packets registered by all ports combined.
As described above, Chargen flood simplicity makes it a good example for illustrating how DDoS amplification works, but it is not particularly interesting beyond that. Another of our top three most requested ports, 1900, presents a more interesting and up-to-date means for the same purpose.
Following the expansion of Internet of Things [IoT] devices, the DDoS landscape has shifted accordingly towards exploiting these connected devices for generating massive amounts of traffic. According to our data, hackers are leveraging protocols commonly used by these devices – Simple Service Discovery Protocol (SSDP) in our example – to improve their DDoS capabilities.
Figure 4 shows how, in a typical setup, a device connected to a local network is set to respond to SSDP requests with different details about its specifications. This functionality is meant to make devices discoverable in the network and to allow others to successfully communicate with them.
In this traffic capture we can see how a request with a size of 68 MB causes the server to respond with a description XML making the response packet weight 300 MB. For an attacker this means that instead of having to generate additional requests for achieving a large amount of traffic, they can simply forward small requests to an exposed SSDP service with a spoofed IP and let it respond to the final target with a larger packet.
In this case, the ratio of the amplification is roughly 4.4:1, which means the response is that many times bigger than the request. But this is only an example, the response and behavior of different servers can vary widely yielding much larger packets.
In Figure 5 we find an example of one of such servers that not only amplifies the requests but also is set up to send several response packages following a single request. In this case the server replies ten times to a single request, raising the amplification ratio to around 40:1.
SSDP is only one of the many examples of IoT devices exposing ports that can be leverage for Denial-of-Service amplification. A quick search on Shodan shows more than 300,000 devices exposing port 1900, while many others might use other ports with a variable amplification ratio.
The case of SSDP is particularly interesting as some servers will send several packets containing responses to the same request. That means the amplification can be even larger, as shown in TBD4. In comparison with declination of Chargen IoT-related protocols with this behavior are appearing in rising numbers.
Our research also uncovered newer, and as yet less widely applied, amplification techniques. These less common attacks usually go unnoticed by volume-based identification and require other means to be detected. Volatility-based analysis allows for identifying ports presenting unusual changes in the number of requests even if the volume is much smaller than for other ports.
In this line, we identified port 3478 as being recently used for amplification attempts, as shown in Figure 6. This port barely received any traffic throughout 2020 and the beginning of 2021, but in the past few months it registered a massive raise of requests, recording 572 times more quests in March than it did in February.
Behind this port, we usually find the Session Traversal Utilities for NAT (STUN) protocol that works as an enabler for other protocols, such as the Session Initiation Protocol (SIP), to discover the presence of Network Address Translators (NAT) and traverse them by gathering the IP address and port that they were assigned.
To do so, the client in the private network connects to a STUN server that provides it with the public IP address and port from which the connection was originated. Figure 7 shows a trace of how a client communicates with a server by sending a small blob of data and how the server replies with the XORed IP address and port. In this case, as in many others, the response also includes additional data describing the server and legacy uses, which increases the amplification factor.
According to our data, the number of requests that were attempting to leverage the STUN service for amplification is much smaller than for other services. Nonetheless, this example illustrates how, as we protect well known services from being used for DDoS attacks, hackers keep on finding new ways of achieving their goals.
As we have seen, well-known techniques (such as Chargen floods) as well as new ones (such as STUN-based amplification) are being used by malicious actors worldwide to orchestrate amplified DDoS attacks. In our research, we have found many examples of this behavior and what impact different services can have.
Figure 7 shows a quick glance of the amplification ratio of different services. This indicator is used to illustrate how different services can have a very different impact in the traffic throughput and shown in comparison with previous research.
Encouragingly the ratios are decreasing over time. More systems are being properly protected, most notably in the case of Simple Network Management Protocol (SNMP). Although the average presented in Figure 8 shows how SNMP amplification ratio has decreased to 6.57:1 average ratio, much variance remains. Our research found several servers that returned an amplification ratio over 18:1. This shows that while many servers are being correctly configured and protected, more work needs to be done.
These are only some examples of amplification we have observed in the wild, but they are far from being the only ones. In large scale attacks, hackers usually find sources of amplification in a large variety of UDP services, often leveraging several different types at the same type to generate massive amounts of traffic.
The goal of DDoS attacks is always to disrupt a service, knocking it offline, usually causing financial loss and negative public attention for the targeted organization. In this blogpost, we focused on DDoS attacks in which there are two victims: the primary target itself and the secondary target whose assets are leveraged to generate the bandwidth to carry out the attack. This means that those intermediate nodes of the secondary target will also suffer high expenses in bandwidth usage, degradation of their network equipment and even outages of their own services.
It would be in the best interest of an organization to avoid exposing services that could be leveraged for these DDoS activities even when they are not the target of the attack. To do so, some common best practices include:
