Небезопасный способ авторизации в 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.
Читать дальше →
Проблема выявлена в подсистеме 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.
Читать дальше →
Источник: Хабрахабр
Похожие новости
- ASOC на коленке: как я навайбкодил замену DefectDojo для своих задач с обогащением из БДУ ФСТЭК
- Три архитектурных решения для multi-tenant B2B SaaS, о которых я пожалел, что не узнал раньше
- Бэкдор вместо тестового
- Ваш Telegram-бот на базе LLM уязвим. Я написал сканер, чтобы доказать это на популярном Open Source проекте
- Цифровой аудит против галлюцинаций по ГОСТу. Как понять, когда ответу ИИ нельзя верить?
- [Перевод] Как ошибка в интернет‑картах превратила жизнь фермы в Канзасе в «цифровой» ад
- А при чём тут законы о ПДн? (или «Как 152-ФЗ зацементировал новую реальность»)
- L×Box: диагностика per-app трафика, посмотрим кто куда ходит
- [Перевод] Как Mozilla нашли 271 уязвимость в Firefox с помощью Claude Mythos
- Как НЕ провалить аудит смарт-контрактов?