2,067 views
HITB2012AMS Day 2 – PostScript – Danger Ahead
Good morning everyone, welcome back at Hack In The Box 2012 Amsterdam !
Before looking at the first talk that I attended today, I would like to mention that you can find copies of the talks and materials on the hitb.org website. Files are made available right after a talk or lab finishes, you can find them: http://conference.hitb.org/hitbsecconf2012ams/materials/
In addition to that, make sure to check out the following sites for more coverage on Hack In The Box:
- http://blog.rootshell.be/2012/05/24/hitb-amsterdam-wrap-up-day-1/
- http://www.cupfighter.net/index.php/category/conferences/hitb2012ams/
PostScript – Danger Ahead – Hacking MFPs, PCs and beyond
Born and raised in Moldova, Andrei is a Computer Science graduate of the Politechnic University of Bucharest where he did his thesis work in Biometrics and Image Processing. He is the author of the MiFare Classic Universal toolKit (MFCUK), the first publically available (FOSS) card-only key cracking tool for the MiFare Classic RFID card family. You can find some of his previous work at http://andreicostin.com/papers.
Introduction
Multifunctional Printers (MFPs) care large abuse potential. People send confidential data to these devices. They are part of the internal network, a trusted resource, often have LDAP integration with Active Directory, and usually doesn’t have patch/vulnerability management. In some case, some of these devices are even directly accessible from the internet. The history of hacking MFPs goes back to the 1960’s, Andrei continues. Back then, hacking was more focused on the electro-mechanical aspect of the device. After doing a quick scan on the internet in 2010, Andrei was able to find and map out a huge amount of devices on the internet.
Some printer drivers have integration with for example office applications, and other (mgmt) apps allow you to interact with the printer. In other words, there must be some API that accepts certain streams sent to the printer, which could be malicious. Payloads can get delivered via Java… in short, Andrei mentions that you should think twice before printing in certain scenario’s.
What about PostScript?
PostScript was introduced by Adobe in 1985. It is one of the first languages that interact with the printer. It’s built to handle complex processing tasks. It’s a programming language. You can run all kind of things against/on a printer. The initial goal of PostScript started with graphics & patterns, but later extended to include web servers, xml parsers, ray-tracing, milling machines and so on.
PostScript is not just a static data stream, text or image. It’s a
- Dynamically typed
- stack-based
- Turing-complete !
- programming lanugage
Usually, when a user wants to print a document, he writes the doc and hits “Print”. The PS printer driver transforms it to PS stream for a specific device and the PS data stream is sent to the printer.
When the User opens a PS file (email/harddrive), the PC-based PS interpreter processes it (renders it, in a sandboxed environment), and the PS data stream gets executed on the PC. In both cases, the PS data stream IS a PS program, Andrei emphasizes. It’s not static data. On top of that, a lot of applications might have an interpreter/renderer for PostScript, even if you don’t know it. Office, for example, has an embedded interpreter.
Andrei shows a simple demo, using a simple infinite loop to demonstrate a Denial of Service condition. Because it’s a program, IDS/IPS solutions won’t work. You actually need an execution sandbox to determine if a PostScript file is fine or not. To demonstrate the PS dynamic statement construction and execution abilities, he used another simple PS script:
Saving this file as an EPS file, and trying to insert into MS Word as a picture, it makes Word hang. In some cases, you can even make the application crash.
As part of his academic work, Andrei is currently working on building a dynamic execution sandbox for PostScript, which might get released in the weeks to come.
By opening a .ps file, using some custom extensions, you might even be able to directly communicate with the printer. PostScript is a language, so you are even able to detect the environment where the code is running, whether it’s an application or directly on a printer. This way, you can add functionality in the PS script to try to use some kind of social engineering trick (showing an image or so) to try to lure the user into printing the document directly on the printer instead (using the printer web gui, upload the file, print)
Usually, when a user opens a document, and prints it, he expects it to be the same after printing it. Not a lot of people actually verify and confirm that the printed document is exactly the same. Imagine you’re printing a contract that contains figures/numbers, and the numbers get changed on the printer, you might get into trouble.
Where can we find PostScript?
We can PostScript in a lot of applications, including CUPS, Gimp, Tex, MS Office, Adobe, printers. The engines used are GhostScript, Access Softek (MS), Adobe, and some other vendors. GhostScript/MS Office and Adobe apps are typically found on client devices. We can also find components on print servers, and of course printers also include PS support.
PostScript Web 2.0
PostScript made it to the web. Around 20+ services were found to be vulnerable to various degrees (including Google). These services are effective for host exploitation and information gathering. Some of the vulnerable services, Andrei continues, had GhostScript running as root. Some ran GS without -dSAFER. All of them ran vulnerable GS versions, containing Heap and Stack buffer overflows.
What else was found ?
As part of his printer research, he found ways to send things to printers. Once you know how to send things to printers, you need payload. PCL and PS are the 2 obvious choices. PCL is not a language, so PS is the preferred choice. He discovered that some XEROX printers supports PS based firmware. He looked for the PS firmware file and discovered that these are not really obfuscated, and was able to reverse some of its functionality.
If you can get access to RAM, you get everything. Andrei continues to mention that he discovered that the Admin restriction fails to prevent memory dumping. Imagine the admin logs on to the device. If the authentication GET URL contains the password, it will be stored in memory somewhere. In other words, you might be able to “sniff” the admin password by dumping internal memory. Same thing applies if the password is simply base64 encoded. In other words, even if access to the admin page is protected with HTTPS, you might be able to get the password. Andrei shows an example where he could even find the private key for HTTPS in memory.
Regardless of how good the network between the user and the printer is protected, or even the printer supports encrypted documents, it needs to be decrypted inside the printer, becoming clear text again. This certainly provides you with a false sense of security.
Andrei continues by showing a demo against a XEROX printer (issue not fixed yet). To communicate with a printer, the printer driver will set up a tcp connection to port 9100 on the printer, and exchange data. To protect printing of confidential documents, lots of printers support the use of passwords. The user needs to walk over to the printer, enter the password, to get the document. This password is usually stored in the generated PS file and sent to the printer. Once the document is sent, the attacker could connect to the same tcp port, and run a memory dumper to get all data, the passwords, and information about the document, and so on.
Besides getting document information, an attacker can use it as a hop point, and use built-in SDP/UPNP functionality to further map the network, as demonstrated by Andrei. You might even be able to send malicious documents from one printer to another, and create a self spreading worm.
Summing things up, there’s a lot of work that needs to be done to protect against this kind of attacks:
A big number of Xerox printers share the affected PS firmware update mechanism. Xerox is still struggling with trying to fix the issues.
From an attack perspective, these are just a couple of possible scenario’s:
One of the ways to prevent issues, as mentioned earlier, is to build a Secure PostScript Execution/Interpreter Sandbox (Andrei is working on this), containing a set of online/offline tools for analysis & reporting, Wepawet-like, but for PostScript related data.
Take aways
In general, MFPs are badly secured computing platforms with large abuse potential. Upcoming MFP attacks could include viruses in MS Office files, PS documents that extract organization data. Secure the MFP infrastructure require better segmentation, strong credentials and continuous vulnerability patching.
© 2012 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.
Donate
Your donation will help funding server hosting.
