VMmanager 6 turvaintsident: mis juhtus ja mida teha

2026. aasta oktoobris sihtisid ründajad korraga mitut Venemaa majutusteenuse pakkujat, kasutades kriitilist haavatavust VMmanager 6-s, mis on ISPsystemi (Astra Groupi osa) välja töötatud virtualiseerimise halduspaneel. See paneel käitab VPS-i nii meie kui ka paljude teiste pakkujate jaoks. Ka meid mõjutas see.

Teie serverid jätkavad töötamist. Allpool on kirjas, mis juhtus, miks, mida me oleme juba teinud ja mida teie peate tegema.

Põhjus: müüja toote haavatavus

Rünnaku tegi võimalikuks kriitiline haavatavus VMmanager 6 tarkvaras endas. Tegemist ei olnud ühe pakkuja vale konfiguratsiooniga: sama haavatavust kasutati samaaegselt ära paljude hostinguettevõtete vastu.

FirstVDS, ForestsNet Cloud, MHost, HSH Network ja YaColo on avalikult teatanud rikkumistest VMmanager 6 kaudu. Tootja on juhtumit kinnitanud: Astra Groupi esindaja sõnul asus haavatavus ühes VMmanageri järkudest.

Mida müüja pole veel avaldanud

Avaldamise seisuga ei ole ISPsystem esitanud majutusteenuse pakkujatele piisavalt teavet, et haavatavust enesekindlalt parandada ja oma infrastruktuuri kontrollida. Järgmist pole avaldatud:

• haavatavuse kirjeldus ja esialgne juurdepääsumeetod;
• CVE identifikaator ja mõjutatud versioonide loend;
• kompromiteerimise näitajad (IoC-d): ründaja serveri aadressid, faili- ja protsessinimed, püsivuse tunnused;
• kinnitus, et avaldatud parandused sulgevad haavatavuse täielikult.

Esimene parandus avaldati 18. oktoobri õhtul, millele järgnes veel mitu. Teiste mõjutatud pakkujate sõnul soovitas müüja ise paneelile juurdepääsu taasavamist enne uute paranduste avaldamist vältida. Tehniliste üksikasjade puudumisel peab iga pakkuja rünnaku ise oma logide põhjal rekonstrueerima ja tulemusi kolleegidega jagades.

Oleme müüjalt küsinud täielikku tehnilist teavet ja avaldame selle niipea, kui selle saame. Usume, et vastutus haavatavuse ja selle kohta käiva teabe õigeaegse avalikustamise eest lasub toote arendajal.

Mis võis lekkida

Ründajad said ligipääsu paneeli andmebaasile, mis sisaldas:

• serverite ja nende IP-aadresside loend;
• paneelikontode e-posti aadressid;
• paneeli kaudu määratud juurparoolid parooli tellimisel, uuesti installimisel või muutmisel;
• VNC konsooli paroolid.

Mõne teenusepakkuja juures jõudsid ründajad ka virtualiseerimissõlmedeni. Seal käivitasid nad programmi, mis ühendas kliendi-serveri kettad kirjutuskaitstud režiimis ja otsis neilt salajasi andmeid:

• SSH-võtmed, authorized_keys, parooliräsi, paroolihaldurid, GnuPG võtmed;
• pilve- ja DevOps-i identiteedid: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab ja npm tokenid;
• .env ja docker-compose.yml failid, rakenduste ja andmebaaside konfiguratsioonid;
• krüptorahakotid, seemnefraasid, vahetuse API-võtmed;
• brauseri paroolid ja küpsised, shelli ajalugu;
• Tehisintellekti teenuse API-võtmed, restic ja Borg varuparoolid.

Programm töötas infrastruktuuri tasandil ja ei käivitunud kunagi serverite sees. Seetõttu ei jäta see serverisse jälgi, isegi kui andmeid kopeeriti.

Me ei leidnud oma sõlmedelt selle programmi jälgi, kuid kuna müüjalt puudub teave, ei saa me täielikult välistada, et see töötas.

Mida me tegime

Ootamata müüjalt täielikku teavet, viisime läbi oma uurimise ja sulgesime meile teadaolevad juurdepääsuteed:

1. Pärast rünnaku avastamist sulges avalik juurdepääs juhtpaneelile kohe.
2. Leidsime ja blokeerisime mõlemas meie paneelis ründajate loodud volitamata administraatori kontod, mis olid püsivuse tagamiseks loodud. Üksikasjad on uurimiseks säilitatud ja müüjaga jagatud.
3. Paigaldasin kõik ISPsystemi välja antud parandused.
4. Vahetasin kõike paneeliserverisse salvestatud: sõlme juurdepääsuvõtmeid, arvelduse ja tugiteenuste integratsioonide teenuseparoole, DNS-i ja varundusvõtmeid.
5. Kontrollisin kliendiservereid majutavaid sõlmi: faile, teenuseid, protsesse ja logisid.

Mida see ei mõjutanud

Meie uurimise põhjal ei mõjutanud intsident:

• varundusserverid;
• isikuandmed arvelduses;
• makseandmed;
• kõik muud teenused peale mõjutatud virtualiseerimise haldusplatvormi.

Nende süsteemide eraldamine tõi kaasa muutuse: juurdepääs osale virtualiseerimishalduskeskkonnast ei andnud juurdepääsu arveldusandmetele, kliendikontodele ega varundusinfrastruktuurile.

Mida peate tegema

Peamine oht on see, et ründajad kasutavad varastatud paroole ja võtmeid. Tehke järgmist nii kiiresti kui võimalik, isegi kui kõik teie serveris tundub normaalne.

1. Esiteks krüptorahakotid. Kui serveris oli rahakotte või algseid koode (seed fraase), siis kanna raha üle uutesse rahakottidesse, mis on loodud teises, puhtas seadmes.
2. Muutke oma root-parooli kui sa selle paneeli kaudu seadistad ja pole seda hiljem muutnud.
3. Lülitu SSH-võtmega sisselogimisele ja keelake parooliga sisselogimine.
4. Pööra kõiki serveris talletatud saladusi: kasutaja- ja andmebaasiparoolid, SSH-võtmed, API-võtmed ja -tokenid, juurdepääs pilveteenustele, CI/CD-le, e-postile, maksesüsteemidele ja tehisintellekti teenustele.
5. Tühistage vanad võtmed selle asemel, et lihtsalt uusi luua: pilvekonsoolides, GitHubis, GitLabis ja makseteenuse pakkujate juures.
6. Kontrollige serverit: võõrad kasutajad, võtmed sisse ~/.ssh/authorized_keys, cron-tööd, harjumatud protsessid ja systemd-teenused.
7. Kontrollige sisselogimislogisid serveris ja teenustes, mille võtmed sinna salvestati: otsige sisselogimisi tundmatutelt aadressidelt pärast 11. oktoobrit.

Kui teil on servereid teiste pakkujate juures, kus töötab VMmanager 6, tehke ka seal samu samme.

Abi vajama?

Leidsite oma serverist midagi kahtlast või pole kindel? Võtke ühendust meie tugimeeskonnaga – aitame teil probleemi lahendada ja vajadusel serveri uuesti installida.

Vabandame ebamugavuste pärast, sh aja pärast, mil paneelile ligipääs puudus. Värskendame seda artiklit niipea, kui müüjalt saab uut teavet, ja avaldame üksikasjaliku järelaruande pärast uurimise lõppu.