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

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

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

Что может пойти не так

Политика безопасности Google указывает, что "если злоумышленник успешно внедрит какой-либо код, то, по большому счету, всё уже проиграно." К сожалению, с более широким распространением непрерывного развертывания (CD), время для обнаружения таких атак до выпуска зараженного кода пользователям сокращается.

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

Давайте рассмотрим некоторые потенциальные риски использования открытых решений.

Распространенные формы атак

Злонамеренное программное обеспечение, маскирующееся под подлинные пакеты, регулярно появляется в системах управления пакетами. Два типа атак на цепочку поставок используют многочисленные зависимости современного программного обеспечения: "typosquatting" (атака на опечатки) и путаница зависимостей. В обоих случаях злоумышленник применяет различные тактики, чтобы обмануть разработчика или программное обеспечение для управления, выполнив загрузку файла зависимостей, способного выполнять злонамеренный код.

Атака на опечатки (Typosquatting)

Атака на опечатки основывается на близости клавиш на клавиатуре и общих ошибках в написании для получения доступа. Этот метод атаки выходит за рамки языковых основ программирования. С начала дней интернета опечатки в названиях доменов были проблемой. Обман с пакетами и образами становится всё более распространенным, расчёт идет на быстрый ввод разработчиками.

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

Простыми примерами будут:

• beautifulsoup4 > beautifulsoup

• crypto > crypt

• django > djago

• openvc-python > opencv

Путаница зависимостей (Dependency Confusion)

Dependency Confusion использует смешение частных и публичных зависимостей, которые использует программное обеспечение. Хакеры обычно исследуют файлы package.json для приложений Node.js, чтобы найти внутренние незарегистрированные пакеты на npm. Затем они создают вредоносные пакеты с тем же именем пространства имен, и автоматизированные инструменты разработчика устанавливают эти внешние вредоносные пакеты вместо предполагаемого внутреннего пакета.

Эта тактика не ограничивается только npm. Например, при использовании Python’s pip также обнаруживаются уязвимости, готовые к эксплуатации. Здесь хакер может зарегистрировать пакет на PyPi с тем же именем, что и внутренний пакет, указанный в файле requirements.txt. При регистрации они выбирают номер версии выше, чем у подлинного пакета. Когда эта более высокая номер версии используется в сборках, которые включают –extra-index-url, она имеет приоритет и заменяет более старую версию на видимо более новую.

Как и атака Typosquatting, Dependency Confusion является проблемой для всех языков программирования. Аналогичные атаки могут произойти с файлом Maven pom.xml или файлом настроек Gradle в Java или файлом .csproj, который ссылается на пакеты NuGet в .NET. Инструменты неправильно заменяют код, делая наше приложение уязвимым.

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

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

Примерный сценарий:

Хакер создаёт якобы легитимный пакет, например, некоторые вспомогательные функции. Назовём этот пакет X.

Затем они публикуют свой код на сайте распространения пакетов. Запомните, что даже если код доступен для просмотра на GitHub, это не обязательно означает, что это тот же код на сайте управления пакетами.

Они используют пакет X как часть запроса на включение в код для пакета Y, исправляя мелкие баги в открытых проектах. Их искренне полезное исправление бага привлекает внимание к вредоносной зависимости (пакет X), и вуаля! Злонамеренный код находится в репозитории.

Если наш код использует пакет Y, наше ПО наследует уязвимость пакета X.

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

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

Заключение

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

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