New DDoS Vector Observed in the Wild: WSD attacks hitting 35/Gbps
Additional research and support provided by Chad Seaman.
Introduction
Members of Akamai's Security Intelligence Response Team have been investigating a new DDoS vector that leverages a UDP Amplification technique known as WS-Discovery (WSD). The situation surrounding WSD was recently made public, but multiple threat actors have begun to leverage this DDoS method to ramp up their attacks.
While conducting exploratory research prior to WSD becoming public, the Akamai SIRT gained first-hand knowledge into the inner workings of a WSD attack after one of our customers came under fire. The attack, which targeted the gaming industry, weighed in at 35/Gbps at peak bandwidth.
Additional research into WSD protocol implementations on devices across the Internet raised grave concerns, since the SIRT was able to achieve amplification rates of up to 15,300% of the original byte size. This places WSD in 4th place on the DDoS attacks leaderboard for highest reflected amplification factor.
In this write-up, we'll cover our findings related to WSD, including amplification concerns and estimates, protocol implementation flaws, and how organizations can posture themselves to defend against it.
What is WS-Discovery (WSD)?
For reference, Wikipedia notes that:
Web Services Dynamic Discovery (WS-Discovery) is a technical specification that defines a multicast discovery protocol to locate services on a local network. It operates over TCP and UDP port 3702 and uses IP multicast address 239.255.255.250. As the name suggests, the actual communication between nodes is done using web services standards, notably SOAP-over-UDP.
Why does it exist?
WSD is yet another technology developed to ease consumer device network discovery and connectivity. It fills a very similar role to other technologies in this space such as Simple Service Discovery Protocol/Universal Plug and Play (SSDP/UPnP) and multicast DNS (mDNS), both of which are used in DDoS attacks today, due to poor implementations by consumer hardware vendors.
What products leverage it?
WSD can be found in a wide-array of products. It was shipped as a default feature set and service starting with Windows Vista, and it has been included in HP printers since 2008. In the case of devices that we found on the Internet to be incorrectly exposing and responding to WSD, most consist of CCTV cameras and DVR systems, a trend that isn't surprising at this point.
The problem
Since UDP is a stateless protocol, requests to the WSD service can be spoofed. This ultimately causes the impacted server, or service, to send responses to the intended victim, consuming large amounts of the target's bandwidth. Attacks powered by poorly implemented IoT services are a very common DDoS type, and we've seen them leveraged in large attacks before (including the attack against Dyn in 2016). Other common reflection DDoS types have been observed in the past as well, such as the 1.3Tbps attack in 2018 due to memcached.
How / why is this possible?
WSD suffers from the same problem we've seen time and time again. WSD was designed and intended to be a LAN-scoped technology, it was never meant to live on the Internet. As manufacturers pushed out hardware with this service (improperly) implemented, and users deployed this hardware across the Internet, they've inadvertently introduced a new DDoS reflection vector that has already begun to see abuse.
Responding to unicast IP addresses
WSD probes are meant to use the LAN scoped multicast address 239.255.255.250. This is a special address that machines on a LAN can use to send a single packet that all hosts on the same subnet will receive. These packets aren't meant to traverse the Internet. In the case of WSD however, the daemon is responding to these probes when using a unicast IP address, where only a single recipient on the network is receiving the packet. If the manufacturers had scoped this technology to only respond to the proper multicast addressed packets, this issue wouldn't exist.
Findings
While researching the WSD protocol, the SIRT conducted several scans across the Internet in attempts to identify various characteristics of this attack. In this section, we'll cover some of those findings including probing, responses, manufacturer/model identification, information leakage, eco-system, amplification ratios, and protocol specifics.
What are probes used for?
WSD probes in a non-abusive scenario are utilized by machines on a LAN to help them in announcing available networked services and aiding in automated configuration and use of these services by consumer devices. As an example, WSD is how a Windows machine (after Vista) automagically finds and configures networked printers.
Probe sizes and responses
The WSD service uses a specific Simple Object Access Protocol (SOAP) payload for device discovery and communications. The default probe payload is outlined in the service specification documents and weighs in at 783 bytes.
Akamai SIRT found that while this probe is well structured and sticks to the specifications outlined by the WSD working group, it can be stripped of much of it's verbosity and still be effective at triggering a "valid" response.
This leaner, minimal valid probe that we're discussing weighs in at just 170 bytes. This smaller probe could allow attackers to push much larger attacks, as their outbound bandwidth needs have been reduced by over 400%.
A 170 byte probe isn't the smallest payload needed to identify end-points or launch an attack however. Typically, in amplification attacks, the goal is to send the least amount of data and trigger the largest response. In the case of WSD, this ratio doesn't actually come from a valid request.
An attacker can trigger an XML error response from WSD by sending a 29 byte malformed payload. In some cases, an 18 byte payload can be used. The 18 byte probe is 43% smaller than the default and 900% smaller than the minimal valid probe. While the response it triggers is also smaller, it still packs a massive amplification ratio.
Amplification
Amplification of the WSD protocol at first glance doesn't appear to be as bad as it actually could be. This is primarily due to the very large default probe/payload needed to illicit a response. However, researchers within Akamai's SIRT were able to find multiple cases where smaller probes could be leveraged to increase amplification potential to over 15,300%.
As stated earlier and is worth repeating, such a rate places WSD at 4th on the list for the highest overall amplification factor, stacking it alongside some of the most abused protocols for reflected DDoS attacks. In this section, we'll discuss amplification scenarios and estimated DDoS impact of WSD fueled attacks.
Padding payloads
During testing, it was discovered that utilizing the MessageID field within the WSD probe payloads would cause observable changes in the WSD probe responses. The MessageID field acts as a sort of session tracking and management mechanism.
In short, this means that, when a client sends a payload with a MessageID value, WSD at the application layer associates this value with future responses directed back at the respective client/session. In some cases, this translates to a persistent field that attackers can leverage to increase the overall responses returned from the WSD service.
MessageID functionality variations
Not all devices and manufactures treat the MessageID field equally. Some devices seem to store this as a sort of sessions-related value that persists across multiple requests, and others will only return the padded value in the initial response. While most devices trim this value to 256 bytes, others allow attackers to keep packing kilobytes of data into this field, which ultimately will be included in the response.
23:20:29.616596 IP Y.Y.Y.Y.3702 > X.X.X.X.56727: UDP, bad length 61648 > 1472 |
Fig. 2 Reflector responding with a 61k padded response
Luckily, most of these devices do not appear to maintain persistent tracking of this value across multiple requests. So attackers would need to pad every request to elicit such large responses, making the amplification nearly non-existent.
MessageID padding, buffer overflows, and amplification
While testing these padding capabilities, more than 2,000 devices from a particular manufacturer were discovered to have an off-by-one buffer overflow within their WSD protocol implementations. This poses potential security risks for the protocol and devices. These cases are outside of the scope of this blog post, but they can be used to cause larger amplification payloads, so we'll discuss them briefly.
In the affected devices, sending an initial probe value with a MessageID payload of more than 257 bytes will result in responses that include a RelatesTo element housing our 257 bytes of the initial payload. Due to the buffer overflow, it will also include the next value in memory until it encounters a null byte. In this case, the next value in memory is the urn:uuid value that is stored in the responses MessageID element.
<wsadis:MessageID>AAA...A</wsadis:MessageID> |
Fig. 3 An example overflow triggering MessageID payload
<wsadis:MessageID>urn:uuid:31f83496-c857-11b2-80d9-54c4157e8d4b</wsadis:MessageID> <wsadis:RelatesTo>AAA...Aurn:uuid:31f83496-c857-11b2-80d9-54c4157e8d4b</wsadis:RelatesTo> |
Fig. 4 An example overflow result
While this does increase the size of the initial probe, the reflected value is actually 46 bytes larger, as the MessageID value is now duplicated in the response. This results in a probe payload of 451 bytes, triggering a response that is 3,445 bytes; this gives us an amplification factor of 700%.
Padded overflow and sticky sessions
In these devices, this session appears to be linked to the IP address of the host that initiated the probe request. This means that subsequent requests will not need to include the MessageID padded payload to trigger the padded response.
In this scenario, an attacker can use the minimal probe request payload and still receive an overflow padded response. Thus, a 170 byte valid probe can trigger a 3,445 byte response; this pushes the amplification factor to over 2,000%.
17:45:54.632582 IP X.X.X.X.63186 > Y.Y.Y.Y.3702: UDP, length 170 17:45:54.905258 IP Y.Y.Y.Y.3702 > X.X.X.X.63186: UDP, bad length 3445 > 1472 17:45:54.905266 IP Y.Y.Y.Y > X.X.X.X: ip-proto-17 (UDP fragment) 17:45:54.906379 IP Y.Y.Y.Y > X.X.X.X: ip-proto-17 (UDP fragment) |
Fig. 5 Triggering 20x response
15,300% amplification using padded overflows, sticky sessions, and errors
The sticky sessions in WSD don't just apply to valid probes; they also apply to errors. As discussed previously, the smallest payload we can send to a WSD enabled host is 18 bytes in size.
This minimal payload won't trigger a valid response and causes the WSD service to issue a /discovery/fault due to a "the xml format error (sic)".
While this fault response isn't the whopping 3,445 bytes we see with a valid response, with overflow padding, it's possible to also pad the error response to 2,762 bytes, which results in an amplification factor of 15,300%.
17:56:21.166839 IP X.X.X.X.53335 > Y.Y.Y.Y.3702: UDP, length 18 17:56:21.483838 IP Y.Y.Y.Y.3702 > X.X.X.X.53335: UDP, bad length 2762 > 1472 17:56:21.483847 IP Y.Y.Y.Y > X.X.X.X: ip-proto-17 (UDP fragment) |
Fig. 6 Triggering a 15,300% response
Amplification modeling and estimates
Given these discoveries, we pulled together a series of quick figures to help estimate the potential bandwidth impact under different scenarios to highlight the nature of the WSD threat. In both scenarios, we'll assume an attacker has 100/Mbps of usable bandwidth and is capable of saturating that uplink fully.
Overflow padded amplification scenario
In this example, we'll assume that all reflectors are subject to the previously-demonstrated padded overflow payloads and sticky sessions. While these things can't be guaranteed in the real world, this example is meant to show a worst case scenario within reason.
We'll also assume the attacker has staged the reflection endpoint with a single padded probe payload. This would result in a valid response of 3,445 and an error response of 2,762 bytes, respectively.
An attacker with the ability to push 100/Mbps of spoofed requests to vulnerable reflectors is capable of producing large floods of reflected DDoS traffic. If this attacker used a default probe (783 bytes), they could cause a 461/Mbps reflected attack. Using the smaller minimal valid probe (170 bytes), that same attacker could cause 2/Gbps of reflected traffic. Finally, in the worst case scenario, using the "minimal error" probe (18 bytes) with hosts staged to respond with overflow padded error responses, that same attacker could cause a flood of 16/Gbps.
Luckily, the pool of available reflectors vulnerable to this scenario is only about 2,151 devices that are scans show and appears to be associated with a device that entered the market in roughly 2015 in Asian markets. Hopefully, we'll see this pool of devices die off as newer, less vulnerable versions, enter the market place.
Average amplification scenario
In this scenario, we'll assume that the attacker has a reflector pool size of more than 60k devices that can respond to the 29 byte payload with the ~2599 byte error response. While we can get a better amplification rate with an 18 byte payload during testing, we saw that the 29 byte would payload triggers a response more often.
By our calculations, if the attack was to send 420,000 requests per second with the 29 byte payload, this would require less than a 100 Mbits/s connection from our attackers controlled system and would generate an attack of 8.73 Gbits/s if all reflectors responded back with 2599 bytes of payload.
This is an 8900% amplification rate.
Get 10 nodes, and this can turn into an 87Gbps attack.
In the sample below, we tested a request of 93 bytes and received a 2506 byte payload, which is 26.95x or 2,695% amplification. The response in this case is an error. We have been able to get the request size down to 20 bytes to increase the amplification factor to 125.3x or 12,530%.
When sending a valid XML request, the systems can leak the internal IP address and model number of the device. This information can be used to search for known exploits on the device in order to gain a foothold into a network.
From our Internet-wide scan with a request size of 783 bytes, the most common response size was 1521 bytes (200% amplification) from 23,723 devices. The median response size was 1517 bytes (193% amplification) from our count of 802,115 devices that responded back to our probe.
Mitigation
Mitigating an attack like this requires planning for a DDoS events. Just placing blocks on the UDP source port 3702 will prevent the traffic from hitting your servers. But that is only half of the issue, as the traffic is still congesting bandwidth on your router. This is where your DDoS mitigation provider would come in and add the needed ACL to block the attack traffic.
Cisco style ACLs
ipv4 access-list [ACCESS-LIST NAME] 1 deny udp any eq 3702 host [TARGET IP]
ipv4 access-list [ACCESS-LIST NAME] 2 deny udp any host [TARGET IP] fragments
Linux iptables ACL
iptables -A INPUT -i [interface] -p udp -m udp --sport 3702 -j DROP
Conclusion
WSD is a major risk on the Internet that can push some serious bandwidth using CCTV and DVRs. Once more, we see security take a back seat for the sake of convenience. Manufacturers can just limit the scope of the UDP protocol on port 3702 to the multicast IP space.
The only thing we can do now is wait for devices that are meant to have a 10/15 year life to die out, and hope that they are replaced with more secured version.
Everyone is a potential target for WSD attacks, so organizations should be ready to route traffic to their DDoS mitigation provider if they're hit with this large attack. Due to its large amplification factors, we expect that attackers will waste little time in leveraging WSD for use as a reflection vector.
Additional mitigation
The Akamai Intelligent Edge platform provides inherent protections against "UDP Amplification" attacks like these because the connection establishment is never completed, so the traffic does not go forward to the origin.
For protection against these types of DDoS attacks via the Prolexic (PLX) platform, customers should see the following recommendations:
Know how to route on to the Prolexic platform in case of an attack.
Ensure runbooks are up to date, accurate, and include all of the necessary contacts and escalation procedures.
Alert staff to this threat and ensure they understand how to engage the Akamai SOCC.
Schedule a service validation via your Security Services Primary if one has not been performed in the last 12 months.
In the medium term, work with the SOCC to proactively configure 0-second SLA pre-mitigations on the Prolexic configuration(s).
Report attacks to law enforcement or to industry trust groups; we know that arrests make an impact on the volume of global DDoS attacks.