17 и 25 сентября 2024 года GitLab выпустил серию важных обновлений для Community Edition (CE) и Enterprise Edition (EE).
Новые версии исправляют ошибки и закрывают обнаруженные уязвимости, одна из которых, CVE-2024-45409, имеет максимальную опасность CVSS 10.0 и связана с обходом аутентификации через протокол SAML. Проблема была критической, так как злоумышленник мог войти в систему, имея произвольную учетную запись.
GitLab выпускает обновления в патч-релизах двух видов: запланированные и срочные. Запланированные патчи выходят дважды в месяц по второй и четвертой средам, а срочные — при возникновении серьезных угроз.
Подробную информацию обо всех вышедших патчах можно найти в специальном онлайн‑каталоге GitLab. Однако при поиске материалов по той или иной уязвимости следует учитывать, что описание технических подробностей выходят с месячной задержкой. Так устроено, чтобы не дать подготовленным злоумышленникам воспользоваться ситуацией и атаковать не успевших применить патчи.
Чтобы самому не искать уязвимости на сайтах вендоров, а также быстрее узнавать обо всех обнаруженных уязвимостях в вашем стеке технологий, можно использовать специальные сканеры уязвимостей. Если и на это нет времени — воспользуйтесь готовым сервисом Selectel.
Суть уязвимости
На этот раз критическая угроза безопасности была связана с Ruby‑модулями omniauth-saml и ruby-saml, отвечающими за аутентификацию SAML.
Библиотека ruby-saml предназначена для реализации клиентской стороны авторизации SAML. В версиях младше 12.2 и с 1.13.0 по 1.16.0 библиотека не проверяет должным образом подпись ответа. Таким образом, неаутентифицированный злоумышленник, у которого есть доступ к любому подписанному документу (по IdP), может подделать ответ или утверждение SAML и войти в систему.
Обнаружение атаки
Как при попытке, так и при успешной эксплуатации уязвимости в файлах журналов application_json и auth_json остаются характерные записи.
Неудачные попытки
Неудачные попытки могут приводить к появлению сообщений ValidationError. Для поиска сообщений в журнале application_json удобно использовать подстроку RubySaml::ValidationError. Сообщения могут быть самыми разными, однако наиболее часто встречаются следующие два примера.
1. Недействительный тикет из-за неправильного URL обратного вызова:
{"severity":"ERROR","time":"2024-xx-xx","correlation_id":"xx","message":"(saml) Authentication failure! invalid_ticket: OneLogin::RubySaml::ValidationError, The response was received at https://domain.com/users/auth/saml/incorrect_callback instead of https://domain.com/users/auth/saml/callback"}
2. Недействительный тикет из-за проблемы с подписью сертификата:
"message":"(saml) Authentication failure! invalid_ticket: OneLogin::RubySaml::ValidationError, Fingerprint mismatch"
Удачные попытки
Удачные попытки вторжения приводят к появлению в журнале других записей, связанных с событиями SAML. Всего может быть несколько отличительных признаков, которые позволяют понять, какие записи вызваны нормальной деятельностью пользователей, а какие свидетельствуют об успешном обходе аутентификации.
Несуществующий extern_uid
Прежде всего следует обращать внимание на значение поля extern_uid, которое наверняка будет содержать идентификатор, не соответствующий ни одному зарегистрированному в организации пользователю.
Пример события в файле журнала application_json с extern_uid, установленным в PoC-коде эксплойта:
{"severity":"INFO","time":"2024-xx-xx","correlation_id":"xx","meta.caller_id":"OmniauthCallbacksController#saml","meta.remote_ip":"0.0.0.0","meta.feature_category":"system_access","meta.client_id":"ip/0.0.0.0","message":"(SAML) saving user exploit-test-user@domain.com from login with admin =\\u003e false, extern_uid =\\u003e exploit-test-user"}
Неверные и странные значения атрибутов
Для атаки злоумышленнику потребуется множество SAML-утверждений, чтобы имитировать нормального пользователя. Все правильные значения полей он знать не может — особенно если IdP был заблаговременно настроен — и наверняка подсттавит значение, которое позволит идентифицировать связанную с ним запись.
Можно просмотреть файл журнала auth_json и в разделе attributes найти ответы SAML с неверной или отсутствующей информацией:
"severity":"INFO","time":"2024-xx-xx","correlation_id":"xx","meta.caller_id":"OmniauthCallbacksController#saml","meta.remote_ip":"0.0.0.0","meta.feature_category":"system_access","meta.client_id":"ip/0.0.0.0","payload_type":"saml_response": {"issuer": ["xxx"],"name_id": "xxx","name_id_format": "xxx","name_id_spnamequalifier": null,"name_id_namequalifier": null,"destination": "xxx","audiences": ["xxx"],"attributes": {"first_name": ["xxx"],"last_name": ["yyy"], "email": ["zzz"]}}
Множественные extern_uid у одного пользователя
Если события аутентификации, связанные с одним и тем же пользователем, имеют разное значение extern_uid, скорее всего, атака прошла успешно. К примеру, спустя время тот же пользователь заходит с другого IP-адреса, который отличается от связанного с предыдущими IdP‑событиями:
title: Multiple extern_ids
description: Detects when there are multiple extern_id's associated with a user.
author: Gitlab Security Engineering
date: 09/15/2024
schedule: "*/10 * * * *"
pseudocode: |
select log source application.log
where 7d < event_time < now()
where severity="INFO" and meta_caller_id="Groups::OmniauthCallbacksController#group_saml"
regex(message, "saving user (?<user_email>\S+) .*extern_uid \S+ (?<extern_id>[\S]+)")
count extern_id by user_email as total_extern_ids
where total_extern_ids > 1
verify: Review Gitlab application logs for the source IP of the SAML authentications. If there is a singular IP for all extern_ids this could point to a false positive. Cross reference the SAML authentication source IP/s with the known user's IP from sso authentication logs.
tuning: N/A
Еще пример — сопоставление событий аутентификации (и GitLab SAML, и IdP), сгруппированных по пользователям для обнаружения изменения IP‑адреса:
title: Gitlab SAML IP differs from SSO IP
description: Detects when the source IP for the SAML authentication to Gitlab from application.log differs from the user's known IP from SSO MFA logs.
author: Gitlab Security Engineering
date: 09/15/2024
schedule: "*/10 * * * *"
pseudocode: |
select log source application.log
where severity="INFO" and meta_caller_id="Groups::OmniauthCallbacksController#group_saml"
regex(message, "saving user (?<user_email>\S+) ")
#Create sub-query to bring in table from SSO authentication data
select meta_remote_ip, user_email
where user_email in
(
select log source authentication
where 1d < event_time < now()
where event_type="user.authentication.auth_via_mfa"
group by user_email, sso_source_ip
)
where sso_source_ip!=meta_remote_ip
verify: False positives can arise when the user is traveling. Review SSO authentication logs to see if the geo-location is similar to the SAML authentication to Gitlab. If any discrepancies are found, reach out to the user for verification. If the user is not traveling, temporarily lock the user's Gitlab account and review their activity through Gitlab's application logs.
tuning: If the query is producing high false positives, consider using geolocation functions on IPs to compare the cities and countries that are generating the authentications.
Какие меры предпринять
Тем, кто собирается использовать наш облачный сервер с GitLab или SaaS‑платформу GitLab.com, никаких действий предпринимать не надо.
Те, кто уже развернул GitLab (из образа Selectel или самостоятельно), должны обновить его до последней версии согласно рекомендациям вендора.
Также присмотритесь к нашему сервису «Анализ уязвимостей» — он в значительной степени упрощает поддержание системы в защищенном состоянии.
Больше новостей из мира информационной безопасности и материалов о том, как противостоять угрозам и оградить свои системы от атак и взлома — в Security Center.
