The Crime Scene
In April 2023, we conducted an internal infrastructure security assessment for a new client, but through one of our dedicated MSSP partners. We were provided with physical access to their head office, as well as a standard user account to simulate a breach via compromised VPN credentials or an implant on a device.
An additional phase of the project was scoped as a white-box internal infrastructure security assessment, where IP ranges were provided to us ahead of time.
As part of the internal infrastructure phase, we ran an automated scan on the network that we were physically connected to. This was mostly to identify deviations from security best practices pertaining to misconfigurations of various services within the network (disabled SMB signing, self-signed TLS/SSL certificates, etc.). This is all standard practice for a white-box engagement, whereby we need to ensure full coverage in an often limited timeframe.
As we were focusing on other areas of the assessment, one of the client’s staff members approached us with a stack of paper. With a concerned tone, they mentioned that one of their printers was printing arbitrary text on dozens of sheets of papers and asked if we had anything to do with it, or if it was something else that they should be worried about?
Of course we had full logs of our activity and easily (and embarrassingly) made them aware that we were at fault for this incident. Thankfully, the individual we spoke to took it light-heartedly (as did we). But what happened begs the question… what did our scan do exactly which made the printer go crazy?
The Investigation
We were well aware that there were printers in the network, as we had earlier on that day had accessed the printers’ web administration portals and found that they had default credentials. However, to speed up network enumeration on a time-limited engagement, we opted to enable the ‘scan network printers’ option, hoping we would have quick access to vulnerabilities such as default SNMP community strings and other lower risk issues.
These options were included in the “Host Discovery” scan’s configuration, which implied that the paper waste was the result of requests sent by the scanner for the purposes of discovering hosts/services within the target network.
It turns out that the paper waste incident was a known phenomena and it didn’t take long for us to find that many other security professionals had come across this before. In fact, Tenable (the company that developed Nessus) “officially does not recommend” scanning fragile devices, including printers, as doing so leads some printers to behave unexpectedly. Whoops..
There are many network printing protocols out in the wild. However, the culprit that we were looking for was the raw 9100 printing protocol, which has a default TCP port of 9100 (as the name suggests) and is used by the majority of modern printers. Before looking at this protocol, it’s important to understand that sending print jobs to a printer over the network involves multiple layers of technologies where one encapsulates the other (much like SOAP within HTTP). The following image depicts the relationship between these technologies:
The network printing protocols encapsulate the printer languages and handle things like authentication and encryption. The printer languages describe the pages to be printed and/or change the printer settings.
The raw 9100 printing protocol is not a “printing protocol” in and of itself. It’s actually just raw TCP/IP traffic where the encapsulated packet data resembles some printer control language (PCL) or page description language (PDL) directly. In contrast, other protocols such as the Internet Printing Protocol (IPP) carry the PCL/PDL within some structured format (e.g. IPP uses HTTP). The raw 9100 printing protocol is probably the simplest network printing protocol out there, with no care for security at all (no authentication, no encryption, etc.). If you want to send a print job, you can simply netcat to port 9100 and start sending your PostScript commands (although not necessarily PostScript as it depends on what the printer supports).
Looking back at our scan output showed that TCP port 9100 was in fact open on the subject printer. The paper waste from the engagement included papers with HTTP requests in them. Others had unintelligible non-printable characters. Funnily enough, one paper which was emphasised by the staff member just had the word “HELP” at the top. Clearly a form of banner grabbing used by the scanner.
All of these pieces together indicated that the paper waste was the result of the scanner attempting to determine what service was running on the port by probing it with requests for a number of protocols hoping that the service listening on the port would return a banner or some other response to it’s request. This behaviour is defined in the Service Detection plugin (22964 – find_service.nasl) and is controlled with the following Nessus scan configuration option in the “Service Discovery” section (enabled by default):
Running a Nessus scan against a local netcat listener confirmed this:
With the above in mind, it seems that the printer’s listener on TCP/9100 simply prints any TCP data it receives – if it doesn’t resemble whatever PCL/PDL it understands. In other words, it’s more of an implementation issue rather than a protocol issue which (strangely) is quite common according to the number of accounts that we came across which mentioned this.
Printer Hacking in the Wild
In terms of impact, how bad is it that implementations similar to this are in use? As long as the printers are in an internal network and are not exposed to the internet, it’s not that big of a deal. The worst that could happen is a bit of trolling, and perhaps a case can be made that allowing a malicious actor to submit print jobs to an internal printer can be used for phishing purposes. Or even financial loss through impact to ink finances 🤡.
Paper waste aside, printers, just like any other device, can suffer from other more serious vulnerabilities that can have a detrimental impact if exploited. These include accessing print jobs (information disclosure) and remote code execution. The amazing Wiki dubbed “Hacking Printers” highlights several examples of these.
Querying Shodan does show that there are quite a few internet-facing printers which goes to show that exposing printers to the internet is not as unrealistic as one may think.
Conclusion
This incident serves as a reminder that we all fault at one time or the other. However, it is important to reflect on our mistakes and take lessons from them, be it technical lessons or otherwise. In our case, we learnt a little about how printers operate, were reminded to RTFM (read the friendly manual) and that the checkbox mentioned earlier under the “Fragile Devices” section was disabled by default for a reason.. ¯\_ (ツ)_/¯
