Detecting cups vulnerabilities while staying ethical

Written on 2024/09/27

As you have probably seen by now @evilsocket published an amazin blog on vulnerabilities in CUPS.

If you’ve been staying away from Infosec socials, and frankly who can you blame you for that, then the issue is as follows :

• the default configuration of the CUPS printing susbsystem on Linux includes cups-browsed
• this service listens on UDP/631 on all interfaces and by default accepts connections from anywhere
• sending a UDP payload can trigger an IPP query to an attacker controller URI
• CUPS then creates a new printer based on the malicious configuration file sent by the attacker
• when the user prints to that printer it triggers specific filters in the configuration resulting in arbitrary remote code execution

At ONYPHE we’re always seeking to add detection for the most critical vulnerabilities to our product so our customers get defensive capabilities for the threats that really matter.

Just scan for UDP/631

On a first quick reading of the vulnerability write-up this looks like an easy win. We just need to:

• scan for UDP port 631
• parse the response of the service
• go & eat a kouign-amman

However looking at this more closely, and examining the payloads the researcher used when scanning the IPv4 space, we remembered that the cups-browsed service does not respond directly to the initial UDP packet, but instead triggers an outgoing HTTP connection on whatever TCP port the evil printer specifies.

The way the researcher and other organisations have handled this is to set up a listener on an arbitrary TCP port and catch the incoming HTTP connections from the cups-browsed processes. Our in-house scanning technology can handle this, and historically we’ve done some targeted scans in exactly that way. But just because we can do something doesn’t mean we should do it.

We are here to help and not hinder cyber-defenders

What’s the big deal with making an outgoing HTTP connection?

When we scan the Internet we distinguish between normal in-protocol communication, and exploiting a vulnerability leading to secondary communications. If we’re discussing with an DNS server over UDP, then we get DNS answers back as defined by the RFC

However triggering an outgoing connection from someone else’s server to a third-party service is not defined in any RFC. It will potentially trigger SOC alerts, fill-up internal firewall logs, make life harder for someone investigating an incident, and it’s probably illegal.

In France, as in many other countries, initiating an outgoing network connection from someone else’s computer to a third-party service they know nothing about, crosses the line from reasonably-accessing-a-service-published-on-the-Internet to a network intrusion.

It’s just like log4shell

Indeed, we stopped scanning for vulnerable log4j systems following friendly discussions with CERT/CSIRT teams and we never peformed 0.0.0.0/0 scans for log4shell, which leads to the second problem.

At ONYPHE we always perform targeted scanning for vulnerabilities. We first of all identify technologies or protocols affected by a vulnerability and then we only scan the relevant IPs and ports.

With this vulnerability the CUPS UDP port won’t respond to us at all, so we can’t even identify the IP addresses that might be vulnerable before we start sending payloads. We won’t scan billions of IP addresses in the hope of triggering a vulnerability in a few hundred thousand of them.

We can and do identify CUPS on TCP

We identify CUPS running on TCP/631, or other non-standard ports https://www.onyphe.io/search?q=category%3Adatascan+product%3ACUPS+productvendor%3ACUPS so our customers can identify systems which might also have their UDP/631 port exposed to the Internet.

Isn’t it justified to intrude on these systems to protect them?

Our vulnerability scan policy sets out a number of principals we use to decide on whether to add a vulnerability detection to our system.

These vulnerabilities are very serious, but if attackers use CVE-2024-47176 combined with CVE-2024-47177 as described in the blog post, then in order to trigger the remote code execution, a user has to print to the new random printer that has appeared on their system. Hardly an industrialised attack scenario.

No doubt a clever attack could create realistic looking printer names, but it doesn’t seem possible to change the default printer using an mDNS UDP broadcast.

So until someone finds a straight up buffer-overflow RCE in CUPS (which could well happen in the coming days as all eyes turn to that codebase), we don’t think mass exploitation is likely.