DrDoS cyberattacks based on the ARD protocol

After the preliminary study of denial-of-service (DoS) cyberattacks, together with some of their variants exposed in the article “DrDoS: characteristics and operation”, this new article will address how the ARD protocol is used as a tool to develop a DoS cyberattack in its Reflected Denial-of-Service (DrDoS) variant.

ARD

The Apple Remote Desktop (ARD) service is a service used by businesses and educational institutions to perform administrative, support or remote connection tasks on Apple Mac products.

ARD operates using UDP port 3283 and is used by at least 40,000 Apple Macs, out of the total number there are in the world; they are relatively easy to find since their port is open and they expose their IP to the Internet.

If a machine or network did not have the ARD service, there would be no problem, since there are other services that can operate in the same way, hence the lack of ARD will not be noticed if this service is blocked for service reasons.

Attack vector

Although the ARD service may seem simple and to have a well-defined utility, a cybercriminal could use it to carry out a DrDoS attack on the network.

By default, UDP port 3283 is disabled on Apple Macs, but when remote sharing is enabled, the service becomes vulnerable. It must be done explicitly by the Mac user himself/herself using administrator privileges.

To develop the mirrored attack feature typical of a DrDoS cyberattack, cybercriminals exploit the Apple Remote Desktop vulnerability, due to the UDP protocol, by spoofing the source IP address with that of the victim (spoofing) in the request packets. Servers are therefore unable to distinguish between legitimate and spoofed requests, which causes them to respond directly to the victim. This technique hides the attacker’s real IP address from both the victim system and the target device.

As regards the amplified attack feature, it may be found in another service called Apple Remote Management Service (ARMS), which machines running the macOS operating system and ARD also run on the same port 3283. This service is responsible for listening for incoming commands given to the computer and serves as the amplification mechanism for the attack. The amplification factor of ARMS is 35.5:1, which is significantly higher than for other services that are commonly used for DDoS attacks, which would make it possible to cause a major impact with very few resources.

Illustration 1. Schematic diagram of an ARD attack.

Of course, this attack could be made using a botnet. In that case, the damage to the company’s network would be far greater, and the bandwidth would be completely saturated by the volume of traffic to which it would be subjected.

It is important to note that, on Mac systems, enabling remote administration in the “System Preferences/Sharing” section of macOS causes computers using this system to listen on UDP port 3283, even if Apple’s firewall service in the “System Preferences/Security and Privacy” section is enabled.

Prevention

Any exposed ARD service on port 3283 will be vulnerable to being used as an amplification method. The following nmap command can be used to look up the exposure status:

nmap -p 3283 [IP to be scanned]

This command returns the status of port 3283, hence if the status of port 3283 is “open”, the server is vulnerable.

It is recommended that the following actions be taken by way of prevention:

• Block incoming UDP port 3283 in the firewall. Blocking and correctly configuring the firewall is the first step in guaranteeing security.

• Enable the macOS application firewall. If it is not already enabled, it should be enabled. Note, however, that the option to enable stealth mode also disables the echo response and the device would no longer respond to ping requests.

• Disable Apple Remote Services (ARD/ARMS), as long as these services are not needed. On the other hand, if a department needs them, there are services with similar options, such as the VNC protocol or Microsoft Remote Desktop (available for Mac).

• Deploy the ARD devices behind firewalls. The firewall must be configured with rules that detect and filter UDP directed requests to the port of the ARD device. It should also have anti-spoofing settings that prevents IP spoofing.

• Request anti-spoofing filters from the Internet Service Provider (ISP). These providers may reject ARD traffic with spoofed addresses, which are not accessible through the packet’s true route.

• Deploy intrusion detection and blocking systems (IDS/IPS). A Security Information and Event Manager (SIEM) will identify anomalies in ARD traffic and detect them quickly so as to implement an immediate response and thus limit the impact of the attack.

• Set out an action protocol for ARD DrDoS incidents. Knowing how to identify these attacks and how to act if they occur is key to limiting their impact. Acting rashly and impulsively can lead to further problems and failures in other components.

• Modify default usernames and passwords. It is recommended two-factor authentication be used on your IoT and other devices.

• Keep Apple Mac systems up-to-date and patched. This guarantees security against new vulnerabilities or possible exploitation of an out-of-date system.

• Make sure the device is not on device search engines. Thus, the device’s IP address cannot be found easily and it will not be known exactly whether its port 3283 is open.

Detection and evidence

To detect whether a device with an ARD service enabled is suffering a DrDoS attack or is being used to perpetrate it against a third party, special attention must be paid to unusual and heavy UDP traffic on port 3283, since this is the address ARD uses for its packets.

Monitoring the traffic using a SIEM application and analysing the packets will make it possible to see in detail how many packets are reaching the network through port 3283, so it will be possible to know whether the number of requests is irregular for the device during the period being analysed.

To ensure early detection, it is recommendable to use network monitoring tools, such as SIEM or IDS/IPS systems and, moreover, device status monitoring tools, such as resource usage monitoring software (processor, memory or disk), so as to notice irregular ARD-related behaviour. In this way, it will be possible to be informed of irregular consumption of device resources. Abnormal activity, in both resource and network usage, will be clear grounds to begin an investigation.

For further evidence, logs related to the ARD connection can be found in the directory “/var/logs/secure.log”.

Response and recommendations

If the evidence confirms that a DrDoS attack is occurring on your own ARD machines, it is important to act quickly and to do so according to the incident management and action protocol drawn up in advance. This protocol should include the following actions:

• Collect as much data as possible about the incident. The source and destination IP addresses, ports and URLs from which the attack may have been launched must be investigated.
• Blocking and filtering of unwanted traffic. The foregoing data collection will make it possible to configure filters in firewalls and using rules that prevent new requests from reaching the machine with the ARD service. It is also recommendable to contact the ISP and host so that they can apply appropriate filters.
• Contact INCIBE-CERT. They will assist in taking mitigation and recovery measures when handling such attacks.

Once the attack has ceased and the service has been restored to normal, an analysis of the causes of the attack should be carried out, identifying possible vulnerabilities and setting out an action plan to improve the bastioning of the systems so as to prevent a new attack.

Likewise, regardless of the scope of the attack suffered, it must be reported to the authorities, just like any other technological crime, so that it can be investigated and prosecuted.