Атаки на разработчика: Dependency Confusion

О техниках атак dependency confusion (или dependency injection) на цепочку поставок в разработке исследователи начали говорить с 2021 года. Но только в этом году исследовательский отдел компании Checkmarx опубликовал отчет с заголовком “Первая известная таргетированная атака на банковский сектор через цепочку поставок ПО с открытым кодом”.

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

1. внедрили пакет с вредоносным кодом в репозиторий пакетов npm, которым пользуются разработчики целевой организации;
2. подготовили инфраструктуру и имплант к стадии пост-эксплуатации, чтобы остаться незамеченными продолжительное время.

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

А вот мои рекомендации:
1. собрать и поддерживать в актуальном состоянии список всех используемых сторонних компонент (как мы ранее решали похожую задачу с инструментами разработчика);
2. внедрить инструмент software composition analysis (SCA) даже если еще не построен процесс безопасной разработки и пока не используется какой-нибудь SAST/DAST;
3. создать внутренний репозиторий для всех зависимостей, поддерживать его в актуальном состоянии и выделить к нему доступ только для разработчика.

Центрам мониторинга (SOC) нужно учиться закрывать набор техник матрицы атак MITRE “Supply Chain Compromise: Compromise Software Dependencies and Development Tools” и осваивать новый скоуп: инфраструктуру разработки и инструменты анализа компонентов программного обеспечения. Теперь мониторить нужно еще и процесс разработки.