[Security:low] psessions case sensitivity might impact security of 2FA when using case-insensitive auth backends
Concerned version
Version: %2.0
Summary
When using a case-insensitive login backend (LDAP), the psession key is by default computed from the _user
variable (through _whatToTrace
), which may be uppercase or lowercase depending what the user typed into the login form.
This can lead to a situation where an attacker can register their own 2F device, unbeknownst to the legitimate user.
Vulnerable scenario
Configure the following:
- LDAP authentication backend
- TOTP enabled, self registration enabled
- Require 2FA enabled
Then, login as myuser
- On first login, you are required to setup a TOTP device
- Login again, you are now protected by the TOTP device
Everything is going well so far
- Login as
MYUSER
withmyuser
's password - You are now asked to setup another TOTP device
You may now login as either myuser
or MYUSER
, each one will use a different TOTP device. But what if the MYUSER
TOTP device was setup by a malicious user using stolen credentials? Applications might in many cases still identify MYUSER
as exactly the same account as myuser
depending what attributes are being transmitted.
Backends used
LDAP backend is vulnerable to this, maybe others...
Mitigations
The attack described here only affects "trust on first login" scenarios, where trust in a 2F device is automatically granted the first time a user logs in.
There is no need to upgrade to mitigate this issue on existing platforms, simply normalize the case of _whatToTrace
and you won't be affected anymore.
Example: _whatToTrace=lc($_user)
or perhaps simply _whatToTrace=$uid
Possible fixes
Since LDAP is probably our most common user backend, perhaps we should use lc($_user)
in _whatToTrace
by default.
Or perhaps case insensitive backend could normalize _user
themselves to make sure situations like the one described above cannot happen?