TL;DR
- Passback attacks involve the reconfiguring of network devices to send stored credentials to an attacker.
- These attacks can be serious and allow an attacker to gain a foothold within an internal network.
- We talk about what exactly it is, how it can occur, demo an example of one, show the impact, and discuss mitigations.
Introduction
Default printer configurations are common to find in internal infrastructure engagements. These configurations are usually insecure, exposing outdated protocols like SNMPv1 and web interfaces without requiring authentication. For an unauthenticated, internal attacker, this can be a treasure trove of information for later exploitation, sometimes including usernames, email addresses and file names:
However, the most desirable scenario for an attacker is saved credentials within the web UI.
But what if the attacker can’t see them? What if they can only change the host the credentials are used to authenticate against? Then maybe the attacker can change this host to one under their control and force a new connection request, leaking the plaintext credentials to them.
This is the basic idea behind a passback attack. Rather than extracting the saved credentials directly, an attacker changes the server that the application or device connects to. When it next tries to authenticate, or is forced to by the attacker, it sends those credentials to a system controlled by the attacker. The technique is not new, but it receives far less attention than attacks involving SMB or Kerberos credential relaying.
In this blog post we will explain and show the common forms such an attack can take, the impact of them and how they can be mitigated.
How passback attacks work
Printers holding saved LDAP credentials, for example, can be useful for organisational and access control reasons, pre-filling their permissions from Active Directory before a user even logs in. Similar reasons for network management and email support are also valid for Simple Network Management Protocol (SNMP) and Simple Mail Transfer Protocol (SMTP) services.
But often, the web interface of the printer is not secured and can be read or even altered by unauthenticated users. It is a scenario I’ve seen numerous times on internal engagements.
Often these interfaces include the ability to change the target host of the connection, sometimes using a low privileged account or without requiring an account at all. If this is the case, an attacker can change the connection string to a host they control, start a listener and execute the connection. Any credentials for any of the above protocols will be leaked in plaintext to the listener and the attacker is rubbing their hands with glee.
Capturing LDAP credentials from a fake printer
To demonstrate this, we whipped up a quick demo of a fake printer interface. The interface has no authentication or authorisation layers and lets users change the LDAP server it queries, mimicking some printer setups we have seen in the wild:
The credentials for a successful LDAP bind are hidden from the client and injected server-side, or printer-side I guess, so they cannot be seen just from looking at the client JavaScript or HTML:
With this setup, an attacker can change the LDAP server option to a host they control and initiate a connection request. The server will inject the plaintext credentials into the request server-side, prior to forwarding onto the attacker’s host. As these are being sent in cleartext, this will leak them to the attacker’s service:
I have used a similar technique in the past to gain authenticated access to a client’s Active Directory during an assessment. Saved credentials for other protocols such as SMTP and SNMP can be exploited the same way.
Preventing passback attacks and limiting their impact
While some third-party software may not ship with the ability to control which users can change the target host for a protocol, administrators can simply not grant printers credentials for other services within the internal network. Without saved credentials, there is no risk here.
If credentials are required for business reasons, there are several mitigations that can be taken to reduce the blast radius of this attack being exploited:
- Enabling authentication controls on devices that support it.
- Strict internal network controls that limit what hosts and ports the device can talk to and what hosts can reach the device.
- Adoption of the least-privilege policy, ensuring that the saved credentials are not overprivileged.