Небезопасный способ авторизации в GitLab CE с использованием LDAP аккаунтов и метод устранения уязвимости

    При эксплуатации системы GitLab CE на своем предприятии (имеющему большую филиальную структуру), была обнаружена уязвимость, которая может привести к получению полного доступа к аккаунту любого пользователя системы администраторами филиалов предприятия.

    Проблема выявлена в подсистеме LDAP-аутентификации пользователей. Дело в том, что основной сущностью, с использованием которой происходит авторизация в GitLab является E-Mail пользователя. Однако при входе пользователей в GitLab с использованием LDAP процесс аутентификации/авторизации происходит следующим образом:
    • Пользователь вводит на странице Sign-In системы свои имя/пароль из службы каталогов LDAP (Active Directory).
    • GitLab, используя введенные данные аккаунта производит аутентификацию пользователя в LDAP.
    • В случае успешной аутентификации GitLab считывает из атрибута MAIL аутентифицированного аккаунта адрес электронной почты и авторизует по нему в GitLab без всяких дополнительных проверок
    .
    В результате, например, «нехороший» системный администратор «филиала A», может используя свои полномочия, к примеру в Active Directory, создать в своем OU «Филиал А» любого пользователя (например hackuser) и записать в его LDAP-атрибут MAIL адрес электронной почты пользователя любого другого филиала, на который даже не распространяются полномочия этого администратора. После этого «нехороший» администратор «Филиала А» может авторизоваться пользователем hackuser в системе GitLab, при этом в результате авторизации будет получен полный доступ к аккаунту пользователя, имеющего адрес электронной почты установленный «нехорошим» администратором для hackuser.

    Таким образом, любой администратор, имеющий возможность изменять у пользователей информационное поле MAIL в службе каталогов, может получать доступ к любому аккаунту системы GitLab, не являясь администратором и даже пользователем этой системы.

    О данной уязвимости было сообщено в команду разработки GitLab CE ( gitlab.com/gitlab-org/gitlab-ce/issues/3741 ), однако в работу указанная проблема не была принята, поскольку такое поведение системы является для разработчиков ожидаемым, нормальным и описано в документации на нее ( doc.gitlab.com/ce/integration/ldap.html#security, doc.gitlab.com/ce/integration/ldap.html#enabling-ldap-sign-in-for-existing-gitlab-users ).

    Для нас использование такого варианта авторизации с применением LDAP являлось неприемлемым, поэтому был разработан небольшой патч, устраняющий указанную проблему. Суть патча состоит в дополнительной проверке соответствия полей username авторизующегося пользователя в GitLab и LDAP.

    Патч для файла: /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
    
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 10
    • +1
      Ну это. Нехороший администратор LDAP? По сути, это уже конец всякой защиты. Я с тем же успехом могу взять чужой аккаунт, поменять пароль и ходить куда мне вздумается. Патч защитой то не назовешь. Поэтому комментарии разработчиков gitlab не удивляют.

      А так, в настройках LDAP можно использовать фильтры, чтобы ограничить аутентификацию по принадлежности к какой-то группе, что собственно у нас и сделано.
      • –1
        Совершенно согласен, «нехороших» администраторов быть не должно да и киберпреступников тоже и других плохих людей. Если такие администраторы есть, то это действительно ничего хорошего не сулит. Но… они бывают!!! Бывают не совсем нехорошие, а просто не вполне квалифицированные и очень любопытные. Ситуации бывают всякие.

        А, то что фактически информационное поле в LDAP является ключом к аккаунту считаю тоже не совсем правильным.
        Тем не менее хочу поблагодарить авторов GitLab — это отличная система управления версиями, очень динамично развивается, быстро исправляются ошибки, добавляются новые фичи.

        Ну и на самом деле я совершенно нормально воспринял реакцию авторов. Они действительно продекларировали такое поведение, а чтобы правильно и качественно изменить его, конечно-же одним патчем не обойдешься.

        А я просто предложил свой вариант решения проблемы (вернее того, что я считаю проблемой) и возможно это решение понадобится еще кому-нибудь.

        Также, я нисколько не сомневаюсь, что в будущем GitLab станет еще лучше, поэтому мы и выбрали эту систему для управления своим исходным кодом.
        • 0
          быстро исправляются ошибки, добавляются новые фичи.

          жаль только вот ошибке с определением не-UTF-8-кодировки содержимого файлов уже пара лет и, судя по комменту, в ноябре 2015-го воз был всё там же
          • 0
            А если нехороший администратор заменит пароль у атакуемого пользователя, предварительно сохранив текущий хэш, залогинится, а потом вернёт хэш назад?
            • 0
              Организация с кучей очень далеко разбросанных филиалов.
              Для филиала А остальные филиалы (например B,C,D) — конкурирующие организации. Адмнистратор филиала А ничего не может делать с пользователями других филиалов (достигается делегированием полномочий), но может создать в своем OU левого пользователя и указав e-mail пользователя практически другой для него организации завладеть аккаунтом.
        • 0
          т.е. почитать документацию и заюзать фильтры в конфигурации gitlab'a сложнее, чем манкипатчить проект?
          http://doc.gitlab.com/ee/integration/ldap.html#configuring-gitlab-for-ldap-integration
          • 0
            Конечно же почитал, и про фильтры знаю и использую, но как конкретно предложите их использовать для устранения указанной проблемы?
            • 0
              написать в base путь к вашему департаменту, а не в корень. тогда гитлаб будет искать только в вашем дереве, и ему будет пофигу на юзеров в других департаментах (деревьях)
          • 0
            А почему Вы решили что другие филиалы не должны использовать Гитлаб?
            • 0
              потому что если вы хотите разграничить доступ к гиту в филиалах, проще поднять в каждом филиале свой гит сервер (и ближе и администрировать проще) и настроить аутентификацию только по OU филиала. Таким образом гит сервер находится и в сети филиала, недоступной для других и аутентификация по OU недоступной для других. Тоже самое справедливо и для локальной конторы с множеством отделов — выносить гит в vlan отдела и аутентификация только по OU отдела.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.