New SLP bug can lead to massive 2,200x DDoS amplification attacks – Source: www.bleepingcomputer.com

A new reflective Denial-of-Service (DoS) amplification vulnerability in the Service Location Protocol (SLP) allows threat actors to launch massive denial-of-service attacks with 2,200X amplification.

This flaw, tracked as CVE-2023-29552, was discovered by researchers at BitSight and Curesec, who say that over 2,000 organizations are using devices that expose roughly 54,000 exploitable SLP instances for use in DDoS amplification attacks.

Vulnerable services include VMWare ESXi Hypervisors, Konica Minolta printers, IBM Integrated Management Modules, and Planex Routers deployed by unsuspecting organizations worldwide.

Most vulnerable instances are in the United States, Great Britain, Japan, Germany, Canada, France, Italy, Brazil, the Netherlands, and Spain, owned by several Fortune 1000 companies in technology, telecommunications, healthcare, insurance, finance, hospitality, and transportation.

The SLP vulnerability

Service Location Protocol (SLP) is an old internet protocol created in 1997 for use in local area networks (LAN), enabling easy connection and communication among devices using a system of service availability through UDP and TCP on port 427.

While its intended use was never to be exposed on the public internet, organizations have exposed SLP on tens of thousands of devices over the years.

“Service Location provides a dynamic configuration mechanism for applications in local area networks. It is not a global resolution system for the entire Internet; rather, it is intended to serve enterprise networks with shared services,” reads the protocol’s description.

According to BitSight, all these instances are vulnerable to CVE-2023-29552 (CVSS score: 8.6), which attackers can leverage to launch reflective DoS amplification attacks on targets.

More specifically, the flaw allows unauthenticated attackers to register arbitrary services on the SLP server, manipulating the content and size of its reply to achieve a maximum amplification factor of 2,200x.

This many exposed servers could allow threat actors to conduct massive DDoS attacks on companies, government entities, and critical services to make them unreachable or no longer work as expected.

Due to the critical nature of this flaw, the U.S. Department of Homeland Security’s Cybersecurity and Infrastructure Agency (CISA) has conducted extensive outreach to inform potentially impacted vendors of the vulnerability.

DoS amplification

DoS amplification attacks involve sending a request with the source IP address of the target of the attack to a vulnerable device, letting the size of data amplify within the abused service up to the maximum point, and then releasing the reply to the victim.

Usually, the size of a typical reply packet from an SLP server is between 48 and 350 bytes, so without manipulation, the amplification factor can reach up to 12x.

However, by exploiting CVE-2023-29552, it’s possible to increase the server’s UDP response size by registering new services until the response buffer is full.

By doing this, attackers can achieve a maximum amplification factor of 2,200x, transforming a tiny 29-byte request into a massive 65,000-byte response directed at the target.

“This extremely high amplification factor allows for an under-resourced threat actor to have a significant impact on a targeted network and/or server via a reflective DoS amplification attack,” warns the BitSight report.

In a real attack scenario, a threat actor would leverage multiple SLP instances to launch such an attack, coordinating their responses and overwhelming their targets with massive traffic.

To protect your organization’s assets from potential abuse, SLP should be disabled on systems exposed to the Internet or untrusted networks.

If this is impossible, it is recommended to configure a firewall that filters traffic on UDP and TCP port 427, which is the main entry for the malicious request that exploit SLP services.

VMWare has also published a bulletin on the matter, clarifying that the issue only impacts older ESXi releases that are no longer supported, advising admins to avoid exposing them to untrusted networks.