İnformasiya Bankı Profitserver xidməti ilə işləmək üçün sadə təlimatlar
Əsas İnformasiya Bankı VMmanager 6 Təhlükəsizlik Hadisəsi: Nə Baş Verdi və Nə Edilməli

VMmanager 6 Təhlükəsizlik Hadisəsi: Nə Baş Verdi və Nə Edilməli


2026-cı ilin oktyabr ayında hücum edənlər, ISPsystem (Astra Group-un bir hissəsi) tərəfindən hazırlanmış virtuallaşdırma idarəetmə paneli olan VMmanager 6-dakı kritik bir boşluq vasitəsilə eyni anda bir neçə Rusiya hostinq provayderini hədəf aldılar. Bu panel bizim və bir çox digər provayderlər üçün VPS işlədir. Biz də təsirləndik.

Serverləriniz işləməyə davam edir. Aşağıda nə baş verdiyi, niyə baş verdiyi, artıq nə etdiyimiz və nə etməli olduğunuz göstərilib.

Səbəb: satıcının məhsulundakı zəiflik

Hücum VMmanager 6 proqram təminatının özündəki kritik bir boşluq sayəsində mümkün oldu. Bu, fərdi provayderdə səhv konfiqurasiya deyildi: eyni boşluq eyni vaxtda bir çox hostinq şirkətinə qarşı istismar edildi.

FirstVDS, ForestsNet Cloud, MHost, HSH Network və YaColo şirkətləri VMmanager 6 vasitəsilə pozuntular barədə ictimaiyyətə məlumat veriblər. Satıcı hadisəni təsdiqləyib: Astra Group nümayəndəsinin sözlərinə görə, boşluq VMmanager versiyalarından birində olub.

tarixhadisə
Oktyabr 11-16Hücumçular zəiflik vasitəsilə VMmanager 6 panellərini yoluxdurur və davamlılıq yaradırlar
16-17 oktyabr gecəsiAktiv faza: panel verilənlər bazalarına və bəzi provayderlərdə müştəri serverlərini yerləşdirən qovşaqlara giriş
Oktyabr 18Biz öz araşdırmamıza başladıq və ilkin tədbirlər gördük
17-18 oktyabr gecəsiISPsystem ilk düzəlişi (versiya 2026.05.2-6) buraxır
Oktyabr 19-20Satıcı əlavə düzəlişlər buraxır; zəiflik üzərində iş davam edir
Oktyabr 25Satıcı son təhlükəsizlik yeniləməsini yayımladı və biz onu quraşdırdıq. Lakin, zəiflik və hücum vektorunun təfərrüatları hələ açıqlanmayıb.

Satıcı hələ nəyi açıqlamayıb

Dərc edildiyi vaxta qədər, ISPsystem hosting provayderlərinə zəifliyi inamla aradan qaldırmaq və infrastrukturlarını yoxlamaq üçün kifayət qədər məlumat verməyib. Aşağıdakılar dərc olunmayıb:

  • zəifliyin təsviri və ilkin giriş metodu;
  • CVE identifikatoru və təsirlənmiş versiyaların siyahısı;
  • kompromis göstəriciləri (IoC): hücumçu server ünvanları, fayl və proses adları, davamlılıq əlamətləri;
  • buraxılmış düzəlişlərin zəifliyi tamamilə bağladığının təsdiqlənməsi.

İlk düzəliş 18 oktyabr gecəsi, ardınca isə daha bir neçə düzəliş buraxıldı. Təsirə məruz qalan digər provayderlərə görə, satıcı özü əlavə yamalar buraxılana qədər panelə girişi yenidən açmamağı məsləhət gördü. Texniki detallar olmadan hər bir provayder hücumu öz qeydlərindən və tapıntıları həmkarları ilə paylaşmaqla müstəqil şəkildə yenidən qurmalıdır.

Satıcıdan tam texniki məlumat istəmişik və onu aldıqdan sonra dərc edəcəyik. Zəifliyə görə məsuliyyətin və bu barədə məlumatların vaxtında açıqlanmasının məhsulun tərtibatçısının üzərinə düşdüyünə inanırıq.

Nə sızmış ola bilər

Təcavüzkarlar aşağıdakıları ehtiva edən panel verilənlər bazasına giriş əldə etdilər:

  • serverlərin siyahısı və onların IP ünvanları;
  • panel hesablarının elektron poçt ünvanları;
  • parol sifariş edərkən, yenidən quraşdırarkən və ya dəyişdirərkən panel vasitəsilə təyin edilən kök parolları;
  • VNC konsol parolları.

