From Printer To Pwnd
Heiland, Deral
In this presentation we go beyond the common printer issues and focus on harvesting data from multifunction printer (MFP) that can be leveraged to gain access to other core network systems. By taking advantage of poor printer security and vulnerabilities during penetration testing we are able to harvest a wealth of information from MFP devices including usernames, email addresses, and authentication information including SMB, Email, LDAP passwords. Leveraging this information we have successful gained administrative access into core systems including email servers, file servers and Active directory domains on multiple occasions. We will also explore MFP device vulnerabilities including authentication bypass, information leakage flaws. Tying this altogether we will discuss the development of an automated process for harvesting the information from MFP devices with the updated release of our tool 'PRAEDA'. Deral Heiland CISSP, serves as a Senior Security Engineer where he is responsible for security assessments, and consulting for corporations and government agencies. In addition, Deral is the founder of Layered Defense Research a group of security professionals responsible for discovering and publishing multiple vulnerabilities. Deral is also co-founder and president of Ohio Information Security Forum a not for profit organization that focuses on information security training and education. Deral has also presented at numerous conferences including ShmooCon, DEF CON, AFCEA InfoTech, Ohio Digital Government Summit , University of Wisconsin lockdown conference and has also been a guest lecturer at the Airforce Institute of Technology (AFIT). Deral has over 18 years of experience in the Information Technology field, and has held multiple positions including: Senior Network Analyst, Network Administrator, Database Manager, Financial Systems Manager and Senior Information Security Analyst where he was responsible for delivering security guidance and leadership in the area of risk and vulnerability management for a global Fortune 500 manufacturer.
 So let's go ahead and get started. My presentation from printer to phone, leveraging multifunction printers during penetration testing. A little bit about myself. My name is Darryl Hyland. I also go by the handle of %X. I live in a Dayton, Ohio area. I've been in IT for about 18 years. Ten of those in security and three of those as a pen tester. I remember the Fusilin S team. You guys are pretty sad. Okay, this is my third time speaking at DEF CON. This is always fun. Always have a ball being here. So let's go ahead and get started. I do have a guy showing up with a 50 foot because I don't know if anyone's seen me speak before, but tether me on a 5 foot rope can be dangerous. So the agenda for days for this presentation is multifunction printer features. We're going to quickly go over some of the features and functions you typically see in multifunction printers that we want to attack or steal information from. Second, we have a single one slide on multifunction printer security. From there we're going to go to attacking multifunction printer devices and leveraging those attacks during penetration testing. And at the end we'll go ahead and conclude with development of an automated harvesting tool. Okay. Okay. I guess we can get started again. So let's go ahead and move into this. Let's start off by talking about multifunction printer features. So let's go ahead and start off with the multifunction printer features. I'm going to start off with the multifunction printer features. I'm going to start off with the multifunction printer features. I don't like that happening. There we go. Okay. I don't know how many people have actually logged on to the web interface on a multifunction printer, but that's generally what we're going to be talking about today. And there's a wealth of features and functions that can be pulled, information can be pulled out of that. An example here is scan the file functionality. The ability to work with a file, a file, a file, a file, a file, a functionality, the ability to walk up to that multifunction printer and scan data or scan something and actually have it store it on a Microsoft file server or on a FTP server. Also scan the email, the ability to scan stuff and have it go out in email. So these have to be able to integrate into those services, SMTP server, SMB authentication onto Windows devices, such stuff like that. Also one big one is LDAP authentication. The ability to go up to that device, authenticate yourself to that printer and then have that printer give you specific features or functions associated directly with you. Also system logs. A lot of us overlook what kind of information exists in system logs on these devices. And it could be a wealth of information. An example would be color printers a lot of times have charge back functions. So they have to be able to log who's actually using the printer. So a lot of times it will log usernames. That can be stripped off these printers and used. And of course remote functionality with the new cloud concepts coming out there. We're seeing more and more stuff roll into this area. So that's an interesting one. And of course backup and cloning. The ability to back up the entire configuration of the device. So if an attacker can pull the backup and cloning information and then strip it apart offline, he can pull that information in one fell swoop. So the next thing I want to get into is multifunction printer security. So we have one slide. Four steps to security failure on a multifunction device. Pretty straightforward. What do we do? We roll these things in, we power them up. We integrate these into the business system so they connect to our SMTP. They connect to our Microsoft Active Directory environment. They connect to FTP servers. And then the third thing, what do we do? We set no passwords on these. Or we leave them at the factory default password settings. So I have a question for you. So we can qualify there. So quantify this. How many people in here, their company requires you to set a complex password on all multifunction printers that are deployed within your organization. So raise your hands. So everyone else look around the room. That's probably the typical amount that I see. Nobody is doing this. And of course, the last one on this list is no patch management. So if there is a bug or vulnerability that exists in these printers, we're not putting patches on these to fix those problems. So let's roll into the fun stuff. Attacking multifunction printer devices. So why do we want to attack multifunction printer devices? Besides it being fun as hell. Basically to gather information as an attacker. We can gather this information and use it to escalate our rights into other core systems within your environment. So when are we going to typically do this? An example would be if you expose it to the Internet. And I know everyone is thinking why would anyone expose a printer to the Internet? Well, go out to Google when you get a chance and type in there and try to pull out some printer information and you'll find there's literally thousands, hundreds and thousands of printers out on the Internet that are exposed out there. And probably half of them have no password set or default factory passwords. The other example is once somebody gains a foothold into your environment. Whether it's an internal user, a disgruntled employee, or an external attacker who has gained access to your environment. Earlier this year I was on paul.com, episode 237, we were talking about this. And Paul made a real interesting point about this. And that is the fact that this vector falls underneath the radar screen. No one's monitoring it, paying attention to it, no one's logging, or doing any auditing against anyone quarrying information from your printer. It's totally ignored. So if an attacker gets a foothold, he can quarry your printers well below the radar screen, through the web interface, and potentially pull information that he could use to log on to your actor directory environment without anyone ever knowing. So that's a real concern. So how are we going to do this? Obviously leveraging default passwords to get into the printer to start with. We've seen all the hands that were raised, so we know that no one's changing these passwords. Second is access bypass attacks. And that's an attack against a printer where they have set a password, but you've found a way to bypass all the security on the device and gain access to that printer. Third one, information leakages. Once we gain access to that printer, how do we extract some of that data? Do these printers leak that information? Fourth one on their forceful browsing. If you know what the URL you want to get access to, forget about the password you need to get to it with, you just enter that URL and the printer gives you access. And of course backup and cloning functions. The ability to pull all those backups or clones offline and pull the information out of those. And the last one on here is a passback attack. Typically to be able to trick that printer into sending the information to you. We're going to go into some detail in that toward the end of this presentation. So the first one I want to talk about is the bypass attack. This is the ability to bypass the authentication of the device by passing various forms of data in the actual URL. We've got two examples we're going to show today and that's the Toshiba and HP. So on the Toshiba, if you look at this URL, this would give us access to the scan the file configuration page on that printer. If you enter this URL in, the Toshiba is going to take you, or redirect you to a log on page. If you happen to know the default password, which is? No, it's 123456. Okay. So that's the default password. So you know what it is for all the eStudio Toshiba. Okay. Should be easy for you to remember then. Okay. So if they've actually changed the password, how do we get into this device? Well, there's a little trick with this particular device. I don't know if you've noticed there. It's an extra slash. Put the extra slash in between top access and administrator and so goes your security and now you're into the configuration page. So the second example, and this is an HP office device. A lot of you guys probably have these sitting in your home right now. The reason why I mention this is it's a really good example of a bypass attack. Plus, as a pen tester, I've been noticing a large number of these showing up on corporate networks. There's small devices, less than a couple hundred dollars, and we find them actually be used in managers' offices so they don't have to walk down the hallway to get their print job or do little copies and scan stuff and they're cheap. So if you actually try to get to a fax address book on one of these devices and authentication has been enabled, it's going to prompt you to log on. So we have a little demo where we can actually show this taking place. So if we go up to the setting part of this and we click on setting and authentication is required, it's actually going to prompt you for using password. And this is my printer and I actually forgot the password like years ago. So you go ahead, hit cancel and you get to the URL up here where the actual fax address is at. And what you do is you actually copy it and you paste it back in there so we actually have what says page equals, page equals, fax address book one. By adding that extra page equals, we can bypass the security and get to the configurations on the device. So the next area we want to delve into is information leakage. Now that we've gained access to a device because of default passwords or by bypassing the actual security on the device, how can we pull information from this device? So the first one we're going to look at is information leakage on an HP device. This is a gig I did here, it's probably about a year and a half ago. It turned out they had actually exposed this printer to the internet. And besides stealing all their faxes off the device, as you notice that the email settings on this points to one of the employees that's taking care of the device is Gmail account. So as an attacker it would be really nice if you could get the password for their Gmail account because then you could use it to carry out other attacks against them or social engineering attacks. So when you look down here and you look at the password and you see all those black dots, a lot of us go, oh, our password is protected. Well, that's not always the case, especially when we're dealing with embedded devices like multi-function printers. So the big thing here is if you have Firefox you can right click on that field and go show properties. If we expand that up we see that it is basically a plain text password in there. So the next device we move on to is the Toshiba. So if we know the password or in the case of Toshiba bypass the actual password on the device and we want to go to the SMB settings on this device, the Samba settings and take a close look at what we have up there. I mean really close look. We have it set up to log on to the domain and guess what the log on name is, administrator. So wouldn't it be sweet if we right clicked on that and we got the password? Pretty much game over at that point. And remember this is all underneath the radar screen. No one ever knows. You're not generating any noise. You're just logging on with a web browser to a printer, right clicking and viewing the source. And now this device is giving up your domain admin password. So the next one I want to move on to is forceful browsing attacks. Basically with a forceful browsing attack it's a concept of if you know the URL that you want to get to in spite of the security of the device you just type in the URL and you go to it. One of the things I've noticed over many years of looking at embedded devices and multifunction printers is a lot of times they will properly handle security on file extensions that are standard like.cgi.htm.html. But if it's a non-standard type file extension on a lot of printers and a lot of embedded devices you can actually just query for that and it will give it to you without any requirement for authentication. So what we want to look at is the Canon. What's interesting about the Canon printer, we're going to be looking at the address books on this device. Canon printers and a lot of other devices, the address books contain more than what you typically expect an address book to contain or they can. We normally expect to see, you know, username, email address, you know, phone number, typical stuff like that, maybe some fax information. Well it turns out on this particular device there's a lot more information. So let's look into forceful browsing gaining access to that. Again the extensions on this device are the files we're after,.ldif,.abk. Very non-standard file extension. So maybe that plays a role in why we can get access to it. The image runner actually has 11 address books or up to 11 address books that you can query on it. So if you type in this URL you should be able to extract it. But first thing you got to do is you have to have a valid cookie to be able to do this. So if you just type in this URL and point it to your image runner it's going to fail because you don't have a valid cookie. Now I didn't say an authenticated cookie, I said a valid cookie. So if you hit the home page on the printer it will give you a valid cookie. And then enter this in and it'll give you the first address book. If you increment the AID up one through 11 you can get each and every one of the address books. The data typically comes off the address books is in plain text. Also a quick note, early this year I had mentioned that I thought this was patched in a lot of devices because I was getting failures on a number of occasions. Well I started analyzing a number of image runner devices and I noticed that these two models here, these product name IR3580 and IR4080 are the only two that I can find that this fails on. It works on all the others that have this address best book functionality. Not that there may not be a way to get around on these devices but this method fails on them. But it doesn't fail on all the other ones. So let's look at this data. So we pull the address book, we can quickly see that URL information, a username and a password can actually be pulled out of the address book. So what are we looking at? This device is actually configured so you can walk up to the printer and do a scan job after you authenticate yourself as D Smith. And what it will do is it will do the scan job and it will save it on your workstation. That URL happens to be his workstation. I've also seen these configured to point to actual file servers. But predominantly I see it pointing to the individual's workstation. So he can do a scan job and it shows up on his workstation. So now I have the password to his workstation. So I can log on. Well, if they screwed that up and they actually created the username of Canon as an administrator on his local workstation, the next step is I'm admin on his workstation which we've done before. At that point I can extract the hashes associated with all the users on the device, particularly the administrator account, and use that to break in on every other machine on the network that actually has the same administrator password. So the next thing we want to delve into is backups and cloning. Backups, the purpose of backups and cloning is ability one, to make a backup if you configuration of your device which is very important if you need to fix it or rebuild it or whatever the case may be. Xerox really does what they call cloning. It gives them the ability to roll out multiple systems. So if you're rolling out 50 Xerox boxes, Xerox multi-function printers in your environment, you really don't want to go to 50 devices and configure them. So you can pull a clone off one device is configured and deploy it across all these different devices and configure. It's really nice process. So the whole idea of this is if this contains information that we could use to attack you, then of course we can log on, pull this, and we'll all we have usernames and passwords. So let's look at the first one. This is a Lexmark. The settings, import, export, export, setting file functionality and this export file is all in plain text. So we easily go to this page, import, export. We click export, setting file and we're able to extract this and as you see plain text passwords are actually stored in this file. The interesting thing about this device, this particular device that I tested, was that they've done a really good job of not having information linkages. So when you go to the configuration pages, you can't extract the passwords out of the source code. So they've made an attempt to actually secure the device from that level but yet have made it possible for you to actually pull all of the configurations including usernames and passwords off the device in a backup file. The next one we want to delve into is the Xerox. Fairly simple. If you go to log on to Xerox WorkCentra and what's the password for a Xerox WorkCentra? I don't know if I heard it but it's 1111. That seems to be the normal for the WorkCentras. Username is admin. So we get to this, we go to the Xerox WorkCenter, general setup under properties, go to cloning and we have all these settings that you can select to extract the cloning data. You click on that and you get a cloning.dlm file. You right click on this and you can save this. So what is a dlm file? So let's go ahead and show you. Before we do that, the previous example with the Lexmark, we noticed that exports everything out in plain text. Xerox used to do that. They fixed that problem. So the newer stuff, the outputs of the dlm is actually the passwords in encrypted. So we're going to show you the older stuff, the newer stuff, some conversation around that and where we're going with that and how to get access to the dlm data. Everyone see that good? Everyone see that? That shouldn't be. I can't control that. So a typical dlm file that you extract off this, let's go ahead and look at the dlm file. As you can see, it looks like a whole bunch of compressed, encrypted, some kind of data with a header, somewhat of a pgl type header. So I really didn't know what the format of this was. So I spent some time on the internet searching around and I searched and I searched and I searched and I finally found a message board out of Norway, all written in Bork Bork, which I couldn't read, but I knew they were talking about this. So I actually fed it through a translator online and basically the jest was, and it was between two Xerox employees, thank you, that this is nothing but a tar ball. So if that's the case, let's just get rid of this header. Maybe I need to... Oh, need to have a spelled dlm. There we go. Okay, they were able to extract it. So it was a tar ball. The item of interest in this particular extract is under data. So if we search down through there, and obviously you can see it's the entire configuration, mostly in plain text, go down through here, looking at all the passwords. There's one and there's one down here. So we instantly find that the LDAP password is like milk dead. So we're able to extract the data. Now this is what they were doing several years ago. They've actually fixed this, which is a good thing. And that's what this is all about anyway. It's about security, not insecurity. So I like to see companies moving in the right direction. So let's go ahead and look at the other example so we can see what it is. We've already extracted that. And as you can see, it's some kind of encryption. And I have to admit the first time I saw this, I thought, oh, it's just an MD5 hash or something like that. But the truth is, remember, this is the LDAP password. So it has to be some form of encryption and coding. We haven't cracked this yet. So I'm just throwing it out there so you can see this and see where we're thinking, we're moving forward. This has to be some kind of encoding or encryption of the password. It's 32 characters, hex. We also know that it's a clone. So this has to be, have the same keys or the same encryption process on every one of that brand of printer or the clone wouldn't work. So we know that much. So it's consistently reused. Research I've done so far up to this point leads me to believe that the cloning process isn't the part that's encrypting this. That more than likely the encryption mechanism of this is actually being maintained within the Postgres database that these devices use. Using some type of Postgres encryption. And that's where it's being handled. So that's where we're at on that right now. So as we move forward, anyone interested in helping me with this down the road, you know, shoot me an e-mail, definitely open to getting some assistance. Okay, the next area is the pass back attack. This is something I've just been working on, I don't know, over the last four or five months. And it's kind of cool and kind of fun, at least I think it is. So the whole idea of a pass back attack is an attack where we trick the multifunctional printer into communicating to us the attacker versus his configured service as the example. A number of printers we found have a test function on them. So if you go to the LDAP configurations on certain printers, you can hit a test button and it will test the actual authentication of LDAP to the configured LDAP server. And there are some other services that do this also. So the whole gist of this attack starts out with the attacker hits the test button on the printer. The printer authenticates to the LDAP server. The attacker changes the LDAP IP address, hits the test button, the printer nicely authenticates to the attacker, giving us the ability to capture all the authentication data. So let's start with a couple of examples. The first one we're not going to get into a whole lot of detail, but the second one we're going to show you a lot of detail. It turns out here on this sharp printer, if we look at each one of these possible settings on the configuration page, every one of those is passed from client side when you hit the test button. So they are, you have the ability to alter those from the client side versus server side. The sharp printer has the ability to do this on LDAP and SMTP. And like I said, the attacker can send all of these fields except the password field. Password field stored on the printer. So if you can tell the printer to test this using what you have stored on the printer as the password, you get the plain text password. These are the three fields on the sharp printer that we want to alter, the server IP address, the auth type. Because remember, it may be configured to do NTLM or Kerberos, but during the test function you can say, let's just do it in plain text. That way you capture it back. And here is the screen for the sharp for the SMTP settings also. So the next we want to get into, we're going to show a little more detail, is the actual Ryco printer. And the Ryco printer, very similar to the sharp printer, easily to trick into doing this. So if we look at the configurations, of course we have the server IP address, we have the port number. And I reference the port number because if you're attacking this device and they have filters between you and him, that particular port may not make it back to you. So if you can alter that, you can get it to go across any filtering they may have. And of course the authentication type, as you see each we have set there, clear text, digest or Kerberos. And you have the ability client side to alter those during the test function. So this happens to be the test CGI that you post the data to. So what's follows next is an I chart. So this is the data that actually gets posted to that URL up there. The area in red, if it's altered, will typically reconfigure the printer, which is not what you want to do. The area in black is what's used by the test function and does not alter the printer's configuration. The blue areas are the things that I like to alter to carry out this particular attack. And we also have a video demo of this. I want to show you real quick. So it's really, really simple. You go up to the right hand corner on the right code page and you click log on. This password is really easy to remember. It's blank. Enter the user name, enter the user name admin and now you log on to the device. Once you're logged on to the right code printer, it gives you a lot more features and you can go to the configuration page. Under the configuration page you have the default settings and the one we're interested in here is the LDAP settings. As you can see, there's only one LDAP server configured on this. So what you want to do is you want to actually check that box and go ahead and open it up so you can see the configurations. And here we see all the different configurations that are available on this particular device that we want to screw with. So to carry out this attack, we want to set up a netcat, listening port 1389. So we fire that up. We also want to set up a proxy server to grab the content coming from your web browser. Here I'm using Burr but you can easily use Peros proxy also. And then we go back to the configurations. We go down to the start for the test function and we click start. Go back to the Peros or Burr proxy and you can see that iChart that I showed you earlier, it captured all that data. And I gradually go through here and highlight different parts of that or interest and I'm not sure if you can actually see any of that out there. And the area you don't want to screw with because you will reconfigure their printer. You don't want to have to go back and change it. So what we want to do is the attacker, it's fairly simple. We want to change the IP address so it's no longer pointing to the LDAP server. And we want to change the port so it's pointing to us on 1389 so our Netcat listener can grab it. And of course if we want to, we want to alter the auth type if needed. So we sent that and you notice we have a connection coming from that printer to our Netcat. So our Netcat has actually got a connection with the printer. Speed this up a little bit because it took about 45 seconds to run through. But you'll see here real quickly after about 45 seconds the printer nicely passes us the username and the password in plain text. So if you have access to the Sharp or the Ryco printers and they are configured and you want to gather information off of it and these devices don't have a whole lot of leakage problems other than this one here, you can carry out this pass back attack by altering, capturing the data that you send to the test function, telling the printer to instead of communicating the test function to its actual LDAP server, I want you to communicate back to me the attacker and I want you to authenticate to me in plain text, give me the username and password. It gives you the ability to strip the password off the printer. Okay, the next thing we want to move into is actual the tool. So we started developing this tool a while back and it's called PREDA. PREDA is Latin for plunder, spoils the war, booty, thief and that's what its purpose is. Its purpose is to go to typically the web interfaces on your multifunction printers using weak passwords, vulnerabilities and what other methods that we can put together to strip this data that can be used to attack other key systems within your environment. The present version, we actually do have one module that a guy has been working with me on that doesn't use the web interface, it actually uses RSH. It turns out that the RSH on the Ryco printer was an easier method for getting the logs off than going through the web interface. It was easier to parse, it gave it to us in a cleaner fashion. So we go ahead and just pull it that way and then parse the logs that way versus the web interface. So we do have one module that goes outside the web part. The present version is actually written in Perl, version 1.2.beta. We have 17 modules so far extracting data from 40 plus different printer models, cannons, HP, Lexmark, Ryco, Sharp, Toshiba and Xerox printers. Simple how the tool works, it's made up of four pieces. You have the appreta.pl which is a dispatcher. You have individual modules designed to go against certain model types. You feed it a target file list or target list of all the IPs or printers that you want to run this attack against and you have a data file which does fingerprinting. The data file, this is a structure of the data file. There's four plus fields in the data file. The first field is nothing more than a sequence number. The second and third field is the method we use for fingerprinting. The way that works is it pulls the second field looks at the title page of the multifunction printer. The third field looks at the server type and that works probably about 80, 85% of the time on fingerprinting specific models or model series. Then fields four, five, six and continuing out there, the actual modules that are actually used to launch the attacks with. Generally the tool syntax is preta.pl, the target file, the TCP port you want to go to, whether it's 80, 443, 8080, 8000. Then also the project name, what you want to call the project. That creates a folder. Project name creates a folder and the output file is a log file that's generated. All the data this thing gathers writes it into the project folder and also the output log file writes what's taking place and in some of the modules where it extracts specific passwords out it will write it into the output log. This query is the printer's in the target list. If a match is found, the data, the device is attacked, the information is pulled and stored in this method here. So where do we see preta going moving forward in the future? The goal here is, as we mentioned with the Xerox, the password encryption part of that. So we have an ongoing project there to evaluate that and see if we can figure that out. Also a number of other printers have actually started the backup clone files that it generates are all encrypted but the fact is that you enter the password to do the encryption. So it's just a matter of figuring out what encryption they have. You have the password, you can easily decrypt it. So probably analyzing that and trying to find various methods to do that. Once we find those for the different models, we'll build modules to pull the encrypted file and decrypt it and save it for you. We also have talked about actually working on migrating this code over to Ruby. Right now I'm kind of holding off on that. We're going to stick with working in Perl. And the main thing is I want to see this project go to critical mass. Right now we have 17 modules, 40 plus different printer device models we go to. But the thing is I want the tool to be a valid usable tool for pen testers. So we're looking for people to jump in, add value to this. Let's work on actually growing this. And once it reaches critical mass where it becomes a real valid tool used by enough people, then we'll go ahead and reanalyze it. Is Perl the best option? Is Ruby a better option? Could it be incorporated into other tools? Or could it be, you know, written in Python? So right now we're going to stick with the Perl and move forward from there. Also we've been looking at developing other modules besides just printers, multifunction printer devices. There's all kinds of embedded devices sitting on our network. Everything from UPSs, sans systems, cameras, every one of these devices we as pen testers have actually found usable data that can be extracted from these devices. So the goal is to expand this project also to actually include all of those type of devices also. And I plan on releasing probably about a half dozen or more modules that go against network appliances next month when I present this in Bangalore, India. And I think that pretty much covers it. Looks like I went a little fast today. And we got a minute here. Let's, I got a couple of T-shirts to give away. People like T-shirts, right? Well, you have to. So we have the FoofusNet T-shirts. And the thing is, you have to answer a question. So real quick, it's fairly easy. What's the default password? You have to raise your hand because obviously everyone's going to, what's the default password for most work-central printers? The gentleman, gentleman back there in the blue shirt, right here, yeah. So I have, I have an extra large here. You can take one of these. And I think the other one's a 2X. There's a 2X. Also, one more. Okay. What's the default password for a Toshiba E studio printer? No. That's it. Looks like you got stuck with a 2X. I'm sorry. So if anyone has any questions, we'll be over in the question and answer room 2. And please come on over and we'll discuss this further. And I hope to hear some input from everybody. Catch you later. Thank you.
 So let's go ahead and get started. My presentation from printer to  phone, leveraging multifunction printers during penetration testing.  A little bit about myself. My name is Darryl Hyland. I also go by the handle  of %X. I live in a Dayton, Ohio area. I've been in IT for about  18 years. Ten of those in security and three of those as a pen  tester. I remember the Fusilin S team. You guys are pretty  sad. Okay, this is my third time speaking at DEF CON. This is always fun.  Always have a ball being here. So let's go ahead and get started. I do have a guy  showing up with a 50 foot because I don't know if anyone's seen me speak  before, but tether me on a 5 foot rope can be dangerous. So the agenda for  days for this presentation is multifunction printer features. We're going to  quickly go over some of the features and functions you typically see in multifunction  printers that we want to attack or steal information from. Second, we have a  single one slide on multifunction printer security. From there we're going to go  to attacking multifunction printer devices and leveraging those attacks during  penetration testing. And at the end we'll go ahead and conclude with development of  an automated harvesting tool.  Okay.  Okay. I guess we can get started again. So let's go ahead and move into this. Let's  start off by talking about multifunction printer features.  So let's go ahead and start off with the  multifunction printer features. I'm going to start off with the  multifunction printer features. I'm going to start off with the  multifunction printer features. I don't like that happening. There we go.  Okay. I don't know how many people have actually logged on to the web  interface on a multifunction printer, but that's generally what we're going to be  talking about today. And there's a wealth of features and functions that can be  pulled, information can be pulled out of that. An example here is scan the file  functionality. The ability to work with a file, a file, a file, a file, a file, a  functionality, the ability to walk up to that multifunction printer and scan data  or scan something and actually have it store it on a Microsoft file server or on a  FTP server. Also scan the email, the ability to scan stuff and have it go out  in email. So these have to be able to integrate into those services, SMTP server,  SMB authentication onto Windows devices, such stuff like that. Also  one big one is LDAP authentication. The ability to go up to that device,  authenticate yourself to that printer and then have that printer give you specific  features or functions associated directly with you. Also system logs. A lot of us  overlook what kind of information exists in system logs on these devices. And it  could be a wealth of information. An example would be color printers a lot of  times have charge back functions. So they have to be able to log who's actually  using the printer. So a lot of times it will log usernames. That can be stripped off  these printers and used. And of course remote functionality with the new cloud  concepts coming out there. We're seeing more and more stuff roll into this area.  So that's an interesting one. And of course backup and cloning. The ability to  back up the entire configuration of the device. So if an attacker can pull the  backup and cloning information and then strip it apart offline, he can pull that  information in one fell swoop. So the next thing I want to get into is multifunction  printer security. So we have one slide. Four steps to security failure on a  multifunction device. Pretty straightforward. What do we do? We roll these  things in, we power them up. We integrate these into the business system so they  connect to our SMTP. They connect to our Microsoft Active Directory environment.  They connect to FTP servers. And then the third thing, what do we do? We set no  passwords on these. Or we leave them at the factory default password settings. So  I have a question for you. So we can qualify there. So quantify this. How many  people in here, their company requires you to set a complex password on all  multifunction printers that are deployed within your organization. So raise your  hands. So everyone else look around the room. That's probably the typical amount  that I see. Nobody is doing this. And of course, the last one on this list is no  patch management. So if there is a bug or vulnerability that exists in these  printers, we're not putting patches on these to fix those problems. So let's  roll into the fun stuff. Attacking multifunction printer devices. So why do  we want to attack multifunction printer devices? Besides it being fun as hell.  Basically to gather information as an attacker. We can gather this information  and use it to escalate our rights into other core systems within your  environment. So when are we going to typically do this? An example would be  if you expose it to the Internet. And I know everyone is thinking why would  anyone expose a printer to the Internet? Well, go out to Google when you get a  chance and type in there and try to pull out some printer information and you'll  find there's literally thousands, hundreds and thousands of printers out on  the Internet that are exposed out there. And probably half of them have no  password set or default factory passwords. The other example is once somebody  gains a foothold into your environment. Whether it's an internal user,  a disgruntled employee, or an external attacker who has gained access to your  environment. Earlier this year I was on paul.com, episode 237, we were talking  about this. And Paul made a real interesting point about this. And that is  the fact that this vector falls underneath the radar screen. No one's  monitoring it, paying attention to it, no one's logging, or doing any auditing  against anyone quarrying information from your printer. It's totally ignored.  So if an attacker gets a foothold, he can quarry your printers well below the  radar screen, through the web interface, and potentially pull information that  he could use to log on to your actor directory environment without anyone  ever knowing. So that's a real concern. So how are we going to do this?  Obviously leveraging default passwords to get into the printer to start with.  We've seen all the hands that were raised, so we know that no one's changing  these passwords. Second is access bypass attacks. And that's an attack against  a printer where they have set a password, but you've found a way to bypass all the  security on the device and gain access to that printer. Third one, information  leakages. Once we gain access to that printer, how do we extract some of that  data? Do these printers leak that information? Fourth one on their  forceful browsing. If you know what the URL you want to get access to, forget about  the password you need to get to it with, you just enter that URL and the printer  gives you access. And of course backup and cloning functions. The ability to  pull all those backups or clones offline and pull the information out of those.  And the last one on here is a passback attack. Typically to be able to trick  that printer into sending the information to you. We're going to go into some  detail in that toward the end of this presentation. So the first one I want to  talk about is the bypass attack. This is the ability to bypass the authentication  of the device by passing various forms of data in the actual URL. We've got two  examples we're going to show today and that's the Toshiba and HP. So on the  Toshiba, if you look at this URL, this would give us access to the scan the file  configuration page on that printer. If you enter this URL in, the Toshiba is going  to take you, or redirect you to a log on page. If you happen to know the default  password, which is? No, it's 123456. Okay. So that's the default password. So you  know what it is for all the eStudio Toshiba. Okay. Should be easy for you to  remember then. Okay. So if they've actually changed the password, how do we get  into this device? Well, there's a little trick with this particular device. I  don't know if you've noticed there. It's an extra slash. Put the extra slash in  between top access and administrator and so goes your security and now you're into  the configuration page. So the second example, and this is an HP office  device. A lot of you guys probably have these sitting in your home right now. The  reason why I mention this is it's a really good example of a bypass attack. Plus,  as a pen tester, I've been noticing a large number of these showing up on  corporate networks. There's small devices, less than a couple hundred dollars, and  we find them actually be used in managers' offices so they don't have to walk  down the hallway to get their print job or do little copies and scan stuff and  they're cheap. So if you actually try to get to a fax address book on one of these  devices and authentication has been enabled, it's going to prompt you to  log on. So we have a little demo where we can actually show this taking place. So if  we go up to the setting part of this and we click on setting and authentication is  required, it's actually going to prompt you for using password. And this is my  printer and I actually forgot the password like years ago. So you go ahead, hit  cancel and you get to the URL up here where the actual fax address is at. And what  you do is you actually copy it and you paste it back in there so we actually have  what says page equals, page equals, fax address book one. By adding that extra  page equals, we can bypass the security and get to the configurations on the  device. So the next area we want to delve into is information leakage. Now that we've  gained access to a device because of default passwords or by bypassing the  actual security on the device, how can we pull information from this device? So the  first one we're going to look at is information leakage on an HP device. This is  a gig I did here, it's probably about a year and a half ago. It turned out they had  actually exposed this printer to the internet. And besides stealing all their faxes  off the device, as you notice that the email settings on this points to one of the  employees that's taking care of the device is Gmail account. So as an attacker it would  be really nice if you could get the password for their Gmail account because then  you could use it to carry out other attacks against them or social engineering  attacks. So when you look down here and you look at the password and you see all  those black dots, a lot of us go, oh, our password is protected. Well, that's not  always the case, especially when we're dealing with embedded devices like  multi-function printers. So the big thing here is if you have Firefox you can right  click on that field and go show properties. If we expand that up we see that it is  basically a plain text password in there. So the next device we move on to is the  Toshiba. So if we know the password or in the case of Toshiba bypass the actual  password on the device and we want to go to the SMB settings on this device, the  Samba settings and take a close look at what we have up there. I mean really close  look. We have it set up to log on to the domain and guess what the log on name is,  administrator. So wouldn't it be sweet if we right clicked on that and we got the  password? Pretty much game over at that point. And remember this is all underneath  the radar screen. No one ever knows. You're not generating any noise. You're just  logging on with a web browser to a printer, right clicking and viewing the source.  And now this device is giving up your domain admin password. So the next one I  want to move on to is forceful browsing attacks. Basically with a forceful browsing  attack it's a concept of if you know the URL that you want to get to in spite of  the security of the device you just type in the URL and you go to it. One of the  things I've noticed over many years of looking at embedded devices and  multifunction printers is a lot of times they will properly handle security on  file extensions that are standard like.cgi.htm.html. But if it's a non-standard  type file extension on a lot of printers and a lot of embedded devices you can  actually just query for that and it will give it to you without any requirement for  authentication. So what we want to look at is the Canon. What's interesting about  the Canon printer, we're going to be looking at the address books on this device.  Canon printers and a lot of other devices, the address books contain more than  what you typically expect an address book to contain or they can. We normally  expect to see, you know, username, email address, you know, phone number, typical  stuff like that, maybe some fax information. Well it turns out on this  particular device there's a lot more information. So let's look into forceful  browsing gaining access to that. Again the extensions on this device are the files  we're after,.ldif,.abk. Very non-standard file extension. So maybe that plays a  role in why we can get access to it. The image runner actually has 11 address  books or up to 11 address books that you can query on it. So if you type in this  URL you should be able to extract it. But first thing you got to do is you have  to have a valid cookie to be able to do this. So if you just type in this URL and  point it to your image runner it's going to fail because you don't have a valid  cookie. Now I didn't say an authenticated cookie, I said a valid cookie. So if you  hit the home page on the printer it will give you a valid cookie. And then enter  this in and it'll give you the first address book. If you increment the AID up  one through 11 you can get each and every one of the address books. The data  typically comes off the address books is in plain text. Also a quick note, early  this year I had mentioned that I thought this was patched in a lot of devices  because I was getting failures on a number of occasions. Well I started  analyzing a number of image runner devices and I noticed that these two models  here, these product name IR3580 and IR4080 are the only two that I can find that  this fails on. It works on all the others that have this address best book  functionality. Not that there may not be a way to get around on these devices but  this method fails on them. But it doesn't fail on all the other ones. So let's  look at this data. So we pull the address book, we can quickly see that URL  information, a username and a password can actually be pulled out of the address  book. So what are we looking at? This device is actually configured so you can  walk up to the printer and do a scan job after you authenticate yourself as D  Smith. And what it will do is it will do the scan job and it will save it on  your workstation. That URL happens to be his workstation. I've also seen these  configured to point to actual file servers. But predominantly I see it  pointing to the individual's workstation. So he can do a scan job and it shows up  on his workstation. So now I have the password to his workstation. So I can  log on. Well, if they screwed that up and they actually created the username of  Canon as an administrator on his local workstation, the next step is I'm  admin on his workstation which we've done before. At that point I can extract the  hashes associated with all the users on the device, particularly the  administrator account, and use that to break in on every other machine on the  network that actually has the same administrator password. So the next thing  we want to delve into is backups and cloning. Backups, the purpose of backups  and cloning is ability one, to make a backup if you configuration of your device  which is very important if you need to fix it or rebuild it or whatever the case  may be. Xerox really does what they call cloning. It gives them the ability to  roll out multiple systems. So if you're rolling out 50 Xerox boxes, Xerox  multi-function printers in your environment, you really don't want to go to  50 devices and configure them. So you can pull a clone off one device is  configured and deploy it across all these different devices and configure. It's  really nice process. So the whole idea of this is if this contains information  that we could use to attack you, then of course we can log on, pull this, and  we'll all we have usernames and passwords. So let's look at the first one. This is  a Lexmark. The settings, import, export, export, setting file functionality and  this export file is all in plain text. So we easily go to this page, import,  export. We click export, setting file and we're able to extract this and as you  see plain text passwords are actually stored in this file. The interesting  thing about this device, this particular device that I tested, was that they've  done a really good job of not having information linkages. So when you go to the  configuration pages, you can't extract the passwords out of the source code. So  they've made an attempt to actually secure the device from that level but yet  have made it possible for you to actually pull all of the configurations including  usernames and passwords off the device in a backup file. The next one we want to  delve into is the Xerox. Fairly simple. If you go to log on to Xerox WorkCentra  and what's the password for a Xerox WorkCentra? I don't know if I heard it but  it's 1111. That seems to be the normal for the WorkCentras. Username is admin. So  we get to this, we go to the Xerox WorkCenter, general setup under properties,  go to cloning and we have all these settings that you can select to extract  the cloning data. You click on that and you get a cloning.dlm file. You right click  on this and you can save this. So what is a dlm file? So let's go ahead and show  you. Before we do that, the previous example with the Lexmark, we noticed that  exports everything out in plain text. Xerox used to do that. They fixed that  problem. So the newer stuff, the outputs of the dlm is actually the passwords  in encrypted. So we're going to show you the older stuff, the newer stuff, some  conversation around that and where we're going with that and how to get access  to the dlm data. Everyone see that good? Everyone see that? That shouldn't be.  I can't control that. So a typical dlm file that you extract off this, let's go  ahead and look at the dlm file. As you can see, it looks like a whole bunch of  compressed, encrypted, some kind of data with a header, somewhat of a pgl type  header. So I really didn't know what the format of this was. So I spent some time  on the internet searching around and I searched and I searched and I searched  and I finally found a message board out of Norway, all written in Bork Bork,  which I couldn't read, but I knew they were talking about this. So I actually  fed it through a translator online and basically the jest was, and it was between  two Xerox employees, thank you, that this is nothing but a tar ball. So if that's  the case, let's just get rid of this header.  Maybe I need to... Oh, need to have a spelled dlm. There we go. Okay, they were  able to extract it. So it was a tar ball. The item of interest in this particular  extract is under data. So if we search down through there, and obviously you can  see it's the entire configuration, mostly in plain text, go down through here,  looking at all the passwords. There's one and there's one down here. So we  instantly find that the LDAP password is like milk dead. So we're able to  extract the data. Now this is what they were doing several years ago. They've  actually fixed this, which is a good thing. And that's what this is all about  anyway. It's about security, not insecurity. So I like to see companies moving  in the right direction. So let's go ahead and look at the other example so we can  see what it is. We've already extracted that. And as you can see, it's some kind  of encryption. And I have to admit the first time I saw this, I thought, oh, it's  just an MD5 hash or something like that. But the truth is, remember, this is the  LDAP password. So it has to be some form of encryption and coding. We haven't  cracked this yet. So I'm just throwing it out there so you can see this and see  where we're thinking, we're moving forward. This has to be some kind of  encoding or encryption of the password. It's 32 characters, hex. We also know  that it's a clone. So this has to be, have the same keys or the same encryption  process on every one of that brand of printer or the clone wouldn't work. So we  know that much. So it's consistently reused. Research I've done so far up to  this point leads me to believe that the cloning process isn't the part that's  encrypting this. That more than likely the encryption mechanism of this is  actually being maintained within the Postgres database that these devices use.  Using some type of Postgres encryption. And that's where it's being handled. So  that's where we're at on that right now. So as we move forward, anyone interested  in helping me with this down the road, you know, shoot me an e-mail, definitely  open to getting some assistance. Okay, the next area is the  pass back attack. This is something I've just been working on, I don't know,  over the last four or five months. And it's kind of cool and kind of fun, at  least I think it is. So the whole idea of a pass back attack is an attack where  we trick the multifunctional printer into communicating to us the attacker  versus his configured service as the example. A number of printers we found  have a test function on them. So if you go to the LDAP configurations on certain  printers, you can hit a test button and it will test the actual authentication of  LDAP to the configured LDAP server. And there are some other services that do  this also. So the whole gist of this attack starts out with the attacker hits  the test button on the printer. The printer authenticates to the LDAP server.  The attacker changes the LDAP IP address, hits the test button, the printer  nicely authenticates to the attacker, giving us the ability to capture all the  authentication data. So let's start with a couple of examples. The first one  we're not going to get into a whole lot of detail, but the second one we're  going to show you a lot of detail. It turns out here on this sharp printer,  if we look at each one of these possible settings on the configuration page,  every one of those is passed from client side when you hit the test button.  So they are, you have the ability to alter those from the client side versus  server side. The sharp printer has the ability to do this on LDAP and SMTP.  And like I said, the attacker can send all of these fields except the password  field. Password field stored on the printer. So if you can tell the printer  to test this using what you have stored on the printer as the password, you get  the plain text password. These are the three fields on the sharp printer that  we want to alter, the server IP address, the auth type. Because remember, it  may be configured to do NTLM or Kerberos, but during the test function you  can say, let's just do it in plain text. That way you capture it back. And here  is the screen for the sharp for the SMTP settings also. So the next we want to  get into, we're going to show a little more detail, is the actual Ryco printer.  And the Ryco printer, very similar to the sharp printer, easily to trick into  doing this. So if we look at the configurations, of course we have the server IP  address, we have the port number. And I reference the port number because if  you're attacking this device and they have filters between you and him, that  particular port may not make it back to you. So if you can alter that, you can  get it to go across any filtering they may have. And of course the authentication  type, as you see each we have set there, clear text, digest or Kerberos. And you  have the ability client side to alter those during the test function. So this  happens to be the test CGI that you post the data to. So what's follows next is  an I chart. So this is the data that actually gets posted to that URL up  there. The area in red, if it's altered, will typically reconfigure the printer,  which is not what you want to do. The area in black is what's used by the test  function and does not alter the printer's configuration. The blue areas are the  things that I like to alter to carry out this particular attack. And we also  have a video demo of this. I want to show you real quick.  So it's really, really simple. You go up to the right hand corner on the right  code page and you click log on. This password is really easy to remember. It's  blank. Enter the user name, enter the user name admin and now you log on to the  device. Once you're logged on to the right code printer, it gives you a lot  more features and you can go to the configuration page. Under the configuration  page you have the default settings and the one we're interested in here is the  LDAP settings. As you can see, there's only one LDAP server configured on this.  So what you want to do is you want to actually check that box and go ahead and  open it up so you can see the configurations. And here we see all the  different configurations that are available on this particular device that we  want to screw with. So to carry out this attack, we want to set up a  netcat, listening port 1389. So we fire that up. We also want to set up a proxy  server to grab the content coming from your web browser. Here I'm using Burr  but you can easily use Peros proxy also. And then we go back to the configurations.  We go down to the start for the test function and we click start. Go back to  the Peros or Burr proxy and you can see that iChart that I showed you earlier, it  captured all that data. And I gradually go through here and highlight different  parts of that or interest and I'm not sure if you can actually see any of that  out there. And the area you don't want to screw with because you will reconfigure  their printer. You don't want to have to go back and change it. So what we want to  do is the attacker, it's fairly simple. We want to change the IP address so it's  no longer pointing to the LDAP server. And we want to change the port so it's  pointing to us on 1389 so our Netcat listener can grab it. And of course if we  want to, we want to alter the auth type if needed. So we sent that and you  notice we have a connection coming from that printer to our Netcat. So our Netcat  has actually got a connection with the printer. Speed this up a little bit because  it took about 45 seconds to run through. But you'll see here real quickly after  about 45 seconds the printer nicely passes us the username and the password in  plain text. So if you have access to the Sharp or the Ryco printers and they are  configured and you want to gather information off of it and these devices don't  have a whole lot of leakage problems other than this one here, you can carry out  this pass back attack by altering, capturing the data that you send to the  test function, telling the printer to instead of communicating the test function  to its actual LDAP server, I want you to communicate back to me the attacker and I  want you to authenticate to me in plain text, give me the username and password.  It gives you the ability to strip the password off the printer.  Okay, the next thing we want to move into is actual the tool. So we started  developing this tool a while back and it's called PREDA. PREDA is Latin for  plunder, spoils the war, booty, thief and that's what its purpose is. Its purpose  is to go to typically the web interfaces on your multifunction printers using  weak passwords, vulnerabilities and what other methods that we can put together to  strip this data that can be used to attack other key systems within your  environment. The present version, we actually do have one module that a guy has  been working with me on that doesn't use the web interface, it actually uses  RSH. It turns out that the RSH on the Ryco printer was an easier method for  getting the logs off than going through the web interface. It was easier to parse,  it gave it to us in a cleaner fashion. So we go ahead and just pull it that way  and then parse the logs that way versus the web interface. So we do have one  module that goes outside the web part. The present version is actually written  in Perl, version 1.2.beta. We have 17 modules so far extracting data from 40  plus different printer models, cannons, HP, Lexmark, Ryco, Sharp, Toshiba and  Xerox printers. Simple how the tool works, it's made up of four pieces. You have  the appreta.pl which is a dispatcher. You have individual modules designed to go  against certain model types. You feed it a target file list or target list of all  the IPs or printers that you want to run this attack against and you have a data  file which does fingerprinting. The data file, this is a structure of the data  file. There's four plus fields in the data file. The first field is nothing more  than a sequence number. The second and third field is the method we use for  fingerprinting. The way that works is it pulls the second field looks at the  title page of the multifunction printer. The third field looks at the server type  and that works probably about 80, 85% of the time on fingerprinting specific  models or model series. Then fields four, five, six and continuing out there, the  actual modules that are actually used to launch the attacks with. Generally the  tool syntax is preta.pl, the target file, the TCP port you want to go to, whether  it's 80, 443, 8080, 8000. Then also the project name, what you want to call the  project. That creates a folder. Project name creates a folder and the output file  is a log file that's generated. All the data this thing gathers writes it into  the project folder and also the output log file writes what's taking place and  in some of the modules where it extracts specific passwords out it will write it  into the output log. This query is the printer's in the target list. If a match  is found, the data, the device is attacked, the information is pulled and stored  in this method here. So where do we see preta going moving forward in the future?  The goal here is, as we mentioned with the Xerox, the password encryption part of  that. So we have an ongoing project there to evaluate that and see if we can  figure that out. Also a number of other printers have actually started the backup  clone files that it generates are all encrypted but the fact is that you enter  the password to do the encryption. So it's just a matter of figuring out what  encryption they have. You have the password, you can easily decrypt it. So  probably analyzing that and trying to find various methods to do that. Once we  find those for the different models, we'll build modules to pull the encrypted  file and decrypt it and save it for you. We also have talked about actually  working on migrating this code over to Ruby. Right now I'm kind of holding off  on that. We're going to stick with working in Perl. And the main thing is I want  to see this project go to critical mass. Right now we have 17 modules, 40 plus  different printer device models we go to. But the thing is I want the tool to be  a valid usable tool for pen testers. So we're looking for people to jump in,  add value to this. Let's work on actually growing this. And once it reaches critical  mass where it becomes a real valid tool used by enough people, then we'll go  ahead and reanalyze it. Is Perl the best option? Is Ruby a better option? Could it  be incorporated into other tools? Or could it be, you know, written in Python? So  right now we're going to stick with the Perl and move forward from there. Also  we've been looking at developing other modules besides just printers, multifunction  printer devices. There's all kinds of embedded devices sitting on our network.  Everything from UPSs, sans systems, cameras, every one of these devices we as  pen testers have actually found usable data that can be extracted from these  devices. So the goal is to expand this project also to actually include all of  those type of devices also. And I plan on releasing probably about a half dozen or  more modules that go against network appliances next month when I present this  in Bangalore, India. And I think that pretty much covers it. Looks like I went a  little fast today. And we got a minute here. Let's, I got a couple of T-shirts to  give away. People like T-shirts, right?  Well, you have to. So we have the FoofusNet T-shirts. And the thing is, you have to  answer a question. So real quick, it's fairly easy. What's the default password?  You have to raise your hand because obviously everyone's going to, what's the  default password for most work-central printers?  The gentleman, gentleman back there in the blue shirt, right here, yeah. So I have,  I have an extra large here. You can take one of these. And I think the other one's  a 2X. There's a 2X. Also, one more. Okay. What's the default password for a Toshiba  E studio printer? No. That's it. Looks like you got stuck with a 2X. I'm sorry. So  if anyone has any questions, we'll be over in the question and answer room 2. And  please come on over and we'll discuss this further. And I hope to hear some  input from everybody. Catch you later.  Thank you.
DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_0_215.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_216_4907.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_4908_6779.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_6780_7115.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_7116_8459.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_8460_9359.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_9360_10835.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_10836_11075.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_11076_11447.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_11448_12203.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_12204_14339.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_14340_14423.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_14424_15887.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_15888_16103.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_16104_17447.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_17448_19379.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_19380_20387.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_20388_23219.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_23220_24959.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_24960_27803.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_27804_29771.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_29772_31643.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_31644_39143.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_39144_39443.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_39444_39671.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_39672_42947.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_42948_44447.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_44448_44879.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_44880_46739.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_46740_49811.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_49812_50987.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_50988_51155.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_51156_51419.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_51420_54791.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_54792_60311.png DEF_CON_19_-_Deral_Heiland_-_From_Printer_To_Pwnd_PH4pTCmKgOg_1_60312_62270.png
So let's go ahead and get started. My presentation from printer to phone, leveraging multifunction printers during penetration testing. A little bit about myself. My name is Darryl Hyland. I also go by the handle of %X. I live in a Dayton, Ohio area. I've been in IT for about 18 years. Ten of those in security and three of those as a pen tester. I remember the Fusilin S team. You guys are pretty sad. Okay, this is my third time speaking at DEF CON. This is always fun. Always have a ball being here. So let's go ahead and get started. I do have a guy showing up with a 50 foot because I don't know if anyone's seen me speak before, but tether me on a 5 foot rope can be dangerous. So the agenda for days for this presentation is multifunction printer features. We're going to quickly go over some of the features and functions you typically see in multifunction printers that we want to attack or steal information from. Second, we have a single one slide on multifunction printer security. From there we're going to go to attacking multifunction printer devices and leveraging those attacks during penetration testing. And at the end we'll go ahead and conclude with development of an automated harvesting tool. Okay. Okay. I guess we can get started again. So let's go ahead and move into this. Let's start off by talking about multifunction printer features. So let's go ahead and start off with the multifunction printer features. I'm going to start off with the multifunction printer features. I'm going to start off with the multifunction printer features. I don't like that happening. There we go. Okay. I don't know how many people have actually logged on to the web interface on a multifunction printer, but that's generally what we're going to be talking about today. And there's a wealth of features and functions that can be pulled, information can be pulled out of that. An example here is scan the file functionality. The ability to work with a file, a file, a file, a file, a file, a functionality, the ability to walk up to that multifunction printer and scan data or scan something and actually have it store it on a Microsoft file server or on a FTP server. Also scan the email, the ability to scan stuff and have it go out in email. So these have to be able to integrate into those services, SMTP server, SMB authentication onto Windows devices, such stuff like that. Also one big one is LDAP authentication. The ability to go up to that device, authenticate yourself to that printer and then have that printer give you specific features or functions associated directly with you. Also system logs. A lot of us overlook what kind of information exists in system logs on these devices. And it could be a wealth of information. An example would be color printers a lot of times have charge back functions. So they have to be able to log who's actually using the printer. So a lot of times it will log usernames. That can be stripped off these printers and used. And of course remote functionality with the new cloud concepts coming out there. We're seeing more and more stuff roll into this area. So that's an interesting one. And of course backup and cloning. The ability to back up the entire configuration of the device. So if an attacker can pull the backup and cloning information and then strip it apart offline, he can pull that information in one fell swoop. So the next thing I want to get into is multifunction printer security. So we have one slide. Four steps to security failure on a multifunction device. Pretty straightforward. What do we do? We roll these things in, we power them up. We integrate these into the business system so they connect to our SMTP. They connect to our Microsoft Active Directory environment. They connect to FTP servers. And then the third thing, what do we do? We set no passwords on these. Or we leave them at the factory default password settings. So I have a question for you. So we can qualify there. So quantify this. How many people in here, their company requires you to set a complex password on all multifunction printers that are deployed within your organization. So raise your hands. So everyone else look around the room. That's probably the typical amount that I see. Nobody is doing this. And of course, the last one on this list is no patch management. So if there is a bug or vulnerability that exists in these printers, we're not putting patches on these to fix those problems. So let's roll into the fun stuff. Attacking multifunction printer devices. So why do we want to attack multifunction printer devices? Besides it being fun as hell. Basically to gather information as an attacker. We can gather this information and use it to escalate our rights into other core systems within your environment. So when are we going to typically do this? An example would be if you expose it to the Internet. And I know everyone is thinking why would anyone expose a printer to the Internet? Well, go out to Google when you get a chance and type in there and try to pull out some printer information and you'll find there's literally thousands, hundreds and thousands of printers out on the Internet that are exposed out there. And probably half of them have no password set or default factory passwords. The other example is once somebody gains a foothold into your environment. Whether it's an internal user, a disgruntled employee, or an external attacker who has gained access to your environment. Earlier this year I was on paul.com, episode 237, we were talking about this. And Paul made a real interesting point about this. And that is the fact that this vector falls underneath the radar screen. No one's monitoring it, paying attention to it, no one's logging, or doing any auditing against anyone quarrying information from your printer. It's totally ignored. So if an attacker gets a foothold, he can quarry your printers well below the radar screen, through the web interface, and potentially pull information that he could use to log on to your actor directory environment without anyone ever knowing. So that's a real concern. So how are we going to do this? Obviously leveraging default passwords to get into the printer to start with. We've seen all the hands that were raised, so we know that no one's changing these passwords. Second is access bypass attacks. And that's an attack against a printer where they have set a password, but you've found a way to bypass all the security on the device and gain access to that printer. Third one, information leakages. Once we gain access to that printer, how do we extract some of that data? Do these printers leak that information? Fourth one on their forceful browsing. If you know what the URL you want to get access to, forget about the password you need to get to it with, you just enter that URL and the printer gives you access. And of course backup and cloning functions. The ability to pull all those backups or clones offline and pull the information out of those. And the last one on here is a passback attack. Typically to be able to trick that printer into sending the information to you. We're going to go into some detail in that toward the end of this presentation. So the first one I want to talk about is the bypass attack. This is the ability to bypass the authentication of the device by passing various forms of data in the actual URL. We've got two examples we're going to show today and that's the Toshiba and HP. So on the Toshiba, if you look at this URL, this would give us access to the scan the file configuration page on that printer. If you enter this URL in, the Toshiba is going to take you, or redirect you to a log on page. If you happen to know the default password, which is? No, it's 123456. Okay. So that's the default password. So you know what it is for all the eStudio Toshiba. Okay. Should be easy for you to remember then. Okay. So if they've actually changed the password, how do we get into this device? Well, there's a little trick with this particular device. I don't know if you've noticed there. It's an extra slash. Put the extra slash in between top access and administrator and so goes your security and now you're into the configuration page. So the second example, and this is an HP office device. A lot of you guys probably have these sitting in your home right now. The reason why I mention this is it's a really good example of a bypass attack. Plus, as a pen tester, I've been noticing a large number of these showing up on corporate networks. There's small devices, less than a couple hundred dollars, and we find them actually be used in managers' offices so they don't have to walk down the hallway to get their print job or do little copies and scan stuff and they're cheap. So if you actually try to get to a fax address book on one of these devices and authentication has been enabled, it's going to prompt you to log on. So we have a little demo where we can actually show this taking place. So if we go up to the setting part of this and we click on setting and authentication is required, it's actually going to prompt you for using password. And this is my printer and I actually forgot the password like years ago. So you go ahead, hit cancel and you get to the URL up here where the actual fax address is at. And what you do is you actually copy it and you paste it back in there so we actually have what says page equals, page equals, fax address book one. By adding that extra page equals, we can bypass the security and get to the configurations on the device. So the next area we want to delve into is information leakage. Now that we've gained access to a device because of default passwords or by bypassing the actual security on the device, how can we pull information from this device? So the first one we're going to look at is information leakage on an HP device. This is a gig I did here, it's probably about a year and a half ago. It turned out they had actually exposed this printer to the internet. And besides stealing all their faxes off the device, as you notice that the email settings on this points to one of the employees that's taking care of the device is Gmail account. So as an attacker it would be really nice if you could get the password for their Gmail account because then you could use it to carry out other attacks against them or social engineering attacks. So when you look down here and you look at the password and you see all those black dots, a lot of us go, oh, our password is protected. Well, that's not always the case, especially when we're dealing with embedded devices like multi-function printers. So the big thing here is if you have Firefox you can right click on that field and go show properties. If we expand that up we see that it is basically a plain text password in there. So the next device we move on to is the Toshiba. So if we know the password or in the case of Toshiba bypass the actual password on the device and we want to go to the SMB settings on this device, the Samba settings and take a close look at what we have up there. I mean really close look. We have it set up to log on to the domain and guess what the log on name is, administrator. So wouldn't it be sweet if we right clicked on that and we got the password? Pretty much game over at that point. And remember this is all underneath the radar screen. No one ever knows. You're not generating any noise. You're just logging on with a web browser to a printer, right clicking and viewing the source. And now this device is giving up your domain admin password. So the next one I want to move on to is forceful browsing attacks. Basically with a forceful browsing attack it's a concept of if you know the URL that you want to get to in spite of the security of the device you just type in the URL and you go to it. One of the things I've noticed over many years of looking at embedded devices and multifunction printers is a lot of times they will properly handle security on file extensions that are standard like.cgi.htm.html. But if it's a non-standard type file extension on a lot of printers and a lot of embedded devices you can actually just query for that and it will give it to you without any requirement for authentication. So what we want to look at is the Canon. What's interesting about the Canon printer, we're going to be looking at the address books on this device. Canon printers and a lot of other devices, the address books contain more than what you typically expect an address book to contain or they can. We normally expect to see, you know, username, email address, you know, phone number, typical stuff like that, maybe some fax information. Well it turns out on this particular device there's a lot more information. So let's look into forceful browsing gaining access to that. Again the extensions on this device are the files we're after,.ldif,.abk. Very non-standard file extension. So maybe that plays a role in why we can get access to it. The image runner actually has 11 address books or up to 11 address books that you can query on it. So if you type in this URL you should be able to extract it. But first thing you got to do is you have to have a valid cookie to be able to do this. So if you just type in this URL and point it to your image runner it's going to fail because you don't have a valid cookie. Now I didn't say an authenticated cookie, I said a valid cookie. So if you hit the home page on the printer it will give you a valid cookie. And then enter this in and it'll give you the first address book. If you increment the AID up one through 11 you can get each and every one of the address books. The data typically comes off the address books is in plain text. Also a quick note, early this year I had mentioned that I thought this was patched in a lot of devices because I was getting failures on a number of occasions. Well I started analyzing a number of image runner devices and I noticed that these two models here, these product name IR3580 and IR4080 are the only two that I can find that this fails on. It works on all the others that have this address best book functionality. Not that there may not be a way to get around on these devices but this method fails on them. But it doesn't fail on all the other ones. So let's look at this data. So we pull the address book, we can quickly see that URL information, a username and a password can actually be pulled out of the address book. So what are we looking at? This device is actually configured so you can walk up to the printer and do a scan job after you authenticate yourself as D Smith. And what it will do is it will do the scan job and it will save it on your workstation. That URL happens to be his workstation. I've also seen these configured to point to actual file servers. But predominantly I see it pointing to the individual's workstation. So he can do a scan job and it shows up on his workstation. So now I have the password to his workstation. So I can log on. Well, if they screwed that up and they actually created the username of Canon as an administrator on his local workstation, the next step is I'm admin on his workstation which we've done before. At that point I can extract the hashes associated with all the users on the device, particularly the administrator account, and use that to break in on every other machine on the network that actually has the same administrator password. So the next thing we want to delve into is backups and cloning. Backups, the purpose of backups and cloning is ability one, to make a backup if you configuration of your device which is very important if you need to fix it or rebuild it or whatever the case may be. Xerox really does what they call cloning. It gives them the ability to roll out multiple systems. So if you're rolling out 50 Xerox boxes, Xerox multi-function printers in your environment, you really don't want to go to 50 devices and configure them. So you can pull a clone off one device is configured and deploy it across all these different devices and configure. It's really nice process. So the whole idea of this is if this contains information that we could use to attack you, then of course we can log on, pull this, and we'll all we have usernames and passwords. So let's look at the first one. This is a Lexmark. The settings, import, export, export, setting file functionality and this export file is all in plain text. So we easily go to this page, import, export. We click export, setting file and we're able to extract this and as you see plain text passwords are actually stored in this file. The interesting thing about this device, this particular device that I tested, was that they've done a really good job of not having information linkages. So when you go to the configuration pages, you can't extract the passwords out of the source code. So they've made an attempt to actually secure the device from that level but yet have made it possible for you to actually pull all of the configurations including usernames and passwords off the device in a backup file. The next one we want to delve into is the Xerox. Fairly simple. If you go to log on to Xerox WorkCentra and what's the password for a Xerox WorkCentra? I don't know if I heard it but it's 1111. That seems to be the normal for the WorkCentras. Username is admin. So we get to this, we go to the Xerox WorkCenter, general setup under properties, go to cloning and we have all these settings that you can select to extract the cloning data. You click on that and you get a cloning.dlm file. You right click on this and you can save this. So what is a dlm file? So let's go ahead and show you. Before we do that, the previous example with the Lexmark, we noticed that exports everything out in plain text. Xerox used to do that. They fixed that problem. So the newer stuff, the outputs of the dlm is actually the passwords in encrypted. So we're going to show you the older stuff, the newer stuff, some conversation around that and where we're going with that and how to get access to the dlm data. Everyone see that good? Everyone see that? That shouldn't be. I can't control that. So a typical dlm file that you extract off this, let's go ahead and look at the dlm file. As you can see, it looks like a whole bunch of compressed, encrypted, some kind of data with a header, somewhat of a pgl type header. So I really didn't know what the format of this was. So I spent some time on the internet searching around and I searched and I searched and I searched and I finally found a message board out of Norway, all written in Bork Bork, which I couldn't read, but I knew they were talking about this. So I actually fed it through a translator online and basically the jest was, and it was between two Xerox employees, thank you, that this is nothing but a tar ball. So if that's the case, let's just get rid of this header. Maybe I need to... Oh, need to have a spelled dlm. There we go. Okay, they were able to extract it. So it was a tar ball. The item of interest in this particular extract is under data. So if we search down through there, and obviously you can see it's the entire configuration, mostly in plain text, go down through here, looking at all the passwords. There's one and there's one down here. So we instantly find that the LDAP password is like milk dead. So we're able to extract the data. Now this is what they were doing several years ago. They've actually fixed this, which is a good thing. And that's what this is all about anyway. It's about security, not insecurity. So I like to see companies moving in the right direction. So let's go ahead and look at the other example so we can see what it is. We've already extracted that. And as you can see, it's some kind of encryption. And I have to admit the first time I saw this, I thought, oh, it's just an MD5 hash or something like that. But the truth is, remember, this is the LDAP password. So it has to be some form of encryption and coding. We haven't cracked this yet. So I'm just throwing it out there so you can see this and see where we're thinking, we're moving forward. This has to be some kind of encoding or encryption of the password. It's 32 characters, hex. We also know that it's a clone. So this has to be, have the same keys or the same encryption process on every one of that brand of printer or the clone wouldn't work. So we know that much. So it's consistently reused. Research I've done so far up to this point leads me to believe that the cloning process isn't the part that's encrypting this. That more than likely the encryption mechanism of this is actually being maintained within the Postgres database that these devices use. Using some type of Postgres encryption. And that's where it's being handled. So that's where we're at on that right now. So as we move forward, anyone interested in helping me with this down the road, you know, shoot me an e-mail, definitely open to getting some assistance. Okay, the next area is the pass back attack. This is something I've just been working on, I don't know, over the last four or five months. And it's kind of cool and kind of fun, at least I think it is. So the whole idea of a pass back attack is an attack where we trick the multifunctional printer into communicating to us the attacker versus his configured service as the example. A number of printers we found have a test function on them. So if you go to the LDAP configurations on certain printers, you can hit a test button and it will test the actual authentication of LDAP to the configured LDAP server. And there are some other services that do this also. So the whole gist of this attack starts out with the attacker hits the test button on the printer. The printer authenticates to the LDAP server. The attacker changes the LDAP IP address, hits the test button, the printer nicely authenticates to the attacker, giving us the ability to capture all the authentication data. So let's start with a couple of examples. The first one we're not going to get into a whole lot of detail, but the second one we're going to show you a lot of detail. It turns out here on this sharp printer, if we look at each one of these possible settings on the configuration page, every one of those is passed from client side when you hit the test button. So they are, you have the ability to alter those from the client side versus server side. The sharp printer has the ability to do this on LDAP and SMTP. And like I said, the attacker can send all of these fields except the password field. Password field stored on the printer. So if you can tell the printer to test this using what you have stored on the printer as the password, you get the plain text password. These are the three fields on the sharp printer that we want to alter, the server IP address, the auth type. Because remember, it may be configured to do NTLM or Kerberos, but during the test function you can say, let's just do it in plain text. That way you capture it back. And here is the screen for the sharp for the SMTP settings also. So the next we want to get into, we're going to show a little more detail, is the actual Ryco printer. And the Ryco printer, very similar to the sharp printer, easily to trick into doing this. So if we look at the configurations, of course we have the server IP address, we have the port number. And I reference the port number because if you're attacking this device and they have filters between you and him, that particular port may not make it back to you. So if you can alter that, you can get it to go across any filtering they may have. And of course the authentication type, as you see each we have set there, clear text, digest or Kerberos. And you have the ability client side to alter those during the test function. So this happens to be the test CGI that you post the data to. So what's follows next is an I chart. So this is the data that actually gets posted to that URL up there. The area in red, if it's altered, will typically reconfigure the printer, which is not what you want to do. The area in black is what's used by the test function and does not alter the printer's configuration. The blue areas are the things that I like to alter to carry out this particular attack. And we also have a video demo of this. I want to show you real quick. So it's really, really simple. You go up to the right hand corner on the right code page and you click log on. This password is really easy to remember. It's blank. Enter the user name, enter the user name admin and now you log on to the device. Once you're logged on to the right code printer, it gives you a lot more features and you can go to the configuration page. Under the configuration page you have the default settings and the one we're interested in here is the LDAP settings. As you can see, there's only one LDAP server configured on this. So what you want to do is you want to actually check that box and go ahead and open it up so you can see the configurations. And here we see all the different configurations that are available on this particular device that we want to screw with. So to carry out this attack, we want to set up a netcat, listening port 1389. So we fire that up. We also want to set up a proxy server to grab the content coming from your web browser. Here I'm using Burr but you can easily use Peros proxy also. And then we go back to the configurations. We go down to the start for the test function and we click start. Go back to the Peros or Burr proxy and you can see that iChart that I showed you earlier, it captured all that data. And I gradually go through here and highlight different parts of that or interest and I'm not sure if you can actually see any of that out there. And the area you don't want to screw with because you will reconfigure their printer. You don't want to have to go back and change it. So what we want to do is the attacker, it's fairly simple. We want to change the IP address so it's no longer pointing to the LDAP server. And we want to change the port so it's pointing to us on 1389 so our Netcat listener can grab it. And of course if we want to, we want to alter the auth type if needed. So we sent that and you notice we have a connection coming from that printer to our Netcat. So our Netcat has actually got a connection with the printer. Speed this up a little bit because it took about 45 seconds to run through. But you'll see here real quickly after about 45 seconds the printer nicely passes us the username and the password in plain text. So if you have access to the Sharp or the Ryco printers and they are configured and you want to gather information off of it and these devices don't have a whole lot of leakage problems other than this one here, you can carry out this pass back attack by altering, capturing the data that you send to the test function, telling the printer to instead of communicating the test function to its actual LDAP server, I want you to communicate back to me the attacker and I want you to authenticate to me in plain text, give me the username and password. It gives you the ability to strip the password off the printer. Okay, the next thing we want to move into is actual the tool. So we started developing this tool a while back and it's called PREDA. PREDA is Latin for plunder, spoils the war, booty, thief and that's what its purpose is. Its purpose is to go to typically the web interfaces on your multifunction printers using weak passwords, vulnerabilities and what other methods that we can put together to strip this data that can be used to attack other key systems within your environment. The present version, we actually do have one module that a guy has been working with me on that doesn't use the web interface, it actually uses RSH. It turns out that the RSH on the Ryco printer was an easier method for getting the logs off than going through the web interface. It was easier to parse, it gave it to us in a cleaner fashion. So we go ahead and just pull it that way and then parse the logs that way versus the web interface. So we do have one module that goes outside the web part. The present version is actually written in Perl, version 1.2.beta. We have 17 modules so far extracting data from 40 plus different printer models, cannons, HP, Lexmark, Ryco, Sharp, Toshiba and Xerox printers. Simple how the tool works, it's made up of four pieces. You have the appreta.pl which is a dispatcher. You have individual modules designed to go against certain model types. You feed it a target file list or target list of all the IPs or printers that you want to run this attack against and you have a data file which does fingerprinting. The data file, this is a structure of the data file. There's four plus fields in the data file. The first field is nothing more than a sequence number. The second and third field is the method we use for fingerprinting. The way that works is it pulls the second field looks at the title page of the multifunction printer. The third field looks at the server type and that works probably about 80, 85% of the time on fingerprinting specific models or model series. Then fields four, five, six and continuing out there, the actual modules that are actually used to launch the attacks with. Generally the tool syntax is preta.pl, the target file, the TCP port you want to go to, whether it's 80, 443, 8080, 8000. Then also the project name, what you want to call the project. That creates a folder. Project name creates a folder and the output file is a log file that's generated. All the data this thing gathers writes it into the project folder and also the output log file writes what's taking place and in some of the modules where it extracts specific passwords out it will write it into the output log. This query is the printer's in the target list. If a match is found, the data, the device is attacked, the information is pulled and stored in this method here. So where do we see preta going moving forward in the future? The goal here is, as we mentioned with the Xerox, the password encryption part of that. So we have an ongoing project there to evaluate that and see if we can figure that out. Also a number of other printers have actually started the backup clone files that it generates are all encrypted but the fact is that you enter the password to do the encryption. So it's just a matter of figuring out what encryption they have. You have the password, you can easily decrypt it. So probably analyzing that and trying to find various methods to do that. Once we find those for the different models, we'll build modules to pull the encrypted file and decrypt it and save it for you. We also have talked about actually working on migrating this code over to Ruby. Right now I'm kind of holding off on that. We're going to stick with working in Perl. And the main thing is I want to see this project go to critical mass. Right now we have 17 modules, 40 plus different printer device models we go to. But the thing is I want the tool to be a valid usable tool for pen testers. So we're looking for people to jump in, add value to this. Let's work on actually growing this. And once it reaches critical mass where it becomes a real valid tool used by enough people, then we'll go ahead and reanalyze it. Is Perl the best option? Is Ruby a better option? Could it be incorporated into other tools? Or could it be, you know, written in Python? So right now we're going to stick with the Perl and move forward from there. Also we've been looking at developing other modules besides just printers, multifunction printer devices. There's all kinds of embedded devices sitting on our network. Everything from UPSs, sans systems, cameras, every one of these devices we as pen testers have actually found usable data that can be extracted from these devices. So the goal is to expand this project also to actually include all of those type of devices also. And I plan on releasing probably about a half dozen or more modules that go against network appliances next month when I present this in Bangalore, India. And I think that pretty much covers it. Looks like I went a little fast today. And we got a minute here. Let's, I got a couple of T-shirts to give away. People like T-shirts, right? Well, you have to. So we have the FoofusNet T-shirts. And the thing is, you have to answer a question. So real quick, it's fairly easy. What's the default password? You have to raise your hand because obviously everyone's going to, what's the default password for most work-central printers? The gentleman, gentleman back there in the blue shirt, right here, yeah. So I have, I have an extra large here. You can take one of these. And I think the other one's a 2X. There's a 2X. Also, one more. Okay. What's the default password for a Toshiba E studio printer? No. That's it. Looks like you got stuck with a 2X. I'm sorry. So if anyone has any questions, we'll be over in the question and answer room 2. And please come on over and we'll discuss this further. And I hope to hear some input from everybody. Catch you later. Thank you.
multifunction printers during penetration live in a Dayton, Ohio area. I've been in IT for about 18 years. Ten of those in security and this is my third time speaking at DEF CON. This days for this presentation is multifunction testing. And at the end we'll go ahead and conclude with development of an automated harvesting tool. Okay. Okay. I guess we can get start off with the multifunction printer there's a wealth of features and functions that email. So these have to be able to integrate into will log usernames. That can be stripped off multifunction printer security. So we have one to our Microsoft Active Directory environment. printers that are deployed within your vulnerability that exists in these printers, to gather information as an attacker. We can our rights into other core systems within your has gained access to your environment. Earlier he could use to log on to your actor directory on the device and gain access to that printer. about is the bypass attack. This is the ability one of these devices and authentication has been information from this device? So the first one we're going to look at is information leakage on right click on that field and go show properties. want to go to the SMB settings on this device, I thought this was patched in a lot of devices configured to point to actual file servers. But in on every other machine on the network that usernames and passwords. So let's look at the conversation around that and where we're going encryption process on every one of that brand of authentication of LDAP to the configured LDAP first one we're not going to get into a whole lot vulnerabilities and what other methods that we can put together to strip this data that can be also the output log file writes what's taking data, the device is attacked, the information is over and we'll discuss this further. And I hope