Is Your Printer a Network Security Risk?

eSecurityPlanet columnist Linda Leblanc says appliances are easily compromised. These small holes can cause major problems.

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.