A Call to ARMS: Apple Remote Management Service UDP Reflection/Amplification DDoS Attacks

Key Takeaways:

• A new UDP reflection/amplification DDoS vector is observed in the wild.
• The surprising nature of the abusable reflectors/amplifiers.
• Recommended DDoS Defense and Best Current Practices (BCPs) for ARMS.

Anatomy of a New DDoS Vector

One of the ground truths of distributed denial-of-service (DDoS) defense is that literally any kind of packet can be utilized to launch an attack against a host, service, application, or network. And when attackers initially identify a service or application which can be abused to indirectly reflect attack traffic to the intended target, while at the same time providing an amplification factor (i.e., the attackers can induce the abusable service or application to generate more network traffic than the amount required to stimulate the spoofed ‘responses’ to the target), they tend to move quickly to utilize it in attacks and to weaponize it for inclusion in DDoS-for-hire ‘booter/stresser’ services.

Late last week, we were made aware that network operators were seeing a sudden surge of attacks in the 70gb/sec range, sourced from UDP/3283. Initial investigations revealed that the abused reflectors/amplifiers were generating two attack-traffic packets for every single spoofed stimulus packet — the initial packet was 32 bytes in length, and the second packet was 1034 bytes in length – attaining a respectable amplification ration of 35.5:1.

Whichever application or service was being abused, it apparently performed application-layer message segmentation, as no non-initial UDP fragments were present. We’ve observed this behavior in some other abusable UDP reflectors/amplifiers such as misconfigured Network Time Protocol (ntp) servers.

Looking at relevant DDoS Misuse alerts in Arbor Sightline deployments, it became apparent that attackers could induce the reflectors/amplifiers to target any destination port of their choosing, and that observed attacks were peaking in the ~75gb/sec range, with a throughput of ~11mpps. While throughput, or packets-per-second (pps), is often the most significant metric in direct-flooding DDoS attacks such as SYN-floods, bandwidth, or bits-per-second (bps), is the primary metric for most (not all) reflection/amplification attacks.

Even though this was a previously-unknown DDoS attack vector, Sightline was able to detect, classify, and traceback these ‘minute-0’ DDoS attacks due to its use of network-wide flow telemetry in order to perform real-time anomaly detection. And based on the attack classification information contained in relevant Sightline DDoS Misuse alerts, network operators were able to instantaneously make use of Arbor TMS to mitigate the attacks as they first appeared on production networks.

Once we had a thorough understanding of the attack characteristics, we turned our attention to identifying the application or service being abused in order to generate these attacks.

A Surprising Discovery

Our initial investigation revealed a surprising piece of information: UDP/3283 was most closely associated with the Apple Remote Desktop (ARD) application and related management service used to remotely manage fleets of Apple Macs, primarily in enterprises and universities. While ARD was most popularly identified with the ability to perform screen-sharing, over the years it has evolved into a more fully-featured system management application, allowing the remote installation of software updates, remote logging, etc.

Based on available online documentation, it appears that Apple’s Remote Management service (ARMS) listens on that port for management console commands and queries. Some time ago, Apple separated ordinary screen-sharing from more comprehensive remote administration capabilities, so ARMS should only be enabled when Macs are being actively administered via a management framework such as ARD.

Making use of the ASERT Virtual Lab, we were able to determine that on Apple macOS, enabling Remote Management under macOS System Preferences/Sharing caused Mac computers to listen on UDP/3283, even if Apple’s Firewall service under System Preferences/Security & Privacy was enabled!

It should be noted that this service is disabled by default, and must be explicitly enabled by a Mac user with administrative privileges.

Why ARMS?

It was somewhat puzzling that we were seeing UDP reflection/amplification attacks abusing a remote administration framework that we’d typically expect to be used across enterprise LANs and WANs, rather than on the public Internet. But once we began delving further into how ARD is typically deployed, the answer became apparent.

In most of the online documentation and discussion we found about enabling and utilizing ARD and ARMS, when it came to remotely administering Macs in environments beyond campus LANs, almost all the focus was on how to implement static NAT translations and allow UDP/3283 through firewall rules and router ACLs, rather than on utilizing standard industry BCPs like virtual private networks (VPNs) and related secure network access policies and authentication techniques.

This same set of Worst Current Practices (WCPs) with regards to vulnerable and/or misconfigured Internet of Things (IoT) devices such as IP-enabled surveillance cameras and digital video recorders (DVRs) has contributed to the compromise of many embedded devices and their consequent enrollment in DDoS botnets, even when they are installed behind NATs and firewalls.

As of this writing, we have determined that there are approximately ~54,000 abusable ARMS-enabled Macs exposed to the public Internet, either directly or via the aforementioned static NAT translations and/or permissive firewall rules and ACLs. These computers are being actively abused by attackers to launch ARMS reflection/amplification DDoS attacks; and not only do the attack targets and intervening networks suffer from the onslaught of DDoS attack traffic, but the abused ARMS-enabled Mac reflectors/amplifiers and the networks on which they reside are negatively impacted, as well.

Via analysis of DDoS attack data collected by Netscout Arbor’s ATLAS system, we were able to determine that the first observed use of ARMS as a reflection/amplification DDoS vector on the public Internet appears to have taken place during the second week of June 2019. It has rapidly grown in relative popularity, and we believe that it will be weaponized by DDoS-for-hire ’booter/stresser’ operators in short order.

Recommendations

ASERT recommends that network operators make use of network-wide visibility and alerting systems such as Arbor Sightline to detect, classify, and traceback ARMS reflection/amplification DDoS attacks. Custom Misuse Alerts for ARMS reflection/attacks can be defined by the system operator.

Together with Sightline, Arbor TMS can be used to mitigate ARMS reflection/amplification attacks using a variety of countermeasure options; Sightline also supports flowspec-based mitigations for flowspec-enabled routers. Other mitigation techniques such as source-based remotely-triggered blackholing (S/RTBH) and ACLs may be employed, as well.

ASERT have transmitted both IPv4 and IPv6 AIF Templates containing example TMS countermeasure configurations to AIF-entitled customers.

We also urge administrators of ARMS-enabled Macs to shield UDP/3283 from the public Internet, and instead make use of VPN technologies in order to forward remote administration traffic between administration systems and managed Macs.

Many thanks to Dmitry Tsarev and Kirill Kasavchenko for their contributions to this report.