Attacking an office printer?

Question

I did an nmap scan on an advanced office printer that has a domain name and is accessible from outside the corporate network. Surprisingly I found many open ports like http:80, https:443, and svrloc:427 and some others. The OS fingerprint says somewhere: "...x86_64-unknown-linux-gnu...", which may indicate that this is some sort of an embedded Linux running some server software for the printer's functionality.

How can I know whether this printer is increasing the attack surface on the network? For example, can it be exploited through a remote privilege escalation vul. and then launch a tunneling attack on other hosts in the network?

Answer 1

You can have some serious fun playing with printers, photocopiers and other such devices - even UPSes. Security is usually an afterthought at best, if not totally absent.

Stuff I've seen:

• Default credentials used everywhere, and web-based config panels storing passwords in plain-text, often within a generated config file. I've never seen anything better than plain MD5 on passwords, and in one case I saw CRC32.
• Document names and usernames leaked via SNMP, usually via open read access to the device and over SNMPv1/2 where no transport security is used.
• Default or hilariously weak SNMP private namespace names (usually "private", "SNMP" or the manufacturer name), allowing you to reconfigure TCP/IP settings, inject entries into the routing table, etc. remotely, and there are often ways to alter settings that can't be set in the control panel. It's pretty trivial to soft-brick the device.
• UPnP enabled on the device in default setup, allowing for more remote configuration fun. Often you can print test pages, hard-reset the device, reset web-panel credentials, etc. Again it's usually possible to modify TCP/IP settings and other networking properties.
• Very outdated 2.2.x and 2.4.x kernels, often with lots of nice root privilege escalation holes.
• Badly written firmware upgrade scripts on the system, allowing you to flash arbitrary firmware to internal microcontrollers. You could use this to brick the device, or install a rootkit if you're willing to spend a lot of time developing it.
• Custom or old SMB daemons, often vulnerable to RCE. Easy to pwn remotely.
• Services running as root, user groups set up incorrectly, file permissions improperly set.
• Printing jobs ran asynchronously by executing shell scripts, making it easy to escalate your privileges up to that of the daemon (often root).
• Poorly written FTP servers built into the device. I'd bet good money that a fuzzer could crash most of those FTP daemons.
• All of the usual webapp fails, but especially file upload vulnerabilities.

Here's where things get extra fun. Once you've pwned the printer, you can usually get hold of usernames and other juicy information from SMB handshakes. You'll also often find that the password to the printer's web control panel is re-used for other network credentials.

At the end of the day, though, the printer is an internal machine on the network. This means that you can use it to tunnel attacks to other machines on the network. On several occasions I've managed to get gcc and nmap onto a photocopier, which I then used as a base of operations.

What's the solution? First, you need to recognize that printers and photocopiers are usually fully-fledged computers, often running embedded Linux on an ARM processor. Second, you need to lock them down:

• Update the firmware of the device to the latest version.
• Firewall the printer off from the internet. This should be obvious, but it's often missed. TCP/IP-based printers / photocopiers usually bind to 0.0.0.0, so they can quite easily sneak onto the WAN.
• If you can make the printer listen only to traffic from the LAN, do so.
• Change the default credentials on the web control panel. Again, obvious, but still not done very often.
• Find any services running on the device and attempt to break into them yourself. Once you're in, change passwords and turn off what's unnecessary.
• Get yourself an SNMP discovery tool and dig around what's available for your printer. SNMP has a bit of a learning curve, but it's worth taking a look.
• If you do internal network monitoring, set up a rule to watch for anything unusual coming out of the printer. This cuts false positives right down and gives you a good indication of when something dodgy is happening.

All in all, if it's a device plugged into your network it is probably pwnable, and should be part of your risk management.

Answer 2

The major issue here is that your printer is accessible from outside your network. I've never seen a situation where printers need to be accessible from outside a network, and I mean ever! I suggest you get that fixed, and urgently!

There's more to printers than most people realize, but the risks can be managed by keeping them updated, turning off options that are insecure like http, and changing the admin passwords.

Answer 3

Often printers maintain logs of printed documents, sometimes containing copies of the documents themselves being able to be downloaded remotely. Even if the documents themselves aren't sensitive metadata can sometimes leak information like the file server name, the computer it was sent from, username...

Answer 4

Generally printers are the unseen and unmitigated risk in a lot of networks. We tend to not think of them as computers, but the fact is almost any modern network printer has a fairly elaborate print server in it, often running some form of embedded linux, and far to often with very little thought given to security. Since they have a full blown micro-controller in them, it is theoretically possible that just about any attack that could be done with a computer or open network jack on your network could also be done from the printer.

In approaching a printer directly connected to the web, I would first ask why it needs to live there instead of going through some other type of print service to request documents be queued to it. If there is a compelling reason for it to live on the outside of your network, is there a reason it needs to be allowed inside? If it's available to the internet, internal users could connect to it via the internet just as someone outside the network could. This could provide some isolation as well.

Answer 5

It is an attack point, so yes, it increases the attack surface of your network. That point could be used to get to another internal web page. Maybe your printer has network credentials that you could steal or replay, etc.

A simple attack on a printer is to change its configuration to save documents both printed or scanned/faxed locally and retreive them later. The printer in itself is irrelevant, it is the data it gives you access to that matters.

Chances are the HTTP(S) ports will give you a web page with a VNC window implemented as a Java applet (our Lexmark printer does that). Even if the physical printer requires us to present our access badge, a VNC connexion will hijack the "session" of someone who is locally at the printer, credentials and all.

What you can do really depends on the printer type and how persistent is the attack.

Answer 6

This is a unique physical implication of a printer being compromised:

http://it.slashdot.org/story/11/11/29/1752231/printers-could-be-the-next-attack-vector

I've used Nessus and found that even printers with the most basic features that you'll find on home networks have vulns like default credentials and open ports galore.

Answer 7

Seems odd and you might have a case for it, but it's rare to have a business need to keep a printer accessible outside the firewall AND the VPN. Now I'm generalizing but with an "advance" printer:

• Bear in mind that a "Secure printer" doesn't increase sales. There is likely very little engineering effort in securing the printer to begin with.
• Due to above, the software and kernel are likely to be older. i.e. their security vulnerabilities are already known and published
• Don't think of it as a 'printer' it's essentially a server running Linux. Linux you can't patch or harden easily
• It is essentially a great launching point for more sophisticated attacks since this situation most likely breaks many security assumptions made in architecting the security policy (eg: FTP password ok since no malicious network sniffers). Faking DNS => MITM => tunneling SSL traffic outside.
• If it happens to be a scanner many devices cache scanned documents in the temp folder (similarly with in-device printer queues)

Answer 8

I'd like to mention a different aspect of this - many copier/device manufacturers will ask that they can access the device remotely as part of their support contact. That surely leads to some companies allowing access directly to the device.

A better solution is to allow external support staff to only connect to a bastion host, and connect to the copier/device from there.