Przejęty kanał aktualizacji cPGuard rozpowszechniał złośliwy skrypt w wersjach 5.88.12–5.88.19, podało OPSSHIELD. Skrypt mógł zainstalować backdoora i zebrać poufne pliki z serwerów Linux. Administratorzy powinni sprawdzić logi aktualizacji, usunąć pozostałe ślady i osobno wymienić dane dostępowe, które mogły zostać skopiowane.

Jak przebiegał atak i jakie serwery mógł objąć

Według późniejszego komunikatu OPSSHIELD napastnik uzyskał dostęp do serwera rozliczeń i licencji 1 listopada 2026 r. Około 02:04–02:09 UTC następnego dnia przesłał złośliwy skrypt do systemu aktualizacji. Instalacje na serwerach klientów miały nastąpić między 02:08 a 03:20 UTC, 2 listopada.

OPSSHIELD oszacowało, że skrypt uruchomił się na około 2950 serwerach. Firma podała też, że skradziono dane rozliczeniowe około 7900 kont klientów i skopiowano trzy jej serwery chmurowe. Wstępny szacunek 32 plików skradzionych z serwera licencyjnego dotyczył innej miary: każdy z tych plików był powiązany z serwerem klienta.

Co sprawdzić w logach i na serwerze

Wpis w logu dotyczący wersji 5.88.12–5.88.19 wskazuje, że zainstalowano podatną aktualizację. Sam wpis nie rozstrzyga, czy skrypt się uruchomił ani czy dane opuściły serwer. Do wyszukania wpisów aktualizacji służy polecenie:

grep 'Successfully updated' /opt/cpguard/logs/install_log

Brak wpisu lub niekompletny log nie wykluczają narażenia. Aktualizacje mogły też usunąć część śladów, więc czysty wynik kontroli plików nie przesądza, że skrypt wcześniej się nie uruchomił.

Skrypt miał zbierać między innymi /etc/shadow, /etc/passwd, pliki SSH roota, /root/.my.cnf oraz historię poleceń roota. Plik /root/.s3cfg wymieniono w przypadku niewielkiej liczby serwerów. Opisane ślady działania obejmowały ukrytą powłokę z uprawnieniami roota w /var/tmp/.cpg91511_sh, zadanie w /etc/cron.d/i93677 oraz pliki w katalogu /var/tmp/.i93677/.

Poprawki i kolejność działań

W pierwszej informacji jako poprawkę wskazano cPGuard 5.88.25. Później podano, że wersja 5.88.26 usuwa backdoora, a osobna aktualizacja usuwa zaplanowane zadanie. Nie podano numeru tej dodatkowej aktualizacji.

OPSSHIELD zalecało aktualizację cPGuard na serwerach, sprawdzenie pozostałych śladów i zmianę potencjalnie narażonych danych dostępowych. W praktyce oznacza to osobne działania w dwóch obszarach:

  1. Zaktualizuj cPGuard i sprawdź serwer pod kątem pozostałych plików oraz zaplanowanego zadania.
  2. Zmień lokalne i ponownie używane hasła, dane dostępowe do baz danych i chmury oraz hasła do portalu rozliczeniowego OPSSHIELD, jeśli mogły znaleźć się w zebranych plikach.
  3. Wymień potencjalnie narażone klucze SSH, przejrzyj authorized_keys i usuń stare, zaufane klucze publiczne. Uwzględnij też sekrety zapisane w historii powłoki.

Sama aktualizacja nie unieważnia skopiowanych danych logowania. OPSSHIELD nie zalecało rutynowej odbudowy całego systemu. Firma opisywała indywidualną ocenę sytuacji oraz odbudowę z czystej kopii zapasowej, gdy potwierdzono ręczne logowanie napastnika.