Unsafe authentication method in GitLab CE using LDAP accounts and vulnerability fix method

    When operating the GitLab CE system at his enterprise (which has 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 administrators of the enterprise branches.

    The problem was identified in the LDAP user authentication subsystem. The fact is that the main entity using which authorization in GitLab is used is the user's e-mail. However, when users log into GitLab using LDAP, the authentication / authorization process proceeds as follows:
    • The user enters his username / password from the Active Directory LDAP directory service on the Sign-In page of the system.
    • GitLab, using the entered account information, authenticates the user in LDAP.
    • In case of successful authentication, GitLab reads out the email address from the MAIL attribute of the authenticated account and authorizes it in GitLab without any additional checks
    .
    As a result, for example, a "bad" system administrator of "branch A", using his authority, for example in Active Directory, can create any user in his OU "Branch A" (for example, hackuser ) and write the email address in his LDAP attribute MAIL mail of a user of any other branch, which is not even subject to 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 to the user’s account with the email address set by the “bad” administrator for hackuser will be obtained .

    Thus, any administrator with 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 ), however, this problem was not accepted into the work, since such system behavior is expected, normal for developers and is described in 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, the use of such an authentication option using LDAP was unacceptable, so a small patch was developed to fix this problem. The essence of the patch is to additionally verify the username fields of the authorized 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
    

    Also popular now: