Privilege escalation with external users, LDAP, and Oauth
ZenDesk issue: https://gitlab.zendesk.com/agent/tickets/28534
Dear sir/madam,
Today we confirmed reproducibility of a privilege escalation issue in the latest version of Gitlab (CE). Along the way we were surprised to discover another less severe but not minor security issue, causing degraded authentication requirements.
We have our Gitlab set up to authenticate/register via Active Directory (LDAP), with mandatory 2FA, and optional external authentication via Github or Gitlab.com as many of our employees use those 2 sites. We use the ‘default internal’ model where all employees can access and fork all projects unless specifically made private, yet need explicit privileges to push.
One of our employees left the company May 1st in good standing. As he wanted to continue contributing to one of his pet projects we made him an ‘External’ user. He reported to me he was still able to access all projects, and I noticed to my surprise he was not External. I reset the flag, suspected LDAP bindings of overwriting it, and thus removed his LDAP identity. 2 weeks later he was no longer External again and could access all projects. We met up tonight and found out that whenever he used Github OAuth login, already established during his employment, the flag was automatically cleared. As a sidenote we noticed that using Github OAuth did not request a 2FA code, despite this being set up for his account still and being globally required. I can reproduce this with my own account – logging out and back in via Github does not request an Authenticator code.
This means there are 2 separate security issues:
1. The ‘External’ flag should never be automatically modified on an existing user. While setting it is just an inconvenience (although it could lock out the last admin), resetting it means a severe privilege escalation with potentially dire consequences. It could even theoretically cause a disgruntled ex-admin who retained external rights for some minor projects could get a global admin role back. I am not sure whether the issue is caused by the OmniAuth bindings being established while he was not External yet, if that is not the case and all External users anyway can upgrade themselves by binding an external auth method this it’s a critical zero-day issue.
2. Any external authentication method should always trigger a 2FA check if configured, as the security of external methods like Github, Facebook accounts et al cannot be monitored by local sysadmins. This is a medium severity issue methinks, as the worst case exploit is making an account hack easier, not trivial, assuming Gitlab users with high access handle their external auth methods also reasonably responsible. I’m still not going to be very happy if all our internal company projects are published on the internet just because someone’s Twitter account got compromised.
If you need more information both I and the user in question are available for follow-up.