Nginx Zero-Day LDAP Reference Implementation Vulnerability Alert
A new zero-day vulnerability in the Nginx web server has been publicly revealed, allowing remote code execution on a vulnerable system.
According to its project website, nginx is an open-source HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server released under the 2-clause BSD-like license. According to Netcraft, nginx served or proxied 25.28% busiest sites in October 2018. Here are some of the success stories: Dropbox, Netflix, WordPress.com, FastMail.FM.
An nginx Zero-Day RCE issue was identified in the nginx LDAP-auth daemon implementation, which was briefly leaked. Twitter user @_Blue_hornet shares some info about this flaw.
Some more information on the #Nginx #0day by @_Blue_hornet as shared via DM and published here with permission: pic.twitter.com/D3sivyrvoD
— Gitworm (@Gi7w0rm) April 9, 2022
nginx Zero-Day RCE flaw affects nginx 18.1. According to the AgainstTheWest Github repo, this bug relates to the LDAP-auth daemon within nginx.
We were initally confused, as LDAP doesn’t interact much with Nginx, however, there is an ldap-auth daemon used alongside Nginx, which allows for this to be used. It primarily is used to gain access to private Github, Bitbucket, Jekins & Gitlab instances. Further testing is required in due time.
Update 1:
As some further analysis is ongoing, the module relating to the LDAP-auth daemon within nginx is affected greatly. 😉 Anything that involves LDAP optional logins works as well. This includes Atlassian accounts. Just working out if we can bypass some common WAFs. Default nginx configs seem to be the vulnerable type, or common configs.
We highly recommend disabling the
ldapDaemon.enabledproperty. If you plan on setting it up, be sure to change theldapDaemon.ldapConfigproperties flag with the correct information and don’t leave it on default. This can be changed until Nginx respond to their emails and DMs.Update 2:
Been talking to some infosec people about this, some mixed responses. Some are saying it’s a problem with LDAP itself and not Nginx, while
ldapDaemonisn’t always used. The exact quote is “CI/CD pipeline hardens the instance, one of the steps is to completely strip out the LDAP module.”. This is partially correct. In fact, it is an option when compiling nginx. However, it could be a problem with LDAP itself.The issue with this, is that it only works with nginx instance using LDAP, such as any login portal that supplies that authentication method.
Further analysis and testing is required. Looks to only be affecting this version. If it affects updated versions of the LDAP protocol, then we’ll see what comes of that.
Hackers have exploited this flaw in the wild. As this vulnerability does not currently have a patch, it is strongly advised that admins using the nginx web server deploy these mitigations as soon as possible.
Update 4:
Regarding what people have been suggesting on twitter and on the issues page about this only being a LDAP or Bitnami issue, the problem with this is, during testing phases, it’s only worked on Nginx, not on Apache or other web servers. Also, Nginx have still not replied. DMs or E-mail. We’ve emailed some companies that are affected that we’ve not breached (since that’s heavily against our ideals) for support on the matter regarding security around this exploit.
Update
On April 11, nginx publishes a blog to describe this flaw. There are security weaknesses in the NGINX LDAP reference implementation. “NGINX Open Source and NGINX Plus are not themselves affected, and no corrective action is necessary if you do not use the reference implementation,” read the blog. This vulnerability only impacts systems with a very particular condition:
You can follow the mitigation methods that were issued by nginx.
