Headline
CVE-2023-28862: [Security][CVE-2023-28862] AuthBasic does not handle failure correctly (#2896) · Issues · LemonLDAP NG / lemonldap-ng · GitLab
An issue was discovered in LemonLDAP::NG before 2.16.1. Weak session ID generation in the AuthBasic handler and incorrect failure handling during a password check allow attackers to bypass 2FA verification. Any plugin that tries to deny session creation after the store step does not deny an AuthBasic session.
Concerned version
Version: 2.0.16
Summary
The AuthBasic handler works like this:
- It computes a sessionid from login+password
- If sessionid already exists in the session DB, authenticate user
- Else, try to create the corresponding session by sending the login+pass to the portal RESTServer plugin
However, the only required step in the login flow is store, if anything happens after thestore step, AuthBasic will succeed because the fixed-id session has been successfully created, which means:
- Accounts that are supposed to be 2FA-protected are not 2FA protected when AuthBasic is used
- If a 2FA module returns an error, the first AuthBasic request will 401, but the second AuthBasic request will work correctly => VERY CONFUSING
- Any plugin that tries to deny session after the store step will not deny AuthBasic sessions
This is probably a security issue
Possible fixes
If the AuthBasic login process fails (not PE_OK), we need to remove the session created by store and return an error
This will cause a regression: users who relied on AuthBasic working for 2FA protected account will now see failures Possible solution: use an env variable in 2FA activation rules if desired:
has2f("TOTP") and not $env->{"AuthBasic"}
or something of that sort