10.04.24

CUPS Exploitation – “I got my ticket for the long way ’round (your Linux machines)”

By Ben Nichols, Threat Detection Researcher

Estimated Reading Time: 7 minutes

At 4 PM EST on September 26th, 2024, Simone Margaritelli, a security researcher, disclosed the technical details of four vulnerabilities affecting the CUPS (Common UNIX Printing System) project. When chained together, these vulnerabilities had the potential for Remote Code Execution (RCE) on vulnerable systems. While this exploit chain was not quite the end of the world, single-click RCE as it first seemed, it does represent an interesting vector for RCE on Linux/Unix-based systems running the vulnerable version of the software. This article will serve as a brief technical overview of the POC from a detection perspective as there has yet to be a significant amount of coverage on the matter from a blue team perspective.

The below vulnerabilities and descriptions are shown in the researcher’s blog post:

  • CVE-2024-47176 | cups-browsed <= 2.0.1 binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker controlled URL.
  • CVE-2024-47076 | libcupsfilters <= 2.1b1 cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker controlled data to the rest of the CUPS system.
  • CVE-2024-47175 | libppd <= 2.1b1 ppdCreatePPDFromIPP2 does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker controlled data in the resulting PPD.
  • CVE-2024-47177 | cups-filters <= 2.0.1 foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter.

Frequently Asked Questions

  1. “Am I at risk?”
    1. All three targeting requirements below must be fulfilled for you to be exploited:
      1. You are running vulnerable versions of the software and are not patched.
      2. You allow either mDNS/DNS-SD or you have 631/UDP allowed by the network/host firewalls on internal systems (or even worse, systems exposed to the internet).
      3. A user is tricked or convinced into sending a print job to the malicious printer.
  2. “How can I detect if it was exploited?”
    1. RCE is a funny topic because regardless of the specific CVE/entry-vector, a command is typically run as a result and these commands usually follow common trends we see time and time again, which feed Deepwatch’s detection engine:
      1. whoami
      2. curl/wget tool ingress
      3. Base64 encoded commands
    2. Outside of process execution on vulnerable hosts, there is also the potential to implement Snort/Suricata (IDS) rules to catch suspicious mDNS or UDP traffic related to exploit as neither vector is encrypted over the wire.
    3. While organizations using CUPS may have lots of internal traffic (mDNS and 631/UDP) in most cases, you can easily spot check firewall logs for any allowed traffic to 631/UDP from external sources. This should not have a legitimate business use case in most scenarios, especially when directed at a CUPS service actually listening on 631/UDP.
    4. You can check logs in /var/log/cups/ for unexpected errors indicating commands run, printers contacted, etc (shown below in Figure 12).
  3. “What can I do to protect myself”
    1. This comes back to the age-old recommendation of least privilege and attack surface reduction. Whether your hosts are internet-facing or internal, removing unnecessary software and enforcing strong firewall rules both between network segments and on host-based firewalls is always your best bet in addition to patching. Regardless of which service has an RCE-capable vulnerability, preventing it is easy when you enforce strong segmentation and access control as low as possible on the OSI model. Don’t need 631/UDP open? Block it and that is no longer a viable entry vector (same with mDNS).
    2. The second core recommendation here is visibility. For Linux/Unix hosts, either run EDR software or ingest Auditd logs into a SIEM to monitor for suspicious process execution, etc. If you can’t do this across the board, use a vulnerability scanner (network or agent-based) and prioritize hosts with the most risk, business criticality, or attractiveness to a threat actor.
    3. The third recommendation relates specifically to Linux. There are options for hardening Linux machines such as SELinux or Ubuntu AppArmor. AppArmor or its alternatives are great options for establishing “firewalls” around a process such as a web server (or CUPS) to allow it to access and execute what is needed but block access to everything else that it may try to access if compromised via an RCE-capable vulnerability. An example of this would be a vulnerable web server being exploited to run a curl download cradle to install a backdoor. If AppArmor was set up, curl would likely be outside the scope of the allowed profile and the attempt would be both blocked and logged for investigation (preventing further actions on the host, lateral movement, etc).

