Direkt zum Hauptbereich

New printers vulnerable to old languages

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:
  • Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
  • Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
  • List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
  • Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
  • Launch denial of Service attacks of various kinds:

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:
Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP’s Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make 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. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer’s parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, “The Wolf” like scenarios can get very real in your office…

Beliebte Posts aus diesem Blog

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

How to Break Microsoft Rights Management Services

In this post, we provide a security analysis of Microsoft Rights Management Services (RMS) and present two working attacks:  We completely remove the RMS protection of a Word document on which we only have a view-only permission, without having the right to edit it. This shows that in contrast to claims made by Microsoft, Microsoft RMS can only be used to enforce all-or-nothing access. We extend this attack to be stealthy in the following sense: We show how to modify the content of an RMS write-protected Word document issued by our victim. The resulting document still claims to be write protected, and that the modified content was generated by the victim This work is going to be presented at WOOT'16.