Insecure authorization method in GitLab CE using LDAP accounts and how to fix the vulnerability
When operating the GitLab CE system in its enterprise (having a large branch structure), a vulnerability was discovered that could lead to full access to the account of any user of the system by the branch office administrators.
A problem has been identified in the LDAP user authentication subsystem. The point is that the main entity with which the authorization in GitLab takes place is the user's E-Mail. However, when users log in to GitLab using LDAP, the authentication / authorization process is as follows:
As a result, for example, a “bad” system administrator of “branch A”, using his credentials, for example in Active Directory, can create any user (for example, hackuser ) in his “Branch A” OU and write to his LDAP attribute MAIL mail user of any other branch, which is not even the authority of this administrator. After that, the “bad” administrator of “Branch A” can log in with the hackuser user in the GitLab system, and as a result of the authorization, full access will be obtained to the user account that has the email address set by the “bad” administrator for hackuser .
Thus, any administrator who has the ability to change the MAIL information field in the directory service for users can access any GitLab account without being an administrator or even a user of this system.
This vulnerability was reported to the GitLab CE development team ( gitlab.com/gitlab-org/gitlab-ce/issues/3741 ), but the problem was not accepted because the system’s behavior was expected, normal, and described in her documentation for it ( doc.gitlab.com/ce/integration/ldap.html#security , doc.gitlab.com/ce/integration/ldap.html#enabling-ldap-sign-in-for-existing-gitlab-users ) .
')
For us, using this LDAP authorization option was unacceptable, so a small patch was developed that fixes this problem. The essence of the patch is the additional verification of compliance of the username fields of the authorizing user in GitLab and LDAP.
Patch for file: /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/ldap/user.rb:
A problem has been identified in the LDAP user authentication subsystem. The point is that the main entity with which the authorization in GitLab takes place is the user's E-Mail. However, when users log in to GitLab using LDAP, the authentication / authorization process is as follows:
- The user enters his name / password from the Active Directory directory service on the Sign-In page of the system.
- GitLab, using the account data entered, authenticates the user to LDAP.
- In the case of successful authentication, GitLab reads the e-mail address from the MAIL attribute of the authenticated account and authorizes it to GitLab without any additional checks.
As a result, for example, a “bad” system administrator of “branch A”, using his credentials, for example in Active Directory, can create any user (for example, hackuser ) in his “Branch A” OU and write to his LDAP attribute MAIL mail user of any other branch, which is not even the authority of this administrator. After that, the “bad” administrator of “Branch A” can log in with the hackuser user in the GitLab system, and as a result of the authorization, full access will be obtained to the user account that has the email address set by the “bad” administrator for hackuser .
Thus, any administrator who has the ability to change the MAIL information field in the directory service for users can access any GitLab account without being an administrator or even a user of this system.
This vulnerability was reported to the GitLab CE development team ( gitlab.com/gitlab-org/gitlab-ce/issues/3741 ), but the problem was not accepted because the system’s behavior was expected, normal, and described in her documentation for it ( doc.gitlab.com/ce/integration/ldap.html#security , doc.gitlab.com/ce/integration/ldap.html#enabling-ldap-sign-in-for-existing-gitlab-users ) .
')
For us, using this LDAP authorization option was unacceptable, so a small patch was developed that fixes this problem. The essence of the patch is the additional verification of compliance of the username fields of the authorizing user in GitLab and LDAP.
Patch for file: /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/ldap/user.rb:
--- user.rb.orig 2016-01-18 12:00:42.315349492 +0300 +++ user.rb 2016-01-18 12:01:30.957432818 +0300 @@ -35,7 +35,7 @@ end def find_by_email - ::User.find_by(email: auth_hash.email.downcase) + ::User.find_by(email: auth_hash.email.downcase, username: auth_hash.username) end def update_user_attributes Source: https://habr.com/ru/post/275403/
All Articles