Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
23  
You'd be surprised how much fun you can have with printers and photocopiers ;) –  Polynomial Nov 6 '12 at 16:29
29  
If you want a step by step tutorial, defer to the movie Office Space. –  Moses Nov 6 '12 at 17:01
3  
It might help with answers if you tell us why it needs to be accessible from outside (e.g. remote admin? automatic consumable ordering? remote printing?) –  Graham Hill Nov 6 '12 at 17:04
12  
Also be aware that most printers/copiers/scanner these days store images of what was printed/copied/scanned within printer memory. And since your printer is accessible outside of your network.... I'm sure you can see where this is going. –  k1DBLITZ Nov 6 '12 at 17:43
2  
@Moses I thought that this post was about Office Space when I read it :) –  Tobi Lehman Nov 6 '12 at 23:12

8 Answers 8

up vote 128 down vote accepted

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 plaintext, 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 setttings, 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 recognise 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.

share|improve this answer
8  
Very comprehensive answer. I'll read this carefully and see what's possible on my side. I like the fact that these are possibly using very old kernels with enough security holes to give remote privilege escalation and easily launch a tunneling attack. –  hsnm Nov 6 '12 at 17:09
1  
@mikebabcock the problem is to identify which is legitimate traffic? –  hsnm Nov 7 '12 at 14:23
2  
@hsnm Not too difficult for obvious stuff - should your printer be allowed to initiate outgoing TCP connections? Should your printer be allowed to perform DNS queries? Do you really need to allow UPnP and SNMP traffic to reach it? –  Polynomial Nov 7 '12 at 14:39
2  
@hsnm as polynomial implies, the best policy is often to allow in bound 515/9100 for printing, and no connections initiated by the printer at all. This prevents a rooted printer from being used to attack other devices, even if it doesn't prevent rooting the printer. –  mikebabcock Nov 7 '12 at 23:34
5  
I feel like throwing my printer out of the window after reading this. –  Herr K Nov 8 '12 at 17:33

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.

share|improve this answer
1  
This applies to print servers too, which have a habit of being web-accessible. –  Polynomial Nov 7 '12 at 12:28

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...

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
Thanks for the answer. What you describe is good for an attacker who wants to misuse the printer itself. I'm in particular interested to see how an attacker can use the printer as a hop to attack other machines. This is very important at this point. –  hsnm Nov 6 '12 at 16:44

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.

share|improve this answer

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.

share|improve this answer
    
true.. but additional cost and maintenance overhead. –  hsnm Nov 6 '12 at 23:04
1  
Agreed, but for most companies it would be prudent and reasonably feasible to introduce that measure. –  scuzzy-delta Nov 6 '12 at 23:46
    
Alternatively, whitelist the IP netblock of the manufacturer and firewall the rest off. –  Polynomial Nov 7 '12 at 12:29
    
@Polynomial I feel like even if the printer is not accessible outside the network, it's still an attack vector on the network. It could enable more opportunities if you launch a multi-hop attack by going through the printer. For example, an attacker can bring in a laptop and connect to the wireless network (if there is any) and then get to other places through the printer. –  hsnm Nov 9 '12 at 2:00
    
@hsnm True, but printers are essential to most businesses. –  Polynomial Nov 9 '12 at 6:56

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)
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.