Knowledgebase Udhëzime të thjeshta për të punuar me shërbimin Profitserver
Kryesor Knowledgebase Incidenti i Sigurisë VMmanager 6: Çfarë ndodhi dhe çfarë duhet të bëni

Incidenti i Sigurisë VMmanager 6: Çfarë ndodhi dhe çfarë duhet të bëni


Në tetor 2026, sulmuesit shënjestruan disa ofrues rusë të hostingut njëherësh përmes një dobësie kritike në VMmanager 6, një panel menaxhimi i virtualizimit i zhvilluar nga ISPsystem (pjesë e Astra Group). Ky panel përdor VPS për ne dhe për shumë ofrues të tjerë. Edhe ne u prekëm.

Serverat tuaj vazhdojnë të funksionojnë. Më poshtë është çfarë ndodhi, pse, çfarë kemi bërë tashmë dhe çfarë duhet të bëni ju.

Shkaku: një dobësi në produktin e shitësit

Sulmi u bë i mundur nga një dobësi kritike në vetë softuerin VMmanager 6. Ky nuk ishte një konfigurim i gabuar te një ofrues individual: e njëjta dobësi u shfrytëzua njëkohësisht kundër shumë kompanive të hostimit.

FirstVDS, ForestsNet Cloud, MHost, HSH Network dhe YaColo kanë raportuar publikisht shkelje nëpërmjet VMmanager 6. Shitësi e ka konfirmuar incidentin: sipas një përfaqësuesi të Astra Group, dobësia ndodhej në njërën nga versionet e VMmanager.

datangjarje
Tetor 11-16Sulmuesit infektojnë panelet e VMmanager 6 përmes cenueshmërisë dhe krijojnë qëndrueshmëri.
Nata e 16-17 tetoritFaza aktive: qasje në bazat e të dhënave të panelit dhe, te disa ofrues, te nyjet që strehojnë serverat e klientëve
tetor 18Ne nisëm hetimin tonë dhe morëm masat fillestare.
Nata e 17-18 tetoritISPsystem publikon rregullimin e parë (versioni 2026.05.2-6)
Tetor 19-20Shitësi publikon rregullime shtesë; puna për dobësinë vazhdon
tetor 25Shitësi publikoi përditësimin përfundimtar të sigurisë dhe ne e kemi instaluar atë. Megjithatë, detajet e dobësisë dhe vektorit të sulmit ende nuk janë zbuluar.

Çfarë nuk ka zbuluar ende shitësi

Që nga momenti i publikimit, ISPsystem nuk u ka ofruar ofruesve të shërbimeve të hostimit informacion të mjaftueshëm për të ndrequr me besim dobësinë dhe për të verifikuar infrastrukturën e tyre. Informacioni i mëposhtëm nuk është publikuar:

  • një përshkrim të cenueshmërisë dhe metodës fillestare të aksesit;
  • një identifikues CVE dhe lista e versioneve të prekura;
  • treguesit e kompromentimit (IoC): adresat e serverëve të sulmuesit, emrat e skedarëve dhe proceseve, shenjat e vazhdimësisë;
  • konfirmim që rregullimet e lëshuara e mbyllin plotësisht dobësinë.

Rregullimi i parë u publikua natën e 18 tetorit, i ndjekur nga disa të tjerë. Sipas ofruesve të tjerë të prekur, vetë shitësi këshilloi kundër rihapjes së aksesit në panel derisa të publikohen patch-e të tjera. Pa detaje teknike, secili ofrues duhet ta rindërtojë sulmin vetë, nga regjistrat e vet dhe duke ndarë gjetjet me kolegët.

Ne i kemi kërkuar shitësit informacion të plotë teknik dhe do ta publikojmë atë sapo ta marrim. Ne besojmë se përgjegjësia për dobësinë dhe për zbulimin në kohë të informacionit në lidhje me të, i takon zhvilluesit të produktit.

Çfarë mund të ketë rrjedhur

Sulmuesit fituan akses në bazën e të dhënave të panelit, e cila përmbante:

  • listën e serverave dhe adresat e tyre IP;
  • adresat e email-it të llogarive të panelit;
  • fjalëkalimet root të vendosura përmes panelit gjatë porositjes, riinstalimit ose ndryshimit të fjalëkalimit;
  • Fjalëkalimet e konsolës VNC.

Tek disa ofrues, sulmuesit arritën edhe në nyjet e virtualizimit. Atje ata ekzekutuan një program që montonte disqet e serverit klient në modalitetin vetëm për lexim dhe i kontrollonte ato për sekrete:

  • Çelësat SSH, authorized_keys, hash-e fjalëkalimesh, menaxherë fjalëkalimesh, çelësa GnuPG;
  • kredencialet e cloud dhe DevOps: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab dhe tokenët npm;
  • .env docker-compose.yml konfigurimet e skedarëve, aplikacioneve dhe bazës së të dhënave;
  • portofolet e kriptove, frazat fillestare, çelësat e API-t të shkëmbimit;
  • fjalëkalimet dhe cookie-t e shfletuesit, historiku i shell-it;
  • Çelësat API të shërbimit AI, fjalëkalimet rezervë Restic dhe Borg.

