Saldırının etkisi yalnızca DNS kaydı değiştirme veya sahte bir alan adı kullanma düzeyinde kalmadı. Yetkisiz ağ, Softaculous altyapısının bulunduğu 162.55.80.0/24 önekini daha ayrıntılı bir rota olarak duyurdu. Bu rota kabul edildiğinde internet trafiği gerçek sunucular yerine saldırganın sistemine aktı. Saldırgan, aynı yönlendirme avantajını kullanarak etkilenen alan adları için teknik olarak geçerli bir TLS sertifikası da alabildi; bu nedenle bağlantılar olağan sertifika uyarısı üretmedi.
Virtualizor, kötü amaçlı paketin yalnızca güncelleme kontrolü saldırgan rotasının etkin olduğu ana denk gelen “bir avuç” sunucuya ulaştığını belirtiyor. Ancak sahte yanıtlar üreticinin kendi altyapısına hiç gelmediği için kesin bir etkilenen sistem listesi çıkarılamıyor. Üretici bu nedenle bütün Virtualizor operatörlerinden olay göstergelerini kontrol etmelerini istiyor.
Virtualizor BGP saldırısında tam olarak ne oldu?
İnternet üzerindeki otonom sistemler hangi IP önekine hangi yol üzerinden ulaşılacağını BGP duyurularıyla birbirlerine bildirir. Yönlendiriciler genel olarak daha özel, yani daha uzun öneke sahip rotayı tercih eder. Softaculous altyapısı normalde Hetzner'in 162.55.0.0/16 duyurusu içinde yer alırken AS62390, bunun içindeki 162.55.80.0/24 önekini yetkisiz biçimde duyurdu.
Virtualizor'un teknik olay raporuna göre duyuru transit sağlayıcı AS6204 üzerinden yayıldı ve AS yolunun sonunda gerçek Hetzner otonom sistemi AS24940 korunmuş görünüyordu. Örnek yol 20912 6204 62390 24940 biçimindeydi. Bu, yalnızca kaynak AS uyuşmazlığına bakan basit kontrollerin olayı kaçırabilmesine yol açabilecek önemli bir ayrıntıdır.
Daha özel /24 rota, onu kabul eden ağlarda normal /16 rotanın önüne geçti. Sonuçta Virtualizor güncelleme uç noktası, müşteri alanı ve aynı IP aralığındaki başka Softaculous alan adlarına giden trafik iki ayrı dalga hâlinde saldırganın sunucusuna yöneldi.
| Zaman (UTC) | Olay | Savunma açısından anlamı |
|---|---|---|
| 28 Ağustos ~20:57 | AS62390 yetkisiz 162.55.80.0/24 duyurusuna başladı | Daha özel rota birçok ağda normal /16 rotayı geçti |
| 28 Ağustos ~21:00 – 29 Ağustos ~08:50 | İlk aktif yönlendirme dalgası | Güncelleme ve müşteri trafiği aralıklı olarak saldırgana gidebildi |
| 29 Ağustos ~08:50 | Hetzner aynı /24 öneki doğrudan duyurdu | Yönlendirme birkaç dakika içinde büyük ölçüde temizlendi |
| 29 Ağustos ~09:00 – ~20:00 | Yaklaşık 11 saatlik sakin dönem | Yetkisiz rota etkisi neredeyse sıfıra indi |
| 29 Ağustos ~20:00 – 30 Ağustos ~06:00 | İkinci yönlendirme dalgası | Risk yeniden küresel ölçekte görünür hâle geldi |
| 30 Ağustos ~06:10 | Yetkisiz duyuru geri çekildi | Normal yönlendirme yeniden sağlandı |
Saldırı ne kadar yayıldı?
Virtualizor, RIPE Routing Information Service verilerinden 10 dakikalık anlık görüntüler çıkararak olayı yeniden yapılandırdı. Rapora göre 368 RIPE RIS eşinin tamamı olayın bir anında yetkisiz rotayı gördü. Aktif dalgaların tepe noktasında /24 rotası taşıyan eşlerin yaklaşık tamamının ve tüm 368 eşin yaklaşık yüzde 72'sinin en iyi yolu saldırgan AS üzerinden geçiyordu.
Bu oran doğrudan trafik hacmini veya internet kullanıcılarının yüzde 72'sini ifade etmez. RIPE RIS eşleri üzerinden ölçülen bir yönlendirme görünürlüğü göstergesidir. Yetkisiz rota yoğun biçimde dalgalandığı için tek bir Virtualizor sunucusunun saldırgana yönlendirilmesi zaman ve ağ yoluna göre değişti. Üreticinin yalnızca az sayıda kurulumda kötü amaçlı paket tespit etmesi bu zamanlama koşuluyla uyumludur.
Raporda yaklaşık 41 bin BGP olayı ve 10.600 rota geri çekme kaydı bulunduğu belirtiliyor. Bu yoğun dalgalanma, bazı transit ağların flap dampening mekanizmalarıyla rotayı geçici olarak bastırmasına; görünürlüğün dakikalar içinde değişmesine neden oldu.
Geçerli TLS sertifikası nasıl alınabildi?
TLS sertifikası, istemcinin belirli bir alan adıyla şifreli bağlantı kurduğunu doğrular; fakat istemcinin paketin üretici tarafından kriptografik olarak imzalandığını tek başına kanıtlamaz. Olay sırasında sertifika otoritesinin otomatik alan adı doğrulama trafiği de kaçırılan BGP rotasını izledi. Saldırgan bu sayede Virtualizor ve Softaculous alan adlarını kapsayan teknik olarak geçerli bir Let's Encrypt sertifikası alabildi.
Bu sertifika kullanıldığında tarayıcı veya güncelleme istemcisi alan adı ile sertifika arasında olağan bir uyuşmazlık görmedi. Virtualizor'un güncelleme istemcileri o tarihte indirilen paketi ayrıca kriptografik imzayla doğrulamadığı için saldırganın değiştirdiği paket bu ikinci güvenlik katmanında da reddedilmedi.
Olay, HTTPS'in tek başına bir yazılım tedarik zincirini uçtan uca güvenceye almadığını gösteriyor. Sağlam modelde TLS taşıma kanalını korurken paket imzası, sabitlenmiş güven kökü, sürüm metadatası ve gerektiğinde şeffaflık kayıtları indirilen içeriğin üreticiye ait olduğunu bağımsız olarak doğrulamalıdır.
Hangi Virtualizor sistemleri risk altında?
Üretici kesin bir etkilenen sürüm listesi yerine zaman ve ağ yolu temelli bir risk tanımı yapıyor. 28 Ağustos 20:57 UTC ile 30 Ağustos 06:10 UTC arasında güncelleme kontrolü yapan ve o anda yetkisiz rotayı kullanan Virtualizor kurulumları kötü amaçlı paketi almış olabilir.
Otomatik güncellemesi kapalı olan, olay penceresinde güncelleme kontrolü yapmayan veya ağ sağlayıcısı yetkisiz /24 rotasını kabul etmeyen sistemler aynı teslimat yoluna maruz kalmamış olabilir. Buna rağmen üretici, kendi günlüklerinde saldırgan yanıtlarını göremediği için bütün operatörlerin kontrol yapmasını istiyor.
Webuzo, Softaculous, Backuply ve SitePad gibi aynı altyapı aralığındaki diğer ürünlerin alan adları da yönlendirmeden etkilenebilecek listedeydi. Ancak üretici şu ana kadar Virtualizor dışındaki ürünler için kötü amaçlı paket tespit etmediğini ve incelemenin sürdüğünü belirtiyor. Bu iki ifade karıştırılmamalıdır: ağ yolunun etkilenmesi, her ürünün yazılım paketinin değiştirildiği anlamına gelmez.
Bilinen olay göstergesi nedir?
Virtualizor'un açıkladığı temel IOC, aşağıdaki systemd birimidir:
CODE TERMINAL
/etc/systemd/system/java-jre-update.serviceÜretici ayrıca java-jre-update adlı etkin veya çalışan servisin kontrol edilmesini istiyor. Dosyanın veya servisin bulunması sistemin etkilendiğine dair güçlü göstergedir. Üretici, böyle bir durumda dosyanın hemen silinmemesini; önce destek ekibiyle iletişim kurularak kanıtın korunmasını öneriyor.
Salt dosya yokluğu sistemin kesin temiz olduğunu kanıtlamaz. Dosya kaldırılmış, başka kalıcılık yöntemi eklenmiş veya saldırı sırasında farklı bir aşama çalıştırılmış olabilir. Bu nedenle hizmet dosyası kontrolü, hesaplar, SSH anahtarları, zamanlanmış işler, süreçler, ağ bağlantıları ve kimlik bilgileriyle birlikte değerlendirilmelidir.
Virtualizor yöneticileri şimdi ne yapmalı?
- IOC'yi kontrol edin: /etc/systemd/system/java-jre-update.service dosyasını ve java-jre-update servisinin etkin/çalışan durumunu inceleyin.
- Security Analyzer'ı çalıştırın: Üreticinin 1 Eylül 2026'da yayımladığı Virtualizor 3.2.9 Patch 9 sürümü yönetici paneline Security Analyzer ekliyor. Sürüm ve güncelleme kaynağını doğrulayarak aracı kullanın.
- API anahtarlarını döndürün: Bütün Virtualizor API anahtarlarını yeniden oluşturun, erişimi güvenilir IP adresleriyle sınırlandırın ve tanımadığınız anahtarları kaldırın.
- SSH erişimini denetleyin: root ve yönetici hesaplarının authorized_keys dosyalarını, yeni kullanıcıları, sudoers değişikliklerini ve son girişleri inceleyin.
- Kalıcılık avı yapın: systemd birimleri, cron kayıtları, zamanlayıcılar, başlangıç betikleri, olağan dışı ikili dosyalar ve beklenmeyen dış bağlantıları kontrol edin.
- Kanıtı koruyun: Şüpheli bulgu varsa servisi silmeden önce süreç listesi, ağ bağlantıları, dosya zaman damgaları, günlükler ve disk imajı gibi kanıtları koruyun.
- Kullanıcı oturumlarını değerlendirin: Olay penceresinde Softaculous müşteri alanına giriş yaptıysanız parolayı değiştirin; aynı parola başka yerde kullanıldıysa orada da döndürün.
- NOC API anahtarlarını yenileyin: Softaculous istemci alanındaki NOC/API anahtarlarını yeniden üretip sunucularda güncelleyin.
- Ağ erişimini daraltın: Virtualizor yönetici paneli ve SSH'ı yalnızca yönetim ağı, VPN veya belirli güvenilir IP'lerden erişilebilir kılın.
Güvenli ilk kontrol komutları
Aşağıdaki komutlar yalnızca görünür durumu toplar; bulunan dosyayı silmez veya servisi değiştirmez:
CODE TERMINAL
sudo test -e /etc/systemd/system/java-jre-update.service && echo "IOC bulundu"
sudo systemctl status java-jre-update --no-pager
sudo systemctl is-enabled java-jre-update
sudo systemctl cat java-jre-update
sudo find /root/.ssh /home -path '*/.ssh/authorized_keys' -type f -print 2>/dev/null
sudo systemctl list-unit-files --state=enabled
sudo systemctl list-timers --all
sudo crontab -l
sudo ss -plantKomut çıktılarında şüpheli bir durum görülürse rastgele temizleme yapmak yerine sunucuyu kontrollü biçimde ağdan izole etmek, uçucu veriyi toplamak ve üretici/olay müdahale ekibiyle çalışmak daha güvenlidir. Sanallaştırma ana sistemi ele geçirilmişse yalnızca Virtualizor panelini yeniden kurmak yeterli olmayabilir; aynı host üzerindeki misafir makineler, yönetim kimlik bilgileri, yedekleme hedefleri ve komşu altyapı da olay kapsamına alınmalıdır.
Virtualizor 3.2.9 Patch 9 ne getiriyor?
Virtualizor ekibi 1 Eylül 2026'da hem Release Candidate hem de Stable dalı için 3.2.9 Patch 9'u yayımladığını duyurdu. Sürüm notundaki güvenlikle ilişkili ana değişiklik, yönetici paneline Security Analyzer eklenmesidir. Olay raporu bu sürümün bilinen istismar izleri için azaltım aracı içerdiğini belirtiyor.
Üretici ayrıca sahte sertifikanın iptali için Let's Encrypt'e bildirim yaptığını, ilgili ağ operatörleri ve CERT'lerle temas kurduğunu, kanıtları koruduğunu ve tüm yazılım paketleri için kod imzalama mekanizması hazırladığını açıkladı.
Yeni sürüm veya tarama aracı önemli olsa da bir kompromize sistemde “güncel sürüm kuruldu” sonucu tek başına yeterli değildir. Root düzeyinde kalıcılık ihtimali varsa güvenilir yedekten yeniden kurulum, anahtar rotasyonu ve ayrı bir sistemden yapılan doğrulama gerekebilir.
Barındırma şirketleri ve VPS müşterileri neyi doğrulamalı?
Virtualizor doğrudan sanallaştırma ana sistemini yönettiği için olayın olası etkisi tek bir web uygulamasıyla sınırlı değildir. Bir barındırma sağlayıcısı aşağıdaki sorulara kanıtla yanıt verebilmelidir:
- Hangi hypervisor düğümleri olay penceresinde güncelleme kontrolü yaptı?
- Bu düğümlerin çıkış trafiği 162.55.80.0/24 için hangi BGP yolunu izledi?
- java-jre-update.service veya başka şüpheli kalıcılık göstergesi bulundu mu?
- Virtualizor, NOC, root, SSH ve yedekleme kimlik bilgileri döndürüldü mü?
- Yetkisiz SSH anahtarı, kullanıcı, cron, systemd birimi veya dış bağlantı tespit edildi mi?
- Etkilenen düğümler güvenilir kaynaktan yeniden kuruldu mu; misafir diskleri ve snapshot'lar incelendi mi?
- Müşterilere olay kapsamı, zaman çizelgesi ve alınan önlemler bildirildi mi?
VPS müşterisi kendi misafir işletim sisteminde IOC görmeyebilir; saldırı Virtualizor'un çalıştığı ana sisteme ulaşmış olabilir. Bu nedenle müşteriler sağlayıcılarından açık bir durum açıklaması, ana sistem denetim sonucu ve kimlik bilgisi rotasyonu bilgisi istemelidir. Hassas iş yükleri için uygulama parolaları, API anahtarları ve sunucu dışına çıkabilen sırlar risk bazlı olarak döndürülmelidir.
BGP ve güncelleme altyapısı için kalıcı dersler
Olay iki ayrı güven katmanının aynı varsayıma bağlanmasının riskini gösteriyor. TLS alan adı doğrulaması ile yazılım teslimatı aynı kaçırılmış ağ yoluna güvendiğinde, geçerli sertifika kötü amaçlı paketin üreticiye ait olduğu yanılgısını oluşturabiliyor.
Yazılım üreticileri için daha dayanıklı model şunları içerir:
- Güncelleme paketlerini çevrimdışı veya güçlü biçimde korunan anahtarla kriptografik olarak imzalamak
- İstemcide imzayı sabitlenmiş ve rotadan bağımsız güven köküyle zorunlu doğrulamak
- Sürüm metadatası, hash ve geri alma korumasını imza kapsamına almak
- RPKI ROA ve Route Origin Validation durumunu sürekli izlemek
- Daha özel önek duyurularını, yeni transit yollarını ve MOAS dışı anormallikleri gerçek zamanlı alarm üretmek
- Sertifika şeffaflığı kayıtlarında beklenmeyen sertifika üretimini izlemek
- Güncelleme kontrol düzlemini müşteri alanı ve genel web altyapısından ayırmak
- İstemci telemetrisini gizliliğe uygun biçimde saklayarak hangi sunucunun hangi paketi aldığını doğrulayabilmek
Sonuç
Virtualizor olayı, BGP yönlendirme güveni, otomatik TLS doğrulaması ve imzasız güncelleme paketinin aynı zincirde birleşmesiyle klasik bir ağ olayının doğrudan yazılım tedarik zinciri saldırısına dönüşebildiğini gösteriyor. Üretici kötü amaçlı paketin az sayıda sisteme ulaştığını doğrulasa da kesin liste çıkarılamadığı için bütün Virtualizor operatörlerinin IOC kontrolü, kimlik bilgisi rotasyonu ve kalıcılık avı yapması gerekiyor.
En önemli gösterge /etc/systemd/system/java-jre-update.service dosyasıdır. Bulgu varsa dosyayı hemen silmek yerine kanıtı koruyun, sistemi izole edin ve üreticiyle olay müdahale sürecini başlatın. IOC bulunmasa bile API/SSH erişimini daraltmak, anahtarları döndürmek ve Virtualizor 3.2.9 Patch 9 içindeki Security Analyzer ile kontrol yapmak uygun bir asgari adımdır.
Kaynaklar
- Virtualizor – Security Incident: BGP Hijacking
- Softaculous – Security Incident: BGP Hijacking Update
- Virtualizor – 3.2.9 Patch 9 sürüm notu
- RIPE Stat BGPlay – 162.55.80.0/24 rota geçmişi
- Virtualizor – Güvenlik tarama betiği
TR Siber Ekibi