Your browser is out of date.

You are currently using Internet Explorer 7/8/9, which is not supported by our site. For the best experience, please use one of the latest browsers.

866.430.2595
Request a Consultation
banner

How I hacked Your Printer Last Night

Happy Halloween–and National Cybersecurity Month–everyone!

As TRUE’s self-proclaimed, and reigning champion Halloween and Horror Movie Expert – seriously, read my Twitter feed (@bl0ckbuster) sometime – and one of TRUE’s Senior Security Consultants (read: “professional hacker”), I know scary. Like, really scary. No, not just horror movies/books/art/posters/80’s VHS covers/etc.…I’m talking about non-kitsch that is REALLY SCARY.

What kind of scary stuff do I mean? Like ways to break your internal network – particularly using devices that you may have forgotten about, bypassing your defenses to get your data. Financial records, proprietary information about your latest prototypes, medical or student records, stuff like that.

You know, that data that no one who is not an employee should ever have access to…and this includes some of your employees?

So, in the immortal words of Dan Ackroyd: "Want to see something really scary?"

Among my favorite things to see on an internal pentest are printers. Particularly the MFPs (Multi-Function Printers) …you know, the printers with copiers and/or scanners built in, etc. Why? Cause they’re almost always configured with some form of credentials to scan to a network share somewhere, or to email.

What does this mean? Credentials.

Aaron’s 2020 Home Office
I collect Horror Movie posters and collectibles - mainly Slasher stuff, as well as
"spores, mold, and fungus"

 (reference - Egon Spengler from Ghost Busters, 1984)

 

When an MFP has to scan to a network share, most of the time it needs credentials to send the scanned document to that share. When it has to scan to email, it generally needs credentials to connect to a mail server. Now, why is this important? Because many MFPs do not encrypt the credentials that are saved on them, which means that the creds are just sitting on that device, in plaintext, ready for anyone who can access the IP address of the device on that network.

In a former life, I was a sysadmin. I liked doing it. I truly enjoyed finding ways to fix and improve processes that let my clients work smarter and harder. And let’s face it, sysadmins are sometimes pretty lazy with methodology we like to characterize as “efficient”. We’ve invented all kinds of processes, tools, and scripts to make life easier, and they work pretty well. Sometimes, though, we’re lazy in the wrong ways. For instance, when we use the same local admin password throughout the network on all the servers, because “no one will ever see it or use it besides IT”, that’s lazy. I have been guilty of that in past lives. Or not changing the default password on a printer because “no one will ever see it or use it besides IT”. Guilty again. Or how about when you use an unprivileged user account that doesn’t have permission to anything but that share (and every directory in that network share, because we forgot to check the permissions properly)? Say it with me one more time – guilty.

How about that time where you used an unprivileged account that was specifically set up to scan to any network share on your Windows network, but that account didn’t work right, and to save time, you just made it a Domain Admin…and then forgot about it?

GUILTY.

Yep, this happened to me. Did it wreak all sorts of havoc on the network that I managed? I don’t think so, but how would I know without the proper logging and monitoring (which I didn’t have setup because, again, I’m lazy)? Well, that’s a different blog post for a different time. My point is, if I’m guilty of setting up MFPs like this, you could be too. As a matter of fact, now might be a good time to check on that.

Go on, I’ll wait… (whistling Jeopardy theme)

 

Did you check? Good.

How did you log in to the MFP? Did you use a default password? Were there any “unprivileged” accounts on your MFPs? Were those accounts actually unprivileged?

Now that I’m at TRUE and have the expertise to test your networks from this side of the table, I love going after the same mistakes I used to make.

In fact, if this were on an internal pentest, and the MFPs were a part of scope (as they SHOULD BE!), my team probably found them. We also easily looked up the default password and logged in with it, because that password had not been changed. Then, we found the accounts which have been saved to the MFP and used to login to the network shares… and found out what kind of privileges they REALLY had.

We’ve used this attack numerous times, primarily because MFPs are easy, soft targets – they’re setup once, with what’s needed to function properly. As long as they’re working, they’re left alone, never thought about whatsoever because they’re not causing a problem. Often, they just sit in the background and continue to work. They scan to email or the network share, the users are happy, and the sysadmins have other things to worry about. Until someone like me comes along, that is. (Cue ominous music.)

Soft, easy targets. During that internal pentest we just hypothetically performed on your network, we just grabbed those plaintext creds (Domain Admin creds or unprivileged creds – doesn’t matter, we escalated those unprivileged accounts to Domain Admin) and went seamlessly through your network, through your defenses, to get to the target we were coming after – your financials/customer database/medical records/credit cards/proprietary prototype data/etc. All because of an MFP which was setup and configured just once and has been working ever since.

So, how do we fix this? Well, that’s actually the simple part! Here’s your cheat sheet:

  1. CHANGE YOUR DEFAULT PASSWORDS. Good grief. How long have we been saying this? For years’ worth of blog posts now, right?
    1. Choose a strong password for the device, one that meets your company policy at the very least.
    2. Make it a different password for each device. I know this is an absolute pain, but it’s worth it to possibly save you from this type of attack in the long run.
  2. Scan to Network Share – this one takes a little more work…and for the love of all that is holy, DON’T make this account a Domain Admin or any other kind of admin.
    1. To start, use an unprivileged account and disable logon sessions for any and all locations except where the account is directly designed for.
    2. Only allow for that account to WRITE to that share, and not read. This can easily be accomplished in Windows Share/Folder Properties.
  3. Scan to Email – maybe think about allowing certain IPs to connect to the email server without credentials to SEND only…like your MFPs. This could possibly open up other avenues of attacks, sure, but they’re FAR less severe than having plaintext credentials on an MFP. Other than that, the same principles from the Scan to Network Share apply.
  4. Encrypt Credentials - Check if there is any way that you can encrypt the credentials on the device. I’ve not personally seen this as an option on many devices, but it’s possible that it exists.

 And last, but certainly not least… 

  1. Are you troubled by strange traffic on your network? Do you experience feelings of dread in your network closet or server room? Have you or your IT team ever seen a spook, spectre or ghost? If the answer is “yes”, don’t wait another minute. Pick up the phone and call the professionals:

 TRUE DIGITAL SECURITY.

 We have a world class Incident Response team, and our courteous and efficient staff is on call 24/7 for IR, or from 8am – 5pm Monday through Friday to serve your non-emergency supernatural security and risk elimination needs.

WE’RE READY TO SECURE YOU.

Ask A Question