Difference between revisions of "Countermeasures"
(Created page with "== Vendors == Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like PostScript from o...") |
(→Admins) |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | Most attacks against printers are enabled because there is no clear distinction between [[Fundamentals#Page_Description_Languages|page description]] and [[Fundamentals#Printer_Control_Languages|printer control]] functionality. Using the very same channel for '''data''' (to be printed) and '''code''' (to control the device) makes printers insecure by design. Potentially harmful commands can be executed by anyone who has the right to print. Thus there is no silver bullet to counter such design-immanent flaws. There are however various short- and long-term recommendations, best practices and workarounds to mitigate the risks. | ||
| + | |||
== Vendors == | == Vendors == | ||
| − | Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented PJL extensions, service codes and further proprietary features. In general | + | Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like [[PostScript]] from one day to the next would break compatibility with existing printer drivers, and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented [[PJL]] extensions, service codes and further proprietary features. In general there is a lot of security by obscurity in the printing industry. Reverse engineering however is not black magic anymore. Vendors need to accept that – sooner or later – someone will discover their ‘hidden functions’ and should instead focus on open, well-studied standards to improve printer security. When it comes to firmware updates and software packages, digital signatures are often advocated as the single countermeasure. If used correctly, only files originating from the entity in possession of the private key can be installed on the device. |
| + | |||
| + | Code signing however also means technically restricting users to run vendor software <ref>This issue has also been discussed by the FSF when HP announced to introduce code signing for their printers: ‘[https://www.fsf.org/blogs/licensing/restricted-printers Fixing rogue printers: don't trade one security threat for another]’</ref>. Certainly there are legitimate reasons to execute custom code on a printer. An example has been given by <ref>''Distribuição Balanceada de Jobs em uma Rede de Impressoras'', L. Waechter, 2005</ref> who extended HP LaserJets to support load-balancing. The [https://en.wikipedia.org/wiki/OpenWrt OpenWrt] success story demonstrated how to improve the often limited functionality of embedded devices and there is no valid reason why printers should be excluded from the benefits of free software. Vendors should therefore take secure alternatives to code signing into account. For example the window of vulnerability can be limited to a local attacker if firmware updates required a confirmation key pressed on the printer's control panel. Further non-code signing based approaches like unique default passwords can be adapted from best practices in the world of home routers. | ||
== Admins == | == Admins == | ||
| − | Network administrators should never leave their printers accessible from the | + | Network administrators should never leave their printers accessible from the Internet and disable raw port 9100/tcp printing if not required. While this does not prevent most of the presented attacks, it complicates them and in particular mitigates the attackers ability to leak data. A more secure but also more expensive approach is to completely sandbox all printing devices into a separate [https://en.wikipedia.org/wiki/Virtual_LAN VLAN], only accessible by a hardened print server. The print server should completely ignore PJL commands and convert PostScript code to another page description language or to a ‘defused’ version using CUPS' ''ps2write'' filter and disallow access to raw print queues. Printers should be completely sandboxed, isolating them from the rest of the network to mitigate the harm in case they are rooted. It must however be noted that print servers themselves can be a target of attacks, for example using the techniques discussed in [[Beyond Printers]]. A schematic view of the VLAN sandboxing approach is given below: |
| + | |||
| + | |||
| + | [[File:Dedicated-print-server.png|600px|Dedicated print server as a countermeasures to sandbox printers]] | ||
| + | |||
| + | |||
| + | Most attacks are based on malicious print jobs. If the device supports authentication, it therefore should be configured to accept print jobs from authorized personnel only. Furthermore, if supported by the device, strong passwords should be set for PostScript ''startjob'' and system parameters, PJL disk lock and control panel lock as well as the embedded web server. Additionally, malicious PJL commands can be blocked using an [https://en.wikipedia.org/wiki/Intrusion_detection_system IDS/IPS]. Note however that such signature-based approaches are doomed to fail for PostScript which offers various code obfuscation techniques. | ||
== Users == | == Users == | ||
| − | Employees should be trained to never leave the copy room unlocked and report suspicious printouts like [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] headers to the administrator. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data. | + | Employees should be trained to never leave the copy room unlocked and report suspicious printouts like [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] headers to the administrator as they may be traces of a [[cross-site printing]] attack. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data. |
| + | |||
| + | |||
| + | ---- | ||
Latest revision as of 11:52, 24 March 2017
Most attacks against printers are enabled because there is no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Potentially harmful commands can be executed by anyone who has the right to print. Thus there is no silver bullet to counter such design-immanent flaws. There are however various short- and long-term recommendations, best practices and workarounds to mitigate the risks.
Vendors
Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers, and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented PJL extensions, service codes and further proprietary features. In general there is a lot of security by obscurity in the printing industry. Reverse engineering however is not black magic anymore. Vendors need to accept that – sooner or later – someone will discover their ‘hidden functions’ and should instead focus on open, well-studied standards to improve printer security. When it comes to firmware updates and software packages, digital signatures are often advocated as the single countermeasure. If used correctly, only files originating from the entity in possession of the private key can be installed on the device.
Code signing however also means technically restricting users to run vendor software [1]. Certainly there are legitimate reasons to execute custom code on a printer. An example has been given by [2] who extended HP LaserJets to support load-balancing. The OpenWrt success story demonstrated how to improve the often limited functionality of embedded devices and there is no valid reason why printers should be excluded from the benefits of free software. Vendors should therefore take secure alternatives to code signing into account. For example the window of vulnerability can be limited to a local attacker if firmware updates required a confirmation key pressed on the printer's control panel. Further non-code signing based approaches like unique default passwords can be adapted from best practices in the world of home routers.
Admins
Network administrators should never leave their printers accessible from the Internet and disable raw port 9100/tcp printing if not required. While this does not prevent most of the presented attacks, it complicates them and in particular mitigates the attackers ability to leak data. A more secure but also more expensive approach is to completely sandbox all printing devices into a separate VLAN, only accessible by a hardened print server. The print server should completely ignore PJL commands and convert PostScript code to another page description language or to a ‘defused’ version using CUPS' ps2write filter and disallow access to raw print queues. Printers should be completely sandboxed, isolating them from the rest of the network to mitigate the harm in case they are rooted. It must however be noted that print servers themselves can be a target of attacks, for example using the techniques discussed in Beyond Printers. A schematic view of the VLAN sandboxing approach is given below:
Most attacks are based on malicious print jobs. If the device supports authentication, it therefore should be configured to accept print jobs from authorized personnel only. Furthermore, if supported by the device, strong passwords should be set for PostScript startjob and system parameters, PJL disk lock and control panel lock as well as the embedded web server. Additionally, malicious PJL commands can be blocked using an IDS/IPS. Note however that such signature-based approaches are doomed to fail for PostScript which offers various code obfuscation techniques.
Users
Employees should be trained to never leave the copy room unlocked and report suspicious printouts like HTTP headers to the administrator as they may be traces of a cross-site printing attack. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data.
- ↑ This issue has also been discussed by the FSF when HP announced to introduce code signing for their printers: ‘Fixing rogue printers: don't trade one security threat for another’
- ↑ Distribuição Balanceada de Jobs em uma Rede de Impressoras, L. Waechter, 2005
