Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • lemonldap-ng lemonldap-ng
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 311
    • Issues 311
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LemonLDAP NGLemonLDAP NG
  • lemonldap-nglemonldap-ng
  • Issues
  • #1869
Closed
Open
Issue created Jul 26, 2019 by Maxime Besson@maxbes🔧Maintainer

[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 with myuser '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?

Edited Sep 17, 2019 by Yadd
Assignee
Assign to
Time tracking