DrDoS cyberattacks based on the TFTP protocol

Continuing with the series of articles dedicated to “DrDoS: characteristics and operation”, today we dealt with the TFTP protocol as a tool used for this type of attacks..

TFTP

The Trivial File Transfer Protocol (TFTP) provides a standardised means for file transfer between connected systems based on a client-server architecture and using UDP for the exchange of file read and write requests, through port 69. This protocol has no encryption or authentication capability and does not have functions to list the content of directories or folders.

Even if it is an obsolete protocol, it is still widely used, since manufacturers find in it a comfortable, easy and quick means to transfer files between devices that have little processing capacity and memory dedicated to managing it, such as routers, switchboards and VoIP telephone exchanges. It is normally used to upload firmware updates and configurations on these devices, and as an operating base for the startup and network upload of the device operating system, known as PXE startup (Preboot eXecution Environment).

- Figure 1. TFTP operational diagram. -

Attack vector

In 2016, a vulnerability was documented based on the protocol’s own operating specifications, RFC 783, and which therefore affects all the machine that have activated the TFTP protocol.

By exploiting this vulnerability, DrDoS attacks could be carried out with an amplification factor of 60 times the original request, and could be re-sent as many as 6 times.

- Figure 2. TFTP DrDoS attack diagram. -

The operating base of the TFTP DrDoS attack follows the same pattern as all other attacks of this type with other protocols. The attacker locates a TFTP server and launches small-scale requests called RRQ or WRQ, depending upon whether it is a read or write operation, including the file name and the operation’s transfer mode. After modifying the requests, to spoof the source IP address, the victim’s IP address is placed and different parameters of the packages are manipulated, «flaws» to be incorrect and require resending with the requester, at the same time as an expanded response is requested so that the size of the package is greater.

The result is that the TFTP server, for each request received, forwards the response packages, enlarged several times, to the victim machine. This would be multiplied by each system belonging to the botnet.

The success of this attack is due to the fact that UDP requests and responses do not require end-to-end identification or authentication to establish a connection, hence the TFTP server processes all the requests received.

Prevention

Any machine that has activated the TFTP service is liable to become a victim of this attack, hence the sole possible prevention is to deactivate this protocol and enable file transfer through other alternative similar means, but which offer a greater level of protection, such as SCP (Secure Copy Protocol and SFTP (SSH File Transfer Protocol) with more restrictions and security measures, which guarantee more secure file transfer. Nor are there specific settings on the TFTP server itself so that it is not vulnerable.

By means of the following Nmap command, it is possible to verify whether there is a TFTP server running.

nmap -sV -sC -sU -p 69 [IP Address]

In the event that it is not possible to replace or eliminate this protocol from the system’s functionalities, it is advisable to apply the following recommendations:

• Ask the internet service provider (ISP) for anti-spoofing filters. These Internet service providers may reject traffic with spoofed addresses, which are not accessible through the actual path of the package. This will prevent the own TFTP server from receiving and processing queries that are vulnerable to an amplified denial-of-service attack through this protocol.
• Deploy the TFTP servers after a firewall. The firewall must be configured with rules that detect and filter requests sent by UDP to port 69 of the TFTP server, that have spoofed source IP addresses, an anti-spoofing configuration and which define rules that include «whitelists» of authorised IP addresses to connect with the TFTP server.
• Limit the visibility of the TFTP server on the Internet. Whenever possible, limit the access to the server so that it is not «public» by filtering IP addresses that may access the service.
• Deploy detection systems and blocking of (IDS/IPS) intrusions. By means of Event Manager- and Security Information-type solutions, known by their initials as SIEM, it is possible to identify anomalies in TFTP traffic and detect them quickly to apply an immediate response that limits the impact of the attacks that may occur.
• Set out an action protocol for TFTP DrDoS incidents. Having an action plan set out in advance for this type of attacks that allow for a quick and effective response. Otherwise, failures and complications may be caused in other components, increasing the impact caused.
• Keep systems up-to-date and patched. To prevent the exploitation of other vulnerabilities from allowing an attacker to launch a TFTP DrDoS attack on the machine.

Detection

Intense and unusual activity in the activity related to the UDP traffic in port 69, may be a sign of being attacked. An analysis of the traffic to the source address of the requests that are received would confirm the participation of our system in the reflected attack.

If the suspicions are confirmed, it is necessary to act promptly to block the server’s participation in the attack. In this case, it could involve legal repercussions since our systems have attacked those of the victim.

The activity logs of the TFTP server, can help, but it poses difficulties when being analysed in search for evidence, since they depend upon each implementation and on the volume of logs that are generated.

Response and recommendations

If the signs are confirmed and a denial-of-service attack is believed to be occurring on the own TFTP servers, it is important to know how to act and to do so as soon as possible. This is the point at which the action and incident management protocol set out previously for this type of attacks must be applied: they should encompass the following actions:

• Compile as much data as possible about the incident. A brief investigation will have to be undertaken to identify source and destination IP addresses, ports and possible URL addresses.
• Block and filter unwanted traffic. The data collected previously may be used to configure filtering rules in firewalls and routers and to prevent requests from reaching the one’s own TFTP server. It is also recommendable to contact the Internet and hosting provider so that they can apply in their area filters that block the installation of unauthorised traffic.
• Obtain technical assistance. Either with the IT technical service providers they may have contracted or through the leading public computer emergency response teams, known as CERT, such as INCIBE-CERT.

Once the attack has ceased and it is verified that the system has been restored to normality, it is necessary to analyse the causes of it, to identify the vulnerabilities that made it possible and to set out an action plan that will allow it to eliminate the weaknesses of the attacked system or, at least, reinforce the prevention measures to prevent it from happening again.

It is desirable to focus upon the devices that use vulnerable file transfer and which are accessible from the Internet, analysing the need to report it publicly and to bastion it, if necessary.

Similarly, regardless of the effects of the attack suffered, it is recommendable to notify the authorities of the incident, as well as of any kind of technological crime.