При эксплуатации системы GitLab CE на своем предприятии (имеющему большую филиальную структуру), была обнаружена уязвимость, которая может привести к получению полного доступа к аккаунту любого пользователя системы администраторами филиалов предприятия.
Проблема выявлена в подсистеме LDAP-аутентификации пользователей. Дело в том, что основной сущностью, с использованием которой происходит авторизация в GitLab является E-Mail пользователя. Однако при входе пользователей в GitLab с использованием LDAP процесс аутентификации/авторизации происходит следующим образом:
В результате, например, «нехороший» системный администратор «филиала 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:
Проблема выявлена в подсистеме 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
Комментарии (9)
or10n
20.01.2016 11:47т.е. почитать документацию и заюзать фильтры в конфигурации gitlab'a сложнее, чем манкипатчить проект?
http://doc.gitlab.com/ee/integration/ldap.html#configuring-gitlab-for-ldap-integration
mitshel
20.01.2016 14:40Конечно же почитал, и про фильтры знаю и использую, но как конкретно предложите их использовать для устранения указанной проблемы?
or10n
21.01.2016 13:12написать в base путь к вашему департаменту, а не в корень. тогда гитлаб будет искать только в вашем дереве, и ему будет пофигу на юзеров в других департаментах (деревьях)
creker
Ну это. Нехороший администратор LDAP? По сути, это уже конец всякой защиты. Я с тем же успехом могу взять чужой аккаунт, поменять пароль и ходить куда мне вздумается. Патч защитой то не назовешь. Поэтому комментарии разработчиков gitlab не удивляют.
А так, в настройках LDAP можно использовать фильтры, чтобы ограничить аутентификацию по принадлежности к какой-то группе, что собственно у нас и сделано.
mitshel
Совершенно согласен, «нехороших» администраторов быть не должно да и киберпреступников тоже и других плохих людей. Если такие администраторы есть, то это действительно ничего хорошего не сулит. Но… они бывают!!! Бывают не совсем нехорошие, а просто не вполне квалифицированные и очень любопытные. Ситуации бывают всякие.
А, то что фактически информационное поле в LDAP является ключом к аккаунту считаю тоже не совсем правильным.
Тем не менее хочу поблагодарить авторов GitLab — это отличная система управления версиями, очень динамично развивается, быстро исправляются ошибки, добавляются новые фичи.
Ну и на самом деле я совершенно нормально воспринял реакцию авторов. Они действительно продекларировали такое поведение, а чтобы правильно и качественно изменить его, конечно-же одним патчем не обойдешься.
А я просто предложил свой вариант решения проблемы (вернее того, что я считаю проблемой) и возможно это решение понадобится еще кому-нибудь.
Также, я нисколько не сомневаюсь, что в будущем GitLab станет еще лучше, поэтому мы и выбрали эту систему для управления своим исходным кодом.
Zapped
жаль только вот ошибке с определением не-UTF-8-кодировки содержимого файлов уже пара лет и, судя по комменту, в ноябре 2015-го воз был всё там же
lukashin
А если нехороший администратор заменит пароль у атакуемого пользователя, предварительно сохранив текущий хэш, залогинится, а потом вернёт хэш назад?
mitshel
Организация с кучей очень далеко разбросанных филиалов.
Для филиала А остальные филиалы (например B,C,D) — конкурирующие организации. Адмнистратор филиала А ничего не может делать с пользователями других филиалов (достигается делегированием полномочий), но может создать в своем OU левого пользователя и указав e-mail пользователя практически другой для него организации завладеть аккаунтом.