Конвейеры разработки программного обеспечения предлагают киберпреступникам «бесплатный» доступ к облаку, локально

Исследователи говорят, что конвейеры непрерывной интеграции/непрерывной разработки (CI/CD) могут быть наиболее опасной потенциальной поверхностью для атак в цепочке поставок программного обеспечения, поскольку кибератаки усиливают свой интерес к поиску слабых мест.

Растет и поверхность атаки: конвейеры CI/CD все чаще используются в командах разработчиков корпоративного программного обеспечения, которые используют их для создания, тестирования и развертывания кода с использованием автоматизированных процессов. Но чрезмерные разрешения, отсутствие сегментации сети, плохие секреты и управление исправлениями мешают их реализации, предлагая преступникам возможность скомпрометировать их, чтобы свободно перемещаться между локальной и облачной средами.

На Black Hat USA в среду, 10 августа, Иэн Смарт и Виктор Газдаг из консалтинговой компании NCC Group выйдут на сцену во время «RCE-as-a-Service: уроки, извлеченные из 5 лет реальной компрометации конвейера CI/CD», чтобы обсудить множество успешных атак на цепочки поставок, которые они осуществили в производственных конвейерах CI/CD практически для каждой компании, протестированной фирмой.

NCC Group наблюдала за несколькими десятками успешных компрометаций целей, от малого бизнеса до компаний из списка Fortune 500. В дополнение к ошибки безопасности, исследователи говорят, что новые злоупотребления предполагаемой функциональностью в автоматизированных конвейерах позволили им преобразовать конвейеры из простой утилиты разработчика в удаленное выполнение кода (RCE) как услугу.

«Я надеюсь, что люди будут больше любить свои пайплайны CI/CD и применять все или хотя бы одну или две рекомендации из нашей сессии», — говорит Газдаг. «Мы также надеемся, что это вызовет дополнительные исследования в области безопасности по этой теме».

Тара Силс, главный редактор новостей Dark Reading, встретилась с Виктором Газдагом, управляющим консультантом по безопасности NCC Group, чтобы узнать больше.

Тара Силс: Каковы наиболее распространенные недостатки безопасности в конвейерах CI/CD и как ими можно злоупотреблять?

Виктор Газдаг: Мы регулярно сталкиваемся с тремя общими недостатками безопасности, которые требуют большего внимания:

1) Жестко запрограммированные учетные данные в системе управления версиями (VCS) или системе управления версиями (SCM).

К ним относятся сценарии оболочки, файлы входа в систему, жестко закодированные учетные данные в файлах конфигурации, которые хранятся в том же месте, что и код (а не отдельно или в приложениях управления секретами). Мы также часто находим токены доступа к различным облачным средам (разработка, производство) или определенным службам в облаке, таким как SNS, база данных, EC2 и т. д.

Мы также по-прежнему находим учетные данные для доступа к вспомогательной инфраструктуре или к конвейеру CI/CD. Как только злоумышленник получает доступ к облачной среде, он может перечислить свои привилегии, найти неправильные конфигурации или попытаться повысить свои привилегии, поскольку они уже находятся в облаке. Имея доступ к конвейеру CI/CD, они могут просматривать историю сборки, получать доступ к артефактам и использованным секретам (например, к инструменту SAST и его отчетам об уязвимостях или токенам доступа к облаку), а в худшем случае — внедрить произвольный код (бэкдор, SolarWinds) в приложение, которое будет компилироваться, или получить полный доступ к производственной среде.

2) Чрезмерно разрешающие роли.

Разработчики или учетные записи служб часто имеют роль, связанную с их учетными записями (или могут принять ее), которая имеет больше разрешений, чем необходимо для выполнения требуемой работы.

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

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

3) Отсутствие аудита, мониторинга и оповещения.

Это область, которой больше всего пренебрегают, и в 90% случаев мы обнаруживали отсутствие мониторинга и предупреждений о любых изменениях конфигурации или управлении пользователями/ролями, даже если аудит был включен или включен. Единственное, что можно отслеживать, — это успешную или неудачную компиляцию или сборку задания.

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

ТС: Есть ли у вас какие-то конкретные примеры из реальной жизни или конкретные сценарии, на которые вы можете указать?

ВГ: Некоторые атаки в новостях, связанные с CI/CD или конвейерными атаками, включают:

