Неидентифициран атакуващ компрометира канала за обновяване на cPGuard, инструмент за сигурност, използван на Linux хостинг сървъри, и чрез него разпространи злонамерен скрипт, който инсталира задна врата и събира чувствителни файлове. OPSSHIELD потвърди, че атакуващият е изтеглил част от откраднатите данни, и призова администраторите незабавно да инсталират версия 5.88.25 или по-нова.

Според бюлетина за сигурност на OPSSHIELD пробивът започва на 2 ноември 2026 г. в 02:06 UTC. Атакуващият е използвал компрометирани идентификационни данни, за да получи достъп до инфраструктурата за разпространение на обновявания на компанията (CDN). Как точно са придобити тези данни, все още се разследва.

Атака по веригата на доставки срещу cPGuard

Атакуващият е разпространил скрипта чрез версии 5.88.12 до 5.88.19 на cPGuard. OPSSHIELD открива атаката в рамките на 12 часа след публикуването на засегнатите обновявания, обезопасява компрометирания акаунт, изчиства идентификационните данни на инфраструктурата и спира по-нататъшното разпространение. Тъй като сървърите проверяват за обновявания през определени интервали, е възможно някои от тях да не са изпълнили злонамерения скрипт.

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

Злонамереният скрипт е събирал файлове с Linux акаунти, включително /etc/shadow и /etc/passwd, конфигурацията на root за MariaDB или MySQL, историята на командите на root в обвивката, както и файловете на root за SSH авторизация и известни хостове (known-hosts). OPSSHIELD не е установила дали всеки от изброените файлове е бил събран от всеки засегнат сървър.

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

Паролите на Linux в /etc/shadow се съхраняват като хешове, а не като четими пароли. Атакуващите могат да тестват предположения за пароли срещу откраднатите хешове офлайн, което прави слабите или повторно използваните пароли особено рискови. Конфигурацията на базите данни и историята на командите може да съдържат други тайни данни, които нямат такава защита.

По-широкият проблем е повторното използване на идентификационни данни извън оригиналния сървър. Cybersecuritynews вече е отразявал кражбата на идентификационни данни QLNX, насочена към Linux разработчици, което е друг случай, показващ стойността на SSH ключовете и облачните идентификационни данни за атакуващите. Не е установена връзка между тези инциденти.

Администраторите трябва да прегледат историята на обновяванията с командата grep 'Successfully updated' /opt/cpguard/logs/install_log. Записи с версии от 5.88.12 до 5.88.19 потвърждават инсталиране на засегнато обновяване, но не доказват изпълнение на скрипта или пренос на данни. Липсващите или непълни дневници също не могат да докажат, че даден сървър е избегнал компрометиране.

Известните индикатори включват скрипта cpguard-v58812-i91511.sh, обвивката за задна врата /var/tmp/.cpg91511_sh, директорията за събиране на данни /var/tmp/.cpg91511 и подготвения архив /var/tmp/.cpg91511/loot.tgz. Тяхното отсъствие след почистване не изключва по-ранно изпълнение.

OPSSHIELD инструктира всеки клиент да изпълни cpgcli update --start, а след това да провери с cpgcli --version, че версията е 5.88.25 или по-нова. Администраторите, при които обновяването пропада, трябва да се свържат с поддръжката на OPSSHIELD. Коригиращото обновяване премахва известната задна врата и подготвените файлове, но не може да обезсили вече копираните идентификационни данни.

На потенциално компрометираните сървъри е необходимо да се сменят паролите на root и на другите локални акаунти с парола, като това става от доверена среда за възстановяване. Администраторите трябва да сменят засегнатите пароли за бази данни, S3 ключове, токени на DigitalOcean и тайните данни, изложени в историята на командите. Трябва да заменят частните ключове в /root/.ssh и да премахнат съответните стари публични ключове навсякъде, където им се има доверие.

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