VMmanager 6 Sikkerhedshændelse: Hvad der skete, og hvad man skal gøre

I oktober 2026 angreb angribere adskillige russiske hostingudbydere på én gang via en kritisk sårbarhed i VMmanager 6, et virtualiseringsstyringspanel udviklet af ISPsystem (en del af Astra Group). Dette panel kører VPS for os og for mange andre udbydere. Vi blev også berørt.

Dine servere fortsætter med at køre. Nedenfor kan du se, hvad der skete, hvorfor, hvad vi allerede har gjort, og hvad du skal gøre.

Årsagen: en sårbarhed i leverandørens produkt

Angrebet blev muliggjort af en kritisk sårbarhed i selve VMmanager 6-softwaren. Dette var ikke en fejlkonfiguration hos en enkelt udbyder: den samme sårbarhed blev udnyttet samtidigt mod mange hostingvirksomheder.

FirstVDS, ForestsNet Cloud, MHost, HSH Network og YaColo har offentligt rapporteret sikkerhedsbrud via VMmanager 6. Leverandøren har bekræftet hændelsen: ifølge en repræsentant for Astra Group var sårbarheden i en af ​​VMmanager-builds.

Hvad sælgeren endnu ikke har oplyst

På tidspunktet for offentliggørelsen har ISPsystem ikke givet hostingudbyderne tilstrækkelige oplysninger til at afhjælpe sårbarheden med sikkerhed og verificere deres infrastruktur. Følgende er ikke blevet offentliggjort:

• en beskrivelse af sårbarheden og den oprindelige adgangsmetode;
• en CVE-identifikator og listen over berørte versioner;
• indikatorer for kompromittering (IoC'er): angriberens serveradresser, fil- og procesnavne, tegn på vedvarende aktivitet;
• bekræftelse af, at de udgivne rettelser fuldstændigt lukker sårbarheden.

Den første rettelse blev udgivet natten til den 18. oktober, efterfulgt af flere. Ifølge andre berørte udbydere frarådede leverandøren selv at genåbne adgangen til panelet, indtil yderligere patches er udgivet. Uden tekniske detaljer skal hver udbyder rekonstruere angrebet på egen hånd, ud fra sine egne logfiler og ved at dele resultater med kolleger.

Vi har bedt leverandøren om fuldstændige tekniske oplysninger og vil offentliggøre dem, så snart vi modtager dem. Vi mener, at ansvaret for sårbarheden og for rettidig offentliggørelse af oplysninger om den ligger hos produktets udvikler.

Hvad der kan være lækket

Angriberne fik adgang til paneldatabasen, som indeholdt:

• listen over servere og deres IP-adresser;
• e-mailadresser på panelkonti;
• root-adgangskoder indstillet via panelet ved bestilling, geninstallation eller ændring af adgangskoden;
• VNC-konsoladgangskoder.

Hos nogle udbydere nåede angriberne også virtualiseringsnoderne. Der kørte de et program, der monterede klient-serverdiske i skrivebeskyttet tilstand og søgte på dem efter hemmeligheder:

• SSH-nøgler, authorized_keys, adgangskode-hashes, adgangskodeadministratorer, GnuPG-nøgler;
• Cloud- og DevOps-legitimationsoplysninger: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab og npm-tokens;
• .env og docker-compose.yml filer, applikations- og databasekonfigurationer;
• krypto-tegnebøger, seed-sætninger, API-nøgler til udveksling;
• browseradgangskoder og cookies, shellhistorik;
• AI-tjeneste API-nøgler, restic og Borg backup-adgangskoder.

Programmet kørte på infrastrukturniveau og blev aldrig udført inde på serverne. Som følge heraf efterlader det ingen spor på selve serveren, selvom data blev kopieret.

Vi fandt ingen spor af dette program på vores noder, men i betragtning af manglen på information fra leverandøren kan vi ikke helt udelukke, at det kørte.

Hvad vi gjorde

Uden at vente på fuldstændige oplysninger fra sælgeren, udførte vi vores egen undersøgelse og lukkede de adgangsveje, vi kendte til:

1. Lukket offentlig adgang til kontrolpanelet umiddelbart efter at angrebet var blevet opdaget.
2. Fandt og blokerede uautoriserede administratorkonti i begge vores paneler, oprettet af angriberne for persistens. Detaljer er blevet gemt til undersøgelse og delt med leverandøren.
3. Installerede alle rettelser udgivet af ISPsystem.
4. Roterede alt, der var gemt på panelserveren: nodeadgangsnøgler, serviceadgangskoder til fakturering og supportintegrationer, DNS og backupnøgler.
5. Kontrollerede de noder, der hoster klientservere: filer, tjenester, processer og logfiler.

Hvad der ikke blev påvirket

Baseret på vores undersøgelse påvirkede hændelsen ikke:

• backup-servere;
• personoplysninger i forbindelse med fakturering;
• betalingsoplysninger;
• andre tjenester end den berørte virtualiseringsstyringsplatform.

Adskillelsen af ​​disse systemer gjorde hele forskellen: adgang til en del af virtualiseringsstyringsmiljøet gav ikke adgang til faktureringsdata, klientkonti eller backupinfrastrukturen.

Hvad du skal gøre

Den største risiko er, at angriberne bruger stjålne adgangskoder og nøgler. Gør følgende så hurtigt som muligt, selvom alt på din server ser normalt ud.

1. Krypto-tegnebøger først. Hvis serveren indeholdt tegnebøger eller seed-fraser, skal du flytte pengene til nye tegnebøger, der er oprettet på en anden, ren enhed.
2. Skift din root-adgangskode hvis du har indstillet det via panelet og ikke har ændret det siden.
3. Skift til SSH-nøglelogin og deaktiver login med adgangskode.
4. Roter alle hemmeligheder gemt på serveren: bruger- og databaseadgangskoder, SSH-nøgler, API-nøgler og -tokens, adgang til cloud-tjenester, CI/CD, e-mail, betalingssystemer og AI-tjenester.
5. Tilbagekald gamle nøgler i stedet for blot at oprette nye: i cloud-konsoller, GitHub, GitLab og hos betalingsudbydere.
6. Tjek serveren: ukendte brugere, taster ind ~/.ssh/authorized_keys, cron-job, ukendte processer og systemd-tjenester.
7. Tjek login-logfiler på serveren og i de tjenester, hvis nøgler blev gemt på den: se efter logins fra ukendte adresser efter 11. oktober.

Hvis du har servere hos andre udbydere, der kører VMmanager 6, skal du også følge de samme trin der.

Brug for hjælp?

Har du fundet noget mistænkeligt på din server, eller er du usikker? Kontakt vores supportteam – vi hjælper dig med at løse det og geninstallerer serveren, hvis det er nødvendigt.

Vi beklager ulejligheden, herunder den tid, det tog at undgå adgang til panelet. Vi opdaterer denne artikel, når nye oplysninger fra leverandøren bliver tilgængelige, og offentliggør en detaljeret obduktion, når undersøgelsen er afsluttet.