Exploitation

An introduction to printer exploitation

9 min read
By 0x434b
An introduction to printer exploitation

Preface

Note: As always the following is just a digest of all the things I could observe by working on printers myself or facts from stuff I read about recently.

Since this thread about the HP printer promo videos caught some attention I will try to shed some light onto the field which was displayed there. First of all we should keep in mind this was a promo video made by a company. So always ask yourself this: "How real are the displayed scenarios, or are these just 'Hollywood fabrications'?"

I had some access to different printers over the last couple of month and learned some basic principles, which I wanna share with you as good as possible now. Printer use a various amount of protocols and firmwares which differ from vendor to vendor and model to model. So this first part might be boring to some, you can try to skip the theoretical part and jump right to the exploitation paragraph, but talking about fundamentals will cover important topics.

Printer as an attack vector?

  • So why would I even want to target a printer in the first place?
  • Why not just target Desktop or Server environments with malware as usual?

We get to that in next couple of paragraphs,

Required Skills

Not much to mention here,

  • basic ability to read for more than 5 minutes

Printer a viable target or just wasted time?

Local vs Network printers

Local printers are just directly connected to a desktop PC and are rather uninteresting. These days almost all printers seem to be network printers though.
So basically network printing enables users in locations geographically separate from each other and from their print devices to produce documents for themselves and others. Print servers enable multiple clients to share one or more print devices. So far so easy right? Let's jump directly to some highlevel view which explains every network printer quite well.

Highlevel view

A highlevel view of current network printers might look something like this:

  +----------------------------------------------------+
                       | Network printing protocols    |
   Printing channel    +-------------------------------+--+
                       |                                  |
                       | IPP, LPD, SMB, raw port 9100     |
                       |                                  |
  +--------------------------------------------------+    |
                       | job/printer control langs.  |    |
   Printer language    +-----------------------------+--+ |
                       |                                | |
                       |  PJL, PML                      | |
                       |                                | |
                       | +------------------------+     | |
                       | | Page descr. langs.     |     | |
                       | +------------------------+---+ | |
                       | |                            | | |
                       | | PS, PCL, PDF, XPS, ...     | | |
                       | |                            | | |
                       | +----------------------------+ | |
                       +--------------------------------+ |
                       +----------------------------------+
Note: This diagram might be incomplete!

The network printing protocol acts as a channel to deploy print jobs, which either contain the page description language directly or first invoke a printer/job control language! Let's take a look at each of those sections in the diagram above more closely and cover some fundamentals.

Fundamentals

Firmware

Printer use, in my experience a couple of different operating systems for embedded devices. I'll list a few of them here, but won't really dive into them, since it would go beyond the scope of this article.

With the different, but limited pool of printers I've had access to all of them had some things in common in the end.

  • slimmed down instruction/command set - reduced functionality,
  • 'legacy kernels' - often around kernel version 2.6.XYZ,
  • might include 'hidden' functionality, which can be enabled through a little patch - e.g.: ssh files are there, but need to be enabled in config files,
  • ssh is more present in printers designed for offices, compared to home printers for some reason,
  • sometimes the way the firmware is stored is hilarious - e.g.: on a SD card you can remove/switch within 30 seconds of physical access

These facts show that printers might be vulnerable to certain attacks, but still these attacks often are made more 'complicated', because certain functions aren't even there or somehow have to get enabled through (remote) file system writes... Next a wild bunch of protocols is used for communication between Printers, print servers, desktop PCs and even internally within a printer. Let's take a look!

Network printing protocols

To summarize it right away there are a bunch of 'exotic' protocols for network printing (NCP or AppleTalk for example). To explain and mention them all here would be too much again. If anyone is interested in some specifics or a follow up post I'd answer any questions there.

In the Windows world, SMB/CIFS printer are popular. The most common printing protocols supported directly by network printers however are LPD, IPP, and raw port 9100 printing, which I will explain a bit more in depth now. Furthermore, some devices support printing over generic protocols such as FTP or HTTP file uploads as well.

LPD

