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