Skip to main content
Delphix

TB078 Passwordless Login Succeeds to Masking Engine Configured for LDAP

 

 

 

Alert Type

Security

Impact

FIPS 199 Severity Level: Critical

CVSS Score: 10.0 CVSS:3.1

Attack Vector (AV): N

Attack Complexity (AC): L

Privileges Required (PR): N

User Interaction (UI): N

Scope (S): C

Confidentiality (C): H

Integrity (I): H

Availability (A): H

 

A user can successfully login to the masking engine using an empty password when the masking engine is configured to use an LDAP server for authentication and the LDAP server is configured to allow unauthenticated binds.

This arcane aspect of the LDAP protocol has resulted in several other software vulnerabilities. These blog posts are an excellent description of the issue:

Contributing Factors

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases
6.0 6.0.0.0, 6.0.1.0, 6.0.2.0, 6.0.2.1

 

Symptoms

A login request for a user with a blank password to the masking API succeeds when:

  1. The masking engine is configured to use an LDAP server for authentication

  2. The LDAP server is configured to allow unauthenticated binds

If the following curl command succeeds, the installation is affected by this issue:

$ curl --insecure -X POST \
 -H "Content-Type: application/json" \
 https://hostname.example.com/masking/api/login \
 -d "{\"username\":\"myusername\",\"password\":\"\"}"

Relief/Workaround

  • Allowing potential authentication with a domain name and an empty password (in LDAP parlance known as ‘Unauthenticated Bind requests’) is a known deficiency of the LDAP protocol and several LDAP server implementations that follow the latest RFC protocol standard have provisions for turning this behavior off. The recommended setting for LDAP servers is that servers SHOULD by default fail Unauthenticated Bind requests with a resultCode of unwillingToPerform.” See the following excerpt from RFC 4513, Section 5.1.2:

  “Unauthenticated Bind operations can have significant security issues (see Section 6.3.1).  In particular, users intending to perform

   Name/Password Authentication may inadvertently provide an empty password and thus cause poorly implemented clients to

   request Unauthenticated access.  Clients SHOULD be implemented to require user selection of the Unauthenticated Authentication

   Mechanism by means other than user input of an empty password.  Clients SHOULD disallow an empty password input to a

   Name/Password Authentication user interface.  Additionally, Servers SHOULD by default fail

   Unauthenticated Bind requests with a resultCode of unwillingToPerform.”

  • The masking engine LDAP client in the affected 6.0.X releases (see above) has a bug in that it allows input of an empty password.

  • A workaround is to configure the LDAP server to prevent Unauthenticated Bind requests.

    If you have an LDAP server that supports the recommendation of RFC 4513 (released in 2006) you should be able to configure the LDAP server to default fail Unauthenticated Bind requests, per the above paragraph.

This blog post written in 2018 discusses the state of many LDAP servers ability to turn off Unauthenticated Bind requests.

https://blog.lithnet.io/2018/12/disabling-unauthenticated-binds-in.html

Summarizing the above link: All major implementations of LDAP as of 2019 can disable this feature. In 2017, when this earlier blog post was initially written, only Microsoft AD LDS/ADAM, and Microsoft Active Directory servers did not have that capability.

There is no reason to have this capability enabled. It was intended for testing the logging of LDAP servers. The recommended best practice is for servers to disable this and clients to not allow empty passwords.

  • Customers are strongly recommended to upgrade to 6.0.3.0 or later, which has a fix for this LDAP client issue on the masking engine.

Resolution

This issue is fully resolved in the 6.0.3.0 release.