DrDoS cyberattacks based on the PortMapper protocol

After the preliminary study denial of service (DoS) cyberattacks alongside any of their variants set out in the article “DrDoS, characteristics and operation“, this new article is going to address how the Portmapper protocol is used as a tool to develop a DrDoS variant of a DoS cyberattack.

Portmapper

It is a service, also known as RPCBind, which first appeared with the BSD 4.3 system (Berkeley Distribution 4.3, 1991),which was based on ONC RPC (Open Network Computing Remote Procedure Call), and which is used to make query requests about certain services.

A portmap server converts the RPC program number into DARPA protocol numbers; that is, when an RPC server is initialised, it generates a list, by associating the active listening ports with the corresponding RPC program numbers. Thus, the services are identified against the portmap server so that, when an access request reaches the service, it can know which port is listening. The portmap server will consult its correspondence table when dealing with a request to connect to a service and it will return the port to connect to. It may also send complementary information, such as the version of the service that is running. Lastly, with the information received, the customer connects with the requested service.

The portmap protocol works on port 111, on both UDP and over TCP.

Figure 1. Diagram of how Portmapper works

Attack vector

The attack begins when the cybercriminal makes a request to a server with a portmap service. This request has to go over UDP, given that the UDP protocol, unlike TCP, is not capable of authenticating the issuer. This allows the attacker to carry out spoofing techniques to change its source IP address to the IP address of the victim machine, such that the servers deal with a legitimate request and respond against the victim machine. The number of requests is high, which makes it impossible to process all the response packets received.

Besides a high number of response packets, to disable the victim machine, the attacker may manipulate the size of those response packets by making specific queries about the deceived portmap servers. This can be used to reflect the attack and an “amplifying” effect, since the victim machine has to use more time and resources to process the packets received.

Figure 2. Diagram of the attack on Portmapper

The amplification factor will depend on the number of services that are running on the server used as an intermediary. The RPC information request occupies between 68 and 70 bytes; by contract, the size of the response, according to the number of services, may vary between 486 and 1930 bytes. In this simple way, the attacker can increase the size of the packet at source by between 7 and 28 times when it reaches the victim.

On the other hand, due to the operating characteristics of the portmap services, they allow the attackers to be able to redirect the inundation of traffic to any active UDP service in the victim machine, modifying the data about the port at source in the requests.

Finally, besides the harm that may be done to the victim by their attacked systems being out-of-use, the portmap servers, which are involved in the cyberattack may also be affected and crash due to the large number of inquiries they may receive, from a botnet consisting of tens, hundreds or thousands of zombie machines.

Prevention

To verify whether the Portmapper UDP port is vulnerable using NMAP, the following command can be used:

nmap -Pn -sU -p U:111 --script=rpcinfo [Dirección IP]

At all events, the recommendations to prevent an own server from becoming liable to participate in a DrDoS attack are as follows:

• Update the portmap server. It is necessary to assess the need to maintain the services because there are other, more evolved protocols, such as NFSv4, which are more secure and can perform to similar level without the need to interact with portmap.
• Set out an action protocol for DrDoS portmap attack incidents: to propose and set out how to act in the face of a denial-of-service attack affecting the own portmap servers, adapting it to the characteristics of the organisation, and also setting out how to identify these attacks.
• Ask the Internet service provider (ISP) for anti-spoofing filters. These Internet service providers may reject portmap traffic with spoofed addresses, which are not accessible through the packet’s actual path. This will prevent the own portmap from receiving and dealing with queries liable to be a DrDoS attack.
• Deploy the servers with portmap behind firewalls. The firewall must be configured with rules to detect and filter UDP-directed requests to port 111 on the portmap server and which have had the source IP addresses spoofed, by using an anti-spoofing setting.
• Limit the visibility of the portmap server on the Internet. Whenever possible, access to the server must be limited to ensure it is not public by filtering IP addresses, using a firewall’s filtering rules.
• Deploy intrusion detection and prevention systems (IDS/IPS), in order to monitor the connections and warn that unusual traffic has been detected in the protocols associated to portmap.
• Deploy machine health monitoring systems: to monitor both specific situations in which there is intensive use of the network, processor and RAM resources, and signs of overloading caused by a denial-of-service attack on these servers.
• Hosting protection measures: learn about the protection measures the Internet or hosting service provider has implemented or which can be contracted to reduce the impact of DoS attacks. Likewise, it is necessary to verify with the supplier that they are deployed and activated and to determine who is responsible for configuring and administering it.

Detection and evidence

The signs that an own portmap server is participating in a DrDoS attack lie in its own activity. Intensive and unusual activity related to the UDP traffic in port 111 will set off all the alerts. The analysis of the traffic with respect to the source address of the queries that are received (the same in all the packets or with clear signs of having been spoofed) confirm the participation in the reflected attack.

In the event that the attack has gone unnoticed when it was carried out, and there are suspicions that it has been executed, traces of the event can be found on the log of the portmap server.

The logs associated with the portmap daemon are accessible according to the platform of the operating system on which it runs and the manufacturer’s documentation to know exactly how these audit records are stored.

Response and recommendations

If it turns out that one is the victim of a distributed denial-of-service attack through a name server amplification, or an own server is unavailable due to their participation as a means of amplification, it is recommended that the following actions be performed, which must be set out in the action and incident management protocol for this type of attack:

• Review the source of the source and destination IP addresses, as well as destination ports: collect all the information considered useful to report it to the Internet service provider so that it can block it. This information can be extracted from the firewall.
• Contact the Internet or hosting provider. The event must be reported to this provider, to which shall be sent the information necessary to apply traffic filters necessary to stop the attack.
• Obtain technical assistance: contact the IT technical services suppliers that are contracted or the leading public computer emergency response teams (CERT) such as INCIBE-CERT.

Once the attack has ceased, the service has returned to normal and the usual name resolution settings have been restored, it is necessary to investigate the causes of what has happened, identify the any vulnerabilities that may be present and implement measures to prevent a new attack, paying attention to the bastioning of the portmap servers exposed on the Internet.

Moreover, regardless of the consequences and impact the attack may have caused, it must be reported to the authorities so that it can be investigated and prosecuted. The legitimate owners of deceived portmap servers may face legal problems in the shape of claims lodged by the victims, since, for them, those servers are the source of the cyberattack.