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? 

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.
