When CUPS Runneth Over: The Threat of DDoS
Editorial and additional commentary by Tricia Howard
Executive summary
Akamai researchers have confirmed a new attack vector using CUPS that could be leveraged to stage distributed denial-of-service (DDoS) attacks. (CVE-2024-47850)
Research shows that, to begin the attack, the attacking system only needs to send a single packet to a vulnerable and exposed CUPS service with internet connectivity.
The Akamai Security Intelligence and Response Team (SIRT) found that more than 198,000 devices are vulnerable to this attack vector and are accessible on the public internet; roughly 34% of those could be used for DDoS abuse (58,000+).
Of the 58,000+ vulnerable devices, hundreds exhibited an “infinite loop” of requests.
The limited resources required to initiate a successful attack highlights the danger: It would take an attacker mere seconds to co-opt every vulnerable CUPS service currently exposed on the internet and cost the attacker less than a single US cent on modern hyperscaler platforms.
The CVEs
On September 26, 2024, security researcher evilsocket disclosed remote code execution (RCE) vulnerabilities within the Common Unix Printing System (CUPS). In short, an attacker could manipulate Internet Printing Protocol (IPP) URLs remotely to execute malicious commands. This could be done by chaining together four different vulnerabilities.
CVE-2024-47176 in cups-browsed, which coerces a request to an attacker-controlled address
CVE-2024-47076 in libcupsfilters, which does not validate or sanitize data returned from the attacker’s server, and passes it to the rest of the CUPS system
CVE-2024-47175 in libppd, which again involves not sanitizing input, and writing it to a temporary file
CVE-2024-47177 in cups-filters, which allows for an arbitrary command execution
More to the CUPS story
While reviewing the technical write-up about the vulnerabilities, we discovered that another attack vector was not discussed: DDoS. DDoS continues to be a viable attack vector used to harass and disrupt victims across the internet, from major industries and governments to small content creators, online shops, and gamers. Although the original analysis focused on the RCE, which could have a more severe outcome, DDoS amplification is also easily abused in this case.
The problem arises when an attacker sends a crafted packet specifying the address of a target as a printer to be added. For each packet sent, the vulnerable CUPS server will generate a larger and partially attacker-controlled IPP/HTTP request directed at the specified target. As a result, not only is the target affected, but the host of the CUPS server also becomes a victim, as the attack consumes its network bandwidth and CPU resources.
Exploitation
A simple script can be used to send the malicious UDP packet to a vulnerable instance of CUPS. The crafted payload directs CUPS to send an IPP/HTTP request to the target and port specified by the attacker. The vulnerability appears when cups-browsed attempts to fetch the URI specified to download the IPP attributes file.
This PPD file URI is somewhat arbitrary and can be modified by the attacker. In testing, we found this URI payload can be padded out to 989 bytes. This padding will be included twice in the IPP/HTTP request: once in the HTTP headers, and again in the POST data that will be directed at the targeted system.
By using this padding technique, attackers could further exacerbate the impact of CUPS-supported DDoS attacks by consuming additional bandwidth and resources on the targeted networks and systems. Figure 1 is a visual representation of what this would look like.
Fig. 1: Network diagram of attack flow
Attacking system
One of the more troubling facets of this threat is how few resources are needed by the attacker to execute it. Figures 2 and 3 show the attacking system only needs to send a single packet to a vulnerable and exposed CUPS service with internet connectivity to cause the system running CUPS to begin the attack.
./cups.py [CUPS_IP] [TARGET_IP]:1337 attacker_controlled-payload%20goes.here
Sending UDP Payload to target [TARGET_IP] and port 1337
Bytes Sent: 78
Fig. 2: Staging exploit
09:05:03.072432 IP 192.168.12.143.43937 > X.X.X.X.631: UDP, length 78
0x0000: 4500 006a 1991 4000 4011 2ed5 c0a8 0c8f E..j..@.@.......
0x0010: xxxx xxxx aba1 0277 0056 bb25 3020 3000 .......w.V.%0.0.
0x0020: 6874 7470 3a2f 2fxx xxxx 2exx xx2e xxxx http://xxx.xx.xx
0x0030: 2exx xxxx 3a31 3333 372f 7072 696e 7465 .xxx:1337/printe
0x0040: 7273 2f61 7474 6163 6b65 725f 636f 6e74 rs/attacker_cont
0x0050: 726f 6c6c 6564 2d70 6179 6c6f 6164 2532 rolled-payload%2
0x0060: 3067 6f65 732e 6865 7265 0goes.here
Fig. 3: Outgoing UDP packet (modified to be a nonfunctional payload)
Target system
What we end up with is the CUPS service attempting to fetch what it believes to be an IPP attributes file, but is, in reality, whatever the attacker had specified. The target specified in the UDP packet will start to receive incoming TCP connections from the system running CUPS (Figure 4).
Fig. 4: CUPS service establishing a connection to the target
If we look closer at the two received packets that contained the actual request data, we can see the raw IPP request, and the accompanying POST data, partially attacker-controlled, coming from the CUPS service (Figure 5).
Fig. 5: IPP/HTTP request received by the target
We can see from the logs for the cups-browsed daemon that the browsed attempts at fetching the IPP attributes are ultimately what generates these requests directed at the targeted host (Figure 6).
Fig. 6: Cups-browsed logs
Impact and exposure
To ensure a well-rounded analysis, we tested and observed different patterns from machines both in the controlled lab and across the internet. These patterns greatly impact the attack scenarios and amplification factors.
The Akamai SIRT scanned and analyzed the global internet for devices that are vulnerable to this flaw and are accessible on the public internet (198,000+), based on data provided to us from evilsocket. Based on that data, we found that approximately 34% of those devices (58,000+) were vulnerable to this attack.
Additionally, our testing found that some of these active CUPS servers will beacon back repeatedly after receiving the initial requests, with some of them appearing to do it endlessly in response to HTTP/404 responses. Hundreds of these systems in the wild individually established thousands of requests and sent them to our testing systems.
This shows that the potential amplification from this vulnerability is quite large and could cause significant issues for organizations who run these affected servers. We also confirmed through our testing that some of the vulnerable CUPS servers were able to complete Transport Layer Security (TLS) handshakes from our probing attempts against valid HTTPS protected websites. The possibility of affecting TLS also adds more fuel to the fire, as it creates further strain on server hardware and resource consumption overhead due to the handshake and encryption/decryption processing.
Outdated technology strikes again
We should note that many of these identified machines were running on very old versions of CUPS, such as version 1.3, which was initially released in 2007. It isn’t uncommon for some organizations to leave machines running on extremely outdated hardware and software, and it is unlikely that such devices will be updated anytime soon. This presents a prime opportunity for malicious threat actors: They can take advantage of the outdated hardware for DDoS amplification, or (given the RCE in this scenario) build botnets for many purposes, including DDoS.
Amplification estimates
Amplification rates can vary significantly so we have covered both an average scenario and a worst-case scenario to help readers assess the potential threat.
Ultimately, the targeting directive dictates the size of this payload, but for baseline calculations we’ll use a minimum viable UDP packet size of 30 bytes and a maximally padded 1028-byte UDP packet for the worst case. This packet uses the IPP URI directive and fills it with 989 bytes (the maximum found during testing), which is duplicated and included in the resulting attack traffic.
In the worst-case scenario, we observed what appeared to be an endless stream of attempted connections and requests as a result of a single probe. These flows appear to have no end, and will continue until the daemon is killed or restarted. This could be considered an infinite amplification in this scenario. During testing of the 58,000+ responders, a few hundred exhibited this pattern.
Roughly 62% (35,900+) of systems sent at least 10 TCP/IPP/HTTP requests to our target system in response to our UDP packet. Overall, the response rate across the 58,000+ responders (including time-scoped infinite responders) averaged 45 responses, which is what we’ll use to further calculate potential amplification rates.
In the minimum viable probe (30 bytes) scenario, we see that the target machine received a full TCP connection and two packets with payloads. The first packet contains the HTTP request and headers; the second contains the POST data for the request (Figure 7).
Fig. 7: Minimal viable amplification flow
These packets (226 bytes and 174 bytes) total 400 bytes. If we assume that we’ll get these connections and requests 45 times per CUPS reflector, that’s 18,000 bytes of resulting traffic per each 30-byte probe, or roughly a 600x amplification factor on an average attempt.
Lower amplification doesn’t mean lower impact
The worst-case scenario has different results outside of packet size. If we run this same exercise using maximally padded UDP payloads of 1,028 bytes (Figure 8), we see much larger flows directed at the target, but lower amplification.
Fig. 8: Maximally padded attack payloads arriving at the target
In this scenario, our two-packet payload still arrives, but the respective sizes are now 1,217 bytes and 1,164 bytes, totaling 2,381 bytes. Assuming the same average of 45 responses per reflector, we end up with a total of 107,000 bytes of traffic per 1,028-byte probe, and our amplification rate drops to 104x.
Although the amplification rate dropped, the bandwidth consumed on the target network is nearly 6x the minimally viable payload. This would also result in the targeted HTTP server needing to allocate resources for handling and processing these requests. So, although it doesn’t improve amplification rates, this scenario does present a more problematic (and realistic) attack for defenders.
Scaling these possibilities
If we assume all 58,000+ identified CUPS hosts were corralled into the same campaign, it could result in a deluge of 1 GB of incoming attack traffic per UDP packet from the minimally padded example. A maximally padded scenario could result in a 6-GB flood of traffic. Although these bandwidth numbers may not be considered earth-shattering, they would still result in the target’s need to handle roughly 2.6 million TCP connections and HTTP requests in either scenario.
DDoS options in CUPS
Attacks of this nature are part of the troubling trend of an ever-decreasing technical barrier to entry for threat actors to conduct such attacks — directing vulnerable systems across the internet to send sustained floods of traffic to victims. To make matters worse, this can be achieved by sending a single packet to internet-exposed CUPS services. It would take an attacker mere seconds to co-opt every vulnerable CUPS service currently exposed on the internet and cost the attacker less than a single US cent on modern hyperscaler platforms.
As evilsocket’s research pointed out, there are slightly more than 198,000 devices found on the internet that respond back to UDP probes — and of those, the SIRT found that roughly 34% (58,000+) reacted to our UDP probe in a manner that could be easily abused for DDoS.
A remote attacker using a crafted payload could exploit this vulnerability to get the cups-browsed daemon to make outbound TCP connections to a third party. If said target happens to be running an HTTPS server on the targeted port, the server will have to spend cycles and resources trying to parse and handle these requests and data, potentially making the attack even more impactful. In the case of CDNs and caching, it’s unlikely that the URLs being specified in the POST request will exist, resulting in a 404 error that bypasses cache hits and forwards these payloads on to the origin servers.
Based on the research conducted by evilsocket, many distributions and versions of CUPS were impacted. Ultimately, the vulnerability lies in “cups-browsed” packaged with “cups-filters” when receiving a request to add a printer via UDP. There appear to be mitigations from several Linux distributions that bind cups-browsed to localhost or disable cups-browsed from listening entirely.
CUPS vulnerabilities mitigations
The decision to update to the latest version of CUPS or remove it entirely depends on your system's specific needs. If your system relies on printing functionality, updating to the latest version of CUPS ensures improved security, performance, and support for modern devices. However, if printing is unnecessary for your setup, removing CUPS can simplify your system, reduce potential vulnerabilities, and save resources.
Ultimately, this decision should be based on how essential printing capabilities are for your environment and on the importance of maintaining an up-to-date, secure system. At the very least, if removing or updating the CUPS software isn’t viable, defenders should firewall the service ports (UDP/631), especially if they’re accessible from the broader internet.
Threat actors are often quick to leverage newly reported vulnerabilities, with many new releases being exploited within just seven days after initial disclosure. Patching takes time, and hackers are eager to take advantage of that vulnerable transition period. Many organizations also neglect to update some of their older software, which may make it especially lucrative for hackers to jump on the bandwagon of exploiting new vulnerabilities such as this.
DDoS mitigation for victims
For victims of a DDoS attack launched from vulnerable CUPS systems, there are some traits of the traffic to help alert, confirm, and drop attack traffic on the network or at the web application firewall (WAF).
All requests coming from the CUPS service begin with POST /printers/ or POST /classes/ and while the payload after the /printers/ string is attacker controllable, the initial part of the payload is not. Additionally, the CUPS User-Agent strings are very informative and use the format CUPS/[VERSION], as well as a reference to IPP. These are very unique strings in the UA and are not typically observed in organic traffic.
There are also static elements in HTTP headers and POST data. The Content-Type header of application/ipp and payload printer-uri in the POST data are both static values we identified during testing (Figure 9).
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
To aid defenders we’ve also included a Snort rule that should help identify these flows coming into your network over plaintext sockets (Figure 10).
alert http any any -> any any (msg:"CUPS Reflected DDoS IPP Request";
pcre:"/POST \/printers\/|POST \/classes\//"; http_method;
content:"Content-Type: application/ipp"; http_header;
content:"User-Agent: CUPS/"; http_header;
content:"printer-uri"; http_client_body;
metadata:service http;
reference:url,https://akamai.com/blog/security-research/2024/october-cups-ddos-threat;
sid:100004; rev:2;)
Fig. 10: Snort rule for CUPS attack traffic
As mentioned, we found systems in the wild that would complete HTTPS handshakes before delivering their HTTP payloads, so defenders that use HTTPS should consider implementing these matching rules in their WAF configurations rather than on their network monitoring systems.
Conclusion
New DDoS attack vectors are sometimes found, and often quickly abused, by low-skilled opportunistic attackers. This vulnerability in CUPS and the large population of devices that could be abused in this manner lead us to believe that it’s likely that defenders may encounter CUPS-based attacks.
Until messaging and cleanup efforts get traction to reduce the number of devices that are vulnerable and exposed on the internet (currently 58,000+), we suspect this vector will see abuse in the wild. We’re hoping that defenders, network operators, and system administrators will get the message and, for the sake of everyone, handle their respective exposures quickly, or at least be prepared to identify and fend off attackers that may leverage the exposures in the future.
We would like to thank evilsocket (Simone Margaritelli) for his valuable assistance and input. ♥️