[4.0.0][CE] LDAP: password not being checked while login in

[CAberry]

Description:

Since upgrading to version 4.0.0, we noticed that login with ldap users was successfull even with a wrong password.

Steps to reproduce:

1. Update rocket-ce from 3.8.12 towards 4.0.0 and update mongodb from 4.0.x to 4.2.x (tested with 4.4 and 5.0 as well)
2. Go to rocket login page, type in any ldap user with random password
3. You realized that what ever the password you input, you still gain access to the account

Expected behavior:

Check password and refuse connection if the password does not correspond to ldap.

Actual behavior:

User get logged in as long as they exist in ldap... enven tho the user password is wrong.

Server Setup Information:

• Version of Rocket.Chat Server:
• Operating System: Debian Buster
• Deployment Method: tar
• Number of Running Instances: 1
• DB Replicaset Oplog: Wiredtiger
• NodeJS Version: 12.22.1
• MongoDB Version: 4.2.15

Client Setup Information

• Desktop App or Browser Version: any
• Operating System: any

This is pretty critical IMHO and we should not be an isolated case. For now our service is down as personal information could be accessed by any peer. (We'll use a backup in last resort scenario)

If any more information is needed, please feel free to ask. From what we've seen, logs do not verbose any strange behavior.

Thanks in advance,

[Gummikavalier]

This sounds familiar in a sense that there has been similar issues in the past for instance with Nextcloud. In these cases it may matter whether you use full ldap path for your bind account, limiting the user path to specific OU or using group membership as a requirement to log in. Try playing around with these.

If I remember correctly the issue with Nextcloud was related to how Active Directory LDAP returns answer that user exists in AD during the ldap bind phase, and application is happy with that answer, letting anybody through with an empty password. However some specific conditions were required for that to happen (bind user path, userDN and/or group used in login).

I checked that there is an option in RC 3.18.2 to prevent the issue from affecting the login, but I haven't been able to start RC 4.0 node yet (segfaults), so I cannot tell what our options are in RC 4.0.0 CE (nor in EE).

[himpierre]

Bug confirmed.

[CAberry]

@Gummikavalier This option is definitely activated in 4.0.0 but it does not prevent issue from affecting the login. Thank you for answering and giving some of your time.

Here are the rocket logs concerning LDAP version v4.0.0

{"level":30,"time":"2021-10-05T08:46:26.526Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Connection","msg":"Init Setup"} 
{"level":30,"time":"2021-10-05T08:46:26.526Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Connection","msg":"Connecting","url":"ldap://LDAPSERV_FQDN:389"} 
{"level":30,"time":"2021-10-05T08:46:26.628Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Connection","msg":"LDAP connected"} 
{"level":30,"time":"2021-10-05T08:46:26.629Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Search","msg":"Searching by username","username":"VALID_LOGIN","baseDN":"dc=DOMAIN,dc=fr","searchOptions":{"filter":"(&(|(ou:dn:=collaborateurs)(ou:dn:=personnes))(uid=VALID_LOGIN))","scope":"sub","sizeLimit":2000,"attributes":["*","+"],"paged":{"pageSize":250,"pagePause":false}}} 
{"level":30,"time":"2021-10-05T08:46:26.666Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Search","msg":"LDAP Search found 1 entries and loaded the data of 1."} 
{"level":30,"time":"2021-10-05T08:46:26.666Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Auth","msg":"Authenticating","dn":"uid=VALID_LOGIN,ou=personnes,dc=DOMAIN,dc=fr"} 
{"level":30,"time":"2021-10-05T08:46:26.669Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Auth","msg":"Not authenticated","dn":"uid=VALID_LOGIN,ou=personnes,dc=DOMAIN,dc=fr"} 
{"level":30,"time":"2021-10-05T08:46:26.696Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Search","msg":"LDAP Search found 1 entries and loaded the data of 0."} 
{"level":30,"time":"2021-10-05T08:46:27.069Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Connection","msg":"Disconnecting"} 
{"level":30,"time":"2021-10-05T08:46:27.073Z","pid":24453,"hostname":"inf-rocket","name":"LDAP","section":"Search","msg":"Closed"} 

Obfuscated : LDAPSERV_FQDN, VALID_LOGIN & DOMAIN

Here is LDAP logs on version 3.18.2

Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Connection.info LDAP connected
Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Search.info Searching user VALID_USER
Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Search.info Search result count 1
Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Auth.info Authenticating uid=VALID_USER,ou=personnes,dc=DOMAIN,dc=fr
Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Auth.info Not authenticated uid=VALID_USER,ou=personnes,dc=DOMAIN,dc=fr
Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAPHandler ➔ info Wrong password for VALID_USER
Oct 05 17:18:04 inf-rocket rocketchat[3249]: server.js:204 LDAPHandler ➔ info Fallback to default account system { username: 'VALID_USER' }
Oct 05 17:18:04 inf-rocket rocketchat[3249]: Failed login detected - Username[unknown] ClientAddress[-] ForwardedFor[-] XRealIp[-] UserAgent[-]
Oct 05 17:18:05 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Search.info Idle
Oct 05 17:18:05 inf-rocket rocketchat[3249]: server.js:204 LDAP ➔ Connection.info Disconecting

Clearly, something wrong happened on v4.0.0.

[morenstrat]

Bug confirmed. This is critical.

[ipikiiskinen]

I can't help myself and say that I hope password check is not considered as an advanced LDAP-integration feature.

[gramakri]

I can reproduce this in the Cloudron package quite easily. LDAP users can login with any password. I have revoked our latest 4.0.0 package. The main 4.0.0 release should probably be pulled as well since this is quite a major bug.

[rodrigok]

Thanks for your report, I'm checking this case right now.

[rodrigok]

This PR seems to fix the issue, we will work to have a patch release ASAP