Univention Bugzilla – Bug 39939
Self Service allows scanning for usernames
Last modified: 2021-06-23 07:29:05 CEST
If a unknown username has been entered during password reset, the following message is returned: "Unbekannter Benutzer 'user5'" With this message, it is possible to scan for all valid usernames within the UCS domain. It would be better, if the backend returns the same error message as if no contact information have been deposited.
Created attachment 7317 [details] Change reply to the same as with bad password.
Forget that patch - it doesn't solve the problem.
Fixed with commit 65892 (incl YAML). If an unknown username is provided, the error message is now the same as for users that have not (yet) registered a contact.
The the last commit only get_reset_methods() was protected against scanning for usernames, but the other functions could be used in the same way. Commit 65893 changes that.
Still possible in various ways: > curl 'http://10.200.27.30/univention-self-service/passwordreset/send_token' -H 'Accept-Language: en-US' -H 'Content-Type: application/json' -H 'X-Requested-With: XMLHttpRequest' --data-binary '{"username":"anton2","method":"foobar"}' {"message": "Unknown recovery method 'foobar'."} → user/mail address exists > curl 'http://10.200.27.30/univention-self-service/passwordreset/send_token' -H 'Accept-Language: en-US' -H 'Content-Type: application/json' -H 'X-Requested-With: XMLHttpRequest' --data-binary '{"username":"anton","method":"foobar"}' {"message": "No contact information to send a token for password recovery to has been found."} → user/mail address doesn't exists. get_reset_methods() is still vulnerable because you can expect a specific response for existing users. Requiring the password here would solve this. If you are able (due to a race condition and multiple module processes) to have mutliple tokens in the database you can also use set_password() to guess usernames. It's possible also to guess usernames because they are blacklisted. Every "Domain Administrator" username can therefore be gained. If the ldap server is down some exceptions are also providing information because you know in which lines LDAP operations are done (and not done if the user is okay). The implementation is also a little bit error prone to future adaptions because the string literals are copied. I took the bug and corrected all those points in svn r66116. Switching QA therefore.
Code: OK: each method raises only one type of Exception (before user is authenticated) with each only one textual response Tests: OK * Ran for each USERNAME in {existing_user_without_contact, not_a_user, "", "@", "Administrator"}: curl -H "Content-Type: application/json" -H "Accept-Language: en_EN" -X POST -d '{"username": $USERNAME}' http://10.200.3.35/univention-self-service/passwordreset/get_reset_methods And the result was always the same: {"message": "No contact information is stored for this user. Resetting the password is not possible."} get_reset_methods() is still "vulnerable" in that existing users with stored contacts can be found - but that is by design (and is at least a little dampened by the request rate limiting). * The reply for all requests, if the LDAP server is down, is in all cases the same: {"message": "Cannot connect to the LDAP service.\nThe following steps can help...}.
<http://errata.software-univention.de/ucs/4.1/24.html>