The document discusses security issues with pull printing solutions. It provides three examples of security assessments conducted on different vendor products. In the first example, the proprietary protocol was reverse engineered and vulnerabilities like weak encryption were found. The second vendor took security seriously and responded quickly to reported issues. The third example showed vulnerabilities like a lack of encryption that could allow print job tampering. The document emphasizes that pull printing solutions require thorough security testing.
Bypassing malware detection mechanisms in online banking
In The Middle of Printers - The (In)Security of Pull Printing solutions - HackInTheBox Amsterdam 2014
1. In The Middle of Printers –
The (In)Security of Pull Printing Solutions
Jakub Kałużny SecuRing
2. #whoami
● IT Security Consultant at SecuRing
● Consulting all phases of SDLC
● Previously worked for ESA and online money
transfers company
● Bug bounty hunter
5. Why hack pull printing?
● It is cool
● Widely used
● Confidential data
● Getting popular
● Legal conditions
https://www.flickr.com/photos/girlgeek/1877517607
7. Attack vectors
Other users’ data
Access to other
print queues
Sniffing, MITM
Authorization bypass
User/admin interface
vulnerabilities
8. Proprietary network protocols
• You will encounter one
• No docs, specs, tools
• What to do ?
• decompile the client?
• search for some tools?
• watch the raw packets?
• Let’s try!
https://www.flickr.com/photos/canonsnapper/2566562866
10. Ex 1: Secure Pull Printing
“is a modern printing solution that
safeguards document confidentiality and
unauthorized access to print, scan, copy and
e-mail functions. Its user-authentication
provides air-tight security on your shared
MFPs that function as personal printers.”
11. Vendor ensures
„Documents are delivered only into the right hands”
„Information is kept confidential. No risk of being left
unattended at the printer”
„Document collection is safe anytime and anywhere —
no “print and sprint”.”
„Integration with other enterprise applications and
workflows is kept secure through single sign-on”
12. Ex 1: Proprietary protocol
First look on communication
● TCP, 2 ports
● No cleartext, no SSL
● Seems to follow some scheme…
13. Ex1: Deeper sight on traffic
S
E
R
V
E
R
P
R
I
N
T
E
R
constant 263B
96B, “X” B, 128B
always different 64 B
many identical 16B blocks
HELLO
HELLO, CERTIFICATE
SESSION KEY
PostScript, ECB mode
https://en.wikipedia.org/wiki/ECB_mode
15. Ex 1: Reverse-engineered
● Hardcoded RSA certificate in printer embedded
software
● No trust store!
● AES-128 ECB for symmetric cryptography
● More vulnerabilities inside
● Same protocol in admin interface
17. “Many of the devices does not have the
CPU power that allows a fast login response
and at the same time establish a high
security level”
“For example changing ECB to CBC mode
encryption will be more CPU intensive and
introducing that may cause slower
performance of the devices, which the
customers are very reluctant to see
implemented.”
Ex 1: Vendor gets notified
“(…) system has been deployed at many
high security customers and has passed
internal audits.”
18. Ex 2: Responsible vendor
“With its roots in education and the full
understanding that college kids “like to
hack”, our development processes
continually focus on security.”
“Secure print release (…) can integrate
card-swipe user authentication at devices
(…) ensuring jobs are only printed when the
collecting user is present.”
20. Charge user “guest-xyz” for copying 100 pages
Ex 2: Closer look
Release my print queue
Just copied 100 pages
User permissions
beginDeviceTransaction
(…) guest-xyz
Release print queue for user “guest-xyz”
S
E
R
V
E
R
P
R
I
N
T
E
R
guest-abc
22. Ex 2: Vendor gets notified
● KB access and support service
● And all versions of software
● Responded in few hours and patched in few
days
● Was happy to be pentested
23. Ex 3: Secure Print Solutions
“The Secure Print technology offers:
High Security - Jobs only print when
released by the user”
24. Ex 3: Architecture design
● Network level protection
● IP whitelist
● Stateless HTTP service, no session token, no
cookie
25. Ex 3: Authentication request
S
E
R
V
E
R
P
R
I
N
T
E
R
POST /AuthenticateLogin2 HTTP/1.1
(...)
param1=username¶m2=password
27. POST /AuthenticateLogin2 HTTP/1.1
(...)
param1=username¶m2=password
Ex 3: Tampering accountability
S
E
R
V
E
R
P
R
I
N
T
E
R
POST /LogJob HTTP/1.1
(…)
data=<job><job-id>1073741847</job-
id><name>_Print_____1073741847</name><type>103</type><
type-string>Print</type-string><page-cnt>0</page-
cnt><color-page-cnt>0</color-page-
cnt><color>0</color><duplex>0</duplex><page-
size>0</page-size><page-size-
string>Unknown_Size</page-size-
string><media>Unknown</media><dest>UNKNOWN</dest>
<user-name>USER1</user-name><email-
address>unknown@unknown.com</email-address></job>
Just printed a job, note it and charge
29. Ex 3: Vendor gets notified
Received, and will look it over with engineers. I'll
come back to you shortly.
Discussed with engineers, and the reason why
communication was non-SSL, was to support older
Lexmark devices which cannot do SSL.
30. Other vulnerabilities
● Logs and printed files on a default web server
● Brute-force attack in admin/user interfaces, no logs
● XSS and CSRF in web interfaces
● Predictable session identifiers
● DoS attack vulnerability
32. Research problems
Why do vendors fear pentests?
● no direct profit
● risk of finding criticals
● implies a lot of patching
33. Cheat sheet - owners
While deploying a pull printing solution:
● Get it pentested
● Network layer security - IPsec, VLANs
● Verify vendor claims, ask for their SDLC, how
do they handle vulnerabilities
34. Cheat sheet - developers
Encryption between server and printer/user:
● Avoid writing your own crypto
● Use known standards
● Authenticate both side
35. Cheat sheet - developers
Behind the proprietary protocol:
● Access control
● Separate interfaces
● MITM protection is not enough
36. Cheat sheet - testers
Look for vulnerabilities in:
● Encryption, trust stores, cipher suites
● Access control in proprietary protocols
● Infrastructure design
37. What’s next ?
● CVEs disclosure
● A follow-up paper
● Ready to fight new proprietary protocols
I was supposed to tell you some impressive things about me, but let’s just stick to the fact that I am penetration tester at SecuRing, a Polish company operating in Europe. So, apart from threat modelling, auditing and business stuff, we do penetration tests – and yes – we hack almost everything – web and mobile applications, networks, environment and devices – such as ATMs, cash deposits machines and of course – printers. And this is the topic of my research which I am going to present you now.
Let’s take a look on the flow diagram. So, normally a user would print files directly to the printer. In this case, in pull printing, he sends files to the server, it is held in the print queue. Then, the user goes to the printer, authenticates at its screen interface or swipes his card. Then, his print queue is released and the printer collects the print job.
One more thing about Pull Printing Solutions – they offer a lot of funcionality, different access roles, which implies many threat agents, attack vectors and as it turned out – many vulnerabilities
I don’t know why, but it gets accepted into every conference I apply to. We have been presenting this topic and a similar one generally about proprietary network protocols on PHDays in Moscow, CONFidence in Poland and OWASP AppSec is coming in July.
Pull Printing Solutions are everywhere.
They all handle a lot of confidential data.
It’s getting even more popular, not only in top fortune companies but also mid-size and small businesses.
There are some legal conditions which help pull printing business, in Poland, recently, banks were recommended by a government organization to implement a secure printing systems in their offices.
Let’s make a quick threat modelling. What would an owner of such solution not like to happen, what are the key risks ? Anyone ? Let’s get some more interaction.
OK, let’s get back to the flow diagram.
How many of you are pentesters?
Have you encountered a proprietary network protocol?
Do you know the helpless feeling, when you are certain that there have to be many vicious vulnerabilities, but you just can’t get to them – because you don’t know the protocol specification, or don’t have proper tools to attack it?
We have had the same problem many times, and would like to share our experience, based on the real-life examples.
MFP got everything – hard disk, usb port, embedded software, VNC server. Ethernet usb adapter – for bridging the interfaces.
100% hackerproof, Marketing rubbish.
Quantity analysis
So, what were the consequences ? Actually, all of the key risks were broken. And this is some sort of a moment of glory – we even have a special procedure in our company for such criticals, but don’t ask, it’s classified
ECB is faster, but Only when using parallel
Either printers have multi-thread procesor, or they lack computation power.
Widely used on universitites, Ivy League.
We started with basic tests: SQLi in param2, omitting param2, empty param2…
To avoid such situations I prepared short cheatsheets.
Infrastructure – so look for accessible admin interface, possibility for man in the middle, etc.