Countermeasures

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, we have the impression that 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.

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. 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. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data.