LPD is short for 'Line Printer Daemon'-protocol. It runs on port 515/TCP and can be accessed by using 'lpr' over the CLI. To print things, the client sends a control file defining job/username and a data file containing the actual data to be printed.

IPP

IPP is an extendable protocol and based on HTTP, so it inherits all existing security features like basic authentication and SSL/TLS encryption. To submit a print job, a HTTP POST request is sent to the IPP server, which listens on 631/TCP. For anyone wondering CUPS is an IPP implementation, which is a default printing system in many Linux distributions and macOS X.

SMB

SMB, short for 'Server Message Block' is an application-layer network protocol, which handles file and printer sharing. It's used by default on Windows. Usually it runs on 445/TCP.

Port 9100

Also known as 'raw printing', since it makes use of connecting to 9100/TCP of a network printer. It is the default method used by CUPS and the Windows printing architecture. Here all data sent is directly processed by the printing device, just like a parallel connection over TCP. In contrast to LPD, IPP and SMB interpreted printer control/page description languages, this one here is capable of sending direct feedback to the client, including status and error messages. So we have a bidirectional channel here, which directly can give us access to results of the Printer control languages!

Printer Control Languages

Basically a job control language manages settings like output trays for the current job. It often just sits in between the printing protocol and the page description language. Printer control and management languages are designed to affect not only a single print job but the device as a whole. I'm not too knowledgeable here but the two most basic ones are listed below.

SNMP

SNMP, short for 'Simple Network Management Protocol' listens on 161/UDP.
Was designed to manage network components

PJL

PJL, short for 'Printer Job Language' is the kinda de-facto standard now. Can be used to manipulate general settings, also with permanent changes. There are many dialects as vendors tend to support only a subset of the commands listed in the PJL reference and instead prefer to add proprietary ones. PJL is also used to set the file format of the actual print data to follow, which makes it interesting for various attacks.

Page Description Languages (PDL)

This one basically specifies how the actual document will look like appearance wise. Here comes the printer driver into play which kinda translate the file to be printed into a PDL that is understood by the printer.

PostScript (PS)

Is well known and made by Adobe and is widely used as a PDL. PS is capable of far more than just defining the appearance of the document and handling vector graphics though. That's why, when used correctly, PS can be used for a variety of attacks such as denial of service (for example, through infinite loops), print job manipulation and retention as well as gaining access to the printer's file system.

PCL

As a minimalist page description language supported by a wide variety of vendors and devices. Is also a de-facto Standard nowadays. It's also not intended to get direct access to the underlying filesystem. So it's not that well suited for exploitation purposes, but still has it's place for such purposes as well.

Possible Exploits - Who would put a printer on the Internet?

> shodan count port:9100 pjl
29111
[7/07/20 7:42:13] dev@ops
> shodan count port:515 lpd
50607
[7/07/20 7:42:46] dev@ops
> shodan count port:631 ipp
90760
[7/07/20 7:43:10] dev@ops
> shodan count port:161 snmp
7876
Data from: 07.07.2020

I'll just leave this here :)

Attack Vectors

Remote

As easily seen above a lot of printers are connected to the Internet through port 9100, which make them attackable. You either know the IP or can just scan for some in your neighborhood radius/ check shodan. Once you have some you might get a SSH connection going. Often standard login credentials are still used, which you can easily scrape from the Internet...

Inside job

If you have physical access to the printer you can also plug in an USB drive or even a SD card.

Possible Mayhem one can cause..

So now we're kinda back to the linked topic at the beginning of the small web series directed by HP. So how realistic are the shown scenarios?

DoS

  • Transmission Channel - basically block the/one printing port to keep the printer busy and don't print anything anymore.
  • Document processing - manipulate a Document via PDL and let the printer interpret it.. e.g.: an infinite loop in PS.
  • Physical damage - malware causing writes on NVRAM chips which have a life expectancy of ~10^5 writes.

Privilege Escalation

  • Factory defaults - reset to factory defaults to bypass authentication.
  • Accounting bypass - similar thing here, printing without authentication.

Print Job Access

  • Print job retention - Try to find stored print jobs on the printer and extract those.
  • Print job manipulation - Alter print jobs. You can imagine the possible mayhem caused itself.

