Network printers and Multifunction Devices (MFDs) are very often a part of a corporate network to which little attention is paid. It is not unusual to find such devices on a network during an internal penetration test with default administrative credentials set. Such devices are often configured with useful credentials, however, so that they can interact with other network infrastructure. For example, a scanner might be configured with Active Directory credentials to allow it to upload files or send email.
While these credentials are concealed in the administrative interfaces of such devices, these credentials can actually be extracted and subsequently used by penetration testers to authenticate to other network services if not properly locked down.
This article will walk the reader through examples of extracting SMTP mail service credentials from two different types of MFDs.
Let’s get started
In the first step of this article, we’ll set up a mail server of our own which the affected devices will attempt to authenticate with. This mail server can be used by any sort of MFD device.
The subsequent two steps will contain a walkthrough for how to configure two different types of example MFDs to send their stored credentials to this mail server.
In the final step, we’ll capture and decode the credentials as they are sent to our mail server from an MFD.
Step 1: Configure Your Mail Server
The first step is to set up a new mail server on the network which is under our control. The vulnerable MFD will be reconfigured to send mail through our mail server using the existing (but concealed) credentials. We will monitor the mail transmission and capture the credentials when they are sent to our mail server.
Any SMTP server will work. In this article I’ll use Exim running on Ubuntu 18.04.
1. First, install Exim with apt-get install exim4.
2. Reconfigure with dpkg-reconfigure exim4-config. Answer defaults to all questions except “Split configuration into small files” - answer Yes here.
3. Insert the following exim4 configuration snippet to a new file at /etc/exim4/conf.d/auth/20_authplain:
4. Edit /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs. Comment out the following:
5. Insert the following exim4 configuration snippet to a new file at /etc/exim4/conf.d/main/10_listen_everywhere:
6. Regenerate the master configuration file and restart Exim:
Verify that authentication is enabled:
If you see 250-AUTH PLAIN after the EHLO, you’re all set and ready to make an MFD try to log in to your mail server.
Step 2A: Configuring a Xerox WorkCentre
In this section, you’ll configure a Xerox WorkCentre to send a test message to the mail server set up above using the existing credentials.
1. First, browse to the device with your web browser and log in with the default credentials: username “admin” and password “1111”.
2. Go to the Properties tab across the top and then Services -> Email -> Setup in the navigation tree on the left.
3. Hit the “Edit…” link to the right of the SMTP setting. You’ll end up at the first page of SMTP settings. Be sure to save everything you see here. After you’re finished, you’ll need to revert these.
4. After you’ve saved the production settings somewhere, change the SMTP server to the host name or IP address of your own mail server set up previously. Set it to use port 25. Once you’re finished, hit Save.
5. Next, head over to the Connection Encryption tab. Skip the SMTP Authentication tab. We don’t want to lose what’s already there. Save the settings on this tab to restore later. Set Connection Encryption to “No Encryption.” Click the Save button.
Step 2B: Configuring a Ricoh MP 306Z
In this section, you’ll configure a Ricoh MP 306Z to send messages to the mail server set up above using the existing credentials.
1. The default administrator credentials are username “admin” with a blank password. After logging in and arriving at the home page, go to Device Management -> Configuration. SMTP settings can be found there at Device Settings -> Email.
2. In the SMTP section, configure your mail server’s hostname/IP address, port 25, and set SMTP Auth Encryption to Inactive. Be sure to save prior settings.
3. These devices apparently do not have a way to send a test message on demand. You can set the device up to send various notifications. From the Configuration page, hit Device Settings -> Auto Email Notification. Add any email address to a Group in the “Groups to Notify” section. In the “Select Groups/Items to Notify” check the box for as many notifications as possible. There’s a notification for “Device Access Violation,” but strangely this doesn’t do anything for failed administrative logins. As far as I can tell, one must wait for one of these events to occur naturally.
4. If the device has any scanned documents available on it, you can ask it to send one immediately. From the Home page, go to Print Job/Stored File -> Document Server and look around.
Step 3: Capturing Credentials
You’re ready to have the device log in to your mail server.
1. First, set up a packet capture on your mail server to record the credentials:
The packet capture will be written to a file named pcap. “-s 1500” should reflect the MTU of the interface you’re capturing from. 1500 is typical for Ethernet; “ip addr show” can be used to obtain the correct MTU.
2. With your packet capture set up, make the MFD send a test message or wait for it to send a message naturally.
Once the MFD tries to log in to our mail server with the already-configured credentials, these should now be in our packet capture.
3. Shut down the packet capture with ctrl-C:
4. Use strings to get non-binary content from the packet capture file. We should be able to see the complete SMTP transaction:
5. The line between 334 and 535 Incorrect authentication data is what we’re looking for. That’s the base64-encoded credentials. The username and password are separated by a null. Decode them with any base64 decoder and parse by the nulls:
Voila! You now have some hopefully useful credentials.
Don’t forget to clean up–back on the MFD, restore the original settings you saved.
With a little luck, those are AD credentials and with a little more luck they have access to more than just an SMTP relay. ;)
Conclusion
These often under-looked devices frequently contain useful information which can lead to further compromise, and it is not difficult to extract them. Always have a look for this low hanging fruit on any internal pentest.