• CCleaner атакаМарт 2018
• Доморощенный, август 2018 г.
• Asus ShadowHammerМарт 2019
• Третье нарушение CircleCI, сентябрь 2019 г.
• SolarWindsДекабрь 2020
• Сценарий загрузки bash от Codecov, апрель 2021 г.
• Несанкционированный доступ TravisCI к секретам, сентябрь 2021 г.

ТС: Почему слабые места в автоматизированных конвейерах вызывают проблемы? Как бы вы охарактеризовали риск для компаний?

ВГ: На этапах конвейера могут использоваться сотни инструментов, и из-за этого огромные знания, которые кому-то нужно знать, огромны. Кроме того, конвейеры имеют сетевой доступ к нескольким средам и несколько учетных данных для разных инструментов и сред. Получение доступа к конвейерам похоже на получение бесплатного проездного билета, который позволяет злоумышленникам получить доступ к любому другому инструменту или среде, привязанной к конвейеру.

ТС: От каких результатов атак могут пострадать компании, если злоумышленник успешно разрушит конвейер CI/CD?

ВГ: Результаты атаки могут включать в себя кражу исходного кода или интеллектуальных данных, бэкдор приложения, которое развернуто для тысяч клиентов (например, SolarWinds), получение доступа (и свободное перемещение между) несколькими средами, такими как разработка и производство, как локально, так и в облако или и то, и другое.

ТС: Насколько изощренными должны быть злоумышленники, чтобы скомпрометировать конвейер?

ВГ: То, что мы представляем на Black Hat, — это не уязвимости нулевого дня (хотя я нашел некоторые уязвимости в разных инструментах) или какие-то новые методы. Преступники могут атаковать разработчиков с помощью фишинга (перехват сеанса, обход многофакторной аутентификации, кража учетных данных) или напрямую через конвейер CI/CD, если он не защищен и подключен к Интернету.

Группа NCC даже провела оценку безопасности там, где мы изначально тестировали веб-приложения. Мы обнаружили, что конвейеры CI/CD редко регистрируются и контролируются с помощью предупреждений, за исключением работы по сборке/компиляции программного обеспечения, поэтому преступникам не нужно быть настолько осторожными или изощренными, чтобы скомпрометировать конвейер.

ТС: Насколько распространены эти типы атак и насколько широкую поверхность атаки представляют конвейеры CI/CD?

ВГ: Как уже упоминалось, в новостях есть несколько примеров реальных атак. И еще можно найти, например, Случаи Дженкинса с Shodan в Интернете. С помощью SaaS преступники могут перечислять и пытаться подобрать пароли для получения доступа, поскольку у них нет включенной по умолчанию многофакторной аутентификации или ограничений IP, и они выходят в Интернет.

При удаленной работе защитить конвейеры еще труднее, поскольку разработчикам нужен доступ из любого места и в любое время, а ограничения IP-адресов уже не всегда осуществимы, поскольку компании переходят к сетям с нулевым доверием или меняют расположение сетей.

Конвейеры обычно имеют сетевой доступ к нескольким средам (чего им не следует) и имеют доступ к нескольким учетным данным для разных инструментов и сред. Они могут действовать как мост между локальными и облачными или производственными и тестовыми системами. Это может быть очень широкая поверхность атаки, и атаки могут исходить из нескольких мест, даже тех, которые не имеют ничего общего с самим конвейером. В Black Hat мы представляем два сценария, в которых мы изначально начали с тестирования веб-приложений.

ТС: Почему конвейеры CI/CD остаются слепым пятном для компаний?

ВГ: В основном из-за нехватки времени, иногда нехватки людей, а в некоторых случаях и нехватки знаний. Конвейеры CI/CD часто создаются разработчиками или ИТ-командами с ограниченным временем и с упором на скорость и доставку, или разработчики просто перегружены работой.

Конвейеры CI/CD могут быть очень или чрезвычайно сложными и включать в себя сотни инструментов, взаимодействовать с несколькими средами и секретами и использоваться несколькими людьми. Некоторые люди даже создали периодическую таблицу инструментов, которые можно использовать в конвейере.

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

ТС: Каковы передовые методы повышения безопасности конвейеров?

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

ТС: Есть ли другие мысли, которыми вы хотели бы поделиться?

ВГ: Хотя облачные или облачные конвейеры CI/CD более просты, мы по-прежнему сталкивались с теми же или похожими проблемами, такими как чрезмерно разрешающие роли, отсутствие сегментации, секреты с чрезмерным объемом и отсутствие предупреждений. Компаниям важно помнить, что они также несут ответственность за безопасность в облаке.