NGNIX is an open-source web server that can also act as a reverse proxy, load balancer, mail proxy, and HTTP cache. The software’s structure is asynchronous and event-driven, allowing it to handle multiple requests at once. NGINX zero day vulnerability is also highly scalable, which means that its service expands in parallel with the traffic of its users.
It all started on April 9th, when a Twitter account linked to a group named @_Blue_hornet tweeted about an experimental NGINX 1.18 attack, claiming to have discovered a zero-day or previously undiscovered security issue in NGINX – a web server used by a third of the world’s websites. The vulnerability appears to be related to how NGINX communicates with LDAP directory services, according to the claims.
“Against the West” – A hacktivist group – made the following claim:
The module relating to the LDAP-auth daemon within Nginx is substantially damaged …
The group further added:
We highly recommend disabling the ldapDaemon.enabled property. If you plan on setting it up, be sure to change the ldapDaemon.ldapConfig properties flag with the correct information and don’t leave it on default. This can be changed until Nginx (#######) respond to their emails and DMs…
To our knowledge, there isn’t a well-known exploit in circulation. It took NGNIX until just after 12:30 PM EST on April 11 to acknowledge receipt of a DM from the group.
However, NGNIX responded:
It’s not an RCE. If any NGINX instance doesn’t talk to LDAP, then it’s useless. Same if you setup a WAF…
The NGINX web server maintainers have revealed three zero-day vulnerabilities in the NGINX Lightweight Directory Access Protocol (LDAP) Reference Implementation module. Bypassing carefully engineered HTTP request headers, malicious attackers can override the configuration parameters and create their own configurations. It’s possible that this will result in an authentication bypass or application breach. In this blog post, we’ll look at how to protect the NGINX LDAP Reference Implementation from three zero-day vulnerabilities.
NGINX further determined that:
Only the reference implementation is affected. NGINX Open Source and NGINX Plus are not themselves affected, and no corrective action is necessary if you do not use the reference implementation.
The NGINX LDAP reference implementation authenticates users of NGINX-proxied applications using LDAP. It’s available as a Python daemon and the associated NGINX settings are available at https://github.com/nginxinc/nginx-ldap-auth.
Note that the LDAP reference implementation describes the integration mechanisms and all components necessary to test the integration. It’s not a production solution. For example, the sample login page does not encrypt the username and password.
When you use NGINX to deploy your application using LDAP Reference Implementation in these three scenarios, things can go wrong.
The LDAP reference implementation has a lot of configuration options. One common method is to configure it using the configuration of command-line options. By submitting specially crafted HTTP request headers, attackers can override some or all of the arguments due to insecure parameter implementation. To prevent this, add the following setting to the location =/auth-proxy block in NGINX configuration file.
location = /auth-proxy {
# ...
proxy_pass_request_headers off;
proxy_set_header Authorization $http_authorization; # If using Basic auth
# ...
}
As in the case above, an attacker can use specially crafted HTTP request headers to override unset configuration parameters. To defend against this, add the following to the location = /auth-proxy block in the NGINX configuration file.
location = /auth-proxy {
# ...
proxy_pass_request_headers off;
proxy_set_header Authorization $http_authorization; # If using Basic auth
# ...
}
An attacker can force LDAP authentication to succeed even if the user does not belong to the relevant groups. This happens due to the Python daemon not sanitizing the data it receives, An attacker can achieve this by using a specially crafted request header to evade the group membership (memberOf) check.
To defend against this, the backend daemon that displays the login form should remove any special characters from the username field. For LDAP servers, the opening and closing parenthesis characters ( ) and the equal sign (=) must be removed. The LDAP reference implementation’s backend daemon will be changed accordingly.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
“Join us on our journey of growth and development by signing up for our comprehensive courses.“
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
