Virtualizor güncellemesine BGP saldırısı: Paketler saptırıldı

Anasayfa » Virtualizor güncellemesine BGP saldırısı: Paketler saptırıldı
Virtualizor güncellemesine BGP saldırısı: Paketler saptırıldı

Softaculous’un güncelleme trafiğini hedef alan bir BGP yönlendirme saldırısı, bazı Virtualizor kurulumlarına kötü amaçlı paket ulaşmasına yol açtı. Şirket, etkilenen sürüm aralığını ya da zararlı paketi alan sistemlerin kesin listesini paylaşamadığı için tüm operatörlerden sunucularını tek tek incelemelerini istiyor.

İncelemelere göre olay 28 Ağustos saat 20:57 UTC ile 30 Ağustos saat 06:10 UTC arasında yaşandı. Bu pencerede güncelleme kontrolü yapan Virtualizor örnekleri, saldırganın yönlendirdiği sunucu üzerinden değiştirilmiş paketi almış olabilir. 1 Eylül’de yayımlanan Patch 9 sürümüne Security Analyzer eklendi, ancak paketlerin kriptografik olarak imzalanması henüz sonraki aşamaya bırakıldı. Virtualizor, kriptografik paket imzalamanın gelecekteki bir çalışma olduğunu da açıkladı.

Yönlendirme saldırısı güncelleme trafiğini saptırdı

Olayın başlangıcı, 28 Ağustos 20:57:30 UTC’de vendor’ın belirlediği yol bilgisiyle yapılan izinsiz bir rota duyurusuna dayanıyor. RIPE Stat verileriyle doğrulanan bu duyuru, Softaculous servis trafiğinin saldırgana ait bir sunucuya akmasına neden oldu. Virtualizor, bu rotanın yetkisiz olduğunu bildirdi. Bu sırada saldırgan, geçerli bir Let’s Encrypt sertifikası da aldı; böylece bağlantılar tarayıcı açısından sertifika uyarısı üretmedi.

Yönlendirme penceresi içinde elde edilen sertifika, saldırganın kullandığı sunucudan geçen bağlantılarda güvenlik uyarısının görünmemesini sağladı. Virtualizor’un aktardığına göre, yönlendirilmiş bir aralıkta güncelleme kontrolü yapan bir kurulum, değiştirilmiş paketi alabilirdi. Güncelleme istemcisi ise kriptografik paket doğrulaması yapmadığı için paketi bu nedenle reddetmedi.

Virtualizor, olay bildiriminde “Bu olay genel Virtualizor kullanıcı tabanından ziyade birkaç sunucuyu etkiledi” ifadesini kullandı. Şirketin açıklaması, zararın geniş bir kitleye yayılmadığını belirtse de, hangi kurulumların paketi aldığına dair kesin bir ayrım sunmadı. Bu nedenle vendor, her operatörün kendi sunucusunu kontrol etmesi gerektiğini söylüyor.

Güncelleme trafiği saptırıldığı sırada client-area oturumları ve ödeme girişi trafiği de saldırganın yönettiği sunucuya ulaşmış olabilir. Ancak 2 Eylül itibarıyla Virtualizor, doğrulanmış müşteri hesabı ya da ödeme verisi hırsızlığını açıklamadı. Vendor, bu aşamada yalnızca bu trafiğin attacker-operated sunucuya yönlenmiş olabileceğini aktardı.

AlbaHost: 34 sistemin 5’inde root düzeyi etki görüldü

LowEndTalk üzerinde Member ve Patron Provider olarak görünen AlbaHost hesabı, üç meşru Virtualizor dosyasına zararlı komutlar yerleştirildiğini yazdı. Hesabın verdiği bilgiye göre daha sonra bir root cron görevi değiştirilmiş kodu çalıştırdı. Aynı hesap, kontrol edilen 34 Virtualizor hypervisor düğümünün 5’inde aynı kötü amaçlı değişiklikleri doğruladığını söyledi. “Bu başlıkta anlatılan kötü amaçlı değişikliklerin aynısının, 34 Virtualizor hypervisor düğümümüzün 5’inde bulunduğunu doğrulayabiliriz” ifadesi de hesap tarafından paylaşıldı.

Enjekte edilen kod, root hesabına saldırganın kontrol ettiği bir anahtar ekledi. Ardından sistemde Java 17 yoksa kurulum yaptı, Java yükünü indirdi ve bu yükü root yetkileriyle çalıştırdı. Yük, bir systemd servisi üzerinden kalıcılık sağladı ve izinsiz bir proxyuser hesabı oluşturdu. Sağlayıcının kayıtlarında bu hesaba 193.32.127[.]248 adresinden parola ile başarılı bir SSH oturumu açıldığı da yer aldı. AlbaHost’un paylaştığı kaynakta, başarılı oturumun parola tabanlı bir Secure Shell bağlantısı olduğu belirtildi.

AlbaHost, kendi incelediği ortamda müşteri sanal özel sunucularında doğrulanmış bir değişiklik görmediğini ve bir veritabanı dışa aktarımını da bağımsız olarak doğrulayamadığını aktardı. Buna karşın yerel loglarda görülen kalıcılık mekanizması, erişimin yalnızca ilk girişle sınırlı kalmadığını gösterdi. Şirketin değerlendirdiği ortamda müşteri VPS’lerine ilişkin kesin bir değişiklik saptanmadığını vurgulaması, olayı kendi ağında ayrı bir başlık olarak tuttuğunu ortaya koydu.

