Why should anybody care about securing their networked printers when there are firewalls, routers and many other fancy (and expensive) network protection devices in place? Can printers really provide a risk to an entity? Printers do not even have enough capability to provide a serious risk, or do they?
Printer capabilities have grown even as relative costs have shrunk. Multifunction printers are cheaper than ever. Common multifunction printers can perform all or most of the following tasks:
- Digital sending to e-mail
- Digital sending to a network folder
Until humans can plug themselves into knowledge-based systems in some futuristic biotechnology manner, printers and screens will remain the way humans interface with information. Printers and screens are dangling at the long end of a tentacle. For those who have seen the movie Gettysburg, a scene comes to mind where a commander in essence tells another commander, “You, sir, are the end of the Union Army’s line; if you fall, the whole Union Army will be flanked and destroyed.” To a certain extent, printers are in the same vulnerable position. Confidential and/or sensitive data often flow to printers left out on the lonely end of a long line. Sure, there are defenses along the way, but printers should also be given a chance to protect themselves if need be.
In light of the ever-increasing abilities of networked printers, every entity should perform an audit to determine whether their networked printer environment is reasonably secure. Some control objectives to consider reviewing are:
- Policies and procedures governing the security of networked printers are adequate
- The remote administration web console for each networked printer is configured strongly
- Risks identified by network-based vulnerability scans of the printers themselves are accounted for and mitigated
- Other printer risks are considered and accounted for through additional tests of general controls
An audit of the organization’s networked printers falls under several categories of relevant security standards or frameworks (e.g., International Organization for Standardization [ISO] standards, CobiT, the US Federal Information Security Management Act [FISMA]). For instance, auditing printers can help the organization gain coverage for some portion of the network security and legal compliance.
After considering the organization’s environment, an audit of printers should use a judgmental sample approach based on risk. Normally, printers located in a cross-section of functional areas, such as administrative, support, human resources and operations, would make up the total population from which to choose samples.
Generally, printers are regarded in the security world today just as they were when they were simply dumb devices that had no memory, without consideration to the advances made in printer technology. As a result, they are often ignored in security policies and procedures. While these documents usually provide some coverage for networked printers in that they are “devices” connected to a network, they are not always specific regarding the configurations. To rely on the these procedures for joining devices to the network for printer security would be like relying on a single posted speed limit sign to enforce traffic safety. It is a nice idea, but consideration for risk (school zone vs. highway) should be applied. Ideally, there should be overarching detailed standards, procedures or guidelines related to networked printers.
Remote Administration and Heartaches
It seems to be less than common knowledge that the only requirement to access the web console for a networked printer is to type the Internet Protocol (IP) address in a web browser. This, of course, is a “feature” of modern printers to enable remote management. The problem with this is that many models in use allow for anybody with the IP address to view most if not the entire configuration. The only thing that anybody with the right IP address cannot do is save any modifications made to the configuration without having the password. Therein lies the rub though. It turns out that many networked printers are deployed without knowledge that factory default passwords are set on the device. Management should have written procedures that require printers to have their default factory-set passwords changed as one of the first steps of deployment.
There are several risks that arise from the vulnerability of unmitigated remote administration, including IP address modification. This is of particular interest on the denial-of-service (DoS) attack front. If one pulls the old switcheroo on the printer’s IP address, users will be unable to successfully send print jobs, leading to mass confusion, or at least mass complaining (see the attack outlined in “The Attack” sidebar). While this would be annoying enough for technical support to remedy, it may be minor in comparison to attacks successfully carried out during many reviews.
The most severe weakness identified in a printer audit would be the concept of a successful man-in-the-middle attack carried out through IP address modification and the use of easily obtainable freeware/shareware tools. It is relatively simple and made possible solely through access to a weakly secured printer’s remote management console.
After finding a printer configuration that is not locked down via strong passwords, the first step to complete an attack is to modify the IP address of the printer to an unused address on the same subnet. Next, the IP address of the PC is modified to the printer’s previous address. Then, all traffic sent over port 9100 (the standard printing port) to the IP address that end users are configured to print to can be captured. The attack could stop here and be used to simply collect print jobs until somebody figures it out, but why quit now?
Instead, all print jobs can be forwarded on to the “new” IP address of the printer. When the end user who submitted the job heads over to the printer in question to retrieve the print job, they will find out that it has processed as normal. In fact, it has happened so fast that there is no cause for suspicion for the end user. If the attack is successfully carried out, this is particularly frightening, as there is not necessarily going to be any detection to end the problem quickly, resulting in prolonged exposure and the monitoring of all or some select print jobs. If the attacker knew the IP address of a particular executive or just someone with whom a grudge was held, they could certainly target a particular user.
- Modify the IP address of the printer to an unused address on the same subnet.
- Switch the IP address of your laptop to what the address of the printer was previously.
- Capture all traffic sent over Port 9100 to the IP address to which end users are configured to print.
- The attack can stop here, simply collecting print jobs until somebody figures it out, or…
- Forward all print jobs on to the “new” IP address of the printer.
- When the end user who submitted the job goes to the printer in question to retrieve the print job, it has processed as normal.
- It has happened so fast that there is no cause for suspicion for the end user.
For the purposes of this type of review, Wireshark could be used to analyze traffic and capture anything sent to port 9100 of the IP address in question. After capturing the traffic, another application, such as RedTitan EscapeE or a similar alternative could be used to convert the captured Printer Command Language (PCL) data into a printable document format. There are probably other freeware or shareware tools available to accomplish the same task, and of course anyone with nefarious intent would not be above seeking these out. Showing management a supposed secure document that has been sniffed off the wire is sure to get a reaction. As always, how far audit should go to prove that vulnerability exists is often a gray area. To properly evaluate the situation, senior management must be in the loop as the tools of the trade must be used, even if normally these would be prevented by the computing policies or procedures at a company or agency.
Another angle that could be taken is to run Nmap scans against the printers selected for review. While undertaking a printer audit, it is often possible to be provided with a partial listing of networked printers from which to select a sample for review. It has to be noted, however, that Nmap can also be used to identify network devices. An attacker can use this widely available software utility to identify printers on a subnet to establish targets with a reasonable degree of accuracy. A common weakness often identified in this type of printer review would be finding Telnet and File Transfer Protocol (FTP) enabled. These protocols are now out of date as they enable communication in an unencrypted fashion. These protocols should always be disabled by default, and only allowed when a legitimate technical case is presented.
Another common weakness identified when scanning is printers running an older version of Simple Network Management Protocol (SNMP). SNMP was developed in the 1980s to provide a simple way to manage many different network devices across the network.1 By default, many previously deployed printers still have version 1 running, when version 3 is the current protocol and supported by most networked printers. The problem with version 1 was that there was no encryption, which left this method of remote administration susceptible to packet sniffing.
Another related problem is that printers can still have the default community string in place. When using SNMP, the community string is used for authentication between a remote administrator and the network device being managed. When the default community string is used, this allows for an attacker to gain information about the device or potentially change the configuration of the device.2
Depending on the organization, management may respond in different ways to remedy audit findings of networked printers. One major factor is whether or not the organization manages printers in a centralized format. If not, the response may include the development of a printer-specific standard that gives detailed settings and instructions. If printers are centrally managed, sweeping changes can be made to the configurations in place and then pushed out to all printers on the network.
From the playing-well-with-others category, there are a number of caveats to mention before taking on this or a similar project, both from a technical and a nontechnical standpoint (see the “Caveats to Consider” sidebar).
Caveats to ConsiderTechnical:
- Check existing policies/procedures for printer security.
- Be aware of network layout (segments/traffic filtering).
- Be aware of baseline standards (printers or PCs).
- Test scanning methodology/attack on a local nonshared device prior to beginning test work.
- Test could lock up a printer requiring a hard reboot and causing accidental DoS.
- Obtain executive management buy-in, avoiding departmental advance notice where possible.
- Get explicit approval and set a time frame for sensitive devices.
- Check printers, including high-volume printers and transcript printers.
- Identify the owner of the printer device to avoid the blame game later.
Technically speaking, a thorough review of any existing policies and procedures for inclusion of printer security is a requisite to start the audit. One should be aware of any established baseline standards for printers and PCs. Auditors should also be aware of the network layout, including segments and any traffic filtering. If intending to implement tests using any of the attacks listed previously, always test scanning and attack methodology on a local device prior to beginning test work. Because one can never know what complications may arise, this will allow one to be better prepared to address them. Seemingly innocuous tests could lock up a printer, requiring a hard reboot. If this happens, short-term accidental DoS may result.
Nontechnically speaking, it is always wise to obtain executive management buy-in as necessary. For instance, one may take the step of avoiding departmental advance notice where possible. This is a fine line, but it may be determined to be worthwhile to get a true picture of the environments without contamination through advanced notice. In the case of sensitive or highly important devices, it is best to get explicit approval and set a time frame for testing. One does not want to take down a payroll check printer during live monthly processing or take down a printer at a nurses’ station relied upon for updating charts during peak hours. It is also best to identify the department or individual who owns the printer, as this may save trouble down the road if findings need to be discussed.
Other Related Printer Risks
So far the article has discussed the most prominent risks centered on unauthorized access to data while in transmission to a printer and DoS vulnerabilities. Other general controls should be considered as well. For instance, auditors should always ask themselves how output from a printer is controlled and who has physical access to critical printers, print stock and printouts. As part of other audits or a larger-scoped networked printer audit, more audit objectives may need to be added. For example, at a university, the auditors may add physical controls over the check printers, clinical printers at its medical center and the printers located at the registrar. These have Health Insurance Portability and Accountability Act (HIPAA) implications and Family Educational Rights and Privacy Act (FERPA) implications. Therefore, the auditors try to determine that printers that print out protected health information (PHI) of patients are not in areas that the public may access freely or unobserved. In addition, printouts that contain PHI should be controlled so that only those employees who have clinical duties for a patient see PHI-related printouts. The same holds true for a registrar. Student grades are not to be exposed to others and, hence, these printers must be in a secured location. In addition, print stock of transcript paper must be tightly controlled.
Many situations such as who should see what information, e.g., PHI, grades or Social Security numbers, may be controlled in the application. Print icons can be grayed out for those individuals lacking the authority to print out such information. These functions are usually tied to roles in an enterprise-based system. Therefore, the review of access to print routines can be incorporated into either application-access audits or printer audits. To be in compliance with HIPAA, FERPA and other regulations, it is best to randomly review access to printouts of PHI, grades and other personally identifiable information.
For finance-related printers, many of the same issues are of concern. Separation of duties is particularly acute for check-printing printers. The auditor needs to be aware of the procedures and, thus, ask for work flow narratives or diagrams to the check-printing process. For example, if a run of checks is interrupted due to power outages or other equipment failure, what is the process for restarting the operation? On more than one occasion firms and entities have been known to send out duplicate checks due to overlapping check runs. Tight control-totals procedures need to be incorporated so that the inputs to a check run reconcile to the output of a check run. Examples of control totals include total monetary amount, number of transactions and even hash totals on a nonfinance-related data element. Just as with a university’s registrar and transcript paper, check stock also needs to be tightly controlled.
Another issue to consider with any printer, especially those of high criticality such as check printers, is who may have access rights to buffer files or temporary preprint files located on printer servers. The organization may have all the controls in the world on the printer but if someone can modify text files located in a buffer or print server, then control over data integrity has been lost; the printer will work properly but contain bad data.
Finally, printer auditing can be greatly aided by the use of print logs included with the printer itself. The auditor should make sure that management is aware of such features and determine that logs are run and monitored using a risk-based approach. Obviously, a printer in a library may not need audit logs turned on. Logs of print jobs can be reviewed as an adjunct to determine if the individual who printed the job should have printed the job. Also, other suspicious activity such as volume of print jobs or time of printing, e.g., late at night when limited personnel are present, can be reviewed.
During these days of cost constraints, auditors are often looking for audits of “low hanging fruit” that will reap great security recommendations at little to no cost. The audit of printers is one of those audits. The two main focuses should be locking down the configuration and turning off unneeded risky services (sound familiar?).
1 Geiger, Amy; “Your Greatest Strength Can Become Your Greatest Weakness: Simple Network Management Protocol Vulnerabilities,” SANS Institute, 2003, www.sans.org/reading_room/whitepapers/protocols/your_greatest_strength_can
2 Romanski, James; “Default SNMP Community Strings Set to ‘public’ and ‘private’,” SANS Institute, 12 August 2000, www.sans.org/security-resources/idfaq/snmp.php
Kevin Savoy, CISA, CPA, CISP
has more than 20 years of experience in IT operations and audit in government and private industry and is currently director of information technology audits for the University of Virginia (USA). Previously, he was IT security audit director for the Auditor of Public Accounts for the Commonwealth of Virginia. He also spent 10 years automating retail and hospital pharmacies for two major pharmaceutical wholesalers. He has spoken on a variety of IT security and audit topics to several professional organizations.
Brian Daniels, CISA, GCFA
has been working in governmental IT audit for five years, working from the external and the internal side. Previously, he was an information systems security auditor for the Auditor of Public Accounts for the Commonwealth of Virginia. He is currently IT audit manager at the University of Virginia. Recent audits performed have focused on wireless security, UNIX security, networked printer security, router and firewall security, disaster recovery, incident response, and various computer forensic investigations.
Enjoying this article? To read the most current ISACA® Journal articles, become a member or subscribe to the Journal.
The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.
Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.
© 2010 ISACA. All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.