Уязвимость у GitLab Community Edition.
ФСТЭК опубликовала предупреждение, что в платформах совместной разработки GitLab Community Edition (CE) и Enterprise Edition (EE) обнаружена критическая уязвимость с номером BDU:2024-04858, которая связана с недостатками разграничения доступа. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, выполнить произвольный код путём запуска пайплайнов от имени других пользователей. Производитель уже выпустил обновленные версии 17.1.1, 17.0.3 и 16.11.5, где исправлено 14 уязвимостей, из которых наиболее опасной является BDU:2024-04858 – она имеет по CVSS 3.1 оценку опасности 9,6 из 10, но есть также три критические.
У многих клиентов есть собственные команды разработки, так как им важна скорость цифровизации. В 85% случаев эти команды используют продукты GitLab, например, GitLab CI. Запрос на импортозамещение этих продуктов пока не актуален, т.к. в России этот сегмент решений еще только зарождается. В новом патче GitLab исправила сразу 14 уязвимостей. Среди них: одна критичная, позволяющая запускать пайплайн от имени любого пользователя; три высокого уровня критичности, позволяющие осуществить нарушение прав доступа и утечки данных; 9 среднего уровня и 1 низкого, связанные в основном с нарушением работы или обходом ограничений доступа внутри системы.
На текущий момент по данным платформы CyberOK СКИПА в российском сегменте Интернета наблюдается более 14 тыс. доступных сервисов GitLab. При этом среди них более 60% с устаревшими и более не поддерживаемыми версиями (версии до 16.11). В последних исправлениях GitLab были устранены 14 уязвимостей. Среди них есть одна критическая и 3 уязвимости с высоким уровнем важности/критичности:
- CVE-2024-5655 (CVSS3.1: 9.6, EPSS: 0.001) – возможность запуска конвейера от имени любого пользователя (требуются определённая конфигурация GitLab);
- CVE-2024-4901 (CVSS3.1: 8.7, EPSS: 0.0004) – XSS-уязвимость, позволяющая внедрить в заметку к проекту вредоносный сценарий, который будет выполнен в контексте пользователя, открывшего эту заметку;
- CVE-2024-4994 (CVSS3.1: 8.1) – CSRF-уязвимость в API GraphQL, позволяющая злоумышленникам выполнять произвольные изменения в GraphQL, путём изменения легитимных запросов аутентифицированных пользователей;
- CVE-2024-6323 (CVSS3.1: 7.5, EPSS: 0.001) – ошибка обработки авторизации в функции глобального поиска GitLab, позволяющая злоумышленникам просматривать результаты поиска из частных репозиториев в общедоступных проектах.
Базовые метрики оценки критичности уязвимостей достаточно высокие, но необходимо заметить, что для эксплуатации 3 из 4 этих уязвимостей злоумышленнику необходимо успешно пройти авторизацию в GitLab (получить валидные учетные данные и обойти остальные средства контроля доступа), что в значительной степени снижает вероятность массовой эксплуатации.
Следует отметить, что GitLab обычно не публикуют в Интернете, а используют чисто во внутренней сети как хранилище для кода, а доступ к нему организуют через VPN для удаленной разработки. Так что, количество реально установленных продуктов, но не доступных из Интернет, может быть больше того, что обнаруживает интернет-поиск СКИПА.
Компрометация GitLab может приводить к модификации кода, хранящегося в репозиториях и, как следствие, к атакам на цепочку поставок. Для того, чтобы защитить свои данные от утечек важно выполнять регулярное обновление GitLab, особенно в случае, если он доступен из Интернета. Также необходимо периодически проводить ревизию активности в репозиториях и самом GitLab: проверять логи аутентификации, коммиты – на предмет вредоносного кода и т.д.
Если злоумышленник может запустить пайплайн от имени любого пользователя, то он может выполнить фактически все, что разрешено любому пользователю в системе: внедрить собственный код, отправить проект в сборку, обойти процедуры согласования (в т.ч. с ИБ). Причем в сочетании с другими уязвимостями, например, с помощью XSS-атаки в заметке (CVE-2024-4901), позволяющей выполнить некоторые действия от имени пользователя или украсть его аутентификационную информацию, можно расширить область поражения атаки и сильно увеличить риски как для самих разработчиков, так и для пользователей разрабатываемого ими программного обеспечения.
ФСТЭК рекомендует следующие компенсирующие меры:
- минимизировать пользовательские привилегии;
- отключить/удалить неиспользуемые учётные записи пользователей;
- использовать средства межсетевого экранирования для ограничения возможности удалённого доступа;
- использовать виртуальные частные сети для организации удаленного доступа (VPN).
Уязвимость у OpenSSH.
OpenSSH — это основной инструмент для удаленного входа в систему по протоколу SSH. Он шифрует весь трафик для предотвращения прослушивания, перехвата соединения и других атак. Кроме того, OpenSSH предоставляет большой набор возможностей безопасного туннелирования, несколько методов аутентификации и различные варианты конфигурации.
В популярном средстве защищённого удалённого доступа — сервере OpenSSH — была обнаружена достаточно опасная уязвимость. Об этом предупреждает ФСТЭК. Ее название BDU:2024-04914 в базе данных угроз и уязвимостей, однако в широких кругах она получила собственное имя — regreSSHion. Это не первая уязвимость в средстве криптографической защиты, получившая собственное имя — в 2014 году в OpenSSL была обнаружена ошибка, получившая наименование Heartbleed.
Исследователи компании Qualys обнаружили, что процесс сервера OpenSSH — sshd — может быть введён в состояние гонки обработчиков сигналов, что позволяет перезаписать память и выполнить неаутентифицированный удаленный код с привилегиями суперпользователя (root). Ошибка точно срабатывает в системах Linux на базе glibc, а вот про Windows и macOS подтверждений пока нет. Возможность совершения атаки продемонстрирована на 32-разрядной системе с Glibc с включённой защитой от переполнения буфера ASLR (рандомизация адресного пространства). Для успешной атаки в лабораторных условиях потребовалось 6-8 часов, в течение которых с сервером непрерывно устанавливались соединения с максимально допустимой в конфигурации sshd интенсивностью.
Уязвимость появилась в результате регрессивного изменения, вошедшего в состав выпуска OpenSSH 8.5 и приводящего к состоянию гонки в коде обработки сигналов в sshd. Именно поэтому она и получила название regreSSHion. Внесенные изменения привели к прекращению действия защиты от старой уязвимости CVE-2006-5051, обнаруженной до версии OpenSSH 4.4 (2006 год) и носившей теоретический характер. Ошибка исправлена в OpenSSH 9.8p1.
Qualys поделилась подробным разбросом regreSSHion, но не публикует примеров ее эксплуатации, чтобы не стимулировать вредоносную активность. По данным компании по всему миру около 700 тыс. систем, подключенных к интернету, могут быть уязвимы для данной уязвимости. В России по данным сервиса ZoomEye.hk находится почти 4 млн серверов OpenSSH. Однако насколько они уязвимы – не очень понятно. Компания Qualys предоставила индикаторы компрометации, с помощью которых любой владелец сервера на базе OpenSSH может выявить возможные атаки.
В связи выявлением данной уязвимости специалисты Центра противодействия киберугрозам Innostage CyberART рекомендуют выполнить обновление ПО OpenSSH до версии 9.8p1. В качестве временных компенсирующих мер возможны следующие действия:
- В sshd_config выставить параметр “LoginGraceTime=0”, при этом отключение таймаута упростит инициирование отказа в обслуживании при установке большого числа соединений, превышающих лимиты, заданные через параметр “MaxStartups”.
- Ограничить доступ по SSH с помощью сетевых средств управления путем внедрения белого списка IP-адресов для минимизации рисков атак.
Сама ФСТЭК также рекомендует максимально быстро установить обновления. Но если это по какой-то причине невозможно, то можно предпринять следующие компенсирующие меры:
- для ограничения возможности эксплуатации в sshd_config выставить параметр «LoginGraceTime=0»;
- установить для LoginGraceTime значение 0 в /etc/ssh/sshd_config и перезапустить sshd;
- использовать антивирусное ПО для отслеживания попыток эксплуатации уязвимости;
- использовать средства межсетевого экранирования для ограничения возможности удалённого доступа.