Is Your Printer a Network Security Risk?

eSecurityPlanet columnist Linda Leblanc says appliances are easily compromised. These small holes can cause major problems.
Posted September 12, 2005

Linda LeBlanc

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 more true than in the hacker's mind.

You see, the average hacker is only looking for a place from which to launch attacks, store warez, 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 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 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 unpatched NT system with default passwords. Oh, right... actually, there's no 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, so I can, for instance, 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 needed for the Webpage and documents legitimate users have won't be adversely affected by my operations.

Other products boast proprietary operating systems as a means of securing the networked device. 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.

Ease-of-use for the consumer, means ease-of-use for all consumers.

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.

(I'm thinking here that if you're not willing to invest in building an ssh daemon, you aren't going for any heavy weight elliptical curve encryption algorithm either. And I'm also guessing you won't use different cipher keys for different systems sold to different locations.) No, at this point, all you've accomplished with light-weight encryption is offer your clients a false sense of security.

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

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.