My CUPS Runneth Over (with CVEs)

The Common Unix Printing System (CUPS), a standard component in nearly every Unix-like and Linux system, has recently come under scrutiny due to a series of critical vulnerabilities discovered by security researcher Simone Margaritelli. These issues, collectively known as the CUPS vulnerability, expose Linux and Unix environments to potential remote code execution and information disclosure risks.

Designated as CVE-2024-47176,CVE-2024-47076,CVE-2024-47175, and CVE-2024-47177, these vulnerabilities affect various components of the CUPS system, including cups-browsed, libcupsfilters, libppd, and cups-filters. The implications of these vulnerabilities are far-reaching, potentially affecting millions of servers and infrastructure components across the globe.

In this blog post, we will dissect the technical intricacies of the CUPS vulnerability, explore its potential impact on affected systems, and provide detection opportunities and mitigation strategies. Much like the recent RegreSSHion flaw in OpenSSH, this vulnerability highlights the ongoing challenges in maintaining security in complex, widely-deployed software systems.

Let's begin by examining the key points of this vulnerability and then dive deeper into its technical aspects, exploitation mechanics, and the steps defenders can take to protect their systems.

CUPS Vulnerability Overview

Quick Facts

• Vulnerability: Remote Code Execution and Information Disclosure in CUPS (Common Unix Printing System)
• CVE Identifiers:CVE-2024-47176, CVE-2024-47076,CVE-2024-47175,CVE-2024-47177
• CVSS Score: 7.5 (High) according to Red Hat's assessment
• Public Exposure: Over 6 million potentially vulnerable systems identified via ZoomEye
• Affected Components: cups-browsed <= 2.0.1, libcupsfilters <= 2.1b1, libppd <= 2.1b1, cups-filters <= 2.0.1
• Impact: Allows attackers to create remote printers, execute arbitrary code, and potentially leak sensitive system information
• Attack Vectors: UDP port 631 (remotely exploitable) and local network via mDNS/DNS-SD
• Affected Systems: Various Unix-like systems using CUPS for printing, including many Linux distributions, and potentially others
• Complexity: Moderate (requires victim to print to malicious printer for code execution)
• Status: Patches available, but widespread impact due to the ubiquity of CUPS
  

Technical Details

The Vulnerability

The CUPS vulnerability stems from a series of flaws in the CUPS system, particularly in the cups-browsed component. These vulnerabilities arise from improper input validation and unsafe handling of attacker-controlled data. The main issues are:

1. Insufficient validation of printer attributes received from network-advertised printers
2. Unsafe handling of these attributes when generating PostScript Printer Definition (PPD) files
3. Potential for command injection through crafted PPD files

Exploit Mechanics

The exploit leverages these vulnerabilities through the following steps:

1. Entry Points:

• UDP Packet Injection: The attacker sends a specially crafted UDP packet to port 631 on the target system.
• Zeroconf/mDNS Spoofing: Alternatively, an attacker on the local network can spoof zeroconf/mDNS/DNS-SD advertisements.
  

2. Forced Connection:

• Upon receiving the malicious packet, cups-browsed initiates a connection to the attacker-controlled URL.

3. Internet Printing Protocol (IPP) Server Impersonation:

• The attacker sets up a malicious IPP server.
• When the target connects, this server responds to the Get-Printer-Attributes request with carefully crafted printer attributes.

4. Malicious PPD Generation:

• CUPS creates a temporary PPD file based on the received attributes.
• Due to lack of proper sanitization, attacker-controlled data is directly written into this file.

5. Command Injection:

• The exploit injects malicious directives into the PPD file, such as:
  • FoomaticRIPCommandLine: "echo 1 > /tmp/PWNED"
  • cupsFilter2 : "application/pdf application/vnd.cups-postscript 0 foomatic-rip"
• These directives leverage the foomatic-rip filter, which has a history of being exploitable.

6. Execution Trigger:

• The injected commands are executed when a print job is sent to the malicious printer.
• This could be automated or require user interaction, depending on the specific attack scenario.

Exploit Code Snippet

Here's a simplified version of how the exploit payload might be constructed:

ipp:

    printer-name: EVIL_PRINTER

    printer-privacy-policy-uri: |

        https://www.google.com/"

        *FoomaticRIPCommandLine: "echo 1 > /tmp/PWNED"

        *cupsFilter2 : "application/pdf

 application/vnd.cups-postscript 0 foomatic-rip

This YAML configuration for the malicious IPP server demonstrates how seemingly innocuous printer attributes can be weaponized to inject malicious commands.

^{Figure 1: Flow of attack, Splunk 2024. Larger image here.}

