Гайнуллина Екатерина, инженер по информационной безопасности, Отдел развития Производственного департамента Security Vision

Беляева Ева, руководитель отдела развития Производственного департамента Security Vision

Введение

Как часто, пользуясь open source, вы задумывались о том, что придет с грядущим обновлением? Скорее всего, регулярно, особенно за последние несколько лет. Весь мир давно говорит о том, что любые обновления проприетарного ПО требуют тестирования и проверки, с обновлениями opensource-решений такая же история.

В последние годы атаки на цепочку поставок стали значительной угрозой для безопасности программного обеспечения.

**Рисунок 1. Рост атак на цепочку поставок, 2019-2022**

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

Как атаки на цепочки поставок влияют на бизнес?

· Утечка данных

· Финансовые потери

· Сбои в работе

· Ущерб репутации

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

От чего нужна защита

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

Внедрение вредоносного кода

Внедрение вредоносного кода - тонкая, но весьма опасная форма атаки, которая подчеркивает угрозы, с которыми сталкиваются разработчики.

Сценарий атаки часто начинается с получения злоумышленником доступа к исходному коду библиотеки, будь то через компрометацию (как в случаях codecov и SolarWinds) или путем выдачи себя за оригинального разработчика с открытым исходным кодом. Затем, когда доступ получен, в код вносятся изменения, которые содержат в себе вредоносные нагрузки. Это может варьироваться от обычной утечки учетных данных до сложного крипто-ограбления, где киберпреступники похищают криптовалюту на миллионы долларов.

В контексте Log4j, который стал катализатором обсуждений в сообществе кибербезопасности, отчет Verizon DBIR 2023 выделяет неожиданные аспекты его использования, включая шпионаж и организованную преступность.

Для недопущения последствий подобных кампаний необходимы два ключевых элемента:

· Осведомленность о программных компонентах: важно знать, какие программные компоненты интегрированы в программное обеспечение, как прямо, так и временно. Использование SBOM (Software Bill of Materials) или спецификаций программного обеспечения позволяет лучше понимать структуру и зависимости в программном коде. Это обеспечивает прозрачность и обнаружение уязвимостей на более ранних этапах разработки.

· Способность к быстрым изменениям: когда поврежденный выпуск программного обеспечения обнаружен, критическим является возможность быстрого внесения корректив. Гибкость и оперативность в реагировании на угрозы позволяют минимизировать временной промежуток между обнаружением и устранением уязвимости.

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

Протестное ПО

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

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

Протестное ПО стало актуальной темой после серии изменений в пакете JavaScript node-ipc. Поскольку node-ipc необходим для функциональности ряда других кодов, включая фреймворк Vue.js для пользовательских интерфейсов, некоторые исследователи по безопасности изначально отнесли злонамеренные изменения к категории атак на цепочку поставок. В то время как в прошлых атаках на цепочку поставок виновными всегда были внешние лица, Брэндон Ноздаки Миллер, основной разработчик node-ipc, использующий псевдоним RIAEvangelist, внес изменения в знак протеста. Обозначенный как peacenotwar, код был разработан для стирания данных, если он использовался на системах, расположенных в России или Беларуси.

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

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

Путаница в зависимостях

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

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

Typosquatting

Typosquatting (опечаточный домен) продолжает быть популярным методом для проведения атак на цепочки поставок программного обеспечения и основывается на обманчиво простой технике. Берется популярный компонент, слегка меняется его название и дальше работает предположение, что некоторые разработчики допустят ошибку при добавлении компонента. Работа с программным обеспечением в конечном итоге представляет собой очень повторяющуюся форму письма. С миллионами пар рук, набирающих npm install или редактирующих requirements.txt на миллионах клавиатур, неизбежно будут допущены ошибки.

Примером, наблюдаемым в реальной жизни, является кампания против библиотеки colors, когда противники называют свои пакеты colors-2.0 или colors-helper и так далее.

Вредоносная полезная нагрузка

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

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

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

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

Как защищаться

Вендорские решения

1. Kaspersky Open Source Software Threats Data Feed

Как уже было упомянуто ранее, Лаборатория Касперского запустила сервис данных об уязвимостях Kaspersky Open Source Software Threats Data Feed. Предоставляя данные о программном обеспечении с открытым исходным кодом, поток данных об угрозах Касперского включает в себя компоненты с необъявленными возможностями и пакеты с небезопасным программным обеспечением. CodeScoring использует эти данные для автоматизированной проверки компонентов с открытым исходным кодом, предоставляя разработчикам результаты анализа. Использование готовых пакетов в разработке ПО стало обычной практикой для экономии времени.

2. GitHub Code Scanning

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

3. CodeScoring

CodeScoring – российское решение OSA/SCA, предоставляющее средства для проверки компонентов с открытым исходным кодом и обеспечения безопасности цепочек поставок программного обеспечения. Использует данные об угрозах от Kaspersky Open Source Software Threats Data Feed. Обеспечивает управление информацией об используемых компонентах и отслеживание безопасности.

4. Snyk

Snyk предоставляет решения для обеспечения безопасности открытого исходного кода и зависимостей. Основное внимание уделяется раннему обнаружению уязвимостей. Использует анализ зависимостей и интеграцию с CI/CD системами. Предоставляет информацию о безопасности зависимостей.

5. WhiteSource

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

6. Sonatype Nexus Lifecycle

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

Самостоятельная защита

Несмотря на то, что на рынке пока нет универсальной стратегии защиты от этой угрозы, существует несколько подходов, которые вы можете использовать самостоятельно для защиты от protestware и внедрений вредоносного кода в зависимости в вашем коде. Вот несколько рекомендаций:

1. Ручные проверки кода

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

2. Используйте инструменты статического анализа

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

Пример: SonarQube - инструмент для непрерывной проверки качества кода, который может выявлять потенциальные уязвимости и проблемы безопасности в коде.

3. Обновляйте зависимости

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

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

4. Используйте проверенные источники

Предпочитайте использование пакетов из официальных репозиториев или источников с доверенной репутацией.

Пример: Использование пакетов из официальных репозиториев, таких как npm (Node Package Manager), PyPI (Python Package Index) или Maven.

5. Мониторинг изменений

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

Пример: Snyk - инструмент для обнаружения и мониторинга уязвимостей в зависимостях вашего проекта.

6. Используйте подписи и хеши

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

Пример: Использование инструментов, таких как GPG (GNU Privacy Guard), для проверки цифровых подписей и SHA-256 для проверки хешей файлов.

7. Образцы кода

Изучайте примеры кода, предоставленные разработчиками зависимостей, чтобы понимать, как эти компоненты используются и какие функции предоставляют.

8. Следите за обновлениями безопасности

Подписывайтесь на обновления безопасности ваших зависимостей, чтобы быть в курсе новых уязвимостей и обновлений.

Пример: Подписка на обновления безопасности через инструменты, такие как OWASP Dependency-Check, который проверяет проект на наличие зависимостей с известными уязвимостями.

Выводы

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

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

SSDL: Знай своего opensource-поставщика в лицо и не только