Unfortunately, due to a rather lousy law1 that makes it illegal to produce and/or traffic software or hardware which decrypts copyrighted material encrypted to prevent copying, I must make this disclaimer: This paper is provided as research material. It does not violate the DMCA, since no encryption or decryption algorithms are discussed. Also, no discussion or distribution of software or hardware designed to break cryptographic algorithms will occur. Printers don't usually use encryption, so it isn't likely that I would violate the DMCA, anyway.
In addition, I will not be violating any other laws, either. I did not exceed access privileges (on my own equipment or equipment I received permission to borrow during my research), so there are no 18 USC 1030 violations2 here. Also, the discovery of vulnerabilities in products is not yet illegal, "yet" being the operative word (and since this paper has been released before any potential law was passed, it cannot be grandfathered in... except if the ATA, another lousy law3 and a knee jerk reaction to the tragic WTC events, is enacted). Hopefully, the government and the manufacturers will realize that full disclosure of these vulnerabilities is key to fixing them, and this paper is meant to increase security awareness.
Now that the Feds have stopped reading, we can continue.
As more and more vulnerabilities are discovered and fixed in Operating Systems and Applications, the general public is rapidly becoming aware that all computers need to be secured from attackers, regardless of their purpose or use. While most home users still have a long way to go to fix their security, most organizations have made moves to adopt some sort of security policy (whether written or implied), and many have become aware of the need to spend money on security problems. Vendors who don't provide patches quickly are slammed by their customers for their inattention to security, and some companies have begun to re-evaluate their software choices based on how responsive a particular vendor is to security vulnerabilities.
Many organizations have invested a significant (though in most cases still too little) portion of their yearly budget in time and talent into creating policies which cover both the Physical Network and the Operations aspects of computer security. There are rules to prevent home computers and media from being brought to work and there are rules to push systems administrators to be more proactive about installing patches and configuring their systems correctly. While bugs in operating systems and applications seem to be getting the most attention, there are other devices on the network which are largely being ignored when it comes to security. While these devices aren't receiving much attention, they tend to be far more vulnerable and aren't as quickly repaired.
Network printers and other network peripheral devices are being added to the network on a frequent basis, and while they tend to have little (if any) security, they continue to be treated as though they are secure by most users. Some are even putting their printers in front of firewalls and other security devices to allow remote users to print to them without difficulty. Others allow holes in their firewalls, or place printers on their DMZ for the same purpose. After all, historically, the only thing a printer does is print, and this is what tends to get most users lured into a false sense of security. Printers were never meant to do anything more than print, yet most printers now come with a multitude of services available by default (in many cases, more services than most operating systems). In many cases, these services are insecure and (even worse) impossible to turn off, as the manufacturer has not provided a way to turn off the service or filter its access. In many cases, the manufacturer takes a default (often BSD) service and incorporates it into the product without taking the time to understand how the service works, the implications of incorporating the service into the printer, or the security risks involved with allowing the service to be accessed via the network. This is done, of course, all in the interest of making the user's life easier by providing a multitude of access mechanisms, all of which the user may want to use to access the printer, but which, in most cases, are never used.
Printers are often taken for granted within organizations, and their security is rarely questioned. Some organizations use their printers to print sensitive or even secret (trade secret or otherwise) documents one minute, then the next minute they're being used to run off several announcements for company parties or favorite Web sites a user wants to hang on their bulletin board. An attack against these devices will usually succeed, and, in many cases, won't be detected or will be ignored.
Other devices such as Webcams, networked fax machines, networked file server devices, and networked copiers are also vulnerable to many of the same attacks, and suffer the same problems as printers, largely because they are viewed more for their functional use than their security risk. Many of the manufacturers of copiers and networked fax systems are also the manufacturers of printers, so there is some correlation between bad printer security and bad copier security. These devices are taken more and more for granted, and the companies responsible for creating them are adding more and more access capabilities. While this paper centers more on the insecurities of printers, the general threats are the same, regardless of whether it is a printer or some other network device.
In order to get a better understanding of why people take printers for granted and don't question their security problems, it is important to look at the history of printers. After all, there must be a reason why people still think that printers are secure because all they do is print. In the beginning, that is all printers did.
When "printers" first appeared on the planet, networks didn't exist. The printer was usually connected to a dumb terminal, known at the time as a typewriter. Ok, so maybe the printer attached to a typewriter wasn't known as a "printer", but bear with me here. Thinking of a printer in this light, as most people do, pressing a key on the keyboard would cause a character to appear on the paper. Attacking this device was possible -- press the wrong keystroke, and you've destroyed whatever document you were working on (until the invention of whiteout), but attacking it was not only dumb, it was pointless. Attacking the printer served no purpose (except for making a large hassle for whoever was typing the document you destroyed).
All in all, a printer that isn't plugged into anything is about as useful as a computer that isn't plugged into anything, but it would probably be fair to say that it was "hacker proof". Once you plug the printer into a computer, it becomes a little less secure.
When the first computers rolled around and people began to use them, the printer became a detached peripheral, still responsible for printing output on paper, but it was usually attached via a serial or parallel port in order to make it useful. Printers connected in this fashion were still relatively secure. It was still possible to screw up a document, and with multitasking computers, it was possible for one user to attack another user's print job. Most people avoided attacking each other's documents, realizing that the ability to screw around with someone else's document meant that someone else was equally able to screw around with their own.
Printers began to grow more intelligent. Printer manufacturers began seeing a need for users to customize the printer while printing their print jobs. There may have been a need to change the paper size, the resolution, or some other custom configuration on the printer. As laser and jet printers replaced dot matrix and letter-quality printers, manufacturers began adding printing languages to printers to allow more customization while printing. Languages such as PostScript, Printer Command Language (PCL), and Printer Job Language (PJL) appeared in printers, and users could use any of them to configure the printer during the processing of a print job. Unfortunately, these languages also allowed a local user to "break" the computer by sending a bad command to the printer. Some of them even have controls that aren't available from the console, so users using these languages have far better control of the printer than the administrator sitting at the console. However, most of these languages are difficult to understand by a lay person, and their true potential for misdeeds remains shrouded by their complexity for local users.
But when printers are attached to the network, they become far less secure; you are no longer dealing with complexity-crunching among a few individuals, but with the network as a whole. The more people who have access to the printer, the more likely it is that someone knows how to program these languages, and the more likely that someone will use these languages for misdeeds.
Printers behind insecure protocols such as SMB, IPX, or LPR rely on the server for security. The server can authenticate users, filter connections, and look at the data being printed to assure it is not harmful. But none of these servers do this by default; they rely on the administrator to do the right thing. Some of these protocols and services can be undermined themselves due to configuration errors or shoddy programming, but because these printers are connected to the server directly through a parallel or serial port, extra services available on the printer are unavailable to the general public.
Users as a whole have become accustomed to the fact that printers only print. They merely need to plug the computer into one of the sockets on a computer and, presto, they can print to their heart's content. Since most are unaware of the local vulnerabilities available, it is pretty safe to assume that all the printer does is turn their electronic documents into paper ones. Unfortunately, users tend to bring this assumption with them when setting up and using network printers.
Unlike printers of yesteryear, printers of today are usually networked, and offer a large number of services available to the user by default. Buy any business printer today, and you're likely to either receive (or have the option of receiving) a print server card within the printer to place the printer on the network. Even most of the home consumer printers have the ability of being networked, usually via a separate print server or via workgroup sharing on insecure protocols such as SMB, IPX, or LPR.
Print servers have tons of services enabled by default, from SNMP to Web servers, FTP, telnet, LPR, and just about anything else you can imagine. Most of these services have vulnerabilities or risks involved with their usage. Simple protocols like SNMP, which most printers use by default (and which on many is difficult, if not impossible, to turn off), allow attackers to reconfigure the printer remotely, unfiltered and unauthenticated. Other protocols like telnet and FTP expose information sent to the printer to sniffers, and FTP servers on printers usually have a nasty tendency of allowing passive port bouncing (similar to a proxy server), meaning that attackers can use the printer to scan machines or access ports normally blocked to them by firewalls or router filters. Again, printer manufacturers don't understand (or completely ignore) the security risks and implications of using the protocol. (Why should the FTP "GET" command be allowed on a printer?) Furthermore, printer manufacturers themselves have subjected their printers to potential compromise by adding backdoors.
Manufacturers add these protocols for the sake of functionality, to make it easier on the user to print, regardless of which protocol is available on the machine. By adding as many access methods as possible, manufacturers are much more likely to sell their printers. What good is a printer that cannot be accessed by the only printer protocol your computer knows how to speak, be it LPR under Unix or SMB or IPX under Windows? Printers that cannot offer a wide degree of access are usually thrown away in favor of those that do. In most cases, users only use one or two methods, yet most printers do not allow the unnecessary services to be turned off by administrators concerned about security.
The biggest cause of printer vulnerabilities is consumers' push for as many ways as possible to connect to their printers, regardless of the fact that they will probably use only one of them.
The problems with printers are pretty much the same with any of the many other peripheral devices which are placed on the network. They all pretty much started out doing one particular thing that was fairly secure, but, in the need to expand functionality, have developed a really bad false sense of security among users. After all, the only thing a Webcam can do is take a picture of a room and its contents and place it online, yet Webcams too tend to have quite a few connection methods so users can access them in a multitude of ways. Networked file system devices are also beginning to see a large number of protocols implemented added, again for convenience.
Just about any functional peripheral moving from the computer-attached to the network-attached world is suffering from the same insecurities as printers, so it is safe to say that most of the vulnerabilities and threats covered here with printers are also available to other network-attached peripherals.
As with everything, there is a theory as to how things work and there is a practice. It is important to note throughout that while many of the attacks are talked about in terms of theory (something is likely to act one way based on evidence and understanding), not all of the theory is practical in all cases. Just because it is said that something could possibly be exploitable doesn't mean that anyone can go out and do it right now. There is still a lot of testing involved to see whether the potential vulnerability exists and can be easily exploited. However, throughout this paper, I've included actual exploits that do work.
There are many aspects here that don't have much source information, mainly because the information just isn't there. After all, I'm literally making this stuff up as I go along; that is the beauty and the beast behind researching information security issues. The job is to go out and purposefully break something to see how it can be made better. As with anything, I welcome comments and suggestions; feel free to email me if you find anything new and exciting.
Because network printers usually have IP addresses and network access ports (and usually aren't monitored carefully), they are good targets for a physical security attack. An attacker needs only to remove the cable connecting the printer to the network and attach her own laptop or portable access device and spoof the printer, and she has access to a wide variety of information. Reconfiguring the laptop to act as a print server could allow an attacker to intercept all traffic sent to the printer, and she could be shady about this by then attaching the printer to the laptop via a parallel cable, so print jobs are still printed for the users.
Attackers aren't the only cause of physical security issues surrounding printers; regular users may also cause problems. Visitors or employees who have legitimate access to the network but do not possess a legitimate connection port may temporarily remove the cable from a printer in order to connect to the network. It is surprising how many times this is done, but, after all, most printers are only used for a small fraction of the day, so why waste the time and the effort to get a legitimate connection when stealing the cable from the printer is so much easier?
Hardcore espionage with printers is always a possibility. Since the machine is network addressable and has an IP address, an attacker can use this access to surf for sensitive internal datastores or protocols, and can disrupt normal traffic. She may also be able to install an inline sniffer device to track packets on the network.
An inline sniffer device is a dongle that is plugged into the cable leading into the printer, and then into the printer itself. It forwards packets found on the network to a third party, or can store them internally for later retrieval. Inline sniffer devices aren't all that feasible at the moment, though advances in devices like keyboard sniffers and ethernet-on-a-chip devices are definitely making an inline sniffer device more practical. The inline sniffer device can be programmed to either store or forward any packets that match a particular ruleset, such as packets destined for the printer or for another device on the network. While the forwarding of packets can be detected, if the inline sniffer device only stores packets, it might be extremely difficult to detect that it is present.
The hard drives in a printer could also allow physical access to sensitive data, since they can be attacked using a simple laboratory attack. Since they are usually IDE or SCSI, they can be removed from the printer, and the data on them analyzed. Most printer manufacturers use a proprietary filesystem and proprietary encryption, which they believe protects them from compromise. However, since very few proprietary algorithms have stood the test of time, an attacker doesn't need to steal the algorithms (though that's possible) in order to break them. Making the problem worse (or easier for the attacker), printers rarely erase data using a sound data wiping mechanism. The data is usually present until it is wiped by a future job, so a laboratory attack will likely be fruitful.
The firmware is the operating system of the printer, usually loaded on a FLASH ROM chip. Without firmware, the printer would not work. Most printer firmware is proprietary in nature, based on simple hardware programming languages like VxWorks. Fortunately (or unfortunately, depending on your point-of-view), firmware can be updated relatively easily, either locally or via a network. If the firmware could be reverse-engineered, it is possible for an attacker to create a new firmware code that is similar to the original but has added features the original code did not possess.
It is possible for an attacker to physically remove the FLASH ROM chip from the printer and replace it with a new chip, which could contain anything from a simple backdoor to a network sniffer. It was widely reported after the Desert Storm period that the U.S. managed to provide Iraq with printers that contained modified firmware designed to inject a virus into the network4. While the Department of Defense denied that this occurred and it is now known that this was an April Fools Joke distributed by a magazine5, it is still possible for a printer's firmware to be modified to do such a thing (though the printer's firmware would have to use other mechanisms to introduce the virus, such as sending email with the virus attached to a client, specifying that a print job had completed). However, it's more likely that the firmware could be modified to send all print jobs to a third party, or to watch for specific traffic on the network and print it or send it to a third party.
Physically reverse engineering the ROM chip may not be necessary. It was recently discovered that at least one printer had the capability of remotely accessing the printer's firmware via a backdoor discovered in the printer (which we will discuss later). With this backdoor, a remote attacker could access and reprogram the ROM unauthenticated and unfiltered. The printer happened to be really old, and the manufacturer has published a technical bulletin on this particular bug along with fix information, so I will not dwell on it here.
Allowing remote access to any machine is a risky venture. There are a number of vulnerabilities in the software and protocols we use when accessing a computer or other networked device. If an attacker can exploit these vulnerabilities, she can get access to the underlying operating system and cause havoc. Allowing remote access to a printer is very risky because the protocols and services are rarely fixed when vulnerabilities are discovered.
Allowing unauthenticated and unencrypted access to a printer's configuration mechanisms is just plain stupid. An attacker can attack the printer without fear of being caught or punished if no other logging/authentication mechanisms are present between the attacker and the printer. Unfortunately, there is a large majority of stupid printers out there, since most printer manufacturers have added unauthenticated and unencrypted access.
The number of open printers available through search engines such as Google or AltaVista has fluctuated over time. Usually, I can find two to three dozen printer Web servers while doing a search for "PhaserLink" or "HP JetDirect" on Google. Since most of these sites have backdoors which allow unauthenticated access or have poorly configured services, it is likely that an attacker can quickly find a number of printers available to attack. Apparently, since I first released this document to the general public, a number of people have. I occasionally find printer names which have obviously been changed by a prankster. The bottom line is: Place any of these printers behind a firewall, unless you don't care about security (in which case, you probably wouldn't be reading this paper).
SNMP (Simple Network Management Protocol), by its very nature, is unauthenticated and unencrypted remote access. SNMP has a very simple authentication mechanism: Users must know a common "community string" in order to authenticate themselves with the SNMP server. However, this access is not encrypted, and the SNMP community strings are usually left with the default settings "public" (for read access) and "private" (for write access), which means that access is prone to attacks from guessing the community string or sniffing it off the network. Once the attacker has the community strings, she has read or write access to the SNMP server and access to the status or configuration of the printer.
SNMP is turned on by default on most printers, and the community strings are usually set to the default settings. Unfortunately, many printers do not allow the administrator to change the community string settings, and many more don't even allow the administrator to turn off SNMP access, meaning that the administrator cannot do anything to lower the risk. To make matters worse, some printers have additional non-standard community strings which allow greater access to the printer. Running a sniffer during a firmware update tends to reveal these community strings, such as when Hewlett Packard machines are updated remotely using the WebAdmin tool.
A number of network protocols on printers allow access to configuration, including FTP, LPR, IPP, AppSocket, SMB, IPX, HTTP, and telnet. By using PostScript, PCL, or PJL scripts, by undocumented commands, or by interfaces via HTTP and telnet, an attacker can access the configuration of the printer without a password or with a sniffed password. Many printers do not automatically set the passwords for telnet or FTP, and, usually, the manuals say nothing about setting the password. While these services can be turned off in a majority of cases, most are on by default and usually aren't turned off by the administrator.
AppSocket, which operates on port 9100, is bi-directional, meaning that an attacker can get an instant response to configuration changes, unlike many of the other network printing protocols. Using netcat or telnet is all that is required to access the printer's configuration. An attacker can send PCL/PJL scripts and get responses directly to the queries, as shown in Figure 1 below.
As shown in the previous section, it is possible to change the ready message the printer displays using PJL. On a printer at work, I used a PJL script to change the Ready message to "Printer Fault" as a joke. Unfortunately, I didn't change it back, and the next morning when I came in to work, someone had placed a yellow sticker on the printer which said "The printer is broken". Apparently, someone printed to the printer, then discovered when picking up the print job that the printer was broken (even though anyone could have tried printing and would have found that the printer was working fine).
The previous script merely changed the ready message, and resetting the machine made the message go away, so its likelihood of being an effective DoS tool was not a question. However, changing the message could get you a foot in the door when it comes to social engineering. Most LED screens on printers are 18 characters wide, and many have two lines (36 characters total). Some even scroll messages when there are more than the maximum number of characters which can be pushed onto the screen. Changing the message to "Printer Fault" could cause users or the administrator to start looking for answers to the printer's problems. An attacker could call soon after, stating that she's a representative of the printer company and that the printer has notified the manufacturer of the problem. Information could be garnished for the reward of making the printer problem disappear.
Tinkering around with the PJL script gave me a real DoS attack, but we'll talk more about this later.
A common and flawed access control mechanism that allows unauthenticated remote access is a backdoor introduced by the manufacturer. Backdoors have traditionally been used to access a system after the administrator has locked it down, usually in the name of technical support or licensing, but they may also be used for a number of other reasons.
Manufacturers rely solely on security through obscurity to protect backdoors from compromise. Rarely are these backdoors protected by other means such as filtering, strong authentication, or encryption. If an attacker finds the backdoor, there is nothing else for the printer's security to fall back on, and the machine is compromised. Exposure of the backdoor is likely, and the consequences of the exposure usually last forever -- manufacturers have been slow to fix backdoors or release new firmware or hardware to fix them. Some manufacturers have also told me that they have no intention of giving up this dangerous practice.
One of the best examples of a backdoor within a printer was one discovered by myself6 which affected a number of one manufacturer's line of printers. The backdoor, present in the Web server, allowed unauthenticated and unfiltered administrator access to the printer. By typing a simple URL (http://printername/ncl_subjects.html), the user was able to access configuration options that the administrator accessing the Web site or the console could not even touch. Anyone with access to a Web browser could exploit this backdoor and make a administrator's day miserable.
Just about anything that could be configured on these printers was available via the backdoor. From the ncl_subjects.html page, unauthenticated users had access to a smorgasbord of configuration options, from changing the IP parameters to turning on email notification and system logging. A number of potential Denial of Service attacks were available by default, including the ability to shut down the printer remotely (and, worse, cause system faults which could potentially cause physical damage) and to reset the system to the factory defaults, which would effectively remove the printer from the network. Changes made via this backdoor were instant and unauthenticated.
Of course, this particular manufacturer isn't the only company that's been caught doing this. Other manufacturers have fallen victims to exposure of their backdoors as well.
The biggest problem with this backdoor was that the manufacturer relied on Security Solely Through Obscurity as the only line of defense. In the business of security, there is a commonly-debated principle known as "Security Solely through Obscurity" which states that a product can be made secure by making its implementation secret or difficult to understand. While there are some very specific cases in which security through obscurity is a good idea, for the most part, it is a bad thing, especially when it is the only defense used to keep the bad guys out. The principle is flawed because it doesn't take into account three facets of human nature: Humans can find things by accident, humans tend to share information when it helps them, and humans can sometimes share information when it hurts their former employer. Let us take a look at each of the three facets:
First of all is the idea that all new ideas are new. Printer manufacturers (and software designers, and so on) often believe that the method they are using to protect their systems is a new, untried approach, and, because it is a new, untried approach, nobody else is likely to think of it. There are very few new ideas in the world; most of the stuff we do, someone else has done before us, and someone else will do long after we are gone. It is not only possible, but quite likely that the methods we think are novel are the same methods someone else thinks are novel as well. We may think that something is novel, new, and untried and that it will be very difficult for someone else to accidentally discover how to break it, but there is dumb luck in the world (as Bugtraq proves on a daily basis). Attackers can use this mindset to their advantage, testing exploits for vulnerabilities that work on one system on another.
While it may be unlikely for attackers to understand all of the technology that goes into a printer, they do have an understanding of common flaws in programming. Printers may be mostly hardware, but the software that runs them (usually called firmware) is really software at rest. A modern printer cannot usually run by itself and mechanically print everything that is fed to it. There is something that must translate the data sent by the computer into dots on the paper. Firmware provides the control mechanism, essentially the translator that parses the data from the computer and converts it. Firmware, like any other software, can contain bugs that can be exploited by an attacker. In the case of the printer, the bug is likely to be in the implementation of the protocols which allow the computer to talk to the printer, and, usually, the bugs in the implementation of the protocols exist elsewhere. Attackers are aware of these bugs, usually more aware of them than the printer manufacturers. Throw this together with manufacturers' general unwillingness to understand security implications, and you have a really bad situation.
However, there are many times when printer manufacturers open themselves up for problems by using the same techniques (which they call proprietary) that many other people have used (and have called proprietary themselves). They add their own proprietary backdoors or protocols which have not been well researched or checked for security implications. In this case, attackers may not be able to use previously-discovered attacks against the printer, but that does not prevent them from discovering the backdoor or protocol and playing with it. While most attackers rely on already-written scripts, there are some who look for adventure in breaking things. They know many of the same tricks manufacturers think they have exclusive rights to, and have figured out how to break them.
Second, people tend to give away information freely in order to help themselves or others. Is it any wonder that social engineering is relatively easy to accomplish or why con artists get away with thousands out of people's wallets? People trust one another, and, in this trust, information which should not be disclosed tends to be disclosed anyway.
Last, people tend to give away information when they are angry about their treatment or upset about their former employer's handling of a firing or layoff. They could respond with blackmail or just with a vindictive act of revenge. While most people would move on with their lives, some feel so angry or upset that they will purposely release information to the public that's detrimental to the company in question. Some call them "whistle blowers" while others call them "disgruntled employees".
All three of these things can cause security through obscurity to fail, and over time, it's likely that all security through obscurity will fail.
Security Solely Through Obscurity is a flawed principle, and this is one of the proofs. The manufacturers in this case believed that if they kept the backdoor a secret, nobody would ever find out, and thus they would never have to worry about a hacker using the exploit to manipulate the printer. But once the backdoor was leaked, there was very little they could do to stop it from spreading. Unfortunately, most of the printers out there today by this manufacturer have this flaw, and the only real way of protecting the printer is to disable the Web server and place the printer behind a firewall or other filtering device. In this case, the Security Solely Through Obscurity was broken via Friendly Disclosure. The technical support folks informed one of our customers about the backdoor when the customer had forgotten the password. Eventually, the author was told about the backdoor, and the rest is history.
The same manufacturer provided me with another proof for the fallacy of Security Through Obscurity about a year and a half later7. After playing with one of their brand new printers, I discovered that they had modified the URL which allowed the user to gain unfiltered and unauthenticated administrator access to the Web server. After testing the server using the original exploit, I was happy to notice that the server returned an "Error 404: File Not Found". It was a good feeling to know that I had helped the company fix the problem and all was right with the world. Other printers of the same model appeared to still have the same problem, but their firmware dates were set around the time that the original vulnerability was divulged, so it was likely that the company wasn't able to fix the problem in that short of a timeframe. But here was a printer with a firmware date almost a year after the exposure of the problem, and it was taken care of.
Unfortunately, the feeling of joy was short-lived, as a simple mistyping of the URL was all that was necessary to discover that they had apparently covered up one failure with another (though they vehemently deny this). I noticed that all Web pages on the server ended with ".shtml", which meant that the backdoor probably ended with that as well. However, when I used http://printername/ncl_subjects.shtml, I got the same results. Playing around with the Web site some more, I accidentally typed http://printername/_ncl_subjects.shtml, and voila -- unfiltered and unauthenticated access to the administrative pages again. Doh!
Worse, the normal method of protecting the printer from this attack by turning off the Web server was disabled. Setting the HTTP Parameters "On" value to "Off" had no affect on the server, no matter how many times the machine was reset.
While I will continue to believe that this change was a coverup for the previous exploit, in all fairness to company, they claim that the change was a functionality change, and not a security change. However, they also promised me they would not include such a backdoor in future printers without adding some sort of filtering and authentication capability. When I brought this to their attention, their response was "You cannot expect us to fix the problem in 4 months!" To date (almost 2 years after first disclosure), they have yet to fix the problem.
While manufacturer-introduced backdoors are far more common, the potential for a third-party backdoor to be added to a printer is always a possibility. If an attacker was able to get access to the system firmware and was able to devise her own firmware update including a backdoor, there would be very little to stop her from tricking an administrator or user into updating the firmware. The third-party backdoor could be anything from a simple traffic sniffer (one that forwards all packets sent to the printer to a third party) to something much more subversive such as a redirector which forwards packets from a remote network or machine to a local machine, bypassing any firewalls, routers, or other filtering mechanisms. Most printer manufacturers allow users or systems administrators to apply updates to the firmware within a printer. To get the rogue firmware installed, an attacker must use the remote update feature or social engineer an administrator to install the firmware. Very few methods are available for the administrator to assure that "safe" firmware from the manufacturer is being installed.
A Denial of Service attack is one of the easiest types of attacks to perform. Very little knowledge is necessary, and there are tools designed to take down entire networks which need little more effort than the majority of 14-year-old "Hackers" can provide, even with their limited experience and programming skills. To overwhelm a network and cause a denial of service attack, you merely need to use the protocols in a way for which they were not intended. Arp-killing or TCP-killing can do much to limit network traffic. However, there are simple but useful techniques which can limit the damage caused by an attacker.
Printers are rarely as rock-solid against denial of service attacks as other devices on the network, due to the lack of understanding of security risks and the slow releases of fixes (usually only on newer systems). Attacks which were fixed in most operating systems still exist and can be exploited in printers. Even script kiddies using scripts designed for other systems have managed to take down printers. Hewlett Packard printers suffered from the ISAPI IDA Attack (a.k.a. the Code Red Worm), a number of printers have suffered from telnet AYT attacks, and others have been defeated by buffer overflows for FTP servers.
The easiest Denial of Service attack to perform is simply done by overwhelming the printer with traffic. Sending a large amount of traffic to the printer will cause it to stop handling valid requests. Making multiple connections to the AppSocket interface accomplishes the same thing, as most printers only allow a limited number of connections to AppSocket. Hewlett Packard printers only allow 8 concurrent connections, with no timeout; new connections after the 8 successful ones get a connection refused message.
By using anonymous print capabilities, an attacker can DoS the machine by sending a large number of print jobs, physically wasting resources which an administrator must cancel manually.
Using unauthenticated remote access methods, an attacker can perform a number of Denial of Service attacks. Changing the IP address to a non-existent or duplicate address causes the machine to no longer be accessible for printing. An attacker could also reset the printer or change the passwords.
After playing around with PJL, I discovered a nasty DoS Attack which could keep a printer offline indefinitely. It works by using the OPMSG PJL command, which is used to place the printer offline for user intervention. Using the OPMSG command, we can continuously place the printer offline, which requires the administrator to remove the network connection or add filtering to the network to stop the printer from being pushed offline. When the administrator brings down the printer and then brings it back up, there is about a 3 second period during which the printer is available before netcat times out and resends the command.
Humans aren't very good at programming securely. It takes a lot of work to think about security issues while trying to quickly generate source code to meet deadlines. Secure programming is a process that involves both the programmer and a number of quality auditors who can go back and review the code for security flaws. Programmers working on "secure" products such as OpenBSD or Apache spend a lot of time reviewing code to make sure it is secure. Unfortunately, most printer manufacturers don't take the same time or the effort with the code loaded into their printers.
I recently discovered that many of the Tektronix and Xerox printers are vulnerable to a simple cross-site scripting flaw in their Web pages. The flaw requires a writable text box form component on a page whose contents will be displayed on a subsequent page using the "VALUE" tag item. The server doesn't validate the contents of the user's entry, so the user can cause it to do something it shouldn't.
To most businesses, information is important, sensitive, and worth money (even though, in most cases, it probably isn't, really). Exposure of information may lead to loss of profit, capital, employees, and business, and to embarrassment. Vulnerabilities in printers may allow this type of attack.
As stated before, a sniffer that tracks documents and other items sent to a printer could be added to firmware if an attacker could recompile the firmware and persuade the administrator to install it. The printer could forward the printed documents or packets to an attacker via email or data stream, or over some other covert channels. A back door could also be added to the firmware to allow the attacker to access the machine remotely so she wouldn't need to expose her email or IP address.
An friend of mine was once misquoted in a newspaper as stating that during an attack, all print jobs were being forwarded to Russia. This caused a lot of hardship for him because he received a number of calls from his superiors asking for further information on this new attack capability. He had to notify each caller that the paper had in fact misquoted him, and that there wasn't any worry about print jobs being forwarded to Russia.
While the paper fumbled up the information and there is no known (published) method for making a printer do this, it could be possible. Some printers already give away quite a bit of information about print jobs. There are several configuration options that may be used to allow print job information to be sent to a third party. Most printers offer some sort of print job completion message, which is user-configurable.
Some printers allow print job pooling, automatically forwarding a print job to another printer if a queue is full. If this is user-configurable, an attacker could manipulate this function to forward documents to a third party.
An attacker could also attempt to force the forwarding of print jobs with a firmware modification.
One feature I discovered with some of the printers was the ability to send status reports to an email address or to a syslog server. The logs contain a lot of information useful for analysis or social engineering, including the titles of documents printed, the number of bytes, characters, pictures, and pages, and the total number of documents, sorted by length. A copy of the logs is included below.
Some printers now include the ability to create RAM disks for storing files, which can be accomplished via the printer's console or via Web or telnet interfaces. Depending on the size of the memory in the printer, these RAM disks could be quite large. Unfortunately, recycling the power on the printer will clear the contents of the RAM disk. Some printers also include the ability to add (or may include when sold) IDE or SCSI disks for storing files on the printer, which are also configured at the console or via Web or telnet interfaces.
Printers may use RAM disks or hard disks for spooling print jobs, which means an attacker might be able to grab spooled files out of the spooler via FTP or by using PJL. In the case of Hewlett Packard printers, the spooler is write only; no files can be read from the spooler directory. Other printer manufacturers may not be so stringent in their protection of the spooler directory.
Many of the printers available on the market offer anonymous FTP servers for dropping print jobs into the printer. Unfortunately, many of these anonymous FTP servers allow passive mode FTP and the get command, which makes them vulnerable to passive FTP forwarding. This allows the attacker to use the anonymous FTP server as a proxy server, forwarding all her packets to the victim while hiding her true IP address. To the victim, the attacking machine appears to be the printer. When the printer's owners are questioned about the attacks, they'll respond defensively, arguing that since it is a printer, it couldn't possibly be responsible (after all, printers only print!). Since no logs are kept by the printer, bounced traffic is essentially anonymous and untrackable. Using the printer to hide the tracks, the attacker can scan the network, access sensitive information, and redirect network attacks without worrying about being discovered.
FTP Servers operating in passive mode have always been known to have some security risk involved8 9. In order for an exploit to work, the attacker must have upload access to the FTP server, something that most printers allow. The passive mode normally allows a client to be operating behind a firewall, where the server cannot do a reverse connect to the client. Switching the FTP server into passive mode means that the server opens a random, unused port and gives the client the port so it can connect its data channel to it. To attack this, a client merely needs to connect to the server and issue a QUOT PASV request. The server will respond with a series of octets consisting of its IP address (four octets), and the open port number (two octets). The client then connects to the server and issues a PORT, giving the value of the open port and using it as a poor man's proxy, submitting requests and downloading files.
Passive FTP can also be used to scan internal machines using nmap's -b
nmap -b <printername> -sT -O
<victim>. To the victims, the printer appears to be the
machine scanning them.
Another potential redirection vulnerability arises with a printer with two NICs. It is possible for an attacker to use the printer as a gateway from one network to another if the printer allows IP forwarding. HP printers with two NICs supposedly cannot do this, but IP Forwarding is available via SNMP. I believe this is an artifact of borrowed code used to code the SNMP server in the printer.
The Internet Printing Protocol allows the sending of URIs for printing Web pages directly to a printer. Instead of requiring the client to download the URI, parse it, format it, and print it as a document, this functionality is turned over to the printer. A potential exploit of this protocol could be made by requesting that an IPP-enabled printer print a URI which the printer can access but the attacker can't, then asking the printer for the properties of the print job or canceling the job and asking the server to return its contents. It is not known if this can be done, though according to the RFC, it is possible to at least return the properties of a job.
IPP also allows an attacker to reconfigure the printer using a proxy server, which can allow attackers to perform man-in-the-middle attacks by creating their own proxy servers and reconfiguring printers to use them.
The problem with IPP is that it is a new and untrusted protocol, designed and implemented by the printer manufacturers. It is being implemented in most newer printers and OSes, even though it has not been finalized. To make matters worse, it has not received its share of security review and there isn't much on security in its RFC.
The advent of printers with storage devices such as hard drives and RAM drives allows an attacker to establish a beachhead in the local network. If an attacker can print to a printer with an internal hard drive or RAM drive and the printer supports programming languages like PJL, the attacker can download and upload files to and from the printer. Given the size of most hard drives, this could be a very large and locally-centralized storage spot for an attacker. Nearly 40 manufacturers have adopted PJL and incorporated it into their printers, though not all of them support every PJL command (in fact, most of them only support a subset of the available commands). However, if a printer has a hard drive or RAM drive, it's likely that the PJL commands to access the drive are also available.
Storing information on a printer could foil investigations, since most investigators will discount the ability to store exploits and spoils on printers.
There don't seem to be any reports in the media or through other channels of attackers using printers as part of their attack methods. With these huge holes, why aren't attackers currently exploiting the vulnerabilities?
Well, how can we be sure they aren't? Very few of the printers I looked at had logging capabilities, and most of the existing capabilities were clunky and difficult to configure. It would be very hard to get an accurate estimate of how many of these vulnerabilities are actually being exploited. Tektronix vulnerabilities were known well before I published them; I received messages from people telling me they were aware of them but didn't have the guts to publish them. Also, I've seen numerous attacks against printers on a class B network, so there definitely are folks out there using these sorts of attacks.
The most likely reasons for attackers not using these vulnerabilities are that they don't know they exist or don't know how to exploit them, or that there are too many easier targets available.
However, as the necessity to implement security in the infrastructure increases and more people build security into their environments or lock down the systems currently available, attackers will increasingly have to resort to any vulnerabilities they can use to gain access to a network.
Dealing with printer manufacturers about security problems in their products has been roughly equivalent to dealing with other software and hardware vendors about security problems. Some vendors are excellent, releasing patches or firmware updates quickly to fix problems. However, most vendors don't understand the implications, and thus will deny a problem exists, will threaten the vulnerability researcher with legal action if the vulnerability is exposed, or will downplay its threat or discredit its importance. To most of these companies, security is a new issue (and one that they haven't planned for), so getting them to work with you on a security issue is difficult and frustrating. On more than one occasion, I've had to explain to an engineer or programmer working at a printer manufacturing company why particular security fixes will not work as they plan for them to work. They just don't understand the problem, and if they cannot understand the problem, coming up with a solution is hopeless.
One example of this cluelessness came when I called Epson about a number of problems in their printers. As mentioned before, their printers allow FTP passive port bouncing, and they have default public and private SNMP communities which cannot be changed by the user. After spending an hour with technical support trying to get someone who knew something about security, I was finally forwarded to one of the engineers who had some inkling of an idea about it. Unfortunately, her awareness of how the printer works left much to be desired. After I explained the situation to her in detail, she told me that she had an easy way to fix the problems without involving Epson: She suggested that I use a computer as a print server. I agreed, stating that doing so would fix a majority of the problems, since SNMP and FTP would no longer be available, but also brought up that it would no longer be a networked printer. She stopped me there, saying there was absolutely no reason that it could not still be a networked printer; the solution she presented was to leave the printer on the network and set up my users' computers to print through a print server, which would turn around and print to the printer using lpd or some other mechanism. Trying not to laugh, I explained to her that leaving the printer connected to the network and using a print server would in no way prevent an attacker from accessing the printer. To this, she responded that if I set up everyone's computer to use the print server, the attacker couldn't access the printer. While there are some methods available to force people to use a print server (such as placing the printer behind a firewall and setting up a rule to allow the firewall to only pass packets to the printer from the print server), it was obvious that she really didn't understand how networks work.
Tektronix provided another example. They believed that their security through obscurity method of protecting their backdoors was perfectly safe, and no one would ever discover the method to access their backdoor. Unfortunately, when the backdoor was discovered and published, they responded with threats of legal action for exposing "secret" information. We were told that our problems with security through obscurity were a local phenomenon, and that none of their other customers appeared to have a problem with it (of course, very few of their other customers knew about it). I spent several hours corresponding by email with the Tektronix folks, suggesting things like adding strong encryption, strong authentication, and filtering to their backdoors, or (better yet) removing them altogether. While some effort was made, it obviously wasn't enough, as they are still producing printers with the same flaws that were discovered over a year ago.
Hewlett Packard, on the other hand, seems to be doing a lot better. HP was hit quite hard by a number of flaws in their printers' firmware as well as their support software and drivers. While problems still exist in their printers, HP tends to be more responsive to flaws that are discovered. While the other two companies have yet to fix the problems or even make their customers aware the problems exist, HP has sent out vulnerability reports and patch announcements quite regularly. Unfortunately, when it was discovered that a worm attacking telnet and FTP vulnerabilities on Unix systems was taking out a number of HP printers, their response was to cover up the issue so as not to cause unnecessary fear for their security or a general lack of faith in the product.
There are many other printer manufacturers out there, and unfortunately, I haven't had enough time to research all of their products and contact them, but it is likely that you'll have responses similar to the ones above when contacting them as well.
Chances are, there are a number of printer manufacturers reading this article, and some of them are considering flaming me or sending it to their legal departments. While I welcome the challenge, they obviously haven't learned anything and probably never will (read: don't buy their products; they are more concerned about their image than security). Luckily, there will probably be quite a few more printer manufacturers who will look at this article and will want to make changes to their product to make it more secure; that is why I wrote this. I applaud those folks for taking the big step in realizing that they may need to change the way they're doing business. There might even be a few manufacturers out there smiling, smug in the fact that they know they are not vulnerable to these attacks (but how can you be sure?).
I am sure the number one question for manufacturers to be asking is: What do you want us to do?
My first bit of advice is to start thinking outside the box. It is too easy to dismiss a potential attack mechanism because you think that only a few people are knowledgeable about how to perform the attack (and they all work for you). There are some folks out there who make a living playing with things to see how they work and how they break, and these folks are likely to find your shortcuts and bad security. Some of them work for the good guys, and some of them don't. Do not immediately assume that someone who is bringing a security problem to your attention is a bad guy; chances are, if they were, they wouldn't be bringing it to your attention. Work with the security community to provide a secure product, and you will go a long way toward winning customers who are interested in security (there seem to be more and more joining the fold every day). Be open minded! Don't stand back with your arms crossed every time someone points out a flaw in your hardware. It doesn't hurt to start building relationships with those people; they tend to be much more helpful when both sides are working together to find and fix flaws than when one is an unwilling partner to the other.
My second bit of advice is to add access control, strong authentication, strong encryption, and filtering to your printers. Adding access control and filtering allows the administrator to keep out the bad guys. Strong authentication keeps the good guys safe from sniffers, protecting their passwords from exposure. Strong encryption, using industrial-standard and well-tested encryption algorithms, eliminates the worry of having data compromised. Use all these mechanisms on any remote configuration capabilities you may employ. Since firmware must be tight in order to fit on the chip, some of these things may be difficult to add, but access control and encryption of any remote configuration services should be the number one priority. Filtering and strong authentication can be added in the future.
My third bit of advice is to give the administrator complete control of the printer, to shut down any service not needed and to properly configure any service that is needed. Most of your customers currently won't take the time or the effort (at least until they get hit by an attacker), but the numbers who do want to configure the printer to be more secure are growing rapidly. Most companies now employ administrators responsible for the security issues of hardware and software on the network, and these administrators will appreciate the ability to have complete control of the machine to turn off dangerous or unnecessary services. Adding this configuration capability doesn't take much space, and is worth your while.
My fourth and final bit of advice is the phrase "Educate... Document... Communicate". Your customers depend on you to supply them with the information they need to get your printers working in their environment. While you may think that they are not likely to read it, you should still provide well-written and extensive documentation on the off chance that one of them does. Very few of the many printer manuals I've read have included security considerations, and even fewer discuss how to secure their printers. Educate your users f