The complexity of this attack lies in the chain of vulnerabilities it exploits and the potential for widespread impact due to the ubiquity of CUPS in Unix-like systems. The ability to silently add printers and execute commands when print jobs are processed makes this a particularly insidious vulnerability.

Practical Exploitation

The proof-of-concept exploit available at https://github.com/RickdeJager/cupshax, shared by Rick de Jager, illustrates the potential impact of this vulnerability. To simulate the exploit, we can follow the scenario below:

The attacker sets up a malicious print server:

root@ar-linux-4:/opt# python3 cups.py --ip 10.0.1.21

[+] Starting IPP server on 10.0.1.21:8631...

On the victim machine, the malicious printer becomes visible:

root@ar-linux-4:/opt# lpstat -e

Printer_10_0_1_21

RCE_Printer

When a print job is sent to the malicious printer:

root@ar-linux-4:/opt# echo "Test print job" | lp -d RCE_Printer

request id is RCE_Printer-21 (0 file(s))

The attacker's payload is executed, creating a file in /tmp:

root@ar-linux-4:/opt# ls -lah /tmp/pwn

-rw------- 1 lp lp 0 Sep 26 23:06 /tmp/pwn

Public Exposure

Public release had a pointer to a Shodan query (account required to view) that showed 73,812 results. Since Shodan is now heavily blocked by others, if we look at ZoomEye there is a much larger footprint exposure of 6+ million results.

^{Figure 2: Shodan identification of CUPS}

^{Figure 3: ZoomEye CUPS identification, Splunk 2024}

^{Figure 4: ZoomEye counts of CUPS}

CUPS Logging

CUPS does have logging capabilities on Linux and its many variants. Here's a brief overview:

• Main log file: The primary CUPS log file on Ubuntu is typically located at `/var/log/cups/error_log`.
• Access log: CUPS also maintains an access log, usually found at `/var/log/cups/access_log`.
• Page log: If enabled, CUPS can log individual printed pages in `/var/log/cups/page_log`.
• Log levels: You can configure the verbosity of logging in the CUPS configuration file, usually located at `/etc/cups/cupsd.conf`.
• Viewing logs: You can use standard Linux tools like `cat`, `less`, or `tail` to view these log files. For example:

  sudo tail -f /var/log/cups/error_log

Example of /var/log/cups/access_log:

localhost - - [26/Sep/2024:19:41:25 +0000] "POST / HTTP/1.1" 200 346

Create-Printer-Subscriptions successful-ok

localhost - - [26/Sep/2024:19:41:25 +0000] "POST / HTTP/1.1" 200 173

Create-Printer-Subscriptions successful-ok

localhost - - [26/Sep/2024:19:41:25 +0000] "POST / HTTP/1.1" 200 11553 CUPS-Get-PPDs -

Example of /var/log/cups/Error_log:

tail -n 50 /var/log/cups/error_log

E [26/Sep/2024:19:47:01 +0000] [Client 11] Returning IPP server-error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost:631/printers/TestPrinter_1727380021) from localhost.

Example event when a print job is sent to printer using the /var/log/cups/access_log:

localhost - - [26/Sep/2024:20:26:38 +0000] "POST /printers/Printer_10_0_1_21 HTTP/1.1" 200 482 Create-Job successful-ok

localhost - - [26/Sep/2024:20:26:38 +0000] "POST /printers/Printer_10_0_1_21 HTTP/1.1" 200 256 Send-Document successful-ok

Defending Against and Mitigating the CUPS Vulnerability

Monitoring for the CUPS Vulnerability with Splunk

Effective monitoring and analysis of CUPS activity is important for maintaining operational efficiency and tracking suspicious activity. This section outlines how to ingest CUPS logs into Splunk and leverage this data for security monitoring and troubleshooting.

To capture CUPS logs in Splunk, configure inputs for both error and access logs. Add these stanzas to your inputs.conf file:

# CUPS error_log