Information Disclosure

  • Memory access - may lead to finding sensitive data like passwords or printed documents.
  • File system access - potentially retrieve sensitive information like configuration files or stored print jobs.
  • Credential disclosure - brute force attacks against changed default login credentials to gain access

Code Execution

  • Buffer overflows - printers provide additional languages and network services, potentially prone to this kind of attack
  • Firmware updates -  it is common for printers to deploy firmware updates as ordinary print jobs ;) cough malicious firmware cough
  • Software packages - 'custom tailored and manipulated printer apps'

Misc

  • Malware - target network printers and spread it in local networks to other peers.

Possible attack scenarios

Depending on the planned attack and possible access one has a variety of attack vectors. One need more planning than others. Some need physical access and some can be done from remote. Combinations of those are easily possible!  For example issuing a malicious firmware update via a simple print job (possible case: no authentication needed), which extracts sensitive data and renders the printer useless. Printer 'ransomware' may be a thing, even if it sounds kinda weird.

So to conclude this section, I think the shown attacks in the videos were presented a tad to 'flashy', but are indeed possible depending on the printers and network they are placed in.

Tools

A lot of these techniques mentioned above need some serious work or knowledge about the underlying structure ( e.g.: used PDL, PCL). Even though these might be fairly easily found out using manuals or online search it's still a hassle and extra work. So people already made our lifes more easy by providing tools for almost all tasks mentioned above  :).

BeEF

The Browser Exploitation Framework (BeEF) is a penetration testing tool that focuses on the web browser. It allows the penetration tester to assess the actual security posture of a target environment by using client-side attack vectors. This is not really printer specific, but it is a framework to implement cross-site printing functionality.

Praeda

Praeda - "An Automated Printer Data Harvesting Tool" written in perl.
Also a tool to help pentesters to gather usable data during security assessment jobs. Praeda systematically collects sensitive information from the printer's embedded web server. This includes device passwords, usernames, email addresses which might be available publicly on the web interface.

PRET

This one is real nifty tool written in python to check for basically every attack vector I mentioned above. It tries to connect to the printer via network or USB and tries to exploit the used printer languages, currently supported are PS, PJL and PCL. When successfully connected one has a ton of available commands. A full list can be found on the Github, linked below.

LES

Linux Exploit Suggester is a neat little perl script, which gives some options for possible exploits depending on your kernel. As stated above the kernel versions for embedded operating systems are often far lower, compared to current linux based desktop or server distributions. So old, usually fixed exploit techniques might still be viable here!

Note: It is likely, that perl is not present in it's full range and copying it to a printer is extra work. Luckily one can run simply run in a desktop environment and specifying the kernel you want to exploit

Summary

Why Printer Exploitation?

  • (most) printers are already full blown computers!
  • Printer as port/network/exploits scanner
  • Computing/hash-cracking/sniffing
  • Malware upload
  • “Stealth”/"uncleanable" command and control
  • Unencrypted data theft

Afterthoughts:

  • How many people would expect their printers is infected?
  • How many users/admins/security-auditors audit and hard secure their network printers?
  • How many persons or anti malware products could clean such a malware?
  • ...?

Outlook and closing words

So I'm keeping it rather open ended now, but I hope I could inspire some minds here to take a closer look as well. Furthermore I hope this article reached the people who were interested and were able learn some things. So if you want to try to exploit your own device, just try it out! Remember:

  • Find a way into the system,
  • Check for the used printer languages and try code injection techniques for these,
  • Try dumping the file system directory structure from the web interface,
  • Upload self created "malicious" firmware if it is supported,
  • Find a new way ;)

I'm looking forward to feedback and improvement suggestions.

Further readings

Article related resources:

Extras:

ExploitationHardware
0x434b

0x434b

Researcher interested in anything low-level: hardware, IoT, kernel, exploitation, reverse engineering, fuzzing, code-audit, and pentesting. This blog represents a random collection of my research.

Next article

Exploit Mitigation Techniques - Part 1 - Data Execution Prevention (DEP)

Related Articles

Low-level adventures
Follow