Is Your Printer a Network Security Risk?

There’s an old adage that goes: On the Internet, no one knows you’re a dog. This has been rendered in terms of the dating pool, products being sold and any number of other things. In no case is it truer than in the hacker’s mind.

You see, the average hacker is only looking for a place from which to launch attacks, store warez (pirated software) and play games. It doesn’t matter to them if you see an IP address and think networked printer. They see ram and disk space. They don’t care if it’s a printer or a garage door opener. If it’s running Windows, it’s definitely fresh meat. It only gets better when it’s your grandmother’s Windows 98 machine that she leaves online over her dialup modem every night when she falls asleep in front of CSI:Sheboygan. (I know you’ve always wondered why her phone was busy at the oddest times.)

In the last several months, I’ve seen several different types of appliances compromised. I have been asked to evaluate the security aspects of some Internet-capable devices and to help devise solutions to their security issues.

Most of you are familiar with networked printers. They allow you to connect to them using TCP/IP so that many people can share one centralized printer, saving money, space and supplies. There also are networked thermostats, networked door controllers and other networked devices. Most run some form of underlying Windows operating system. Occasionally, I work with companies using proprietary operating systems in their components.

One printer manufacturer, which enjoys a majority of the business market, sells networked printers that run on Windows NT. In and of itself, this is problematic, but when was the last time you saw an NT machine capable of auto-updates for OS security patches? For that matter when was the last time Microsoft delivered a patch for NT? The problem isn’t so much when the patches are released, as when the owner of the printer rolls a monitor and keyboard over to the printer and plugs in to download and install the patches.

If it looks like a printer, acts like a printer and sounds like a printer, why should anyone think of it as a computer?

Unfortunately, on the Internet, it just looks, acts and sounds like an unprotected NT system with default passwords. Oh, right &#151 actually, it doesn’t have a password at all.

The hacker in me is happy to upload my little FTP server with all my zipped warez files for my pals to trade around. Or I might load a little IRC chat bot that I can use to control other machines, which would let me, for example, launch distributed denial-of-service attacks. When they trace the attack back, it points to a printer, owned by a group of people who have no idea what a bot is.

And to boot, the little bit of memory legitimate users have and need for their Web page and documents have won’t be adversely affected by my operations.

Other products secure network devices boast via proprietary operating systems. But a proprietary operating system offers little more protection. It only makes it more difficult to break into if the proper authentication procedures are set. If the vendor only supports unencrypted telnet or HTTP (and not HTTPS) then it doesn’t matter. A little brute force dictionary attack of the root/login password and the system is there for the taking. This is of course, assuming there was a password to brute force in the first place.

Don’t Make it Too Easy

Up to this point, we’ve been assuming the hacker is remote to the network the appliance or printer resides on. If the intruder is physically proximate, and can sniff the traffic on the wire, it’s a different game altogether. The attacker then simply needs to copy enough traffic to recover the passwords, since HTTP and telnet send their passwords in the clear (as does FTP).

One vendor suggested that rather than build an SSL component or an SSH daemon to go with their proprietary operating system, they could use a form of ‘light encryption’ to protect the data while in transmission. On the surface, this sounds like a reasonable alternative, except if you have an attacker motivated enough to sift through copied traffic to recover your passwords and gain control of your system. Then offering up the additional challenge of cracking your encryption algorithm is just making the game that much more exciting. Not only that but you’ve given him all of your systems up front.

The hazard of the proprietary operating system is that it lends a sense of security through obscurity.

If no one knows how our operating system works, then it can’t be used for bad behavior. But the operating system still must be integrated into the larger networked world using well-defined traffic protocols. If those protocols aren’t secure, or the passwords aren’t well chosen, the propriety operating system looks just like every other piece of low-hanging fruit on the Internet waiting to be exploited.

Proprietary operating systems have another disadvantage, as well. In open source operating systems, there is a community of developers who work on projects that benefit everyone in the community. For example, an SSH daemon only has to be built once. (In reality it will be built several times to provide particular features or security measures that one group might wish to enhance more than a different set.) Once the particular protocol has been built, it’s available to everyone who uses that particular operating system.

On the other hand, a propriety operating system has to have all the protocols written by those who have the source code and know how it works. This can be an enormous financial burden for the owner of the operating system. If you happen to be Bill Gates, you can throw your money away on bad implementations before you get it right. If you’re a little guy, you can’t afford to get it wrong, because, really, you can’t afford to have to write the protocol in the first place.

Adapted from esecurityplanet.com.