W październiku 2026 roku atakujący zaatakowali jednocześnie kilku rosyjskich dostawców hostingu, wykorzystując krytyczną lukę w zabezpieczeniach VMmanager 6, panelu do zarządzania wirtualizacją opracowanego przez ISPsystem (część Astra Group). Panel ten obsługuje serwery VPS dla nas i wielu innych dostawców. My również zostaliśmy zaatakowani.
Twoje serwery nadal działają. Poniżej znajdziesz informacje o tym, co się stało, dlaczego, co już zrobiliśmy i co musisz zrobić Ty.
Przyczyna: luka w zabezpieczeniach produktu dostawcy
Atak był możliwy dzięki krytycznej luce w zabezpieczeniach oprogramowania VMmanager 6. Nie była to błędna konfiguracja u pojedynczego dostawcy: ta sama luka została wykorzystana jednocześnie w wielu firmach hostingowych.
FirstVDS, ForestsNet Cloud, MHost, HSH Network i YaColo publicznie zgłosiły naruszenia za pośrednictwem VMmanager 6. Dostawca potwierdził incydent: według przedstawiciela Astra Group, luka występowała w jednej z kompilacji VMmanager.
| Data | wydarzenie |
|---|---|
| Październik 11 – 16 | Atakujący infekują panele VMmanager 6 poprzez lukę i ustanawiają trwałość |
| Noc z 16 na 17 października | Faza aktywna: dostęp do baz danych paneli i, u niektórych dostawców, do węzłów hostujących serwery klienckie |
| Październik 18 | Rozpoczęliśmy własne dochodzenie i podjęliśmy wstępne działania |
| Noc z 17 na 18 października | ISPsystem udostępnia pierwszą poprawkę (wersja 2026.05.2-6) |
| Październik 19 – 20 | Dostawca udostępnia dodatkowe poprawki, prace nad luką w zabezpieczeniach trwają |
| Październik 25 | Dostawca opublikował ostatnią aktualizację zabezpieczeń, a my ją zainstalowaliśmy. Szczegóły dotyczące luki w zabezpieczeniach i wektora ataku nadal nie zostały jednak ujawnione. |
Czego sprzedawca jeszcze nie ujawnił
W chwili publikacji ISPsystem nie dostarczył dostawcom hostingu wystarczających informacji, aby mogli oni z pełnym przekonaniem usunąć lukę w zabezpieczeniach i zweryfikować swoją infrastrukturę. Nie opublikowano następujących informacji:
- opis podatności i początkowej metody dostępu;
- identyfikator CVE i lista wersji, których dotyczy problem;
- wskaźniki zagrożenia (IoC): adresy serwerów atakującego, nazwy plików i procesów, oznaki trwałości;
- potwierdzenie, że udostępnione poprawki całkowicie eliminują lukę w zabezpieczeniach.
Pierwsza poprawka została wydana w nocy 18 października, a po niej pojawiło się kilka kolejnych. Według innych dostawców, których dotyczył problem, sam dostawca odradzał ponowne otwieranie dostępu do panelu do czasu wydania kolejnych poprawek. Bez szczegółów technicznych każdy dostawca musi samodzielnie odtworzyć atak, korzystając z własnych logów i udostępniając wyniki innym podmiotom.
Zwróciliśmy się do dostawcy z prośbą o pełne informacje techniczne i opublikujemy je, gdy tylko je otrzymamy. Uważamy, że odpowiedzialność za lukę w zabezpieczeniach i terminowe ujawnienie informacji na jej temat spoczywa na twórcy produktu.
Co mogło wycieknąć
Napastnicy uzyskali dostęp do bazy danych paneli, która zawierała:
- lista serwerów i ich adresów IP;
- adresy e-mail kont panelowych;
- hasła roota ustawiane poprzez panel podczas zamawiania, ponownej instalacji lub zmiany hasła;
- Hasła konsoli VNC.
U niektórych dostawców atakujący dotarli również do węzłów wirtualizacji. Tam uruchomili program, który montował dyski serwerów klienckich w trybie tylko do odczytu i przeszukiwał je w poszukiwaniu poufnych informacji:
- Klucze SSH,
authorized_keys, skróty haseł, menedżery haseł, klucze GnuPG; - dane uwierzytelniające chmurę i DevOps: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab i tokeny npm;
.envorazdocker-compose.ymlpliki, konfiguracje aplikacji i baz danych;- portfele kryptowalutowe, frazy początkowe, klucze API giełd;
- hasła i pliki cookie przeglądarki, historia powłoki;
- Klucze API usług AI, hasła zapasowe restic i Borg.
Program działał na poziomie infrastruktury i nigdy nie był wykonywany wewnątrz serwerów. W rezultacie nie pozostawiał żadnych śladów na samym serwerze, nawet jeśli dane zostały skopiowane.
Nie znaleźliśmy żadnych śladów tego programu na naszych węzłach, ale biorąc pod uwagę brak informacji od dostawcy, nie możemy wykluczyć jego uruchomienia.
Co zrobiliśmy
Nie czekając na pełne informacje od sprzedawcy, przeprowadziliśmy własne dochodzenie i zamknęliśmy znane nam ścieżki dostępu:
- Zamknięto natychmiast publiczny dostęp do panelu sterowania po wykryciu ataku.
- Znaleziono i zablokowano nieautoryzowane konta administratorów w obu naszych panelach, utworzone przez atakujących w celu utrwalenia się. Szczegóły zostały zachowane na potrzeby śledztwa i udostępnione dostawcy.
- Zainstalowano wszystkie poprawki wydane przez ISPsystem.
- Dokonano rotacji wszystkich danych przechowywanych na serwerze panelowym: kluczy dostępu do węzłów, haseł serwisowych do integracji rozliczeń i wsparcia, kluczy DNS i kluczy zapasowych.
- Sprawdzono węzły hostujące serwery klienckie: pliki, usługi, procesy i logi.
Co nie zostało dotknięte
Na podstawie naszego dochodzenia ustalono, że incydent nie miał wpływu na:
- serwery zapasowe;
- dane osobowe w rozliczeniach;
- szczegóły płatności;
- jakiekolwiek usługi inne niż platforma zarządzania wirtualizacją, której to dotyczy.
Rozdzielenie tych systemów miało znaczenie: dostęp do części środowiska zarządzania wirtualizacją nie dawał dostępu do danych rozliczeniowych, kont klientów ani infrastruktury zapasowej.
Co musisz zrobić
Główne ryzyko polega na tym, że atakujący wykorzystają skradzione hasła i klucze. Wykonaj poniższe czynności jak najszybciej, nawet jeśli wszystko na serwerze wygląda normalnie.
- Najpierw portfele kryptowalutowe. Jeśli na serwerze znajdują się portfele lub frazy początkowe, przenieś środki do nowych portfeli utworzonych na innym, czystym urządzeniu.
- Zmień swoje hasło roota jeśli ustawiłeś to za pomocą panelu i od tego czasu tego nie zmieniłeś.
- Przełącz na logowanie za pomocą klucza SSH i wyłącz logowanie hasłem.
- Obróć wszystkie sekrety przechowywane na serwerze: hasła użytkowników i baz danych, klucze SSH, klucze API i tokeny, dostęp do usług w chmurze, CI/CD, poczta e-mail, systemy płatności i usługi AI.
- Cofnij stare klucze zamiast po prostu tworzyć nowe: w konsolach chmurowych, GitHub, GitLab i u dostawców płatności.
- Sprawdź serwer: nieznani użytkownicy, klucze
~/.ssh/authorized_keys, zadania cron, nieznane procesy i usługi systemd. - Sprawdź logi logowania na serwerze i w usługach, których klucze zostały na nim zapisane: po 11 października należy szukać logowań z nieznanych adresów.
Jeśli posiadasz serwery innych dostawców korzystające z VMmanager 6, wykonaj te same kroki również w ich przypadku.
Potrzebuję pomocy?
Znalazłeś coś podejrzanego na swoim serwerze lub nie masz pewności? Skontaktuj się z naszym zespołem wsparcia – pomożemy Ci rozwiązać problem i w razie potrzeby ponownie zainstalować serwer.
Przepraszamy za niedogodności, w tym za czas braku dostępu do panelu. Będziemy aktualizować ten artykuł w miarę pojawiania się nowych informacji od dostawcy i opublikujemy szczegółową analizę po zakończeniu dochodzenia.
