How To Mitigate The 3 0-Day Vulnerabilities In The NGINX LDAP Reference Implementation?

The maintainers of the NGINX web servers have disclosed 3 0-day vulnerabilities in the NGINX LDAP Reference Implementation module. These flaws allow malicious attackers to override the configuration parameters and set their own configurations just by passing specially crafted HTTP request headers. This may end up with an authentication bypass or application compromise. Let’s see how to mitigate the 3 0-day vulnerabilities in the NGINX LDAP Reference Implementation in this post.

NGINX states in its advisory, “Only the reference implementation is affected. NGINX Open Source and NGINX Plus are not themselves affected, and no corrective action is required if you do not use the reference implementation.” 

About NGINX LDAP Reference Implementation:

The NGINX LDAP reference implementation allows using NGINX as an LDAP proxy. This can be useful if you want to use NGINX as a load balancer for your LDAP servers or if you need to implement single sign-on for your website. Since it is released under an open source license, you can customize it as per your needs. It supports both unencrypted and encrypted connections and also supports SASL authentication, so you can use it to authenticate your users.

If you would like to use the NGINX LDAP reference implementation, you will need to install the Python module. You can do this using CPAN or download the module from CPAN and install it manually. Once the Python module is installed, you will need to configure NGINX to use the reference implementation. The reference implementation comes with a sample configuration file that you can use as a starting point.

3 Vulnerabilities In The NGINX LDAP Reference Implementation:

Things can go wrong with your application when you use NGINX to deploy it with LDAP Reference Implementation in these three conditions.

How To Mitigate the 3 0-day Vulnerabilities In The NGINX LDAP Reference Implementation?

Command-Line Parameters:

There are different ways to configure the LDAP reference implementation. Setting up the configuration using command-line parameters is one such prominent way. Insecure implementation of parameters allows attackers to override some or all of the parameters just by sending specially crafted HTTP request headers. A simple solution to protect against this is by setting the appropriate configuration parameters in the location = /auth-proxy block of NGINX’s nginx-ldap-auth.conf file to an empty value.

location = /auth-proxy {
    ...
    proxy_set_header X-Ldap-URL      ""; # Empty value when using command-line
                                        # config
    proxy_set_header X-Ldap-BaseDN  ""; # Empty value when using command-line
                                        # config
    proxy_set_header X-Ldap-BindDN  ""; # Empty value when using command-line
                                        # config
    proxy_set_header X-Ldap-BindPass ""; # Empty value when using command-line
                                        # config
    ...
}

Unused, Optional Configuration Parameters:

A simple solution to protect against this is by setting the unused and optional configuration parameters in the location = /auth-proxy block of NGINX’s nginx-ldap-auth.conf file to an empty value as like in the 1st condition.

location = /auth-proxy {
    ...
    proxy_set_header X-Ldap-Template ""; # Optional, but do not comment
                                        # (use empty value)
    proxy_set_header X-CookieName    ""; # Optional, but do not comment
                                        # (use empty value)
    proxy_set_header X-Ldap-Realm    ""; # Optional, but do not comment
                                        # (use empty value)
    proxy_set_header X-Ldap-Starttls ""; # "True" or empty (do not comment)
    ...
}

LDAP authentication depends on specific group membership

Since the Python daemon does not sanitize its inputs, attackers can bypass the group membership (memberOf) check and force LDAP authentication to succeed even if the authenticated user does not belong to the required groups. Attackers can exploit this vulnerability just by crafting a special request.

To reduce the risk of compromise, make sure the backend daemon that displays the login form removes any special characters from the username field. It must also get rid of the opening and closing parenthesis symbols – ( ) – and the equal sign (=), which all have special meanings for LDAP servers. In time, the backend daemon in this LDAP example will be modified to do so.

We hope this post would help you know How to Mitigate the 3 0-day vulnerabilities in the NGINX LDAP Reference Implementation. Please share this post and help to secure the digital world. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram, and subscribe to receive updates like this. 

You may also like these articles: