[New Rules] CVE-2024-x.x.x.x.x (CUPS/Foomatic-RIP RCE)

Summary

A set of vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177) allows remote unauthenticated attackers to achieve remote code execution (RCE) by sending UDP packets to port 631 or through local network-based attacks, such as spoofing mDNS or DNS-SD advertisements. These flaws affect components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, enabling attackers to replace or install malicious printer configurations, which could lead to arbitrary command execution when a print job is started. The detection rules aim to identify suspicious IPP requests and command execution attempts to mitigate the risk of exploitation from these vulnerabilities.

Detections

This PR adds 5 new detection rules, all focusing on different behaviors that are part of the attack chain:

Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d
Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309
Network Connection by Cups Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab
File Creation by Cups Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4
Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4

Cupsd or Foomatic-rip Shell Execution

This rule detects shell executions from the foomatic-rip parent process. This detection rule detects all 33 attempts that we ran with the POC.

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.parent.name == "foomatic-rip" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
not process.command_line like ("*/tmp/foomatic-*", "*-sDEVICE=ps2write*")

Printer User (lp) Shell Execution

This rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). This query is broader, but will only work when your Cups/foomatic-rip processes run as the lp-user. You can alter this query to a different user.name if this is different in your environment.

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and user.name == "lp" and
process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
not process.command_line like ("*/tmp/foomatic-*", "*-sDEVICE=ps2write*")

Network Connection by Cups Foomatic-rip Child

This rule detects network connections initiated by a child processes of foomatic-rip. This should be suspicious. If these services do communicate in your environment, make sure to whitelist destination IP's.

sequence by host.id with maxspan=10s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.parent.name == "foomatic-rip" and
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted"] by process.parent.entity_id

File Creation by Cups Foomatic-rip Child

This rule detects suspicious file creation events executed by child processes of foomatic-rip. The default PoCs test by writing a file to /tmp/, which would be detected through this rule. Additionally, if the attacker were to download a stage and execute it manually afterwards, this rule would detect the file creation event.

This rule excludes /tmp/gs_*, because this is the default pattern. If you want to be more secure, remove the white listing. It will become noisier though.

sequence by host.id with maxspan=10s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.parent.name == "foomatic-rip" and
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id
  [file where host.os.type == "linux" and event.type != "deletion" and
   not (process.name == "gs" and file.path like "/tmp/gs_*")] by process.parent.entity_id

Suspicious Execution from Foomatic-rip or Cupsd Parent

This rule detects suspicious process command lines executed by child processes of foomatic-rip and cupsd. The command lines focus on persistence, file downloading, encoding/decoding activity, reverse shells, shared-object loading through GTFOBins and more.

process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like (
  // persistence
  "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/sudoers*",
  "*/etc/profile*", "*autostart*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*udev*",
  "*/etc/shadow*", "*/etc/passwd*",

  // Downloads
  "*curl*", "*wget*",

  // encoding and decoding
  "*base64 *", "*base32 *", "*xxd *", "*openssl*",

  // reverse connections
  "*GS_ARGS=*", "*/dev/tcp*", "*/dev/udp/*", "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*",
  "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*", "*disown*", "*nohup*",

  // SO loads
  "*openssl*-engine*.so*", "*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*", "*Fiddle.dlopen*.so*",
  "*cdll.LoadLibrary*.so*",

  // misc. suspicious command lines
   "*/etc/ld.so*", "*/dev/shm/*", "*/var/tmp*", "*echo*", "*>>*", "*|*"
)

References

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

[ ] Detailed description of the rule.
[ ] List any new fields required in ECS/data sources.
[ ] Link related issues or PRs.
[ ] Include references.

Rule Metadata Checks

[ ] creation_date matches the date of creation PR initially merged.
[ ] min_stack_version should support the widest stack versions.
[ ] name and description should be descriptive and not include typos.
[ ] query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
[ ] min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
[ ] index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
[ ] integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
[ ] setup should include the necessary steps to configure the integration.
[ ] note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
[ ] tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
[ ] threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

[ ] building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
[ ] bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

[ ] Provide evidence of testing and detecting the expected threat.
[ ] Check for existence of coverage to prevent duplication.

elastic / detection-rules