ZoriaNews

Ne oldu?

Okta Red Team tarafından keşfedilen ve "HollowByte" adı verilen yeni bir güvenlik açığı, OpenSSL tabanlı sunuculara karşı son derece etkili bir hizmet dışı bırakma (DoS/DDoS) saldırısı yöntemi sunuyor. Saldırganın sadece 11 baytlık özel hazırlanmış bir TLS paketi göndermesi yeterli oluyor. Açık, TLS el sıkışma (handshake) sürecinde OpenSSL'in mesaj boyutunu önceden doğrulamadan bellek ayırması zafiyetinden kaynaklanıyor. TLS mesajlarının 4 baytlık başlığında, üç baytlık bir uzunluk alanı sonraki verinin ne kadar büyük olacağını bildiriyor. Savunmasız OpenSSL sürümleri bu boyutu hemen allocate ediyor; saldırgan 11 baytlık küçük pakette 131 KB'lik bir boyut bildirebiliyor ve sunucu bu belleği boşuna ayırıyor. Bağlantı kopunca OpenSSL belleği serbest bıraksa da, GNU C Library (glibc) küçük ve orta ölçekli tahsisleri işletim sistemine geri vermek yerine yeniden kullanım için elinde tutuyor. Saldırgan farklı boyutlarla tekrarlanan bağlantılar kurduğunda, glibc bu parçaları yeniden kullanamıyor; sunucunun Resident Set Size (RSS) değeri kalıcı olarak yükseliyor. Okta'nın testlerinde 1 GB RAM'li bir sunucu 547 MB donmuş bellekle OOM-kill edilirken, 16 GB'lik bir sistemde %25 bellek kilitlenebildi.

Neden önemli?

HollowByte, klasik bağlantı tüketme saldırılarından (örneğin Slowloris) farklı olarak sadece bağlantı sınırını değil, doğrudan sistem belleğini hedef alıyor. Bu, standart connection-limiting veya rate-limiting önlemlerinin yetersiz kalabileceği anlamına geliyor; çünkü bellek tüketimi bağlantı sayısından bağımsız olarak birikebiliyor. Ayrıca saldırı tamamen kimlik doğrulama öncesi gerçekleştiği için, HTTPS uç noktasını internete açık tutan herhangi bir sunucu potansiyel hedef. Açık, bulut sunucuları, CDN'ler, API gateway'ler ve web uygulamaları için ciddi erişilebilirlik riski oluşturuyor. OpenSSL ekibi haziran ayında sessizce yama yayınladı ancak resmi bir CVE veya danışma belgesi atanmış mı kesin değil; bu da sızma testleri ve envanter yönetiminde farkındalığı zorlaştırıyor.

Kim veya ne etkileniyor?

Etkilenen sistemler, savunmasız OpenSSL sürümlerini kullanan ve TLS/HTTPS üzerinden hizmet veren tüm sunuculardır. Okta'nın testlerinde NGINX ile çalışan bir ortam kullanıldığı belirtiliyor; ancak OpenSSL'i statik veya dinamik olarak bağlayan web sunucuları, ters proxy'ler, yük dengeleyiciler ve API sunucuları da risk altında. Linux tabanlı sistemlerde özellikle glibc kullanan dağıtımlar daha savunmasız görünüyor, çünkü bellek parçalanması sorunu glibc'nin tahsis stratejisiyle ilişkili. Windows veya farklı C kütüphaneleri kullanan platformlarda etki farklılık gösterebilir; detaylı etki henüz doğrulanmadı. Bulut sağlayıcıları, e-ticaret siteleri, finans API'leri ve sağlık sektörü gibi 7/24 erişilebilirlik gerektiren hizmetler kritik hedefler arasındadır.

Ne yapılmalı?

Sunucu yöneticilerinin acil olarak kullandıkları OpenSSL sürümünü güncellemeleri ve yamanın geriye doğru port edilmiş sürümlere uygulanıp uygulanmadığını kontrol etmeleri gerekiyor. Yama detayları şeffaf olmadığı için, OpenSSL 3.3/3.2/3.1/3.0 ve 1.1.1 dallarının son yama seviyelerine geçmek en güvenli yaklaşımdır. Ayrıca TLS uç noktaları önünde WAF, DDoS koruması ve bağlantı başına zaman aşımı (timeout) sınırları uygulanmalı; ancak bunlar tek başına yeterli olmayabilir. Bellek kullanımı izleme alarmları güçlendirilmeli, OOM durumlarında otomatik restart veya container yeniden başlatma politikaları devreye alınmalıdır. Kurumsal ortamlarda TLS terminasyonu yapan cihazlar ve container imajlarındaki OpenSSL bağımlılıkları envantere çıkarılmalı; kritik hizmetler için TLS offloading veya alternatif TLS kütüphaneleri değerlendirilebilir, ancak bu geçiş riskli olabilir ve dikkatli test gerektirir.