POC & Detection Analysis

Figure 1: A vulnerable system is prepared. Wireshark is running to provide network insight into the attack, the baseline for the /tmp directory is shown, and a sample file to print is open
Figure 2: The print pane is empty/default on our victim system
Figure 3: The “adversary” who has access to a machine on the local network executes the POC (mDNS version) on their system. This broadcasts the malicious printer to all hosts within the broadcast domain. This can spoof a real printer name or can be accompanied by an email socially engineering victims to print to the malicious printer
Figure 4: Wireshark capture showing the malicious mDNS broadcast containing the malicious printer’s information
Figure 5: The malicious printer appears in the print pane of the victim without any actions by the victim user, from here the print button is clicked to send the print job and execute the malicious payload specified in Figure 3
Figure 6: Network view of the IPP traffic sent from the victim to the attacker machine when the “print” button is clicked
Figure 7: Network view of the malicious command/payload contained within the IPP response. This highlighted packet is showing the malicious printer sending the command parameters to the victim that will be executed as part of the print process. It should be noted that the variation of the POC using 631/UDP direct targeting leverages https://github[.]com/h2g2bob/ipp-server and malicious IPP traffic will contain the string “h2g2bob”
Figure 8: Investigating the /tmp directory again on the victim machine shows two new files, one of which is the output of the malicious payload command
Figure 9: Checking the contents of the output file shows the result of the “whoami” command (the user the vulnerable service was running in the context of)
Figure 10: View of the malicious process tree in a Crowdstrike detection
Figure 11: View of the above Crowdstrike detection in the detections pane
Figure 12: Manual review of the /var/log/ directory for artifacts of the exploitation. These entries show both the malicious printer being contacted and the malicious base64 encoded command that was executed

alert tcp any any -> any any (msg:”Detected TCP Traffic with h2g2bob string, used in CUPS exploitation”; content:”h2g2bob”;nocase;sid:01; rev:1;)

alert tcp any any -> any any (msg:”Detected TCP traffic with FoomaticRIPCommandLine Specified, used in CUPS exploitation”; content:”foomaticripcommandline”;nocase; sid:02; rev:1;)

Figure 13: Validation of above Suricata/Snort (IDS) signatures on both direct 631/UDP exploit and mDNS PCAP’s

Hunting Guidance

  1. Anomalous inbound 631/UDP traffic, especially from the internet to known-vulnerable CUPS services
  2. Anomalous mDNS broadcasts advertising printers on the local network (Figure 4)
  3. Anomalous outbound IPP traffic (printing) to anomalous addresses or addresses matching the above two items
  4. Rare child processes of foomatic-rip
  5. Rare entries in /var/log/cups/ showing unauthorized printers or commands being run
  6. IPP traffic being sent over unexpected ports. Both POC’s hosted the IPP endpoint on ports other than 631/TCP. This is visible in the Suricata output above, showing the IPP server being hosted on 12345/TCP for the direct version and 8631/TCP on the mDNS version
  7. Results for IDS signatures shown above (these may need to be tuned depending on the environment baseline)
  8. Rare/anomalous .PPD file presence or creation in /etc/cups/ppd/ (shown in Figure 12)

Resources

https://github.com/RickdeJager/cupshax/blob/main/cupshax.py

https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I

Ben Nichols, Threat Detection Researcher

Ben started his career as an analyst before moving into the Cyber Intelligence and Research realm where he has performed hands-on simulations and research for cutting-edge threats to bolster coverage and uncover emerging patterns in the cyber threat landscape. Since 2022 he has been working in threat research to better understand the most urgent threats facing organizations and ways to identify and counter them. Most passionate about “playing in the dirt” and obtaining organic data from adversary tools and infrastructure, his organic research engagements have helped surface previously unknown threats and methods of detecting them in the enterprise.

Read Posts

↑

Share

LinkedIn Twitter YouTube

Subscribe to the Deepwatch Insights Blog