Pass Back vulnerabilities: what they are and how dangerous they are

Pass Back vulnerabilities: what they are and how dangerous they are 🧐

There is a whole class of vulnerabilities that at first glance look harmless, and even have a low or medium severity level. But if you dig into the nuances, it no longer seems so harmless.

An example of such a vulnerability is LDAP Pass Back (CVE-2024-32122), which was registered by leading specialist of the PT ESC offensive security department Vladislav Driev together with security analysis specialist at UTsSB Oleg Labyntsev.

This vulnerability allows obtaining credentials from LDAP in cleartext (often these are AD accounts); an attacker only needs to partially change the connector configuration. The vulnerability occurs in various forms and in a wide variety of devices and software products.

An attacker can obtain credentials in cleartext or as a hash from a compromised device or software. A prime example of such devices, of course, are MFPs, but we are definitely not limited to them. Intercoms, cameras, and network equipment can also be vulnerable. As for software, most often it is CMS.

What exactly is the problem 🤔

The problem is that an attacker can influence the configuration of a device that contains credentials. To make it even clearer, let’s give an example. An MFP was configured so that it could send messages via SMTP to email, LDAP authentication was also configured so that the contact list would be loaded dynamically, and SMB as well, so that scanned documents could be immediately placed into a network folder.

Next, let’s consider a situation where an attacker was able to gain access to the web interface using default credentials. In that case, they can try to change the IP address of the configuration that contains the credentials, replacing its IP address with one they control. What will this achieve and why is this even possible? Experience shows that in most cases, changing only the IP address in the configuration is allowed. Accordingly, valid credentials will be used. Thus, the attacker will be able to get a request with correct credentials sent to their IP address, where they can extract them from the traffic either in cleartext or as a hash.

• SMTP (without TLS) often allows obtaining credentials in cleartext.
• LDAP allows obtaining data in cleartext.
• SMB allows obtaining a hash (often NetNTLMv1, from which NTLM Relay can be performed).
• other (credentials for IP telephony, which are wrapped in Base64).

What is insecure here, since access to all configs is hidden behind authentication? Yes, but that is not always the case. Ways to gain access to configurations:

• Default credentials.
• IDOR (listed separately from vulnerabilities because it occurs often).
• A vulnerability for gaining access to the administrator web interface.

There are also cases when several administrators work on a device, they have different roles, but each of them can gain access to connector credentials through this simple trick.

One way or another, the attacker will gain access to the device. After that, they will compromise the credentials and begin developing attacks on adjacent services, in particular on AD. In addition, among all this there are unique and outstanding cases:

• A CMS operates with a domain administrator account.
• An MFP operates with a domain administrator account.

As a result, a low- or medium-severity vulnerability can become a link in the chain of compromising the entire infrastructure.

So, how to avoid this 🧐

The simplest way is, whenever the configuration is changed, to require credentials to be entered again. If an administrator is changing the configuration, this will not be a problem for them. But if it is an attacker, they will get nothing. It is clear that software cannot always be influenced, so before logging in with your account on some new device, you can independently check how it behaves with different configurations, and whether there is any possibility of extracting credentials from it.

Moreover, such accounts should be restricted in rights and taken under monitoring. If reconnaissance in the domain begins under the account’s identity, this is a clear sign of device compromise. And of course, devices and software need to be protected: change default passwords and regularly install updates.

#CVE #offensive
@ptescalator