Автоматизированные конвейеры CI/CD (непрерывная интеграция/непрерывная доставка) используются для ускорения разработки. Замечательно иметь триггеры или планирование, которые берут ваш код, объединяют его, создают, тестируют и автоматически отправляют. Однако то, что они созданы для скорости и простоты использования, означает, что большинство конвейеров по своей сути не созданы с учетом безопасности. Поскольку конвейерам обычно необходим доступ к Интернету для загрузки зависимостей, а также к вашим различным секретам для загрузки в вашу производственную среду, это означает, что как только такой конвейер будет скомпрометирован, злоумышленник имеет широкий спектр возможностей, чтобы нарушить вашу работу или выведать информацию или секреты.
Все истории, представленные в этой статье, описывают нарушения в известных инструментах CI/CD. Тот факт, что большинство компаний полагаются на такие инструменты, означает, что, как и многие другие атаки на цепочку поставок программного обеспечения, все, что нужно злоумышленникам, — это пробить одну цель, чтобы получить огромный радиус взрыва.
Давайте взглянем на несколько ярких историй за последние несколько лет, демонстрирующих уязвимости, присущие этому вектору атак. В конце статьи я обязательно предложу свои рекомендации по укреплению и защите ваших конвейеров, независимо от того, какие инструменты вы используете.
Нарушение CircleCI
В январе 2023 года CircleCI, платформа непрерывной интеграции и доставки, раскрыла нарушение безопасности что позволило злоумышленнику получить несанкционированный доступ к инфраструктуре компании. Атака была инициирована фишинговым электронным письмом, которое заставило сотрудника поделиться своими учетными данными, которые злоумышленник затем использовал для доступа к системам компании. Сотрудник использовал 2FA, но злоумышленник смог получить файл cookie сеанса, как только сотрудник уже вошел в систему, что позволило ему выдать себя за сотрудника и в конечном итоге расширить доступ к подмножеству производственных систем CircleCI.
Злоумышленник получил доступ к некоторым данным клиентов, включая имена, адреса электронной почты и платежную информацию. Компания сообщила, что доступ к коду или интеллектуальной собственности не был получен, и ни один клиент не сообщил о несанкционированном доступе к своим учетным записям или данным.
CircleCI быстро отреагировала на взлом, проведя расследование и работая с правоохранительными органами и экспертами по кибербезопасности, чтобы определить масштабы атаки и устранить уязвимости, которые позволили ей произойти. Компания также сбросила учетные данные всех сотрудников и клиентов и внедрила дополнительные меры безопасности, такие как усиленный мониторинг своих систем.
DevOps нарушен: нарушение безопасности Argo CD
Argo CD — популярный инструмент с открытым исходным кодом для непрерывного развертывания приложений в кластерах Kubernetes. В феврале 2022 года в Argo CD обнаружена новая уязвимость это позволяло неаутентифицированным пользователям получать доступ к конфиденциальной информации о приложениях Kubernetes, управляемых этим инструментом. Уязвимость была вызвана неправильной настройкой API-сервера Argo CD, которая позволяла неавторизованным пользователям выполнять запросы к API и получать такую информацию, как секреты, конфигурации и метаданные приложения. Пока злоумышленник имел разрешение на создание или обновление приложений и знал или мог угадать полный путь к файлу, содержащему действительный YAML, он мог создать вредоносную диаграмму Helm и продолжать использовать файлы YAML в качестве значений, пока не найдет ценный фрагмент данных, который обычно был бы недоступен.
Уязвимости был присвоен рейтинг CVSS 7.5 (высокая серьезность) и она затрагивала все версии Argo CD до версии 2.1.4 включительно. Компания Argo CD выпустила патч для уязвимости версии 2.1.5, и пользователям посоветовали как можно скорее перейти на эту версию.
Уязвимость вызвала особую обеспокоенность, поскольку Argo CD часто используется для управления критически важными приложениями и инфраструктурой в производственных средах. Утечка конфиденциальной информации могла позволить злоумышленнику получить доступ к конфиденциальным данным или предпринять другие вредоносные действия, которые могли бы повлиять на доступность или безопасность приложений.
Обнаружение нарушения Codecove: извлеченные уроки
Codecov — это инструмент отслеживания и анализа покрытия кода, используемый в конвейерах CI/CD и позволяющий разработчикам измерять и анализировать эффективность своих тестов. Как опубликовано в Codecov's обновление для системы безопасности:
«В четверг, 1 апреля 2021 года, мы узнали, что кто-то получил несанкционированный доступ к нашим Bash-загрузчик скрипт и изменил его без нашего разрешения. Актер получил доступ из-за ошибки в процессе создания образа Docker в Codecov, которая позволила ему извлечь учетные данные, необходимые для изменения нашего сценария Bash Uploader».
Bash Uploader используется клиентами для загрузки отчетов о покрытии кода на платформу Codecove. Получив этот доступ, злоумышленник модифицировал сценарий Bash Uploader, добавив вредоносный код, который собирал переменные среды, токены аутентификации и другие конфиденциальные данные из системы пользователя во время процесса загрузки. Затем эти данные были отправлены на удаленный сервер, контролируемый злоумышленником.
По данным Codecove, нарушение затронуло примерно 1% ее клиентской базы, в которую вошли крупные компании в сфере технологий, финансов и здравоохранения. Компания подтвердила, что ни один клиентский код или отчеты о покрытии кода не были изменены во время взлома, но что токены аутентификации пользователей и другая конфиденциальная информация могли быть скомпрометированы.
Codecove предприняла немедленные действия по удалению вредоносного кода и предупредила затронутых клиентов о необходимости сбросить свои токены аутентификации и принять другие меры безопасности. Компания также начала расследование инцидента и обратилась к правоохранительным органам и экспертам по кибербезопасности, чтобы определить источник атаки.
Как защитить свой трубопровод?
Комплекты градирен в здании центра обработки данных.
Как упоминалось выше, конвейеры CI/CD созданы для скорости и автоматизации, но не обязательно для безопасности. Тот факт, что три крупные и уважаемые компании стали жертвами той или иной атаки, потенциально раскрывающей информацию их клиентов, демонстрирует уязвимость вашего собственного конвейера и данных.
Независимо от того, какие инструменты или платформу CI/CD вы используете, вы можете сделать несколько вещей, чтобы повысить свою безопасность и уменьшить возможный ущерб в случае, если злоумышленнику все же удастся получить доступ к вашему конвейеру или сети.
- Моделирование угроз – Моделирование угроз – это структурированный подход к выявлению потенциальных угроз безопасности системы или приложения и разработке соответствующих контрмер для смягчения этих угроз. В качестве упражнения представьте, что кто-то получил доступ к вашему конвейеру. К каким средам они теперь могут получить доступ? Какие секреты и ключи они могут увидеть и использовать? Могут ли они изменить ваш код? Тесты на влияние? Извлечь файлы из Интернета или запустить обратную оболочку? Даже если вы думаете, что очистили свой конвейер и правильно сегментировали доступ к сети, не помешает представить, а затем проверить, чтобы вы знали о наихудшем сценарии. Вы можете быть удивлены, какие секреты и возможности доступа скрыты на виду внутри вашей конвейерной платформы или инструментов.
- Сегментация сети – Сегментация сети — это практика разделения более крупной сети на более мелкие и более безопасные подсети или сегменты, каждый из которых имеет свои собственные средства управления безопасностью и политики. Целью сегментации сети является повышение безопасности всей сети за счет ограничения масштабов потенциального нарушения безопасности и сведения к минимуму потенциального воздействия атаки. Разбиение сети на более мелкие сегменты ограничивает горизонтальное перемещение злоумышленников и снижает риск несанкционированного доступа или утечки данных.
С ростом популярности фишинговых атак любой из ваших разработчиков или других сотрудников может стать жертвой такого мошенничества – мы все люди. Если предположить, что учетные данные ваших разработчиков могут быть использованы злоумышленниками, вам необходимо убедиться, что подавляющее большинство разработчиков не будет иметь доступа, который позволил бы им в одиночку выведать секреты, внедрить вредоносный код в рабочий образ и т. д. или просто беспрепятственно продвигать свою собственную версию производственного кода. Обеспечение того, чтобы каждый человек имел наименьший объем доступа, необходимого для его работы, требует много времени, и соблазн просто предоставить всем доступ администратора и покончить с этим очень силен. Не поддавайтесь искушению темной стороны – соблюдайте правила нулевого доверия и минимальных привилегий. - Мониторинг и оповещение – Исходя из последнего пункта, даже если вы тщательно натренировали своих разработчиков, чтобы они не устали от фишинга и других видов мошенничества в области социальной инженерии, взлом все равно может произойти. Вы не знаете, когда и как, но вы должны быть готовы, по крайней мере, узнать об этом. Поскольку большинство сред конвейера являются эфемерными, это означает, что после завершения работы не останется никаких следов того, что произошло, если только вы не создадите такие следы самостоятельно.
Обязательно записывайте все, что происходит в ваших конвейерах, при каждом PR, слиянии, сборке и тестировании. Убедитесь, что информация пользователей также зарегистрирована, чтобы ее можно было просмотреть, если проблема потребует такой проверки. Любые изменения в файлах конфигурации или самой среде также должны регистрироваться. Цель здесь состоит в том, чтобы иметь возможность провести четкое вскрытие взлома, чтобы иметь возможность сказать, что произошло и как. Заранее определите, какие события должны вызывать оповещение, и убедитесь, что это предупреждение получат нужные люди. Старайтесь не загружать людей бесполезными или ложными оповещениями — это вызовет усталость от оповещений, которая просто приведет к тому, что они будут игнорировать оповещения или реагировать намного позже, чем желательно. Очевидно, что ни один из этих журналов не должен содержать никаких открытых секретов или ключей, что приводит к следующему пункту:
- Управление секретами – Убедитесь, что вы используете какой-либо инструмент управления секретами. По крайней мере, это облегчит смену ваших секретов и паролей в случае взлома. Он также должен выполнять работу по удалению открытых секретов и ключей доступа, обнаруженных в конвейере, из любых журналов, выполняемых в системе. Ни в коем случае посторонние лица не должны иметь доступ к такой информации, и они определенно не должны иметь возможность ее изменить.
Управление секретами становится все более важным, поскольку организации все больше полагаются на облачные сервисы, контейнерные приложения и другие распределенные среды, которые требуют безопасного обмена секретами и управления ими в различных системах и приложениях. - Используйте принцип RBAC в сочетании с наименьшими привилегиями. – Принцип управления доступом на основе ролей (RBAC) заключается в предоставлении доступа к системным ресурсам на основе назначенной пользователю роли или должностной функции в организации. В RBAC пользователям назначаются роли, которые определяют разрешения и права доступа, которые они имеют к различным системным ресурсам, таким как файлы, папки или приложения. С другой стороны, принцип наименьших привилегий — это практика предоставления пользователям минимального уровня доступа и привилегий, необходимых для выполнения их рабочих функций. Это означает, что пользователи имеют доступ только к тем ресурсам, которые им необходимы для выполнения конкретных задач, и не более того. RBAC и Least Privilege часто используются вместе как дополнительные принципы безопасности. В RBAC пользователям назначаются роли, которые имеют соответствующий уровень доступа к ресурсам, необходимым им для выполнения своих рабочих функций, а принцип наименьших привилегий гарантирует, что пользователи имеют доступ только к минимальному уровню ресурсов, необходимому для выполнения их конкретных задач. В совокупности эти принципы помогают поддерживать безопасную и хорошо управляемую систему с минимальным риском несанкционированного доступа или утечки данных. В качестве дополнительной меры безопасности вы можете настроить его так, чтобы критические действия в системе требовали нескольких авторизаций пользователя. К этому подходу следует относиться с осторожностью, поскольку он может значительно замедлить работу по разработке. Однако для критических обновлений, таких как удаление основной ветки или изменение списка зависимостей, вам следует сделать так, чтобы их одобрили как минимум два человека с соответствующим доступом.
Взгляд в будущее
Никто не собирается прекращать использовать CI/CD и другие инструменты автоматизации для ускорения своей работы. Мы живем в мире, где постоянно стремимся к более быстрому обновлению кода. Нам просто нужно убедиться, что мы делаем это с учетом безопасности и не ставим под угрозу наш код и производственную среду.
Одна из самых важных вещей, которые вы можете сделать, — это просто подумать о том, что может случиться, если неавторизованные люди получат доступ. Как только вы осознаете опасность и различные места в ваших трубопроводах и сети, которые уязвимы, я надеюсь, вы сможете предпринять правильные шаги для устранения потенциальных утечек.
Scribe — компания, занимающаяся безопасностью цепочек поставок программного обеспечения, чья платформа предназначена для обеспечения прозрачности того, что происходит в процессе и конвейере вашей разработки. Чтобы узнать больше о том, как Scribe может помочь вам защитить ваши конвейеры напишите нам.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