Virtualizor’un verdiği IoC listesi ve operatörlere çağrı

Virtualizor, yalnızca belirli versiyonları değil, tüm kurulumların kontrol edilmesi gerektiğini söylüyor; çünkü hangi sistemlerin paketi aldığına dair kesin bir liste yok. Şirketin 1 Eylül tarihli Patch 9 duyurusunda Security Analyzer’ın release-candidate ve stable kanallarına eklendiği belirtildi. Olay bildirisinde sürüm adı Virtualizor 3.2.9.9 olarak geçerken, sürüm notunda Virtualizor 3.2.9 (Release Candidate and Stable Branch) (Patch 9) ifadesi kullanıldı. İki metinde yer alan sürüm adlandırması farklı olsa da ikisi de aynı Patch 9 güncellemesine işaret ediyor.

Vendor ayrıca şu dosya ve kalıntıların kontrol edilmesini istedi: /etc/systemd/system/java-jre-update.service, /usr/lib/jvm/.cache/jre-runtime.dat, /usr/lib/jvm/.cache/.installed, /tmp/widdow.jar, /usr/local/virtualizor/globals.php, /usr/local/virtualizor/_universal.php ve /usr/local/virtualizor/zzvirtservice. Zararlı paketin SHA-256 değeri olarak b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7 paylaşıldı. Şirketin resmi tarayıcısı, bu kalıntıları ve bilinen göstergeleri eşleştirmek için kullanılıyor.

İncelemeye göre yerleştirilen göstergeler arasında cdn[.]nerat[.]cc/installer/widdow.jar, connect[.]ne-rat[.]xyz ve jre-runtime.dat dizeleri de var. Komuta-kontrol alan adları olarak cdn[.]nerat[.]cc ile connect[.]ne-rat[.]xyz listelendi. SSH anahtar malzemesi, proxyuser hesabı, 31.77.220[.]138:2025 IP ve port bilgisi, /tmp/.vz_svc_done işareti ve SHA256:YQmy1hKF1h5cdJLxlZ5EScNoxe/UDWahjsWuQw2ERi8 parmak izi de sağlayıcının bildirdiği göstergeler arasında yer aldı. AlbaHost’un raporunda ayrıca saldırganın kullandığı SSH kaynak adresi olarak 193.32.127[.]248 bilgisi de geçti.

Virtualizor, pozitif bir host üzerinde temizleme işlemine geçmeden önce destek ekibiyle temas kurulmasını, böylece delillerin korunmasını öneriyor. Şirket, tarayıcının tespit ettiği unsurların yalnızca bilinen göstergeleri kapsadığını, değiştirilmiş çekirdek Virtualizor dosyalarının ise ancak bilinen temiz içerikle geri yüklenerek ya da yeniden kurulumla toparlanabileceğini belirtti. AlbaHost hesabı da root düzeyinde onaylanmış bir ihlal görülen sistemlerde uzun vadede güvenilir tek yöntemin temiz yeniden kurulum olduğunu söyledi. Vendor, tarama sonucu pozitif çıkan bir host için önce destekle iletişime geçilmesini, ardından kalıcı izlerin ve yetkisiz erişim kalıntılarının tek tek temizlenmesini istedi.

Vendor’ın yönlendirmesi Virtualizor operatörlerinin yanı sıra, olay penceresinde client-area’ya giriş yapan ya da ödeme bilgisi giren kullanıcılara da dokunuyor. Bu gruptan istenen, client-area parolasını sıfırlamak, aynı parola başka yerde de kullanıldıysa onu da değiştirmek, hesap hareketlerini incelemek ve kart bilgisi girildiyse ekstreleri kontrol etmek. Client Center API kullanıcılarının ise anahtarlarını yeniden üretip sunucularına yeniden tanımlaması gerekiyor. Virtualizor, bu adımların olay penceresinde giriş yapan kullanıcılar için geçerli olduğunu ayrıca not etti.

Softaculous ekosistemindeki diğer ürünleri işletenlerden de Webuzo, Softaculous, Backuply, SitePad ve benzeri ürünlerde olay penceresinde yapılan güncelleme kontrollerini gözden geçirmeleri isteniyor. Vendor, bu ürünler için henüz kötü amaçlı paket adı ya da hash’i açıklamadı ve incelemenin açık olduğunu bildirdi. Başka bir deyişle, soruşturma yalnızca Virtualizor kurulumlarıyla sınırlı kalmadı.

Virtualizor’un resmi tarayıcısı, 2 Eylül 2026 tarihinde alınan script için SHA-256 değerini 73e74402b3a61c7bab289fc11347bd54c7fcdc2fa2e410f4c3de9d6cd7377d48 olarak paylaştı. Şirket, resmi tarayıcıyla bulunan her işaretin tek başına kanıt sayılmaması, ama ilk tespit ve sınırlama adımı olarak ele alınması gerektiğini belirtti. Onaylı root ihlali görülen bir makinede ise güven zincirini yeniden kurmak için tam temizleme ve yeniden inşa ihtiyacı sürüyor. As of September 2, Virtualizor had not published a malicious-package filename or hash, an affected update-channel list, or a build that enforces package signing.