Highlights:
- The maintainers of a web server project, NGINX, share mitigations to solve the security challenges in the LDAP implementation.
- The maintenance team has got expertise in experimental exploitation of NGINX 1.18. They have also found the list of companies and enterprises that have fallen prey to it.
The maintenance team of the NGINX web server project has issued mitigations to overcome security weaknesses in its Lightweight Directory Access Protocol (LDAP) Reference adoption.
Liam Crilly and Timo Stark, working with F5 networks, stated in an advisory published this week, “NGINX Open Source and NGINX Plus are not themselves affected, and no corrective action is necessary if you do not use the reference implementation.”
NGINX stated that the reference adoption that utilizes LDAP to validate users is affected only under three conditions if the deployment includes –
- Command-line parameters to install the Python-based reference adoption daemon.
- Unused, optional configuration parameters.
- Particular group membership to execute LDAP authentication.
If any of the above-mentioned conditions are met, a cybercriminal can potentially override the configuration framework by transmitting specially designed HTTP request headers. and even bypass group membership needs to force LDAP validation to succeed even when the fake authentication user is not from the group.
As a counteract measure, the project maintenance teams have suggested that users ensure that special characters are stripped from the username field in the login form presented while authentication and update appropriate configuration parameters with an empty value (“”).
The maintenance teams also emphasized that the LDAP reference adoption mainly “describes the mechanics of how the integration works and all of the components required to verify the integration” and “it is not a production‑grade LDAP solution.”
The public announcement has come after the details of the issues emerged in the public domain over the weekend when a hacktivist group named Blue Hornet stated it had “gotten our hands on an experimental exploit for NGINX 1.18.”