CVE-2023-29552 Service Location Protocol-Denial of Service Amplification Attack

CVE-2023-29552 Service Location Protocol-Denial of Service Amplification Attack

Author: Marco Lux
Date: 2023-04-25 15:20:55

In 2019 Pedro Umbelino and myself (Marco Lux) figured that we had made attempts to research DoS issues with the Service Location Protocol. Each of us stumbled by accident across that protocol.  Myself during ongoing failures regarding an installation of an HP Printer to the local network and Pedro by skimming through RFCs.

Quickly we found that the results we had are common and decided to correlate the data to publish it in the near future. As it turned out, the near future was several years later. While collecting the evidence in 2023 we recognized the #ESXi attack by a random-ransomware group. We decided it is time to publish our results which cumulated in CVE-2023-29552.

We do pretty much doubt that we are the first constructing lab-wise an attack scenario, concluding that protocol is a valuable asset for an attacker in regard of OSINT and DoS. However, we are the first talking about the latter one.

What is SLP

SLP - which stands for Service Location Protocol - has been instantiated in 1997 and since then enhanced in five additional RFCs. It has two different protocol versions, both have been seen in the wild. There are three different SLP components:


In our scenario we will mostly ignore the ideas of UA,SA and DA. Simply because the overall concepts of UA and SA are close to each other. With the difference that normally SAs should register/deregister services. In essence we will consider mainly User Agents as client(the attacker) and the Directory Agents as the remote server side enabled SLP node.

Having a glance into RFC 2165 from June 1997 the abstract states:

"The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network-based applications.

This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration."

And from the Introduction in the same paper:

"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.  Applications are modeled as clients that need to find servers attached to the enterprise network at a possibly distant location. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services."

Reading this, it instantly reminds services like UPNP, SSDP, MDNS, Directory Services or even DHCP with special options for finding certain devices or services in the network. It becomes clear that the protocol was thought of being an address book for internal services in networks.

Addressing:

The truth however is, that SLP can be found in the internet. Several products are publicly serving SLP using TCP and UDP.

How does the protocol work

Generally speaking, SLP was thought for usage in local area networks, thus one of its main capabilities is communication via multicast. As a result, a node will send regular updates and requests to discover neighbors,de/register them. This information can also be gathered by clients. However, the protocol also supports unicast access, which allows direct communication also outside of the multicast domain.

Taken that into account, a user agent of any type can request a service overview or try to register one if a valid IP address is known. This enables also the communication with SLP daemons over the internet and makes this protocol interesting for abuse.

To identify a remote system running SLP as service it is possible to use an onboard tool of OpenSLP or a published research tool from here us. This tool is interesting, as it also allows threaded scanning if you need to evaluate a bigger region.

./slpscan.py -m svc_req_v2 -l 10.0.0.4 PKT: b'\x02\x01\x00\x00!\x00\x00\x00\x00\x00\x96\xdb\x00\x02en\x00\x00\x00\x00\x00\x07default\x00\x00\x00\x00' Hostmode: 10.0.0.4 Targets: 1 [RAW] ['10.0.0.4:427', "b'\\x02\\x02\\x00\\x00\\x14\\x00\\x00\\x00\\x00\\x00\\x96\\xdb\\x00\\x02en\\x00\\x00\\x00\\x00'"]


The request packet looks like this:


And the corresponding response:

With such a request, it is possible to discover SLP services in the local network, as well as around the world.

How does the attack work

Most attacks in regard of DoS Amplification with UDP protocols work the following way:


To create an amplification attack, the request and the response must differ in size. The smaller the request and the bigger the response, the higher the amplification. Also, those variables, while maybe obvious for most readers, are important for the attacker himself. An attack cost, decreases with smaller request size and raises costs and impact at the victim. 

Using the described default approach, it is possible to gain an amplification factor between 1.6x and 12x times.

./slpload.py -m check -l 10.0.0.4 [+] Sending service type request v2... [+] Data Buffer: b'\x02\n\x00\x000\x00\x00\x00\x00\x00\xeb\xaa\x00\x02en\x00\x00\x00\x1cservice:VMwareInfrastructure' [!] Host: 10.0.0.4 Buffer Size: 48 Ampfactor: 1.6551724137931034


But SLP is special, as it allows an unauthenticated user, to register arbitrary services at the side of the DA. After a successful registration, the new service is announced as well. While this is intended behavior, it suites perfectly for an amplification attack. As we can increase - in the setup phase - the response size dramatically. 

Taking this fact into account the attack scheme for a highly amplified attack with SLP would look like:


One Request (1), several replies (2).

This approach is able to amplify one request up to 2200 times at the response. This renders SLP one of the top attack vectors when it comes to Denial of Service Amplification attacks.

However, it is necessary to note that not every SLP listening service is affected in the same way. During our research we have found different behavior, depending on product, vendor or version. Please take those into account during testing your own:

Practical Attack Example

In recon phase a target needs to be identified. For this a SLP version 2 service type request can be used. This is a normal request and will show all registered services if any available at the remote site. In this particular example the used language is "en" and the scope "DEFAULT".

To register a service the service registration opcode and corresponding fields are used.



Check the size and add data with a normal Service Type Request, here the response:


Send a spoofed packet, to force the daemon sending a response to the victim:


All the steps, besides sending a spoofed packet, can be accomplished by using slpload. Use the options `check`, `load-test` and `one-shot`.

Single load packet stored at remote slpd: python slpload.py -t 2 -l -m one-shot Loop and try to load up the remote slpd until its filled. Use option -m "load-test": python slpload.py -t 2 -l -m load-test -s 1200 -T 1000 Check data stored at remote site, print data and size plus amplification factor: python slpload.py -t 2 -l -m check IPV6 Support: Can you enabled by -6 ./slpload.py -6 -l NOTE: -s Minimum size is 30 bytes, otherwise calculation gets incorrect. This is related to the svc url / svc type fields necessary for registration. Also try to have size ~100 bytes less than the MTU to avoid fragmentation. A safe maximum value is ~1300.


Defense Mechanism

It is our thesis that most systems reachable with SLP are not serving by purpose but mistake. As a result the first step is to disable it. If this is not possible adding a blocking firewall ruleset for tcp/udp at port 427 can be done. Last but not the least, SLP configuration might allow disabling registration of extra services without authentication or signed messages. If all above steps fail and your vendor has no hints - good luck.

Known devices publicly facing SLP

Interestingly, internet search engines like shodan, still missing SLP in their collection, which is a pity. Early numbers in february 2023 showed 54.000 devices. Research of todays device alive revealed that at least 34.000 systems available with SLP and prone to the attack.

Find a table with the known amplification numbers:

Product/Vendor Amplification Factor
Planex Routers 2200x
IBM Integrated Management Module (IMM) 2200x
Konica Minolta printers 1180x
VMWare ESXi hypervisor 300x
SMC IPMI ?
HP Printers ?

Comparing the attack

SLP is far from being alone when it comes to DoS amplification potential in network protocols. However, being quite cost effective abuse and pure amplification factor, it could be arguably the most powerful we know so far. While memcached has also quite an amplification factor (10k-50k), a check at memcached identified systems showed, that most of them do not support UDP anymore. Which renders an abuse not that effective.

Thanks, and Salutes

While this quick post, leaves some spots untouched on purpose, we invite researchers to message us if they need further information or address issues. We are happy to support the research community but won’t spread every detail - protect the innocent.

Tools

slpscan
slpload

References:

CVE-2023-29552
Rossow on Amplification Attacks 2014
RFC2165

Who we are & Disclaimer