Ошибка в одном символе, приведшая к распространению вредоносного ПО
Всё началось с опечатки. Где-то среди огромного потока предложений и PR-объединений кто-то набрал @utils_core вместо @utils-core в пакет.json. Этот односимвольный пропуск не вызвал ошибку. Вместо этого он тихо ввёл вредоносный пакет-двойник в течение следующего CI/CD запустить, используя доверие к закрепленным версиям и автоматизации. Добро пожаловать в мир тайпсквоттинга в сфере открытого исходного кода.
Тайпсквоттинг: вектор атаки, процветающий за счет человеческих ошибок
Тайпсквоттинг — это именно то, что вы описали: злоумышленники регистрируют пакеты с именами, практически идентичными легитимным. В быстро меняющихся средах это работает, потому что разработчики уверены, что их пакет.json и Пакет-lock.json Отражает то, чего они ожидают. Разница в один символ? Это можно было бы скрыть в PR-отчете.
NPM Имеет историю эксплуатации через тайпсквоттинг. Пакеты, такие как кроссенв вместо кросс-env or поток событий Бэкдоры уже продемонстрировали эффективность подобных двойников. Эти поддельные пакеты часто проходят проверку просто потому, что выглядят корректно и не вызывают мгновенных ошибок во время выполнения.
К распространённым ловушкам относятся:
- Дефис и подчеркивание: lodash-core vs lodash_core
- Множественное число: запросить vs Запросы
- Замененные символы: экспресс вместо экспресс
Где package-lock.json становится слепым пятном
Разработчик исправляет опечатку. Или так ему кажется. Но к этому моменту Пакет-lock.json Уже заблокировал пакет злоумышленника. И именно здесь кроется настоящий риск.
В отличие от пакет.json, который редактируется вручную и подвергается более тщательной проверке, Пакет-lock.json автоматически генерируется NPM. В результате к нему часто относятся как к формальности, пропускают или лишь бегло его изучают. pull request Отзывы. Команды часто отмечают его как «слишком шумный» или безоговорочно доверяют ему, не изучая его внимательнее.
Злоумышленники это знают. Они на это рассчитывают. вредоносный пакет упоминается, благодаря опечатке в package.json, package-lock.json Записывает разрешённую версию. Даже если опечатка будет исправлена позже, вредоносная запись может сохраниться, если файл блокировки не будет явно пересоздан.
Хуже того, закрепление версий, призванное обеспечить согласованность, может иметь обратный эффект. Злоумышленники могут создать поддельный пакет, идентичный легитимному. Если CI/CD Система слепо доверяет закрепленным версиям, она не обнаружит, что устанавливает пакет с заведомо исправным номером версии, но из другого, вредоносного источника.
Это молчаливое упорство – то, что делает Пакет-lock.json Очень опасно. Да, это гарантирует детерминированную сборку, но также гарантирует, что вредоносный пакет останется, пока его не выловят и не удалят вручную.
CI/CD: Куда попадает вредоносное ПО – package.json
В типичном CI/CD pipeline, вредоносному пакету не нужно ждать выполнения. Он разрешается и активируется гораздо раньше в потоке:
Разрешение зависимости
pipeline извлекает точные версии зависимостей из package-lock.json, который теперь включает в себя пакет тайпсквотирован из-за опечатки в пакет.json.
Фаза установки
В процессе npm ci устанавливаются все зависимости, включая вредоносную. Никаких предупреждений, никаких подсказок, просто тихая установка.
Выполнение скрипта после установки
Пакет-двойник включает в себя скрипт, который автоматически запускается после завершения установки. Именно здесь и происходит компромисс.
Пример псевдокода:
if (installation_phase_active) {
runHiddenPayload()
}Описание псевдокода:
На этапе установки, если присутствует хук пост-установочного жизненного цикла, поддельный пакет активирует свою скрытую логику — часто ещё до запуска сборок или тестов. Это может включать в себя внешние запросы, внедрение бэкдоров или другие несанкционированные действия.
⚠️ Внимание: этот псевдокод предназначен только для демонстрационных целей и не должен использоваться в реальных условиях.
Никаких оповещений не срабатывает. Всё работает без сбоев. Окружающая среда уже находится под угрозой, ещё до того, как вы... pipeline даже доходит до стадии тестирования.
Найдите разницу, пока не стало слишком поздно
Распространенная ошибка: предполагать, пакет.json рассказывает всю историю. Это не так. Настоящая сила кроется в сочетании package.json + package-lock.json.
Вот что нужно искать:
- Ли Пакет-lock.json включать неожиданные пакеты?
- Имеются ли какие-либо зависимости из неизвестных реестров или имеют странные области действия?
- Номера версий слишком конкретные или несоответствуют друг другу?
Используйте инструменты CLI, такие как:
- аудит нпм для уведомления об известных проблемах
- npm ls для просмотра полного дерева зависимостей
- Разница для сравнения версий между пакет.json и Пакет-lock.json
Закаляйте свои Pipeline: Защита, которая работает
Чтобы защититься от тайпсквоттинга:
- Обеспечить соблюдение ограничений области действия в пакет.json.
- Добавить предварительное слияние hooks для проверки и валидации зависимостей.
- Используйте нпм си чтобы избежать непреднамеренного смещения версий.
- Регулярно сканируйте Пакет-lock.json на предмет аномалий.
И самое главное: относитесь к непроверенным записям в Пакет-lock.json как потенциальные риски. Каждый commit следует рассматривать как контрольно-пропускной пункт цепочки поставок.
Автоматизированное обнаружение: как помогают такие инструменты, как Xygeni
Хотя это и не панацея, автоматизированные инструменты, такие как Ксигени Играют решающую роль в снижении человеческого фактора, на котором процветает тайпсквотинг. Xygeni интегрируется непосредственно в ваш рабочий процесс DevOps, добавляя уровень защиты в режиме реального времени от перехвата зависимостей ещё до того, как код будет запущен в исполнение.
Вот как помогает Xygeni:
- Обнаружение подозрительного имени пакета:
Использует интеллектуальную эвристику для обнаружения шаблонов тайпсквоттинга в пакет.json, поиск незначительных изменений в названиях известных пакетов (например, добавленные подчеркивания, транспозиции или перестановки букв). - Проверка неизвестного хеша:
Сравнивает хэш каждой зависимости в Пакет-lock.json по базе данных заведомо исправных артефактов из доверенных реестров. Даже если имя пакета и версия выглядят корректно, несовпадение хешей вызывает опасения. - Блокировка перед сборкой:
Перехватывает и блокирует установку любых непроверенных или подозрительных пакетов до того, как они достигнут фазы установки или после установки в CI/CD pipeline. - Анализ графа зависимостей:
Постоянно проверяет все дерево зависимостей на предмет попыток косвенного тайпсквоттинга или вредоносных транзитивных зависимостей. - Оповещения и отчеты:
Предоставляет подробные и действенные оповещения, показывающие, что было отмечено, почему и откуда это взялось в цепочке зависимостей.
По мере усложнения экосистем пакетов такие инструменты, как Xygeni, становятся незаменимыми. Ручная проверка не масштабируется с ростом зависимостей или быстрой итерацией. Xygeni автоматизирует критически важные проверки, необходимые для современных pipelineпотребность, устранение разрыва между доверием и проверкой.
Один персонаж. Реальные последствия.
Это не было экзотикой. нулевого дняЭто была опечатка. Один неуместный символ в пакет.json, молчаливо подкреплённый Пакет-lock.jsonи вредоносное ПО было отправлено автоматически во время обычного CI/CD бежать.
Вот в чём настоящая опасность тайпсквоттинга: ему не нужна сложность. Он использует скорость, доверие и автоматизацию. Этот компромисс можно было бы предотвратить, если бы были внедрены правильные меры контроля:
- Автоматическое сканирование для выявления подозрительных имен и версий пакетов перед установкой.
- Аудит файлов блокировки для обнаружения непроверенных или неожиданных записей в Пакет-lock.json.
- Эвристика проверки имени для пометки пакетов, близких к доверенным.
Хватило одного символа. Правильные проверки остановили бы его прежде, чем он коснулся бы вашего pipelineДоверия недостаточно. В современных DevSecOps вы либо всё проверяете, либо рискуете всем.
