Dependency confusion по-прежнему срабатывает — и помогает разведке
Новая вредоносная кампания в npm использовала 33 пакета, распространявшихся через dependency confusion, чтобы собирать данные о рабочих станциях разработчиков и системах сборки. По данным исследователей Microsoft Security, цель операции заключалась не в немедленном развёртывании разрушительных нагрузок и не в массовой краже данных, а в профилировании окружений.
Для организаций, использующих npm, автоматизированные пайплайны сборки и внутренние экосистемы пакетов, это не только проблема вредоносного кода, но и вопрос видимости цепочки поставок ПО. Разведка часто становится первым этапом атаки. Когда злоумышленники понимают, в какие среды они проникли, они могут планировать более точные последующие действия.
Что произошло#
Microsoft сообщила о кампании dependency confusion, в которой использовались 33 вредоносных npm-пакета для сбора информации о средах разработки и сборки. Атака опиралась на хорошо известную схему компрометации цепочки поставок: публикацию пакетов таким образом, чтобы менеджеры пакетов или процессы сборки загружали код злоумышленника вместо ожидаемой внутренней зависимости.
Главная особенность кампании — её цель. По имеющимся данным, пакеты были ориентированы на сбор сведений об окружениях, в которых они запускались. Речь шла не о саботаже, а о получении разведданных.
Такую активность легко недооценить. Команды безопасности обычно сосредоточены на вредоносном ПО, которое крадёт секреты, разворачивает ransomware или закрепляется в системе. Однако картирование среды часто помогает выявить, где находятся ценные учётные данные, облачные ресурсы, системы развёртывания и чувствительные рабочие нагрузки.
В крупных организациях поверхность атаки не ограничивается ноутбуками разработчиков. Полезную информацию могут раскрывать раннеры сборки, инфраструктура CI/CD, тестовые среды, зеркала репозиториев пакетов и различные системы автоматизации.
Что такое dependency confusion#
Dependency confusion — это техника атаки на цепочку поставок ПО, использующая особенности разрешения зависимостей.
Типичный сценарий выглядит так: компания поддерживает внутренние пакеты, которые должны оставаться закрытыми. Злоумышленник публикует пакет с тем же или похожим именем в публичном репозитории. При определённых настройках автоматизированные инструменты могут выбрать и установить публичный пакет вместо внутренней зависимости.
Результат прост: код атакующего выполняется внутри доверенного процесса разработки или сборки.
Метод далеко не новый. Его эффективность сохраняется потому, что сложность управления пакетами часто растёт быстрее, чем процессы контроля. Со временем организации накапливают внутренние реестры, зеркала, системы сборки, временные проекты, устаревшие конфигурации и интеграции со сторонними сервисами. Ошибки в правилах разрешения зависимостей создают возможности для злоупотреблений.
Почему разведка опасна сама по себе#
Информация об инфраструктуре имеет ценность.
Вредоносному пакету необязательно сразу похищать учётные данные, чтобы представлять риск. Достаточно понять устройство среды и оценить перспективность дальнейших операций.
Примеры полезных разведданных:
- характеристики систем сборки;
- сведения о хостах и операционных системах;
- конфигурация среды разработки;
- информация о сети;
- данные об используемых экосистемах пакетов;
- признаки облачной или корпоративной инфраструктуры.
Поэтому оценивать вредоносную активность в npm только по факту утечки данных недостаточно. Пакет, который собирает информацию, тоже может быть серьёзным инцидентом безопасности, поскольку раскрывает структуру организации и потенциальные точки атаки.
Именно поэтому защита цепочки поставок ПО всё чаще делает акцент на обнаружении, подтверждении происхождения компонентов и прозрачности процессов, а не только на периметровой защите.
Разведка против прямой кражи секретов#
| Цель атаки | Немедленный эффект | Долгосрочный риск |
|---|---|---|
| Кража учётных данных | Обычно заметна сразу | Прямая компрометация аккаунтов |
| Эксфильтрация данных | Мгновенное раскрытие информации | Регуляторные и операционные последствия |
| Разведка и профилирование | Может выглядеть малозначительной | Подготовка целевых последующих атак |
Разведывательные кампании часто привлекают меньше внимания, потому что ущерб трудно измерить сразу. Это опасное заблуждение. Качественная разведка снижает неопределённость для атакующего и повышает эффективность следующих этапов операции.
Что проверить#
Первым делом обеспечьте видимость процессов установки пакетов и активности сборки.
Проверьте, могут ли среды разработки и сборки устанавливать пакеты из публичных источников в ситуациях, когда должны использоваться внутренние зависимости. Не полагайтесь на предположения — проведите аудит фактических правил разрешения зависимостей.
Полезные действия:
- проверьте схемы именования внутренних пакетов;
- проведите аудит источников пакетов и конфигураций реестров во всей инфраструктуре CI/CD;
- расследуйте неожиданные загрузки пакетов из публичных репозиториев;
- мониторьте выполнение недавно добавленных зависимостей в средах сборки;
- поддерживайте актуальный список разрешённых источников пакетов;
- проверьте покрытие систем обнаружения для событий, связанных с цепочкой поставок и менеджерами пакетов.
Главный вывод совпадает с тенденцией, которую всё чаще обсуждают в сообществе безопасности open source: одной профилактики недостаточно. Необходимо понимать, какие пакеты были установлены, где они запускались и какие действия пытались выполнить.
Материалы по теме:
- OpenSSF’s April signal: make security artifacts operational: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
- 100% package test coverage is the point, not the slogan: https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
- Compromised npm packages put CI/CD secrets at risk: https://gigatap.top/en/articles/compromised-npm-packages-put-cicd-secrets-at-risk
Чего не стоит утверждать без доказательств#
В отчёте Microsoft описана кампания, использовавшая вредоносные npm-пакеты для разведки. Это не означает автоматически, что каждая затронутая среда столкнулась с кражей учётных данных, закреплением в системе, боковым перемещением или успешной компрометацией.
Доступная информация позволяет сделать более узкий вывод: злоумышленники пытались собрать сведения из окружений, где выполнялись эти пакеты.
Для реагирования на инциденты такое различие критично. Командам безопасности следует опираться на факты и телеметрию, а не исходить из худшего сценария по умолчанию. При этом разведывательную активность нельзя считать безобидной только потому, что наблюдался сбор информации, а не её кража.
FAQ#
Это новая техника dependency confusion?#
Судя по опубликованным данным, значение имеет не новая техника, а то, что dependency confusion по-прежнему остаётся рабочим инструментом атакующих. Кампания показывает, что многие организации всё ещё уязвимы, когда границы доверия между источниками пакетов определены недостаточно чётко.
Кому стоит обратить внимание на этот отчёт?#
Всем организациям, использующим разработку на базе npm, внутренние экосистемы пакетов, автоматизированную инфраструктуру сборки или среды CI/CD. Риск касается не только разработчиков — системы сборки и пайплайны автоматизации также могут стать целью атаки.
Означает ли разведывательный пакет, что компрометация уже произошла?#
Нет. Разведка означает попытку собрать информацию. Чтобы определить, были ли дополнительные этапы компрометации, необходимы расследование, журналы событий, телеметрия и доказательства из затронутой среды.