[monitor:///var/log/cups/error_log]

sourcetype = cups:error

index = unix

disabled = false

host = cups_serversource = cups_error_log

# CUPS access_log

[monitor:///var/log/cups/access_log]

sourcetype = cups:access

index = unix

disabled = false

host = cups_serversource = cups_access_log

These configurations instruct Splunk to monitor both CUPS error and access logs, assigning appropriate sourcetypes and adding the proper index.

Using the Splunk Add-on for Unix and Linux

To enhance CUPS system identification and monitoring, we recommend leveraging the Splunk Add-on for Unix and Linux. Enable the Unix:Service input:

[script://./bin/service.sh]

disabled = false

interval = 3600

source = Unix:Service

sourcetype = Unix:Service

index=unix

Example event of the Unix:Service sourcetype after being enabled:

Thu Sep 26 08:54:53 PM UTC 2024 type=systemctl UNIT=cups-browsed.service, LOADED=loaded, ACTIVE=active, SUB=running, DESCRIPTION="Make remote CUPS printers available locally"

In addition, we can use the add-on to enable Unix:ListeningPorts with this stanza to identify port 631 in use on *Nix systems:

[script://./bin/openPortsEnhanced.sh]

disabled = false

interval = 3600

source = Unix:ListeningPorts

sourcetype = Unix:ListeningPorts

index=unix

Detecting the CUPS Vulnerability

Analytic Stories from the Splunk Threat Research Team

The Splunk Threat Research Team has developed a collection of Linux analytic stories that align with activity related to post-exploitation behaviors, providing defenders with powerful detection capabilities for Linux environments. Four key stories stand out in this collection:

• Linux Living Off The Land, which focuses on the abuse of native Linux binaries and utilities for malicious purposes
• Linux Privilege Escalation, covering techniques attackers use to elevate their privileges on a system
• Linux Persistence Techniques, addressing methods used to maintain long-term access to compromised systems
• Linux Rootkit, which tackles the challenging task of identifying sophisticated rootkits

These stories encompass a wide range of detection techniques, from anomaly detection to specific Tactics, Techniques, and Procedures (TTPs), all aligned with the MITRE ATT&CK framework. By implementing these analytic stories, organizations can significantly enhance their ability to detect, investigate, and respond to advanced threats targeting their Linux infrastructure across various stages of post-exploitation activity.

Detections from the Splunk Threat Research Team

The Splunk Threat Research Team has also developed several detections Splunk customers can use to help identify potential indicators of a CUPS exploit. To leverage these detections, simply copy and paste the SPL for search provided below into your Splunk Search app. For more information on searching in Splunk, check out our Search Manual.

Network Identify CUPS Port 631

For this query, we are utilizing Sysmon for Linux to collect EventID 3 (network) data. The query is easily modifiable for other endpoint detection and response (EDR) products to identify CUPS listening.

index=unix sourcetype="sysmon:linux" (src_port=631 OR dest_port=631) Image="*cups*" EventID=3

| eval dest_port = coalesce(DestinationPort, dest_port)

| eval Protocol = lower(coalesce(Protocol, protocol, transport))

| where Protocol="udp"|

 stats

     values(Computer) as Hosts,

     dc(Computer) as HostCount,

    values(Image) as Apps,

    values(User) as Users,

    values(SourceIp) as SourceIPs,

    values(DestinationIp) as DestinationIPs    

by dest_port, ProcessId

| sort - HostCount

^{Figure 5: CUPS running on port 631, Splunk 2024}

Identify CUPS Service Running

This analytic is designed to identify and monitor the status of the CUPS browsing service (cups-browsed) across Unix and Linux systems in the environment. The detection provides visibility into the operational state and configuration of the CUPS browsing service.

index=unix sourcetype=Unix:Service UNIT=cups-browsed.service

| stats

    latest(ACTIVE) as ActiveStatus

    latest(LOADED) as LoadedStatus

    latest(SUB) as SubStatus

    latest(DESCRIPTION) as ServiceDescription

    latest(status) as ServiceStatus

    latest(start_mode) as StartMode

    count as EventCount

    by host, UNIT

| rename UNIT as ServiceName

^{Figure 6: Finding CUPS, Splunk 2024}

Find Printers Used with CUPS Access Logs

This detection examines CUPS access logs to identify and monitor printer usage across the environment. It provides visibility into printer activities, including when printers were first seen, how frequently they are used, and what types of actions are performed. This information is crucial for maintaining printer security, detecting potentially unauthorized printers, and monitoring printing activities.

index=unix sourcetype=cups:access 

| rex field=_raw "(?\[(?[^\]]+)\]) \"POST /printers/(?[^ ]+) HTTP"

| rex field=_raw "(?Create-Job|Send-Document) successful"

| eval timestamp=strptime(date, "%d/%b/%Y:%H:%M:%S %z")

| stats

    min(timestamp) as first_seen

    count as event_count

    values(action) as actions

    by printer_name host

| convert ctime(first_seen)

| sort - first_seen

^{Figure 7: Results from CUPS Access Log detection, Splunk 2024}

Identify suspicious printers via CUPS Error logs

This detection examines CUPS error logs to identify suspicious printer activities. It extracts and analyzes key information from print job logs, including renderer commands, printer details, and user actions. The query categorizes renderer commands by potential security risk (Shell, Network, Other) and aggregates comprehensive data for each print job. This allows for detection of anomalies such as unauthorized printers, suspicious commands, or unusual printing patterns that may indicate security threats like data exfiltration or printer-based attacks. The analytic is crucial for maintaining printer security, detecting misconfigurations or compromises, and ensuring printing activities align with organizational security policies.

index=unix sourcetype=cups:error 

| rex field=_raw "\[(?[^\]]+)\] \[Job (?\d+)\] (?.*)"

| rex field=log_message "Starting renderer with command:

\\\\\"(?.*?)\\\\\"" 

| rex field=log_message "Printer make and model: (?.*)"

| rex field=log_message "DEVICE_URI=(?..*?)\""

| rex field=log_message "(?\w+)\.local=(?\d+\.\d+\.\d+\.\d+)"

| rex field=log_message "PPD file: (?.*)"

| rex field=log_message "Queued on \"(?.*?)\" by \"(?.*?)\""

| eval

     command_type=case(

        isnotnull(renderer_command) AND match(renderer_command,

"touch|echo|wget|curl|nc|bash|sh|python|perl"), "Shell",

        isnotnull(renderer_command) AND match(renderer_command, "http|ftp|ssh"), "Network",

        isnotnull(renderer_command), "Other",

        1=1, "No Command"

    )

| stats

    values(renderer_command) as commands,

    values(command_type) as command_types,

    values(printer_model) as models,

    values(printer_name) as printer_names,

    values(printer_ip) as ips,

    values(device_uri) as uris,

    values(ppd_file) as ppd_files,

    values(queue_name) as queue_names,

    values(queued_by) as queued_by_users,

    dc(job_id) as job_count

    by job_id

^{Figure 8: Identifying Suspicious printers in CUPS error logs, Splunk 2024}

Snort Rule Detection from Cisco Talos

Network defenders can leverage signature-based detection for this vulnerability. Cisco Talos has released a Snort rule (SID: 64051) to detect exploitation attempts of the CUPS vulnerability. This Snort rule looks specifically for incoming IPP responses, from an attacker-controlled IPP server, containing two specific printer attributes: "FoomaticRIPCommandLine" and "cupsFilter2". Normally "cupsFilter2" attributes will be filtered out before being saved to a temporary PPD file, but those checks are easily bypassed due to an insufficient strncmp check in the cups-browsed daemon. This provides an additional layer of protection for organizations using Snort in their security infrastructure.

Mitigation Strategies

While patching is the most effective solution, there are several mitigation strategies organizations can employ to reduce their risk exposure to the CUPS vulnerability:

Network-level Mitigation

Block CUPS port (631) using UFW (Uncomplicated Firewall):

sudo ufw enable

sudo ufw deny 631

Server-level Mitigation

Find and remove CUPS packages:

Find CUPS packages

      dpkg -l | grep cups

Remove CUPS packages (example)

      sudo apt-get remove cups cups-daemon cups-core-drivers

Or for a complete removal including configuration files

      sudo apt-get purge cups cups-daemon cups-core-drivers

Remember, these mitigations should be part of a defense-in-depth strategy. No single measure is foolproof, and the most effective protection comes from combining multiple security layers.

Conclusion

The CUPS vulnerability serves as a reminder of the ongoing security challenges in widely-deployed software systems. As with the recent RegreSSHion vulnerability in OpenSSH, it highlights the need for constant vigilance, regular updates, and a multi-layered approach to security.

What stands out in this instance is the remarkable response from the cybersecurity community. Even when the disclosure process wasn't smooth, security researchers, software maintainers, and IT professionals came together to address the vulnerability swiftly and effectively. This collaborative effort underscores the strength and resilience of our industry in the face of complex security challenges.

In order to help reduce the risk of exploitation, organizations should prioritize addressing this vulnerability by implementing the suggested mitigations, including patching, network-level protections, and enhanced monitoring.

Remember: security is an ongoing process. Regularly review and update your security measures to address new threats and vulnerabilities as they emerge. By staying informed, proactive, and collaborative, we can collectively improve the security posture of our systems and networks.

Learn More

You can find the latest content about security analytic stories on research.splunk.com and in the Splunk ES Content Update app.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we'll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Michael Haag and Jose Hernandez for authoring this post, as well as the Splunk Threat Research Team (Lou Stella,Bhavin Patel,Rod Soto, Eric McGinnis, and Patrick Bareiss), Splunk Global Security Operations Team (Pike Reynolds, Deivid Aguero, Marissa Bower, and Richard Marsh), and Cisco Talos (Matthew Mickel and John Levy) for their contributions.

Public link

Please use the above public link if you want to share this noodl on another website.