Heartbleed Güvenlik Açığı (OpenSSL)

SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Sitenizi Tarayın

Sitenizi bu zafiyete karşı kontrol edin

Otomatik bir tarama başlatın ve sitenizin etkilenip etkilenmediğini görün — sade dille bulgular ve çözümlerle.

Taramaya Başla
Kategori Bellek İfşası / Kriptografik Kütüphane Hatası
Tipik Önem Düzeyi Kritik
CVE CVE-2014-0160
CVSS v2 Puanı 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N) — etki nedeniyle sektörde Kritik olarak değerlendirilir
OWASP A02:2021 – Kriptografik Başarısızlıklar; A06:2021 – Savunmasız ve Güncel Olmayan Bileşenler
CWE CWE-125 (Sınır Dışı Okuma), CWE-126 (Arabellek Aşımı Okuma)
Diğer Adlar Heartbleed Hatası, TLS Heartbeat Arabellek Aşımı Okuma
Etkilenen OpenSSL Sürümleri 1.0.1 – 1.0.1f arası, 1.0.2-beta – 1.0.2-beta1 arası
Etkilenen Sistemler HTTPS web sunucuları, posta sunucuları, VPN uç noktaları, yük dengeleyiciler ve savunmasız OpenSSL kullanan tüm TLS hizmetleri
Açıklanma Tarihi 7 Nisan 2014
Düzeltme Sürümü OpenSSL 1.0.1g (7 Nisan 2014)

Genel Bakış

Heartbleed, OpenSSL'in 1.0.1 ile 1.0.1f arasındaki sürümlerinde bulunan TLS/DTLS heartbeat uzantısının (RFC 6520) gerçekleştirimindeki kritik bir güvenlik açığıdır. Açık, 31 Aralık 2011'de OpenSSL kod tabanına eklendi ve Mart 2012'de OpenSSL 1.0.1 ile birlikte yayımlandı. İki yılı aşkın süre fark edilmeden kaldı; 7 Nisan 2014'te Codenomicon ve Google Security araştırmacıları tarafından kamuoyuna duyuruldu.

Hata bir arabellek aşımı okumasıdır: sunucu, bir heartbeat isteğindeki istemci kaynaklı uzunluk alanının gerçek yük uzunluğuyla eşleşip eşleşmediğini doğrulamaz; bu nedenle meşru yükün çok ötesinde bellek içeriğini geri gönderir. Açık kimlik doğrulaması gerektirmediğinden ve standart günlüklerde iz bırakmadığından, büyük ölçekte ve sessiz biçimde istismar edilebilir.

Sensagraph, hâlâ savunmasız OpenSSL sürümleri çalıştıran veya uygun sınır denetimi olmaksızın heartbeat uzantısını açık bırakan sunucuları otomatik olarak tespit eder.

Nasıl çalışır?

TLS Heartbeat uzantısı (RFC 6520), bir tarafın rastgele bir yük ve talep edilen yük uzunluğu içeren bir HeartbeatRequest mesajı göndermesine olanak tanır. Alıcı tarafın yükü olduğu gibi HeartbeatResponse ile yankılaması beklenir. ssl/d1_both.c (DTLS) ve ssl/t1_lib.c (TLS) dosyalarındaki savunmasız OpenSSL kodu şu hatalı mantığı izliyordu:

  1. Gelen heartbeat mesajından 2 baytlık payload_length alanını oku (saldırgan tarafından denetlenen, en fazla 65.535).
  2. payload_length + başlık ek yükü boyutunda bir yanıt arabelleği tahsis et.
  3. İstek arabelleğinin en az o uzunlukta gerçek bir yük içerip içermediğini doğrulamadan, istek arabelleğinden payload_length bayt kopyala.
  4. Yanıtı isteği yapana gönder.

Saldırgan, 1 baytlık yük içeren ama uzunluğu 65.535 olarak beyan eden bir heartbeat isteği göndererek heartbeat arabelleğine bitişik sunucu işlemi yığın belleğinden 64 KB'ye kadar ham veri alabilir. Bu bellek şunları içerebilir:

  • RSA veya EC özel anahtarları (kaydedilmiş TLS trafiğinin geriye dönük şifresini çözmeye ve sunucunun kimliğine bürünmeye olanak tanır).
  • Oturum çerezleri ve OAuth jetonları (kimlik bilgisi olmadan hesap ele geçirmeye izin verir).
  • Kullanıcı adı ve parola içeren POST verileri dahil HTTP istek/yanıt gövdeleri.
  • ASLR'ı atlatmaya yönelik sonraki saldırılarda kullanılabilecek iç bellek adresleri.
  • Diğer TLS oturumu anahtar materyalleri.

Saldırı kimlik doğrulaması gerektirmez, yalnızca 443 numaralı bağlantı noktasına (veya herhangi bir TLS bağlantı noktasına) standart bir TCP bağlantısı yeterlidir ve anlamlı bir sunucu tarafı günlük kaydı oluşturmaz. İstekler ek bellek bölgelerini ele geçirmek için sürekli tekrarlanabilir.

İş etkisi

