Ekim 2026'da, saldırganlar ISPsystem (Astra Grubu'nun bir parçası) tarafından geliştirilen bir sanallaştırma yönetim paneli olan VMmanager 6'daki kritik bir güvenlik açığı aracılığıyla aynı anda birçok Rus hosting sağlayıcısını hedef aldı. Bu panel, bizim ve diğer birçok sağlayıcının VPS hizmetlerini yönetiyor. Biz de etkilendik.
Sunucularınız çalışmaya devam ediyor. Aşağıda neler olduğu, nedenleri, halihazırda yaptıklarımız ve sizin yapmanız gerekenler yer almaktadır.
Sebep: Tedarikçinin ürünündeki bir güvenlik açığı.
Saldırı, VMmanager 6 yazılımının kendisindeki kritik bir güvenlik açığı sayesinde mümkün oldu. Bu, tek bir sağlayıcıdaki yanlış yapılandırmadan kaynaklanmadı: aynı güvenlik açığı eş zamanlı olarak birçok hosting şirketine karşı kullanıldı.
FirstVDS, ForestsNet Cloud, MHost, HSH Network ve YaColo, VMmanager 6 üzerinden güvenlik açıkları yaşadıklarını kamuoyuna duyurdu. Satıcı da olayı doğruladı: Astra Group temsilcisine göre, güvenlik açığı VMmanager sürümlerinden birinde bulunuyordu.
| Tarih | Etkinlikler |
|---|---|
| Ekim 11 – 16 | Saldırganlar bu güvenlik açığından yararlanarak VMmanager 6 panellerine bulaşıyor ve kalıcı erişim sağlıyor. |
| 16-17 Ekim gecesi | Aktif aşama: panel veritabanlarına ve bazı sağlayıcılarda istemci sunucularını barındıran düğümlere erişim. |
| Ekim 18 | Kendi soruşturmamızı başlattık ve ilk önlemleri aldık. |
| 17-18 Ekim gecesi | ISPsystem ilk düzeltmeyi yayınladı (sürüm 2026.05.2-6) |
| Ekim 19 – 20 | Satıcı ek düzeltmeler yayınladı; güvenlik açığı üzerindeki çalışmalar devam ediyor. |
| Ekim 25 | Satıcı son güvenlik güncellemesini yayınladı ve biz de yükledik. Ancak, güvenlik açığı ve saldırı yöntemine ilişkin ayrıntılar henüz açıklanmadı. |
Satıcının henüz açıklamadığı şey
Yayın tarihi itibariyle, ISPsystem, barındırma sağlayıcılarına güvenlik açığını güvenle gidermeleri ve altyapılarını doğrulamaları için yeterli bilgi sağlamamıştır. Aşağıdakiler henüz yayınlanmamıştır:
- Güvenlik açığının ve ilk erişim yönteminin açıklaması;
- Bir CVE tanımlayıcısı ve etkilenen sürümlerin listesi;
- Güvenlik ihlali göstergeleri (IoC'ler): saldırgan sunucu adresleri, dosya ve işlem adları, kalıcılık belirtileri;
- Yayınlanan düzeltmelerin güvenlik açığını tamamen kapattığına dair teyit.
İlk düzeltme 18 Ekim gecesi yayınlandı, ardından birkaç tane daha geldi. Etkilenen diğer sağlayıcılara göre, satıcı firma, daha fazla yama yayınlanana kadar panele erişimin yeniden açılmaması konusunda uyarıda bulundu. Teknik detaylar olmadan, her sağlayıcı saldırıyı kendi günlüklerinden yola çıkarak ve bulgularını meslektaşlarıyla paylaşarak yeniden oluşturmak zorunda.
Satıcıdan tüm teknik bilgileri talep ettik ve alır almaz yayınlayacağız. Güvenlik açığı ve bununla ilgili bilgilerin zamanında açıklanması sorumluluğunun ürün geliştiricisine ait olduğuna inanıyoruz.
Sızmış olabilecekler
Saldırganlar, aşağıdaki bilgilere sahip panel veritabanına erişim sağladı:
- Sunucuların ve IP adreslerinin listesi;
- Panel hesaplarının e-posta adresleri;
- Sipariş verirken, yeniden yüklerken veya parolayı değiştirirken panel üzerinden ayarlanan root parolaları;
- VNC konsol şifreleri.
Bazı sağlayıcılarda, saldırganlar sanallaştırma düğümlerine de ulaştılar. Orada, istemci sunucu disklerini salt okunur modda bağlayan ve içlerinde gizli bilgiler arayan bir program çalıştırdılar:
- SSH anahtarları,
authorized_keysParola karmaları, parola yöneticileri, GnuPG anahtarları; - Bulut ve DevOps kimlik bilgileri: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab ve npm token'ları;
.envhem dedocker-compose.ymlDosyalar, uygulama ve veritabanı yapılandırmaları;- Kripto cüzdanları, kurtarma cümleleri, borsa API anahtarları;
- Tarayıcı şifreleri ve çerezleri, kabuk geçmişi;
- Yapay zeka hizmeti API anahtarları, restic ve Borg yedekleme şifreleri.
Program altyapı düzeyinde çalıştı ve sunucuların içinde asla yürütülmedi. Sonuç olarak, veriler kopyalansa bile sunucunun kendisinde hiçbir iz bırakmadı.
Sunucularımızda bu programın herhangi bir izine rastlamadık, ancak satıcıdan yeterli bilgi gelmediği için çalışmış olma ihtimalini tamamen dışlayamayız.
Biz ne yaptığını
Satıcıdan tam bilgi beklemeden kendi araştırmamızı yürüttük ve bildiğimiz erişim yollarını kapattık:
- Saldırı tespit edildikten hemen sonra kontrol paneline genel erişim kapatıldı.
- Her iki kontrol panelimizde de saldırganlar tarafından kalıcı erişim sağlamak amacıyla oluşturulmuş yetkisiz yönetici hesapları tespit edildi ve engellendi. Soruşturma için ayrıntılar saklandı ve tedarikçiyle paylaşıldı.
- ISPsystem tarafından yayınlanan tüm düzeltmeler yüklendi.
- Panel sunucusunda depolanan her şeyi sıfırladım: düğüm erişim anahtarları, faturalama ve destek entegrasyonları için hizmet şifreleri, DNS ve yedekleme anahtarları.
- İstemci sunucularını barındıran düğümleri kontrol ettim: dosyalar, hizmetler, işlemler ve günlükler.
Neler etkilenmedi?
Yaptığımız incelemeye göre, olay aşağıdaki hususları etkilememiştir:
- yedekleme sunucuları;
- faturalamada kişisel veriler;
- Ödeme bilgileri;
- Etkilenen sanallaştırma yönetim platformu dışındaki tüm hizmetler.
Bu sistemleri ayırmak fark yarattı: sanallaştırma yönetim ortamının bir bölümüne erişim, faturalama verilerine, müşteri hesaplarına veya yedekleme altyapısına erişim sağlamıyordu.
Ne yapmak gerekiyor
En büyük risk, saldırganların çalınmış şifreleri ve anahtarları kullanacak olmasıdır. Sunucunuzda her şey normal görünse bile, aşağıdaki adımları mümkün olan en kısa sürede uygulayın.
- Önce kripto cüzdanları. Eğer sunucuda cüzdanlar veya kurtarma ifadeleri bulunuyorsa, fonları farklı, temiz bir cihazda oluşturulmuş yeni cüzdanlara taşıyın.
- Root parolanızı değiştirin Eğer ayarı panel üzerinden yaptıysanız ve o zamandan beri değiştirmediyseniz.
- SSH anahtar oturum açma yöntemine geçin. ve parola ile giriş yapmayı devre dışı bırakın.
- Sunucuda saklanan tüm gizli bilgileri döndürün: Kullanıcı ve veritabanı şifreleri, SSH anahtarları, API anahtarları ve token'ları, bulut hizmetlerine erişim, CI/CD, e-posta, ödeme sistemleri ve yapay zeka hizmetleri.
- Eski anahtarları iptal et Yenilerini oluşturmak yerine: bulut konsollarında, GitHub'da, GitLab'da ve ödeme sağlayıcılarında.
- Sunucuyu kontrol edin: yabancı kullanıcılar, tuşlara basıyor
~/.ssh/authorized_keysCron işleri, alışılmadık süreçler ve systemd hizmetleri. - Giriş kayıtlarını kontrol edin Sunucuda ve üzerinde anahtarları saklanan hizmetlerde: 11 Ekim'den sonra bilinmeyen adreslerden yapılan girişleri arayın.
Başka sağlayıcılardan VMmanager 6 çalıştıran sunucularınız varsa, aynı adımları orada da uygulayın.
Yardıma mı ihtiyacınız var?
Sunucunuzda şüpheli bir şey mi buldunuz, yoksa emin değil misiniz? Destek ekibimizle iletişime geçin; sorunu çözmenize ve gerekirse sunucuyu yeniden kurmanıza yardımcı olacağız.
Panel erişimine izin verilmemesi de dahil olmak üzere, verdiğimiz rahatsızlıktan dolayı özür dileriz. Tedarikçiden yeni bilgiler geldikçe bu makaleyi güncelleyeceğiz ve soruşturma tamamlandıktan sonra ayrıntılı bir değerlendirme yayınlayacağız.
