Введение

11 января 2024 года была опубликована информация об уязвимости в GitLab CE/EE, затрагивающая все версии с 16.1 до 16.1.6, 16.2 до 16.2.9, 16.3 до 16.3.7, 16.4 до 16.4.5, 16.5 до 16.5.6, 16.6 до 16.6.4 и 16.7 до 16.7.2. Данная уязвимость получила идентификатор CVE-2023-7028 и 7.5 баллов критичности по CVSS NVD - CVE-2023-7028 (nist.gov).

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

Уязвимость была вызвана ошибкой в том, как GitLab обрабатывал проверку электронной почты при сбросе пароля. Злоумышленник мог указать два адреса электронной почты при запросе на сброс пароля, и код сброса отправлялся на оба адреса. Это позволяло злоумышленнику сбросить пароль любого пользователя, даже если он не знал его текущий пароль.

Данная статья представлена исключительно в образовательных целях. Red Team сообщество "GISCYBERTEAM" не несёт ответственности за любые последствия ее использования третьими лицами.

В этой статье мы проведём разбор данной уязвимости, её эксплуатации, а также узнаем как проверить факт компрометации и избежать её влияния на свой GitLab сервер.

Подготовка

Для тестирования развернем уязвимую версию GitLab на нашем сервере.

# 1. Установите и настройте необходимые зависимости 
sudo apt-get update 
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl 
# Затем установите Postfix для отправки писем с уведомлениями
sudo apt-get install -y postfix
# 2. Добавьте репозиторий пакетов GitLab и установите пакет 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
# При установке требуется указать utl на котором будет доступен GitLab, а также можно указать конкретную версию 
sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-сe=16.2.2-сe.0
# 3. Можно переходить по имени хоста и входить в систему 
# 4. Чтобы получилось проэксплуатировать эту уязвимость, нам требуется GitLab с настроенным SMTP 
# В зависимости от используемого SMTP можно правильно настроить отправку сообщений следуя официальной документации: 
# https://docs.gitlab.com/omnibus/settings/smtp.html

Разбор эксплуатации

Так как уязвимость находится в механизме восстановления пароля, взглянем сначала на форму в интерфейсе пользователя. Если открыть исходный HTML-код, можно увидеть все параметры и куда отправляется запрос. Здесь, для подделки запроса, нам будет нужен скрытый input с отправляемым CSRF-токеном.

Непосредственно сама уязвимость находится в эндпоинте API GitLab POST /users/password , куда отправляется запрос.

Как в HTML-форме выше, так и в примере нормального запроса ниже можно увидеть, что помимо CSRF-токена, отправляется только единственный параметр user[email] с почтой пользователя.

В качестве proof of concept предлагается изменить параметры стандартного запроса таким образом, что параметр user[email] изменяется на user[email][] , вероятно для использования уязвимости динамической типизации языка Ruby, и передаётся 2 раза: первый раз со значением email-адреса жертвы, а второй раз - со значением email-адреса злоумышленника. Главное не забыть изменить значение параметра authenticity_token на валидный токен, который мы нашли в HTML-форме.

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

В полученном на ящик злоумышленника письме, можно увидеть в адресатах и адрес владельца аккаунта.

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

Как это работает?

Если посмотреть исходный код, а точнее коммит с патчем данной уязвимости, становится ясно, что в старом коде отсутствовал механизм верификации и проверки подтверждения электронной почты, что она связана с правильным пользователем.

Обнаружение эксплуатации

Для проверки факта эксплуатации данной уязвимости можно оценить в логе gitlab-rails/production_json.log наличие HTTP-запросов к обработчику /users/password с указанием массива из нескольких email в параметре "params.value.email". Также предлагается проверить наличие в логе gitlab-rails/audit_json.log записей со значением PasswordsController#create в meta.caller.id и указанием массива из нескольких адресов в блоке target_details.

Меры защиты

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

Также, стоит отметить, что если на аккаунте настроена двухфакторная аутентификация, то, даже на уязвимой версии, злоумышленник не сможет получить доступ к аккаунту. Поэтому важно выставить политики безопасности так, чтобы хотя бы у администраторов эта функция была обязательной.

Заключение

GitLab является широко распространенным программным обеспечением, которое используется многими компаниями и организациями для хранения и совместной работы над кодом и другими данными.

Хотя уязвимость была исправлена, осталось еще много не обновленных инстансов GitLab в публичном доступе через интернет. Это означает, что злоумышленники могут использовать данную уязвимость для атаки на эти системы в целях получения несанкционированного доступа к хранимым данным.

Поэтому, важно регулярно обновлять программное обеспечение и следить за обновлениями безопасности, чтобы минимизировать риски компрометации и обеспечить безопасность своих систем. Печальным остаётся то, что во многих продуктах, в числе которых GitLab, данная процедура требует постоянного внимания человека, что невозможно обеспечить в большинстве случаев.

Подписывайтесь на наш Telegram-канал https://t.me/giscyberteam

GitLab CVE-2023-7028