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:

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.

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.

Fig. 3 An example overflow triggering MessageID payload

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%. 

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%.

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%.