DrDoS cyberattack based on the QOTD protocol

After the preliminary study of denial-of-service (DoS) cyberattacks, together with some of their variants set out in the article “DrDoS: characteristics and functioning“, this new article will address how the SSDP protocol is used as a tool to conduct a DoS cyberattack, specifically the Reflected Denial-of-Service (DrDoS) variant.

QOTD

Within Internet protocols (IP), the QOTD (Quote of the Day) service has always been used by mainframe administrators (computers with large capacities used for massive data processing) to send a daily message to all users who connect to the servers that work with this protocol.

QOTD is defined in RFC 865 and works on both Windows and Unix. In its transport layer it uses the UDP protocol, which is executed by default on port 17. Its operation is reduced to, when computers establish a connection with the server, the server sends them a message, and after sending the message the service terminates the connection.

Illustration 1. QOTD architecture diagram

Attack vector

The possibility of sending data packets to every computer connected to the server on which the QOTD service is enabled makes DrDoS attacks highly likely. At the same time, any machine accessible from the Internet and visible from device browsers, which has port 17 open, will be vulnerable to these attacks.

The amplification of a denial-of-service attack starts with sending of a multitude of requests whose source IP address has been replaced by the victim’s address (IP spoofing). The manipulated service, i.e., QOTD, acts as an intermediary between the attacker and the victim, as the protocol receives the above requests as legitimate due to spoofing. Subsequently, QOTD responds to the requests, sending them to the victim. This causes the other computers connected to the server to slow down and saturate the network traffic.

This saturation occurs because the normal confirmation message upon successfully connecting to the service is small compared to the manipulated one sent after the attack. The amplification factor can be as high as 140.3.

llustration 2. Schematic diagram of the attack on QOTD

Prevention

The first step in prevention is to find out whether your own server is vulnerable. To do this, it can be useful to run the following command in the NetCat tool, which is freely available on Linux:

nc -u [IP to connect to] 17

This command will establish a UDP connection (option -u) through the Netcat tool to the specified IP, with port 17 as the destination. If the IP address has the QOTD service enabled, a message or quote will be displayed, meaning that it is possible to access the QOTD service without restrictions.

Another way to check if the computer is vulnerable is to use one of the following commands, which would follow the same mechanics as the previous one, that is, they would make a request to port 17 of the IP for which you want to check the availability of the QOTD service.

nmap -sU -PN -p17 [IP]
telnet [IP] 17

In the task of preventing and protecting equipment from this type of attack, it is advisable to follow the recommendations below:

• Block incoming port 17 for UDP and TCP on the firewall.
• Disable port 17 on Unix. To disable port 17 on computers running the Unix operating system, rewrite the “qotd” line found in /etc/inetd.conf, adding the # character to the beginning of the line in the configuration file to comment out and restart the inetd service.
• Disable port 17 in Windows. To do this, proceed as follows:
  • Set the following registry keys to 0:

HKLM\System\CurrentControlSet\Services\SimpTCP\Parameters\EnableTcpQotd
HKLM\System\CurrentControlSet\Services\SimpTCP\Parameters\EnableUdpQotd

• Start “exe” and type the following commands to restart the service:

net stop simptcp
net start simptcp

• Disable the QOTD service on both computers and servers.
• Deploy intrusion detection and blocking systems (IDS/IPS). The use of a Security Information and Event Manager (SIEM) makes it easier to identify and detect anomalies in QOTD traffic so you can respond quickly, thus limiting the impact of the attack.
• Set out an action protocol for DDoS incidents by QOTD. This is a further measure to limit the impact of the attack, which recommends having prior, specific guidelines on how to identify these attacks and how to act when they occur.
• Keep systems updated. Thus, systems will be protected against new vulnerabilities or exploits of past vulnerabilities.
• Prevent computers from appearing as a result of device search engines. This is one way to prevent the device’s IP address from being easily found or finding out exactly whether it has port 17 open. An example would be to limit access to a device through the scanners used by Shodan.

Detection and evidence

The main way to detect a QOTD-based DrDoS cyberattack is to pay attention to irregular UDP or TCP traffic on port 17, since this is the port used by QOTD to send its data packets.

To monitor the number of packets arriving at port 17, and to assess whether they are unusual, it is recommended you use a traffic monitoring application (SIEM).

On the other hand, it is important to constantly analyse the device’s state of health, given that a specific peak in the consumption of its resources may mean that something serious is happening. To do so, it is recommended you use computer monitoring tools that monitor the use of the processor, memory or disk. One example is the Nagios programme. In this task, it is also important to check the alerts coming from the active IDS/IPS (any SIEM device is capable of performing this function). With all this, it is possible to be constantly informed about the irregular consumption of the computer’s resources.

Response and recommendations

In the event of a DrDoS attack through the QOTD service that affects your own machine, you must know how to act and act quickly, applying the pre-set action and incident management protocol for this type of cyberattack. This protocol must include the following steps:

• Incident data collection. The source and destination IP addresses, ports and possible URLs from which the attack may originate should be investigated.
• Blocking and filtering of unwanted traffic. The data collected above can be used to set up filters on firewalls and routers to prevent requests from reaching the equipment running the QOTD service. The Internet and hosting provider may also set up filters at their end when providing the information.
• Contact with INCIBE-CERT. This will help in taking mitigation and recovery measures against such attacks.

Once the attack is over and it has been verified that the service and communications have been restored to normal, the causes of the incident must be analysed, identifying possible vulnerabilities. An action plan must also be defined to eliminate the system’s weaknesses and reinforce prevention measures to avoid a recurrence.

On the other hand, regardless of the impact of the cyberattack suffered, it must be reported to the relevant authorities so that it can be investigated and prosecuted.