Пользователь
0,0
рейтинг
18 января в 14:11

Разработка → Небезопасный способ авторизации в 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
Shelepnev Dmitriy @mitshel
карма
9,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (9)

  • +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
    А почему Вы решили что другие филиалы не должны использовать Гитлаб?

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