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 highlights of the entire survey will be presented by Jens Müller for the first time at RuhrSec in Bochum.

Background


There are many cool protocols and languages you can use to control your printer or your print jobs. We assume you have never heard of at least half of them. An overview is depicted in the following figure and described below.

 

Device control

This set of languages is used to control the printer device. With a device control language it is possible to retrieve the printer name or status. One of the most common languages is the Simple Network Management Protocol (SNMP). SNMP is a UDP based protocol designed to manage various network components beyond printers as well, e.g. routers and servers.

Printing channel

The most common network printing protocols supported by printer devices are the Internet Printing Protocol (IPP), Line Printer Daemon (LPD), Server Message Block (SMB), and raw port 9100 printing. Each protocol has specific features like print job queue management or accounting. In our work, we used these protocols to transport malicious documents to the printers.

 

Job control language

This is where it gets very interesting (for our attacks). A job control language manages printer settings like output trays or paper size. A de-facto standard for print job control is PJL. From a security perspective it is very useful that PJL is not limited to the current print job as some settings can be made permanent. It can further be used to change the printer's display or read/write files on the device.

 

Page description language

A page description language specifies the appearance of the actual document. One of the most common 'standard' page description languages is PostScript. While PostScript has lost popularity in desktop publishing and as a document exchange format (we use PDF now), it is still the preferred page description language for laser printers. PostScript is a stack-based, Turing-complete programming language consisting of about 400 instructions/operators. As a security aware researcher you probable know that some of them could be useful. Technically spoken, access to a PostScript interpreter can already be classified as code execution.

 

Attacks


Even though printers are an important attack target, security threats and scenarios for printers are discussed in very few research papers or technical reports. Our first step was therefore to perform a comprehensive analysis of all reported and published attacks in CVEs and security blogs. We then used this summary to systematize the known issues, to develop new attacks and to find a generic approach to apply them to different printers. We estimated that the best targets are the PostScript and PJL interpreters processing the actual print jobs since they can be exploited by a remote attacker with only the ability to 'print' documents, independent of the printing channel supported by the device.
We put the printer attacks into four categories.

 

Denial-of-service (DoS)

Executing a DoS attack is as simple as sending these two lines of PostScript code to the printer which lead to the execution of an infinite loop:

Denial-of-service%!
{} loop


Other attacks include:
  • Offline mode. The PJL standard defines the OPMSG command which 'prompts the printer to display a specified message and go offline'.
  • Physical damage. By continuously setting the long-term values for PJL variables, it is possible to physically destroy the printer's NVRAM which only survives a limited number of write cycles.
  • Showpage redefinition. The PostScript 'showpage' operator is used in every document to print the page. An attacker can simply redefine this operator to do nothing.

Protection Bypass

Resetting a printer device to factory defaults is the best method to bypass protection mechanisms. This task is trivial for an attacker with local access to the printer, since all tested devices have documented procedures to perform a cold reset by pressing certain key combinations.
However, a factory reset can be performed also by a remote attacker, for example using SNMP if the device complies with RFC1759 (Printer MIB):

Protection Bypass# snmpset -v1 -c public [printer] 1.3.6.1.2.1.43.5.1.1.3.1 i 6
Other languages like HP's PML, Kyocera's PRESCRIBE or even PostScript offer similar functionalities.

Furthermore, our work shows techniques to bypass print job accounting on popular print servers like CUPS or LPRng.

Print Job Manipulation

Some page description languages allow permanent modifications of themselves which leads to interesting attacks, like manipulating other users' print jobs. For example, it is possible to overlay arbitrary graphics on all further documents to be printed or even to replace text in them by redefining the 'showpage' and 'show' PostScript operators.

Information Disclosure

Printing over port 9100 provides a bidirectional channel, which can be used to leak sensitive information. For example, Brother based printers have a documented feature to read from or write to a certain NVRAM address using PJL:

Information Disclosure@PJL RNVRAM ADDRESS = X
Our prototype implementation simply increments this value to dump the whole NVRAM, which contains passwords for the printer itself but also for user-defined POP3/SMTP as well as for FTP and Active Directory profiles. This way an attacker can escalate her way into a network, using the printer device as a starting point.
Other attacks include:
  • File system access. Both, the standards for PostScript and PJL specify functionality to access the printers file system. As it seems, some manufacturers have not limited this feature to a certain directory, which leads to the disclosure of sensitive information like passwords.
  • Print job capture. If PostScript is used as a printer driver, printed documents can be captured. This is made possible by two interesting features of the PostScript language: First, permanently redefining operators allows an attacker to 'hook' into other users' print jobs and secondly, PostScript's capability to read its own code as data allows to easily store documents instead of executing them.

  • Credential disclosure. PJL passwords, if set, can easily retrieved through brute-force attacks due to their limited key space (1..65535). PostScript passwords, on the other hand, can be cracked extremely fast (up to 100,000 password verifications per second) thanks to the performant PostScript interpreters.

PRET

To automate the introduced attacks, we wrote a prototype software entitled PRET. The main idea of PRET is to facilitate the communication between the end-user and the printer. Thus, by entering a UNIX-like command PRET translates it to PostScript or PJL, sends it to the printer, and evaluates the result. For example, PRET converts a UNIX command ls to the following PJL request:


Information Disclosure@PJL FSDIRLIST NAME="0:\" ENTRY=1 COUNT=65535
It then collects the printer output and translates it to a user friendly output.

PRET implements the following list of commands for file system access on a printer device:

Evaluation

As a highly motivated security researcher with a deep understanding of systematic analysis, you would probably obtain a list of about 20 - 30 well-used printers from the most important manufacturers, and perform an extensive security analysis using these printers.
However, this was not our case. To overcome the financial obstacles, we collected printers from various university chairs and facilities. While our actual goal was to assemble a pool of printers containing at least one model for each of the top ten manufacturers, we practically took what we could get. The result is depicted in the following figure:
The assembled devices were not brand-new anymore and some of them were not even completely functional. Three printers had physically broken printing functionality so it was not possible to evaluate all the presented attacks. Nevertheless, these devices represent a good mix of printers used in a typical university or office environment.
Before performing the attacks, we of course installed the newest firmware on each of the devices. The results of our evaluation show that we could find multiple attacks against each printer. For example, simple DoS attacks with malicious PostScript files containing infinite loops are applicable to each printer. Only the HP LaserJet M2727nf had a watchdog mechanism and restarted itself after about ten minutes. Physical damage could be caused to about half of the tested device within 24 hours of NVRAM stressing. For a majority of devices, print jobs could be manipulated or captured.
PostScript, PJL and PML based attacks can even be exploited by a web attacker using advanced cross-site printing techniques. In the scope of our research, we discovered a novel approach – 'CORS spoofing' – to leak information like captured print jobs from a printer device given only a victim's browser as carrier.
A proof-of-concept implementation demonstrating that advanced cross-site printing attacks are practical and a real-world threat to companies and institutions is available at http://hacking-printers.net/xsp/.

Our next post will be on adapting PostScript based attacks to websites.

Authors of this Post

Jens Müller
Juraj Somorovsky
Vladislav Mladenov

Related links
  1. Hacking Tools Windows
  2. Pentest Tools Find Subdomains
  3. Hacking Tools Software
  4. What Are Hacking Tools
  5. Pentest Tools For Windows
  6. Hack Tools 2019
  7. Hacker Tools For Ios
  8. Pentest Tools Github
  9. Pentest Tools Github
  10. Pentest Tools Apk
  11. Pentest Tools
  12. Hacking Tools For Beginners
  13. Nsa Hack Tools Download
  14. Hacking Tools For Windows 7
  15. Nsa Hack Tools
  16. Pentest Tools Free
  17. Hacker Tool Kit
  18. Nsa Hack Tools
  19. Hacker
  20. New Hacker Tools
  21. Hacker Tool Kit
  22. Pentest Tools Online