Bəzi provayderlərdə hücum edənlər virtuallaşdırma qovşaqlarına da çatıblar. Orada onlar müştəri server disklərini yalnız oxuma rejimində quraşdıran və onlarda sirləri axtaran bir proqram işlədiblər:

  • SSH düymələri, authorized_keys, parol heşləri, parol menecerləri, GnuPG açarları;
  • bulud və DevOps etimadnamələri: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab və npm tokenləri;
  • .env və docker-compose.yml fayllar, tətbiqlər və verilənlər bazası konfiqurasiyaları;
  • kripto cüzdanlar, toxum ifadələri, mübadilə API açarları;
  • brauzer parolları və kukilər, qabıq tarixçəsi;
  • Süni intellekt xidmət API açarları, restic və Borg ehtiyat nüsxə parolları.

Proqram infrastruktur səviyyəsində işləyirdi və heç vaxt serverlərin içərisində icra edilmədi. Nəticədə, məlumatlar kopyalansa belə, serverin özündə heç bir iz buraxmır.

Düyünlərimizdə bu proqramın heç bir izini tapmadıq, lakin satıcıdan məlumatın olmaması səbəbindən onun işlədiyini tamamilə istisna edə bilmərik.

Nə etdik

Satıcıdan tam məlumat gözləmədən öz araşdırmamızı apardıq və bizə məlum olan giriş yollarını bağladıq:

  1. Hücum aşkar edildikdən dərhal sonra idarəetmə panelinə ictimai giriş bağlandı.
  2. Hər iki panelimizdə hücum edənlər tərəfindən davamlılıq üçün yaradılan icazəsiz administrator hesabları tapıldı və bloklandı. Təfərrüatlar araşdırma üçün qorunub saxlanıldı və satıcı ilə paylaşıldı.
  3. ISPsystem tərəfindən buraxılan bütün düzəlişlər quraşdırıldı.
  4. Panel serverində saxlanılan hər şeyi fırladın: qovşaq giriş açarları, ödəniş və dəstək inteqrasiyaları üçün xidmət parolları, DNS və ehtiyat açarları.
  5. Müştəri serverlərini yerləşdirən qovşaqları yoxladı: fayllar, xidmətlər, proseslər və qeydlər.

Nə təsirlənmədi

Araşdırmamıza əsasən, hadisə aşağıdakılara təsir etməyib:

  • ehtiyat serverlər;
  • ödəniş zamanı şəxsi məlumatlar;
  • ödəniş təfərrüatları;
  • təsirlənmiş virtuallaşdırma idarəetmə platformasından başqa hər hansı xidmətlər.

Bu sistemlərin ayrılması fərq yaratdı: virtuallaşdırma idarəetmə mühitinin bir hissəsinə giriş ödəniş məlumatlarına, müştəri hesablarına və ya ehtiyat infrastrukturuna giriş imkanı vermədi.

Nə etmək lazımdır

Əsas risk hücumçuların oğurlanmış parol və açarlardan istifadə etməsidir. Serverinizdəki hər şey normal görünsə belə, aşağıdakıları mümkün qədər tez edin.

  1. Əvvəlcə kriptovalyuta cüzdanları. Əgər serverdə cüzdanlar və ya toxum ifadələri varsa, vəsaitləri fərqli, təmiz bir cihazda yaradılan yeni cüzdanlara köçürün.
  2. Kök parolunuzu dəyişdirin əgər onu panel vasitəsilə təyin etmisinizsə və o vaxtdan bəri dəyişdirməmisinizsə.
  3. SSH açar girişinə keçin və parol girişini deaktiv edin.
  4. Serverdə saxlanılan bütün sirləri çevirin: istifadəçi və verilənlər bazası parolları, SSH açarları, API açarları və tokenləri, bulud xidmətlərinə giriş, CI/CD, e-poçt, ödəniş sistemləri və süni intellekt xidmətləri.
  5. Köhnə açarları ləğv edin sadəcə yeniləri yaratmaq əvəzinə: bulud konsollarında, GitHub, GitLab və ödəniş provayderləri ilə.
  6. Serveri yoxlayın: tanımadığı istifadəçilər, açarları daxil edin ~/.ssh/authorized_keys, cron işləri, tanımadığı proseslər və sistemli xidmətlər.
  7. Giriş qeydlərini yoxlayın serverdə və açarları orada saxlanılan xidmətlərdə: 11 oktyabrdan sonra tanımadığı ünvanlardan girişlər axtarın.

Əgər VMmanager 6 işlədən digər provayderlərlə serverləriniz varsa, orada da eyni addımları atın.

Kömək lazımdır?

Serverinizdə şübhəli bir şey tapdınız, yoxsa əmin deyilsiniz? Dəstək qrupumuzla əlaqə saxlayın — lazım gələrsə, problemi həll etməyə və serveri yenidən quraşdırmağa kömək edəcəyik.

Paneldən istifadənin olmaması da daxil olmaqla, yaranan narahatçılığa görə üzr istəyirik. Satıcıdan yeni məlumatlar əldə etdikcə bu məqaləni yeniləyəcəyik və araşdırma başa çatdıqdan sonra ətraflı mortopediya dərc edəcəyik.


Bizdən VPS haqqında soruşun

Günün və ya gecənin istənilən vaxtında suallarınızı cavablandırmağa hər zaman hazırıq.