Приховані «логічні бомби» в NuGet-пакетах

Дослідники виявили дев’ять шкідливих NuGet-пакетів, які виглядають як легітимні бібліотеки для роботи з БД та промисловими контролерами, але містять логічні бомби з відкладеним запуском. Шкідливий код має активуватись лише у 2027–2028 роках, провокуючи «випадкові» збої застосунків та саботаж роботи промислових систем — тоді, коли більшість розробників уже давно забудуть, що колись підключали ці залежності.

Компанія Socket, що спеціалізується на безпеці ланцюга постачання ПЗ, повідомила про дев’ять зловмисних NuGet-пакетів, опублікованих користувачем під ніком shanhai666 у 2023–2024 роках. Загалом їх завантажили майже 9,5 тисячі разів.

Ці пакети:

• виглядають як звичайні бібліотеки для роботи з SQL Server, PostgreSQL, SQLite;

• використовуються для доступу до баз даних або керування PLC (програмованими логічними контролерами) у промислових системах;

• містять прихований код, який перевіряє дату й активується тільки після настання строгих тригерних дат у серпні 2027 та листопаді 2028 року.

Ключова небезпека — пакет Sharp7Extend, спрямований на користувачів популярної бібліотеки Sharp7 для взаємодії з Siemens S7 PLC:

• одразу після встановлення він може завершувати роботу процесу із певною ймовірністю;

• додатково, через 30–90 хвилин, починає тихо псувати операції запису на PLC (частина записів просто непомітно не відбувається);

• такий саботаж може вдарити по виробничих лініях, системах безпеки та інших критичних процесах.

Інші пакети спеціально «затримані» у часі:

• одні спрацьовують лише після 8 серпня 2027 року,

• інші — після 29 листопада 2028 року.

Це дає зловмисникам великий проміжок часу, щоби:

• зібрати максимум «жертв», поки пакети здаються безпечними;

• забезпечити, щоб до моменту активації dev-команди вже змінилися, проєкти переписалися, а логіка підключення залежностей давно забута.

Коли ж «бомба» спрацьовує, застосунок:

• то випадково падає,

• то вибірково псує операції з БД або PLC,і все це дуже схоже на нестабільність заліза або випадкові баги, а не на цілеспрямовану атаку.

1. Логічні бомби у ланцюзі постачання ПЗ

Логічна бомба — це код, який сидить тихо доти, доки не виконається певна умова: дата, подія, конфігурація тощо. У цьому кейсі:

• тригером є конкретні дати у 2027–2028 роках;

• це supply chain-атака: підмінюються компоненти, які розробники скачують із довіреного репозиторію (NuGet).

Такий підхід особливо небезпечний для:

• enterprise-проєктів на .NET, які активно використовують NuGet;

• промислових систем (ICS), де помилка в PLC може призвести до

• • зупинки виробництва,
  • аварій,
  • ризиків для людей.

2. Використання C# extension methods

Згідно з дослідженням Socket, зловмисники активно використовують extension methods у C#

Extension methods дозволяють:

• «розширити» існуючий тип новими методами без зміни його вихідного коду;

• виглядають, як звичайні методи класу, тому не кидаються в очі при поверхневому перегляді.

У зловмисних пакетах:

• розширення перехоплюють запити до БД і операції з PLC;

• кожен виклик потрапляє через «обгортку», яка:

• перевіряє поточну дату;

• у потрібний час запускає шкідливу логіку — завершення процесу, саботаж запису тощо.

У частині пакетів дати жорстко прошиті в коді, а у Sharp7Extend — зашифровані в конфігурації, що ускладнює аналіз.

3. Відсутність очевидного винного і складність розслідування

Socket вказує, що:

• усі шкідливі пакети вже видалено з NuGet;

• аналіз коду й нікнейм автора (shanhai666) можуть натякати на китайське походження загрози, але прямих доказів немає.

Головна проблема для організацій:

• відкладений запуск + ймовірнісна поведінка (наприклад, падіння процесу лише в 20% випадків) роблять інцидент схожим на «рандомні проблеми»;
• через роки буде майже неможливо:
  • згадати, хто і коли додав компрометований пакет;
  • відтворити повний ланцюг подій і компрометації;
  • довести, що це цілеспрямована атака, а не збіг обставин.

ВИСНОВОК (що це означає для розробників і компаній)

Історія з прихованими логічними бомбами в NuGet-пакетах показує:

1. Отруєння ланцюга постачання ПЗ стає дедалі складнішим і «довгограючим»: зловмисники готові чекати роками, поки їхній код «дозріє».
2. Відкладений і ймовірнісний саботаж — ідеальний спосіб замаскувати атаку під:
   • випадкові збої;
   • проблеми заліза;
   • нестабільність мережі чи БД.
3. Організації, які не ведуть чіткий облік залежностей та їхніх версій, ризикують опинитись у ситуації, коли:
   • атака відбулася,
   • системи падають або працюють некоректно,
   • а джерело» отрути знайти майже неможливо.

Для розробників і компаній це сигнал:

• посилювати контроль залежностей (software composition analysis, блокування підозрілих пакетів, перевірка розширень);

• впроваджувати процедури аудиту для пакетів із відкритих реєстрів;

• планувати довгострокову безпеку, а не лише реагувати на миттєві загрози.