inBINcible Writeup - Golang Binary Reversing

This file is an 32bits elf binary, compiled from go language (i guess ... coded by @nibble_ds ;)
The binary has some debugging symbols, which is very helpful to locate the functions and api calls.

GO source functions:
-  main.main
-  main.function.001

If the binary is executed with no params, it prints "Nope!", the bad guy message.

~/ncn$ ./inbincible 
Nope!

Decompiling the main.main function I saw two things:

1. The Argument validation: Only one 16 bytes long argument is needed, otherwise the execution is finished.

2. The key IF, the decision to dexor and print byte by byte the "Nope!" string OR dexor and print "Yeah!"


The incoming channel will determine the final message.


Dexor and print each byte of the "Nope!" message.


This IF, checks 16 times if the go channel reception value is 0x01, in this case the app show the "Yeah!" message.

Go channels are a kind of thread-safe queue, a channel_send is like a push, and channel_receive is like a pop.

If we fake this IF the 16 times, we got the "Yeah!" message:

(gdb) b *0x8049118
(gdb) commands
>set {char *}0xf7edeef3 = 0x01
>c
>end

(gdb) r 1234567890123456
tarting program: /home/sha0/ncn/inbincible 1234567890123456
...
Yeah!


Ok, but the problem is not in main.main, is main.function.001 who must sent the 0x01 via channel.
This function xors byte by byte the input "1234567890123456" with a byte array xor key, and is compared with another byte array.

=> 0x8049456:       xor    %ebp,%ecx
This xor,  encode the argument with a key byte by byte

The xor key can be dumped from memory but I prefer to use this macro:

(gdb) b *0x8049456
(gdb) commands
>i r  ecx
>c
>end
(gdb) c

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx            0x12 18

The result of the xor will compared with another array byte,  each byte matched, a 0x01 will be sent.

The cmp of the xored argument byte,
will determine if the channel send 0 or 1


(gdb) b *0x0804946a
(gdb) commands
>i r al
>c
>end

At this point we have the byte array used to xor the argument, and the byte array to be compared with, if we provide an input that xored with the first byte array gets the second byte array, the code will send 0x01 by the channel the 16 times.


Now web have:

xorKey=[0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12]

mustGive=[0x55,0x75,0x44,0xb6,0x0b,0x33,0x06,0x03,0xe9,0x02,0x60,0x71,0x47,0xb2,0x44,0x33]


Xor is reversible, then we can get the input needed to dexor to the expected values in order to send 0x1 bytes through the go channel.

>>> x=''
>>> for i in range(len(xorKey)):
...     x+= chr(xorKey[i] ^ mustGive[i])
... 
>>> print x

G0w1n!C0ngr4t5!!


And that's the key :) let's try it:

~/ncn$ ./inbincible 'G0w1n!C0ngr4t5!!'
Yeah!

Got it!! thanx @nibble_ds for this funny crackme, programmed in the great go language. I'm also a golang lover.


Related posts


🔗 Antonio Caforio shared a link

 
Mauro, see the post that he shared.
   
 
   Facebook
 
   
   
 
   
🔗 Antonio Caforio shared a link.
11 April at 10:14
 
View
 
 
   
   
 
This message was sent to missamic.s2a2008@blogger.com. If you don't want to receive these emails from Facebook in the future, please unsubscribe.
Facebook, Inc., Attention: Community Support, 1 Facebook Way, Menlo Park, CA 94025
   
   
To help keep your account secure, please don't forward this email. Learn more
   
 

Building My New Gaming Rig


So this is about a month late, but I wanted to document the awesomeness of building my new PC with my oldest daughter.


I got sick of waiting for the Ryzen 3000 series to launch, which as it turns out with a month of hindsight, wont' be happening till July 2019, meaning my build back in late April was a good idea since I was having a really hard time putting off a new build then.