This post is the second in a three-part series surveying recent DDoS attack trends, and detection and mitigation techniques. Catch up on part 1 here.
SSDP
SSDP attacks have been around for a long while but until recently, SSDP reflection type attacks usually originated from UDP source port 1900, making it easy to mitigate these kinds of attacks.
In 2018, there was a large upswing in attacks using SSDP reflection, where the UDP source port wasn’t 1900 but a random value. To make a long story short, this is due to a bug in a popular Linux library called libupnp, which is included in most customer premises equipment (CPE) used to connect consumers to the Internet. These kinds of attacks are referred to as ‘SSDP diffraction’ to distinguish them from normal SSDP attacks.
Based on analysis done by Arbor Networks, the majority of CPE devices (55%) that respond to SSDP, exhibit this behaviour.
Figure 1 — SSDP clients vulnerable to use in an SSDP diffraction attack.
In addition, around 1.65% of the CPE devices that can be used as SSDP reflectors, have a vulnerability that allows any remote attacker to create their own NAT rules, effectively punching ‘holes’ through the CPE device to allow access from the Internet to internal devices.
More details on the above mentioned vulnerabilities can be found in this blog post by Arbor Networks.
Detecting SSDP diffraction attacks
As the SSDP reflector randomizes its source port, SSDP diffraction attacks will consist of UDP packets with random source ports. In addition, the packets might potentially be fragmented.
To detect these kinds of attacks, flow-based network telemetry (for example, Netflow) will easily detect the flood of UDP packets and fragments.
Mitigating SSDP diffraction attacks
As the source ports are random, it is not possible to use the standard SSDP source port (1900) as a component for mitigation. Instead the attack can be mitigated by:
- Blocking the source IPs of reflectors using S/RTBH or Flowspec.
- Use pattern matching, looking for the SSDP header ‘UPnP/1\.0’ in the payload.
- Rate limit non-initial IP fragments as explained earlier.
- Diverting the attack traffic to IDMSes for mitigation.
Memcached
Memcached is an in-memory database caching system that is typically deployed in IDC (Internet Data Centre), ‘cloud’, and Infrastructure-as-a-Service (IaaS) networks to improve the performance of database-driven websites and other Internet-facing services.
Unfortunately, the default implementation has no authentication features and is often deployed as listening on all interfaces on port 11211 (both UDP and TCP).
In March 2018, memcached was used as an attack vector to launch the largest DDoS attack to date, a 1.7 Tbps DDoS attack. This attack was soon followed by a 1.3 Tbps attack and numerous smaller attacks.
In addition, the memcached attack was rapidly weaponized and attack toolkits appeared on GitHub within five days of the initial attack. The booter/stresser community also made this attack available on their services within two weeks.
Unsecured memcached services will respond to any queries or commands without any form of authentication or authorization. For example, when receiving the ‘stats’ command, the memcached service will respond with statistics about the service itself. As this reply is rather large, it will result in an amplification factor of 1:19.
Figure 2 — Memcrashed, a memcached DDoS exploit tool.
Memcached is designed by default to act as a memory cache for large objects. If the attacker injects their own object (up to max size of 1MB), they can then repeatedly request that object in a single command. For example, by injecting a 1MB object and giving it a short name, for example, ‘a’, the attacker can then request that object using the ‘get’ command 729 times using a single 1450-byte UDP packet. The memcached server will respond with 536,302 packets, resulting in an amplification factor greater than 1:500,000!
The weaponization of memcached as a DDoS attack vector demonstrates that it is of utmost importance that those who design and implement Internet-facing services secure them properly to avoid them being used to launch DDoS attacks.
Detecting and mitigating memcached attacks
Memcached attacks are classified as reflection type DDoS attacks and will appear as a flood of non-fragmented UDP packets with source port 11211. Flow-based network telemetry (Netflow) will, therefore, easily detect this kind of attack.
Traditional UDP reflection type mitigation practices, therefore, apply:
- Use Flowspec (dynamic approach) or iACLs on the edges of the network (static approach) to block or rate limit traffic with UDP source port 11211.
- FIltering commonly exploited ports has been effective in blocking memcached and other types of attacks.
Those organizations that have taken proper precautions and deployed advanced DDoS protection solutions, will, in most cases, be able to mitigate this and similar types of attacks. For example, when the 1.7 Tbps memcached attack was launched against an organization that implemented modern DDoS defences, there was zero impact to their services.
Steinthor Bjarnason is Principal Engineer in Arbor’s Security Engineering & Response Team (ASERT) at Netscout.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.