Rocket.Chat (JSON) accepting blank password field

[xxxdebug]

Description:

We use RocketChat with our AD servers for LDAP authentication. But we experience some strange behaviour on iOS devices as our users can authenticate without giving a password (read: empty field).

As far as we can see the Android, Windows and webclient do work as expected, seems like the iOS device has no check whether the authentication is correct. This is already investigated by the iOS team of RocketChat seems the API is not validation credentials and just allow anoymous access on the server side.

We have got anonymous binding only open for RootDSE in AD as designed and adviced by Microsoft (microsoft.png). When connecting to the OU where our AD users are in authentication is not possible with anonymous binding.

---

Server Setup Information:

• Version of Rocket.Chat Server: 0.64.1
• Version of Rocket.Chat iOS client: 2.2.0
• Operating System: linux 4.4.0-98-generic
• Deployment Method(snap/docker/tar/etc): snap
• Number of Running Instances: 1
• Node Version: v8.11.1

Steps to Reproduce:

1. Open the iOS app (step1.png)
2. Fill in the username && blank password field (step2.png)
3. Logged in without a password (step3.png)

Expected behavior:

I would expect the system to give an error that the users haven't entered their passwords and cannot login

Actual behavior:

The user is logged in on an iOS device, without entering a password

Relevant logs:

When I try to reproduce the LDAP query with my serviceaccount in AD (ldapsearch) and try to search and/or bind the user I cannot bind or search without entering a password in the particular OU, it is only accepting anonymous bindings on RootDSE. Probably the the iOS client is not checking this or whatsoever.

Also see ldapsearch1.png & ldapsearch2.png

Also when trying to validate to JSON it's giving access without password:

curl -X POST "https://rocketchat.domain.com/api/v1/login" -H "Content-Type: application/json" -d '{"ldapPass": "", "ldapOptions": [], "ldap": true, "username": "firstname.lastname@domain.com"}' {"status":"success","data":{"userId":"zRhXFE7yMcttZq7Ky","authToken":"pewwsqX11BO66WEfFPglDJvvViIi8fwjNbYDcclPfT_"}}

[VareliyK]

it's really (((((

[VareliyK]

It's very big problem. We are waiting the critical patch for all server version.

[rodrigok]

@xxmoC I wasn't able to reproduce your issue.

Can you please contact me at https://open.rocket.chat/direct/rodrigo.nascimento ?

[xxxdebug]

@rodrigok I will drop a DM in a bit to provide you the URL of the test/acceptance server we built, to reproduce the issue in a clean environment with a dummy Active Directory. Meanwhile, @VareliyK you are having the same issue?

[VareliyK]

@rodrigok and @xxmoC i reproduce this problem with version 0.65.1 and 0.64.1 with AD users. We had to disaible our chat, because it's critical vulnerability.

[rodrigok]

@VareliyK can we chat at https://open.rocket.chat/direct/rodrigo.nascimento too? Lets try to find the root cause.

[fsdaniel]

Glad its being looked into! thanks! :)

[VareliyK]

@rodrigok Do you have any news for us ?

[fsdaniel]

@VareliyK If you are desperate you can use this patchy workaround.
https://github.com/fsdaniel/Rocket.Chat/commit/82ba9cedef53c094e7664774f037554290550368

[VareliyK]

@fsdaniel Thank's. Does compilation require for the patch?

[VareliyK]

@rodrigok when you commit this patch ?https://github.com/fsdaniel/Rocket.Chat/commit/82ba9cedef53c094e7664774f037554290550368 ?

[rodrigok]

@VareliyK You don't need this patch, just enable your user Search (Group Validation) set Group OjbjectClass to * and keep the other fields empty.

This is not a Rocket.Chat but, the LDAP (AD only) reply with bind as success but will fail on next requests saying that the bind was not done.

I'll release an option (false by default) to allow empty passwords ASAP for our 3 latests versions

[VareliyK]

@rodrigok It's correct settings ?

[VareliyK]

@rodrigok Thank's! It works, if Login Fallback false. But i still can login with empty password, if Login Fallback - true :(

[rodrigok]

@VareliyK Yes, it will work since the login fallback will store the informed password in Rocket.Chat user's record and will use it if the login on LDAP fails, so if the empty login was working before and you had the login fallback enabled it stored the empty passwords for the users that did login on that time, then, even if the LDAP blocks the login the fallback will be executed and the password will match (empty === empty)

[rodrigok]

The fallback login should be user only if you have some users that should authenticate against the internal account system cuz they are not in your LDAP system. Or if you LDAP server have recurrent outages.

[VareliyK]

@rodrigok i have two questions:

1. how to rewrite empty passwords, if login fallback - true ?
2. Why login the fallback will be executed if account was blocked in the LPAD ? For example, employee left company.

[xxxdebug]

@rodrigok any update on when the new version will be released?

[xxxdebug]

@rodrigok reminder