Heartbleed, yaygın kullanılan OpenSSL şifreleme kütüphanesinde 2014’te açıklanan ve CVE-2014-0160 ile kayda geçen bir zafiyettir. Sorun, TLS bağlantısının canlı tutulması için tasarlanan heartbeat mesajlaşmasında yatar. Bu mekanizma, bir tarafın küçük bir veri parçası gönderip aynısını geri istemesine dayanır; hata, geri istenen boyutun gönderilen gerçek veriyle karşılaştırılmadan işlenmesinden doğar.

Heartbleed, TLS heartbeat isteğinde belirtilen uzunluğun doğrulanmaması nedeniyle sunucunun kendi belleğinden istenen kadar fazla veriyi yanıt olarak geri verdiği bir bilgi sızıntısı zafiyetidir.

Sınır Hatası Neye Yol Açıyor?

Saldırgan bir heartbeat isteğinde çok küçük bir veri gönderir ama yanıtta çok daha büyük bir uzunluk talep eder. Sunucu, kütüphanenin talep edilen uzunluğu sorgulamaması nedeniyle gönderilen küçük parçanın ötesindeki bellek bölgesini de yanıta kopyalar. Bu bölgede o an ne varsa saldırgana ulaşır: başka kullanıcıların oturum çerezleri, form verileri, parolalar ve en kritiği sunucunun TLS özel anahtarı. Her istek en fazla yaklaşık 64 kilobayt döndürür, ancak istek tekrar edilebildiğinden veri sızdırma adeta sürekli akan bir kanal hâline gelir.

Neden Bu Kadar Ciddiydi?

Özel anahtarın sızması, tek bir olayın çok ötesinde sonuç doğurur. Anahtarı ele geçiren saldırgan, o sunucu adına şifreli trafiği çözebilir ve inandırıcı sahte siteler kurabilir. Dahası saldırı, bağlantının normal TLS el sıkışması akışından önce çalışabildiği ve sunucu günlüklerine olağandışı bir kayıt bırakmadığı için fark edilmesi zordu. Bu sessizlik, açığın ne kadar süredir ve kimler tarafından kullanıldığının kesin olarak bilinememesine yol açtı.

Protokol Değil, Uygulama Hatası

Heartbleed’i doğru konumlandırmak önemlidir: hata SSL/TLS protokolü tasarımında değil, o protokolü uygulayan belirli bir OpenSSL sürümündeki kodda vardı. Aynı protokolü kullanan başka kütüphaneler etkilenmedi. Bu ayrım, standardın kendisi sağlam olsa bile bir uygulamadaki tek bir sınır denetimi eksikliğinin küresel ölçekli sonuç doğurabileceğini gösterir.

Kapsamlı Müdahale

Yamayı yüklemek gerekli ilk adımdır ve savunmasız OpenSSL sürümlerinin envanterdeki her yerden temizlenmesi disiplinli bir yama yönetimi sürecine bağlıdır. Ancak yama tek başına yeterli değildir; anahtarın zaten sızmış olabileceği varsayımıyla sertifikaların yeniden üretilip iptal edilmesi ve tüm kullanıcı oturumlarının geçersiz kılınması gerekir.

Sunucusu bu açığa maruz kalmış bir kurumda hangi verilerin ve anahtarların risk altında olduğunun belirlenmesi, saldırganın bu bilgilerle başka sistemlere sıçrayıp sıçramadığının araştırılması kritik önemdedir. Bu değerlendirme için olay inceleme ve olay müdahalesi çalışması, yenilenmesi gereken kimlik bilgilerinin tam listesini çıkarır.