Shmoocon 2011 Conference Wrap-Up

Getting to ShmooCon each year is always challenging (as is trying to get home). Mother Nature seems to enjoy disrupting the travel to and from the conference, which is held in Washington, D.C in January or February of each year. Despite the weather issues, I've always found it to be a conference worth attending. It features quality talks, leading security researchers sharing thoughts and ideas and several extra events such as "Firetalks" and "Hacker Karaoke".

From Printer to Domain Admin

I've always been fascinated with the concept of attacking printers. The common misconception of "oh, it’s only a printer" makes them a prime target for attackers because people believe that printers pose little to no security risk. This mindset typically translates to the following conditions, which help to fuel my fascination:

• People do not factor printer or MFD (multi-function device) security into their purchasing decisions. Features and cost rank before security in this case.
• Printers are typically a "fire and forget" installation; once they are set up and working no one wants to touch them again for fear of breaking them (as most of us know, users get very upset if they cannot print).
• Organizations are buying more printers as the cost decreases and functionality increases, believing that it leads to increased productivity. I have often heard that more printers have been purchased and installed to prevent people from having to walk too far to the printer. Just how far is too far anyhow? 20 feet? 30 feet? As a cubicle worker, couldn't you benefit from a nice walk to the printer?
• Printers tend to last a long time (in a technology context anyhow)and can be in operation on the network for more than 10 years, long after security updates are available.
• To my knowledge there are no anti-virus or anti-malware products for printers or MFDs.
• Printers may not included in your IT management strategy with respect to vulnerability testing, patch management and security monitoring.

Several security researchers, including myself, have also found that the manufacturers of printers and MFDs often do not implement proper security into the development and implementation of the devices. The vulnerabilities that are being disclosed are relatively simple and well-understood issues outside of the embedded systems space. Vulnerabilities such as password disclosure, authentication bypass, and weak encryption are examples of the problems that have been found.

At this year's conference there were two talks that centered around uncovering vulnerabilities in printers and MFDs. The first was titled "Printer to PWND: Leveraging Multifunction Printers During Penetration Testing" by Derel Heiland and Pete Arzamendi. They targeted devices from three different manufacturers, each with the same twist. The first phase was to identify a vulnerability that would grant them access to the web-based management interface on the devices. Each device took on a slightly different flavor; for example, one device would allow you to bypass authentication by sending multiple parameters to it (such as 'page=page='), others would allow you access by simply putting in an extra "/" when making a request and others allowed you to directly download the configuration backups without prompting for a username and/or password.

The second phase was to look at the information you can collect from the printer. This was broken up into two categories:

• Authentication - Many printers support LDAP for both authenticating users and populating the address book. Once you've gained access to the management interface you are able to read the username and password used to connect to the LDAP or Active Directory server.
• Username/Email address harvesting - Several printers imported the AD address book, which allows you to then use password brute-forcing attempts across the entire domain. Also, the internal logs from several printers allow you to read the usernames of those who have printed to the device.

One of the most glaring vulnerabilities is that the ability to read the passwords to AD or LDAP is as easy as viewing the source code of the management HTML pages. When the management page is displayed, the password field contains the infamous dots that obfuscate the password. However, if you use your web browser to view the HTML source code many printers display the password in clear-text, and a few "encrypt" them (some using base64 encoding).

Derl and Pete created a tool called "PRAEDA" (Latin for “taken in war”, or "booty"), which is a Perl-based tool that will scan for printers that have known vulnerabilities and then extract the information from it, including user lists and credentials.

More Printer “Hijinx”

Another talk on printer security was given titled "Printers Gone Wild" by Ben Smith, and uncovered vulnerabilities in PJL (Printer Job Language), a method for printers to control and manage print jobs and device configuration. PJL can be accessed over port 9100 TCP on many different models of printers, but this talk focused only on those manufactured by Hewlett-Packard.

While the presenter stated that PJL was being replaced by a new method, the install-base of HP PJL-enabled printers is quite large [1]. One of the interesting things about Ben's talk, and the functionality that allowed him to conduct his research and create tools and libraries for exploitation, is that even if SNMP is disabled or blocked, you can still send the printer all of the device management commands over PJL, including changing the display, rebooting the printer and more. Since the PJL port is commonly used to allow users to print, this offers a significant advantage to attackers.

Modern printers, and even older ones, have the ability to store print jobs and other files. Some use a RAMDISK, and others have an actual hard drive. Using the PJL control channel you can upload and download files of your choosing to the printer's storage. Ben created a tool that implements a distributed, compressed and encrypted file system across multiple printers. The tool is called "printFS" and will be released shortly. He also created another tool called "printJack" that allows you to manipulate the printer in different ways, such as changing the display and printing solid black pages.

Evite: Or How Not to Build a Web Application

One of the dangers that always seems to scare me the most about web sites today is how you often do not have a choice about it picking up data about you. Evite is such an example. Take a quick poll of your friends and ask who has used it. Several people will probably state that they have used it to create an invitation for an event. However, if you've been invited to an event via Evite, at the very least your email address is probably still in the Evite system even though you may have never opened the email.

Enter security researcher Trent Lo, a cool suave "dress in all black to look like I lost 5 pounds" security researcher with a devious smile who likes to set up naked parties and his talk "An Evite from Surbo? Probably an Invitation for Trouble". Trent spent some serious time debugging and analyzing the Evite web application. As it turns out, there is little authentication required in order to control events, attendees, messages and more. This means if you can find the unique identifier for an Evite event (called the EID) you can:

• Invite yourself (or other guests)
• Remove guests
• Send messages to all attendees
• Update the status message of any user

While this may not have repercussions on a global scale that affects the worldwide economy or the security of a nation, it does highlight how web application vulnerabilities can manifest themselves. Trent did highlight one XSS vulnerability on the site. However, all of the other problems stem from the way the application was designed. Someone in the audience asked if this could be patched or fixed easily, and Trent's opinion is that in order to fix the vulnerabilities in the Evite system, a complete re-write of the code is required. Even worse, the same problems were found in a previous iteration of the Evite application, then carried forward into the version running today (http://new.evite.com) and remain unpatched. It underscores the importance of building in security from the ground up and testing your application during the development and testing phases to ensure this does not happen. Until then, I imagine that there will be a few parties that will have their dress code changed unexpectedly.

Final Thoughts

This year's ShmooCon was a fantastic experience that included learning from and interacting with the security community. It highlighted that there are several other people who are looking into printer and embedded device security, encountering them on security assessments and seeing the same problems as I've highlighted in the past. Web applications also continue to be problematic when it comes to security, and especially shows when security architecture is left out completely. I also had several conversations where the term "penetration testing" was defined. I believe there are exciting ideas and efforts in this area, and I was honored to meet with some of the top penetration testers to begin to hash out an “official definition” of a penetration test. As always, I am looking forward to next year already!

[1] Over 10.5 million printer shipments in 2005 by HP alone. Source: "Hacking printers: for fun and profit" by Andrei Costin at Hack.lu 2010 [Note: This is a fantastic read, and includes ideas for setting printers on fire!. However, I do not condone this behavior in any way shape or form, unless you have permission to do so and its in a controlled environment (and that you capture it on video and send it to me].