Heartbleed, bugüne dek keşfedilen en yıkıcı web güvenlik açıklarından biri olarak kabul edilmektedir. Yama uygulanmamış bir sunucuya yönelik başarılı bir saldırı şunlara yol açabilir:

  • Özel anahtar ihlali: Sunucunun TLS özel anahtarı ele geçirilirse saldırgan, gelecekteki tüm bağlantılara yönelik ortadaki adam saldırıları gerçekleştirebilir ve önceden kaydedilmiş tüm şifreli trafiği çözebilir (mükemmel ileri gizlilik olmaksızın geçmiş oturum şifre çözümü mümkündür).
  • Oturum ele geçirme: Çalınan oturum jetonları, kimliği doğrulanmış kullanıcıların parolalarına gerek kalmadan hesaplarının tam olarak ele geçirilmesine olanak tanır.
  • Kimlik bilgisi hırsızlığı: Yığın belleğinde bulunan düz metin parolalar (aktarım halindeki HTTPS isteklerinden) doğrudan çıkarılabilir.
  • Yasal ve uyumluluk riski: Kişisel verilerin çıkarılması; GDPR, HIPAA, PCI-DSS ve benzer çerçeveler kapsamında bildirim yükümlülükleri doğurur.
  • İtibar kaybı: Heartbleed'e atfedilen yüksek profilli ihlaller (örn. Canada Revenue Agency, Mumsnet), ağır itibar sonuçlarını gözler önüne sermiştir.
  • Sertifika yeniden düzenleme maliyetleri: Yama uygulandıktan sonra, anahtarları ifşa edilmiş olabilecek tüm TLS sertifikaları iptal edilip yeniden düzenlenmelidir.

Nasıl giderilir?

  1. OpenSSL'i derhal güncelleyin: OpenSSL 1.0.1g veya daha yeni bir sürüme (ya da dağıtım tarafından yamalanmış eşdeğerine) geçin. Doğrulama için openssl version -a komutunu kullanın. Modern dağıtımlar OpenSSL 3.x hedeflemelidir.
  2. Tüm servisleri yeniden başlatın: OpenSSL, başlangıçta işlem belleğine yüklenir; kütüphane güncellemesi servisi yeniden başlatmadan savunmasız kodu bellekten kaldırmaz.
  3. TLS sertifikalarını iptal edip yeniden düzenleyin: Savunmasız dönem boyunca kullanılan sertifikalara ait tüm özel anahtarların ele geçirilmiş olduğunu kabul edin. Etkilenen sertifikaları düzenleyen CA nezdinde iptal edin ve yeni anahtar çiftleri oluşturarak yeniden düzenleme talep edin.
  4. Tüm etkin oturumları geçersiz kılın: Tüm kimliği doğrulanmış kullanıcıları çıkış yapmaya zorlayın; oturum sırlarını, CSRF jetonlarını ve yığın belleğinde bulunmuş olabilecek simetrik anahtarları yenileyin.
  5. Gizli bilgileri ve kimlik bilgilerini döndürün: API anahtarlarını, OAuth sırlarını, veritabanı parolalarını ve savunmasız sunucu tarafından işlenmiş olabilecek diğer gizli bilgileri döndürün.
  6. Mükemmel İleri Gizlilik (PFS) etkinleştirin: ECDHE veya DHE anahtar değişimini tercih eden şifre paketlerini yapılandırın (örn. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); böylece gelecekteki anahtar ihlalleri geçmiş oturumların şifresini çözemez.
  7. Gerekmiyorsa heartbeat uzantısını devre dışı bırakın: Heartbeat özelliği operasyonel olarak gerekli değilse OpenSSL'i -DOPENSSL_NO_HEARTBEATS seçeneğiyle derleyin.
  8. Bağımlılıkları denetleyin: OpenSSL içeren tüm yazılım bileşenlerini (yük dengeleyiciler, posta sunucuları, VPN cihazları, gömülü aygıtlar) belirleyin ve tedarikçi yamalarını uygulayın.
  9. Etkilenen kullanıcıları bilgilendirin: Oturum veya kimlik bilgisi verilerinin ifşa edilmiş olabileceği durumlarda, geçerli ihlal bildirim yasalarına uyun ve etkilenen kişileri derhal bilgilendirin.

Kaynaklar

Sıkça sorulan sorular

Evet. Büyük internet hizmetlerinin büyük çoğunluğu Nisan 2014 açıklamasının ardından birkaç hafta içinde yamalanmış olsa da gömülü sistemler, eski cihazlar, IoT aygıtları ve ihmal edilmiş iç altyapı hâlâ savunmasız OpenSSL sürümleri çalıştırmaktadır. Otomatik taramalar, düzeltmenin yayımlanmasından yıllar sonra dahi yamalar uygulanmamış uç noktalar keşfetmeye devam etmektedir.

Standart web sunucusu günlükleri heartbeat alışverişlerini kaydetmez; bu da Heartbleed saldırılarını erişim günlüklerinde fiilen görünmez kılar. Tespit için, hatalı biçimlendirilmiş bir heartbeat isteği gönderip sunucunun gönderilenden daha fazla veri döndürüp döndürmediğini inceleyen özel bir heartbeat probu gereklidir.

Hayır. Yama uygulamak gelecekteki istismarı durdurur; ancak halihazırda sızdırılmış olabilecek verilere yönelik hiçbir şey yapmaz. Tam giderme; kütüphane yükseltmesine ek olarak TLS sertifikalarının iptal edilip yeniden düzenlenmesini, tüm gizli bilgilerin döndürülmesini ve tüm etkin oturumların geçersiz kılınmasını gerektirir.

OpenSSL 1.0.1 – 1.0.1f arası sürümler ve ön sürüm 1.0.2-beta1 etkilenir. OpenSSL 1.0.0 ve önceki ile 0.9.x dalları, heartbeat uzantısını gerçeklememekte olup Heartbleed'e karşı savunmasız değildir.

TLS 1.3 (RFC 8446), heartbeat uzantısını protokolden tamamen kaldırmaktadır; dolayısıyla yalnızca TLS 1.3'ü destekleyen gerçeklemeler Heartbleed'e maruz kalmaz. Bununla birlikte, bellek işlemlerinden önce uzunluk alanlarını doğrulama gerekliliği, protokol sürümünden bağımsız genel bir güvenli kodlama gereksinimidir.