Programi ekzekutohej në nivelin e infrastrukturës dhe nuk ekzekutohej kurrë brenda serverave. Si rezultat, nuk lë gjurmë në vetë serverin, edhe nëse të dhënat kopjoheshin.

Ne nuk gjetëm gjurmë të këtij programi në nyjet tona, por duke pasur parasysh mungesën e informacionit nga shitësi, nuk mund ta përjashtojmë plotësisht mundësinë që ai të ketë funksionuar.

Çfarë bëmë

Pa pritur informacion të plotë nga shitësi, ne kryem hetimin tonë dhe mbyllëm rrugët e aksesit që njihnim:

  1. Mbyllja e aksesit publik në panelin e kontrollit menjëherë pas zbulimit të sulmit.
  2. U gjetën dhe u bllokuan llogari administratori të paautorizuara në të dy panelet tona, të krijuara nga sulmuesit për vazhdimësi. Detajet janë ruajtur për hetimin dhe janë ndarë me shitësin.
  3. U instaluan të gjitha rregullimet e lëshuara nga ISPsystem.
  4. U rrotullua gjithçka e ruajtur në serverin e panelit: çelësat e aksesit në nyje, fjalëkalimet e shërbimit për integrimet e faturimit dhe mbështetjes, çelësat DNS dhe rezervë.
  5. U kontrolluan nyjet që strehojnë serverat e klientëve: skedarët, shërbimet, proceset dhe regjistrat.

Çfarë nuk u prek

Bazuar në hetimin tonë, incidenti nuk ndikoi në:

  • servera rezervë;
  • të dhëna personale në faturim;
  • detajet e pagesës;
  • çdo shërbim tjetër përveç platformës së menaxhimit të virtualizimit të prekur.

Ndarja e këtyre sistemeve bëri ndryshimin: qasja në një pjesë të mjedisit të menaxhimit të virtualizimit nuk jepte qasje në të dhënat e faturimit, llogaritë e klientëve ose infrastrukturën e rezervimit.

Çfarë duhet të bëni

Rreziku kryesor është se sulmuesit do të përdorin fjalëkalime dhe çelësa të vjedhur. Bëni sa më poshtë sa më shpejt të jetë e mundur, edhe nëse gjithçka në serverin tuaj duket normale.

  1. Portofolet kripto të parat. Nëse serveri mbante portofolet ose frazat fillestare, zhvendosni fondet në portofolet e reja të krijuara në një pajisje tjetër dhe të pastër.
  2. Ndrysho fjalëkalimin tënd rrënjë nëse e keni vendosur përmes panelit dhe nuk e keni ndryshuar që atëherë.
  3. Kaloni në hyrjen me çelës SSH dhe çaktivizoni hyrjen me fjalëkalim.
  4. Rrotulloni të gjitha sekretet e ruajtura në server: fjalëkalimet e përdoruesve dhe të bazës së të dhënave, çelësat SSH, çelësat dhe tokenët API, aksesi në shërbimet cloud, CI/CD, email-i, sistemet e pagesave dhe shërbimet e IA-së.
  5. Anuloni çelësat e vjetër në vend që thjesht të krijohen të reja: në konsolat cloud, GitHub, GitLab dhe me ofruesit e pagesave.
  6. Kontrolloni serverin: përdorues të panjohur, çelësat brenda ~/.ssh/authorized_keys, punë cron, procese të panjohura dhe shërbime të sistemuara.
  7. Kontrolloni regjistrat e hyrjes në server dhe në shërbimet çelësat e të cilave ishin ruajtur në të: kërkoni për hyrje nga adresa të panjohura pas 11 tetorit.

Nëse keni servera me ofrues të tjerë që përdorin VMmanager 6, ndiqni të njëjtat hapa edhe atje.

Kam nevojë për ndihmë?

Gjetët diçka të dyshimtë në serverin tuaj, apo nuk jeni të sigurt? Kontaktoni ekipin tonë të mbështetjes — ne do t'ju ndihmojmë ta zgjidhni dhe ta riinstaloni serverin nëse është e nevojshme.

Kërkojmë ndjesë për shqetësimin, përfshirë kohën pa qasje në panel. Do ta përditësojmë këtë artikull sapo të ketë informacione të reja nga shitësi dhe do të publikojmë një vlerësim të detajuar pas hetimit sapo të përfundojë.


Na pyesni për VPS

Ne jemi gjithmonë të gatshëm t'u përgjigjemi pyetjeve tuaja në çdo kohë të ditës apo natës.