DHDiscover reflection attacks can magnify nearly 200 times of the attack 2

DHDiscover reflection attack analysis

In this chapter, we’ll demonstrate the threat status quo of DHDiscover reflection attack after referring to log data captured by the NSFOCUS Threat Capture System[AZ1]  from June 1, 2020 to August 18, 2020 at the port 37810.

We analyzed the number of logs at the port 37810 as shown in the figure. It can be seen from the figure that the attacks increased in an upward trend from early June to early August, and then decreased in mid-August, with the maximum number of packets captured by a single honeypot reaching 900,000 in a single day.

Figure 1.1 DHDiscover[AZ3]  server accessing trend

We also have counted the payload in the log data received at the port 37810. And out of the concern not to spread the attack messages, we have named them here according to the length of the messages. As we can tell in Figure 1.1, the more common payloads used by attackers are 4 bytes and 62 bytes in length, between which the 62-byte payload also has been mentioned in an article written by Tencent.

Figure 1.2 percentages of payloads captured by the NSFOCUS threat capture system

Combining the finding above on payload percentages captured by the NSFOCUS system, we conducted a whole-net-wide mapping with Payload4 and Payload62 respectively. As shown in Table 3.1, 53.6% of DHDiscover services respond to Payload4, and the bandwidth amplification factor [2] of the possible reflection attacks caused by these IPs is as high as 178.5. By using Payload62 for mapping, we can obtain the full network exposure situation of DHDiscover service, and its bandwidth amplification factor is 11.4.

Table 1.1 DHDiscover reflection attack bandwidth amplification factor evaluation

Summary

With NTI’s full network mapping data and the threat data from the NSFOCUS Threat Capture System, this article analyzes the full network exposure of DHDiscover service, reflection attack trend, common attacking techniques used by attackers and reflection attack bandwidth amplification factors. DHDiscover is a video surveillance device discovering service. And in previous analysis, we pointed out that the video surveillance organization ONVIF chose to use WS-Discovery as a device discovering protocol. From our data last year, about 730,000 video surveillance devices with open WS-Discovery services were exposed to the Internet. Therefore, device discovery services such as DHDiscover and WS-Discovery need to be taken seriously by video surveillance vendors.

Due to the large number of DHDiscover services exposed, we have contacted the relevant vendor. The feedback we received was that they had provided Discovery enabling and disabling functionalities in their product. Since the vendor  don’t know whether customers will deploy the device in a public network or a restricted one, this feature is enabled by default. Users can choose to  to turn it off. In addition, the device also has firewall function to block communications between their devices and unintended IP segments as needed. If users didn’t find these two features in their devices yet, they could upgrade their devices through the official website or cloud upgrading service.

We believe effective detection and prevention aginst Discovery-related DDoS attacks needs efforts from multiple parties. Therefore, we have the following suggestions:

1. For a security vendor

(1) Add Discovery scanning capability in scanning products to discover  the potential security threat in the customer’s network timely.

(2) Add Discovery flow detection capability in protection products to timely discover the security threats in the customer’s networks. Collebrating with Threat Intelligence will be better to block the connections with the IPs opening the Discovery service.

2. For a device manufacturer , apart from functions like open/close service and black&white list to be provided, we also suggest adding  self-learning capability to generate a whitelist based on user behaviors and provide configuration recommentions as well.  At the same time, a more reasonable method of device discovery should be designed to avoid the risk of devices being used for reflection attacks.

3. Telecom operators are recommended to implement BCP38 network ingress filtering.

4. Supervision departmentsshould monitor the DHDiscover threat in the networks and synchronize discoveries in time.

5. Users who are using devices with Discovery service can set up a white list for device access, or disable the Discovery function if not necessary.

6. For users with the need for DDoS protection, DDoS protection products from security vendors can be purchased to protect against Discovery reflection attacks.

We have started IoT-related reflection attack research since last year, and have been thinking about whether there is a way to address the root cause of this problem.

The device discovery protocols are designed to facilitate device discovery within the LAN, so multicast addresses are typically used when performing device discovery. For example, the address used by WS-Discovery is 239.255.255.250. Since we don’t have any experimental devices on hand, we are not sure which address is used by DHDiscover. But it is bound to be some kind of multicast address. In the case of a reflection attack, the attacker actually sends a probing message directly to the target device (IP), which is unicast. Therefore, it is possible to analyze the incoming device discovery message on the device side to determine whether the message is unicast or multicast. And if it is unicast, just don’t respond. In this way, the problem of reflection attacks from the device discovery service can be solved at all theoretically, and the potential benefit is that the device discovery port will not be scanned in the public network. In addition, this approach would not have any adverse effects on the use of un-upgraded devices. In practice, device discovery via unicast may also have its own cases. In conclusion, we come up with a more ideal response strategy for device discovery messages as follows.

1. Reply to the multicast messages.

2. If it is a unicast message, determine whether the sender’s IP is on the same network segment as the device’s IP, and reply if yes. You can also adjust this policy to a LAN IP of senders.

3. In case neither 1 nor 2, no reply should be made. Meanwhile, the function of Discovery replying to any unicast message shall be added to the devices, which can be turned on by the user when needed, but shall be turned off by default when they are shipped from factory.

Last but not least, we also hope that not only can this article attract more attention from the major video surveillance manufacturers, but also these manufactures can carefully evaluate the feasibility of our advice. Please feel free to contact us if more information is needed.

Articles:

Alert: Digi Devices Affected by Ripple20 Can Be Used in Reflection Attacks

A Look Into WS-Discovery Reflection Attacks for 2020 Q1

An Anatomy of WS-Discovery Reflection

What You Should Know about OpenVPN Reflection Attacks

Reference

• [1] https://security.tencent.com/index.php/blog/msg/146
• https://www.ndss-symposium.org/ndss2014/programme/amplification-hell-revisiting-network-protocols-ddos-abuse/