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