GitLab CVE-2023-7028
Введение
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
