npm червеят Shai-Hulud се появява отново след 111 дни и заобикаля сканирането за зловреден софтуер

Познат npm червей се завърна след повече от три месеца мълчание, носейки същия зловреден файл, свързан с предишен инцидент във веригата за доставки.

Повторната поява показва как известна заплаха може отново да получи достъп до среди за разработка, когато бъде препубликувана в обикновени софтуерни пакети.

Последната активност включва четири пакета, качени в рамките на един час на 7 септември. Когато даден разработчик инсталира отровена зависимост, зловредният код може да се изпълни преди започването на редовната работа, да потърси токени за достъп и да използва правата за публикуване на жертвата, за да се разпространи в допълнителни пакети.

Това е същият риск, наблюдаван и в други доклади за атаки срещу веригата за доставки на npm, където довереното обновяване се превръща в първоначална входна точка. Анализаторите от Aikido идентифицираха завръщащия се зловреден код по време на триаж и установиха, че неговата SHA-256 стойност е идентична с тази на файла, наблюдаван по време на атаката от 19 май срещу пакетите на @antv.

От Aikido заявяват в доклад, споделен с Cyber Security News (CSN), че резултатът е бил 111-дневен период между последното известно засичане и неговата нова поява.

Предишната вълна беше значителна: компрометиран профил на поддържащ пакета потребител качи 639 зловредни версии на пакета @antv в рамките на един час.

Записите на Aikido отчитат 319 версии на пакети, съдържащи този хеш на файла, всички първоначално засечени на 19 май, преди четири нови версии да се появят на 7 септември. Новият инцидент е по-малък по мащаб, но е важен, тъй като кодът вече е бил широко идентифициран.

Shai-Hulud npm червеят се появява отново

Четирите завръщащи се версии са публикувани от същия npm профил. Тяхната основна характеристика не е преработен имплант или новоскрит компонент, а повторна употреба на зловреден код, чийто отпечатък е бил публично известен от месеци, предлагайки на атакуващите пряк път към доверените работни процеси за разработка.

Тази разлика е важна. Сканирането за зловреден софтуер е изправено пред трудни случаи, включващи скрити етапи, забавена активност или код, който се променя според средата.

Тук анализаторите посочват, че пробата не е била преопакована или леко променена. Тя е била точно съвпадение по хеша на файла, което прави инцидента тест за откриване на известен зловреден софтуер, а не състезание с нов метод за заобикаляне на защитите.

Зловредният код използва действие по време на инсталация, за да започне изпълнението си. Той може да валидира откраднати токени спрямо npm регистъра, да изтегля архиви с пакети, да инжектира код, да увеличава номера на версията и да препубликува променената версия.

Този автоматизиран цикъл обяснява защо инфекциите с червеи в npm могат бързо да превърнат един компрометиран профил на разработчик в по-широк проблем във веригата за доставки.

Активността му надхвърля рамките на инсталацията. Изходните материали описват опити за създаване на конфигурационни файлове на проекта, които могат да оставят път за изпълнение, когато хранилището бъде отворено по-късно.

Отбелязва се и масово създаване на GitHub хранилища с имена, свързани с Dune, и обърнати референции за Shai-Hulud — поведение, което може да помогне на защитниците да проследят свързана активност.

Какво трябва да проверят разработчиците

През юли npm въведе сканиране по време на публикуване, като задържа пакетите за около 5 до 15 минути, преди те да станат достъпни за инсталиране.

Системата има за цел да спре откриваемия зловреден софтуер, преди той да достигне до потребителите. Тази реактивация подсказва, че проверката в регистъра все още може да се провали, когато трябва да разпознае предварително каталогизиран зловреден артефакт.

Екипите трябва да прегледат дали четирите идентифицирани версии са били инсталирани на работни станции на разработчици, в задачи за непрекъсната интеграция (CI) или в кеша за изграждане (build cache).

Те трябва да променят секретите в npm, GitHub, облака и други среди, които може да са били изложени на риск, след което да проучат последните публикувания на пакети от засегнатите профили. Реакцията отразява уроците от компрометирането на пакета Keyv, където валидните канали за разпространение усилиха атака с компрометирани пароли.

Организациите трябва да фиксират одобрените версии на зависимостите, да проверяват инсталационните скриптове и архивите с пакети преди внедряване, както и да ограничат обхвата и продължителността на живота на токените за публикуване.

Блокирането на инсталационни скриптове намалява риска, но не е пълна защита, когато злонамереният код използва алтернативни пътища за изграждане или конфигурация на проекта. Скорошното отражение на атаката срещу веригата за доставки чрез binding.gyp илюстрира как атакуващите могат да избегнат проверките, на които екипите разчитат за защита.

Притеснението не е, че всеки скенер пропуска всяка заплаха. Проблемът е, че зловреден код с известен публичен хеш и дълга история на откриване е влязъл отново непроменен в основна екосистема от пакети.

Разработчиците и операторите на регистри трябва да проверят многослойните си контроли, да наблюдават активността по публикуване и да предполагат,телно, че спящият зловреден софтуер може да се върне без предупреждение по всяко време чрез познати наглед обновления на пакети.

Индикатори за компрометиране (IoCs):-

Забележка: IP адресите и домейните са нарочно неутрализирани (напр. [.]), за да се предотврати случайно разрешаване на имена или отваряне на хипервръзки. Възстановете оригиналния им вид само в рамките на контролирани платформи за анализ на заплахи като MISP, VirusTotal или вашата SIEM система.

Поддържайте вашия SOC център информиран за активен зловреден софтуер и фишинг в рамките на 24 часа от появата им. Изпробвайте ANYRUN, за да предотвратите инциденти с ранно откриване.