Netcat and MFD’s – The Gifts That Keep on Giving

It’s fairly well known that printers and MFDs can be a gateway to compromise on otherwise secured networks. We regularly encounter networks filled with these devices internal tests and (ab)use their functionality in various ways, including harvesting usernames, share names, and email addresses. We can also use them to harvest credentials! Follow along to learn how I used netcat and Wireshark to harvest domain credentials from an MFD.

Getting In

The first step in harvesting information from these devices is often finding the default password for the device. Fortunately, these are rarely changed from the defaults, and manufacturer documentation is available online and a simple search away 99.9% of the time.

Such was the case on a recent assesment where I encountered a Ricoh MP C2504ex device. A quick search confirmed that the username was admin and the password was blank – literally don’t enter a password. I’m in!

Once logged into the device, I reviewed the various menus, looking for things like passwords saved in a scan-to-share function, address books, etc. Eventually I found a scan-to-email function that included the ability to load a list of users via an LDAP query. I found this device was already configured and pointed at one of the target’s domain controllers.

I noted that the interface showed a user name was already populated but I couldn’t view the password. The device included the ability to test the connection, meaning I could trigger an LDAP bind and lookup to my testing box!

I reconfigured the device to point to my dropbox, set up a netcat listener on port 389, and pressed the start button. I saw the device connect to my netcat listener, but I didn’t see any credentials. It turns out the device wanted me to speak LDAP, and simply establishing the connection was not enough to trigger the authentication. Time to put my thinking cap on.

Enter Netcat Relays

Netcat is known as the TCP/IP Swiss Army Knife for good reason. It’s incredibly useful as a diagnostic tool to initiate and receive connections. But the real power of netcat comes from it’s ability to glue connections together.

Unix systems have a file type known as a named pipe or FIFO. These are similar to a real pipe in that you push data in on one side, and it comes out the other. More importantly, these named pipes are bidirectional, meaning we can use them to allow two separate processes to communicate with each other using a file on the file system.

To use a named pipe, you first have to create it using the mknod command. In this case, I created a pipe named backpipe using the following command. The ‘p’ at the end tells mknod we want to create a pipe.

mknode backpipe p

Next, I needed to set up my netcat relay. Doing this requires several commands pipelined together. The full command I used was:

nc -l -p 389 0<backpipe | nc dc_ip 389 | tee backpipe

Let’s break that down. nc -l -p 389 runs a netcat listener (-l) on port 389 (-p 389). Netcat is bidirectional and normally takes it’s input from standard input, aka STDIN or File Descriptor 0. 0<backpipe tells this netcat listener to get it’s input from our named pipe, backpipe.

Netcat’s output normally goes to the screen. Here, I piped the output of that netcat listener – the connection I’m receiving from the MFD – into a new netcat process which will connect to the LDAP port on the target DC. I do this with the following command which launches a new instance of netcat in client mode, connecting to the DC on TCP port 389.

| nc dc_ip 389

Finally, I take the output of the netcat client connection to the DC – the responses from the LDAP server – and direct that output back into the named pipe using the tee command. This sends it back to my netcat listener, who gladly sends that data back to the MFD and also sends a copy of the output back to the screen.

As you can see in the following screenshot, once I clicked the connection test start button, I received a netcat connection from the MFD which was relayed to the DC, and the DC’s responses were relayed to the MFD, making a fully-functional LDAP connection. Unfortunately, I couldn’t actually see the credentials in the output!

Putting It All Together

Enter the final piece of the puzzle. While the MFD was using unencrypted LDAP, the credentials weren’t viewable in the netcat output. I used tcpdump to perform a packet capture of the connection and used Wireshark to decode the bind request and recover the credentials. As you can see in the following screenshot, I was able to recover the username and password for the service account used by the MFD to query LDAP.

TLDR

Printers and MFDs often make use of some kind of service accounts for LDAP lookups, scanning files to file shares, sending email, etc. These service accounts often have elevated privileges in the domain. Even without elevated privileges, the credentials we recover from MFDs are often the first foothold into the network.

You may be tempted to just overlook these devices when you encounter them on your pen tests. I encourage you to slow down, dig a little deeper, and mine these devices for all the gold they can hold.