LDAP pass back attack

par | Nov 30, 2023 | Articles techniques, Outils et méthodes

This article describes the methodology for Active Directory domain accounts takeover through LDAP pass back attack on printers.

Note: This article is also available in french 🇫🇷.

Goal 🥅

In the context of an internal infrastructure penetration test, where the auditor has not succeeded in obtaining an Active Directory (AD) domain account — unsuccessful MitM attack, no anonymous enumeration via LDAP / SMB, etc. — the LDAP pass back attack can be used to recover initial access to AD.

Concept 💡

A scenario involving such an attack could be as follows:

  1. Scan the network for printers;
  2. WebUIs with the default account are present (very likely), giving the attacker access to the printer’s administration interface;
  3. An LDAP account is configured (moderately likely) to enable the use of features such as the contact book (e-mailing the scanned document to the designated address);
  4. The password for the LDAP account is not displayed (very likely);
  5. The attacker will change the IP address of the LDAP server to that of a machine under his control;
  6. The attacker will trigger a connection attempt;
  7. The printer will then send the credentials of the LDAP account to the machine under the attacker’s control.

The listening issue 👂

Naive approach — no negotiation, no chocolate 🍫

Some might naively assume that all that’s needed is to set a network socket to listen and receive these identifiers, using tools such as netcat or ncat.

sudo ncat -lvp 389

A very old printer, or one that is woefully vulnerable or poorly configured, could use a rudimentary LDAP authentication algorithm and send credentials in cleartext directly, but fortunately this is not very common and is becoming less and less the case. In such a case, the use of a network socket may suffice.

In the vast majority of cases, however, this will not be sufficient. As we’ll see later, there are many LDAP authentication methods. If the one configured by default in the printer is not a simple method, then the only data we’ll probably receive is an attempt to negotiate algorithms. For SASL, for example, the negotiation will fail, and we won’t have any identifiers to work with.

simple listening via a network socket when using SASL authentication

It’s easy to imagine that a simple network socket won’t be able to emulate or implement the LDAP authentication protocol and negotiate the authentication method to be used.

However, it is unfortunate that there are so many articles on the Internet that simply stop at this point — LDAP back-pass attack with nc — when in reality it has very little chance of working.

Responder : the answer? ↪️

In order to be more efficient, the most interesting thing would be to be able to reuse a tool that acts as an LDAP server.

The Impacket library does not offer an LDAP server. However, the responder tool does.

sudo responder -I <interface>

The LDAP server is integrated into responder, as are many other protocols which automatically listen when the tool is launched and display the authentication attempts received. Simple and effective, wouldn’t you say? Allow me to qualify your enthusiasm.

Unfortunately for us, the negotiation of the authentication method will work correctly and result in the use of a secure mechanism.
As a result, we’ll only recover the hash of an authentication challenge, not a plain-text password.

For example, we recover an NTLVMv1-SSP hash.

NTVMv1-SSP hash capture

There are several possibilities:

But wouldn’t it be significantly easier to retrieve the password in cleartext directly? As a rhetorical question, the answer is obviously yes.

LDAP authentication methods 🔐

As my knowledge of the LDAP protocol is by no means advanced, I cannot guarantee the completeness or veracity of the following information.

As far as I know, there are two main families of LDAP authentication methods.

The SIMPLE family, which isn’t secure at all, supports an anonymous mode and an unauthenticated mode, but we’re not interested in this, as we wouldn’t have any credentials to retrieve in this case, not to mention the fact that if AD supported anonymous login, we could take advantage of it to consult the LDAP database and attempt attacks on accounts.
Finally, this family also includes a mode for sending a username and password. This could have interested us if this simple family were supported. However, there’s a good chance that the printer doesn’t support this family for security reasons, and if it did, we’d have been able to retrieve the password in clear text with nc and not need to read this boring article so far.

The other family is SASL, and again the extent of my knowledge on this subject is not very extensive. Roughly speaking, SASL is an authentication ‟ framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL ”" (from Wikipedia – SASL).
Without taking more time to describe each method, here’s what to remember: we want to target the PLAIN or LOGIN mode. The PLAIN mode allows the password to be sent in clear text, and the word LOGIN is an obsolete variant that has been replaced by PLAIN.

  • SIMPLE
    • anonymous
    • unauthenticated
    • username / password
  • SASL
    • GSSAPI
    • Kerberos 5, Kerberos 4
    • NTLM
    • DIGEST-MD5
    • EXTERNAL
    • TLS, IPC
    • PLAIN
    • LOGIN
    • …

So we’re going to try to deploy an LDAP server that will only pretend to support PLAIN and LOGIN during SASL negotiation.

Deploying a rogue LDAP server 🐛

On the one hand, there are solutions such as glauth, which allow you to configure an LDAP server using a simple INI configuration file. However, it is difficult (if not impossible) to configure a non-secure method.

On the other hand, there are of course real full-featured LDAP servers like OpenLDAP, but these are complex to configure and deploy.

We need the configuration power of OpenLDAP, but we’d like the deployment simplicity of glauth (not spending hours configuring and messing up our system).

Fortunately for us, there’s a compromise: a docker container including an OpenLDAP server specifically configured for our needs.

pedrojosenavasperez/ldap-passback-docker

This will, for example, disable anonymous authentication and enable PLAIN authentication.

For special cases where it would be impossible to use Docker, I’ve adapted a version for Vagrant (virtual machine).

noraj/ldap-passback-vagrant

Let’s get back to business. Deploying the docker container after cloning the git repository is very simple:

docker buildx build -t ldap-passback .
docker run --rm -ti -p 389:389 ldap-passback

Interception with tshark 🦈 — Capture them all 🕸️

It’s all very well to have a server, but our aim is to capture the password in clear text, and it seems unlikely that the server will log the secrets, at most, it might log the login.

This is where tshark — the command-line version of WireShark — comes in. Simply listen on the network interface for all LDAP traffic and extract only authentication attempts using plaintext credentials.

entrypoint.sh

tshark -i any -f "port 389" \
  -Y "ldap.protocolOp == 0 && ldap.simple" \
  -e ldap.name -e ldap.simple -Tjson

We will therefore capture frames as shown below:

  {
    "_index": "packets-2023-09-20",
    "_type": "doc",
    "_score": null,
    "_source": {
      "layers": {
        "ldap.name": [
          "za.tryhackme.com\\svcLDAP"
        ],
        "ldap.simple": [
          "tryhackmeldappass1@"
        ]
      }
    }
  }

You can now shout "Victory".

Where to practice? 🏃

You can practice this attack in TryHackMe’s virtual laboratory:
TryHackMe – Breaching Active Directory – Task 4.

Security tips 🛡️

Here are a few simple suggestions for securing your ink and paper spitting machine (understand printer):

  • Change the default password for the administrator account.
  • If using an LDAP account, set up a robust authentication method.
  • Ensure that the printer’s LDAP account has restricted domain rights.
  • To a lesser extent, secure the printer’s administration interface by restricting access to the administrators’ network or IP addresses, and by enabling HTTPS to prevent MiTM

About the author

Article written by Alexandre ZANNI alias noraj, Penetration Test Engineer at ACCEIS.