Selamlar,
Kriptografide "algoritma güçlü ama anahtar zayıf" senaryosunun bundan daha net bir örneğini görmek zor. Sertifika otoritesi eMudhra, sekiz ara (intermediate) sertifikasını iptal etti; çünkü bu sertifikaların özel anahtarları o kadar küçüktü ki herkes neredeyse anında kurtarabiliyordu. Bu anahtarlarla büyük tarayıcıların ve işletim sistemlerinin güvendiği, meşru siteler adına sahte sertifikalar üretmek mümkündü.
Konuda anlatılacaklar
- Ne bulundu, nasıl bulundu?
- "Değeri 256'dan küçük P-384 anahtarı" ne demek?
- Tarayıcılar ve yazılım ekosistemi nasıl tepki verdi?
- Kendi sistemlerinizde kontrol listesi
Ne bulundu?
BleepingComputer'ın aktardığına göre Wayne takma adlı bir araştırmacı 17 Ekim'de kamuya açık sertifika verilerini tararken zayıflığı fark etti. Mozilla'nın olay raporuna göre sekiz sertifikanın tamamı Nisan 2025'te üretilmiş P-384 özel anahtarları kullanıyordu ve bu anahtarların değerleri 256'dan küçüktü. Yani anahtarı bulmak için yalnızca 256 olasılığı denemek yeterliydi.
Araştırmacı Flüpke zayıflığı göstermek için ele geçen anahtarlardan birini GitHub'da yayınladı: eMudhra'nın "EM OV TLS CA - G3C" sertifikasının özel anahtar değeri sadece 4 idi. BleepingComputer yayınlanan anahtarın iptal edilen sertifikalardan biriyle eşleştiğini bağımsız olarak doğruladı.
Teknik açıdan: neden felaket?
Eliptik eğri kriptografisinde (ECDSA) özel anahtar, eğrinin mertebesinden küçük rastgele bir tam sayıdır; açık anahtar ise bu sayının eğri üzerindeki üreteç noktasıyla çarpımıdır. P-384 eğrisinde güvenlik, özel anahtarın yaklaşık 384 bitlik uzaydan rastgele seçilmesine dayanır. Anahtar 1 ile 255 arasında bir değerse, saldırganın yapması gereken tek şey bu değerleri sırayla deneyip açık anahtarla karşılaştırmaktır; bu, sıradan bir bilgisayarda anlık bir iştir.
Burada algoritma kırılmadı; anahtar üretim süreci bozuldu. eMudhra'nın Mozilla'ya açıklamasına göre Nisan 2025'te sertifikaları üreten bir betikteki hata ikinci bir zayıf anahtar seti üretti ve bu anahtarlar, düzgün üretilmiş anahtarlara benzer etiketler taşıdığı için yanlışlıkla imzalama için seçildi. Bazı sertifikalar Sectigo'ya çapraz imza için de gönderilmişti.
Kod:
# Mantığı anlamak için kavramsal örnek (lab, Python + cryptography)
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import serialization
hedef = ec.derive_private_key(4, ec.SECP384R1()).public_key() # "zayıf" anahtar
hp = hedef.public_bytes(serialization.Encoding.X962, serialization.PublicFormat.UncompressedPoint)
for d in range(1, 256):
k = ec.derive_private_key(d, ec.SECP384R1()).public_key()
if k.public_bytes(serialization.Encoding.X962, serialization.PublicFormat.UncompressedPoint) == hp:
print("ozel anahtar bulundu:", d); breakEkosistem nasıl tepki verdi?
- eMudhra: Sekiz sertifikayı iptal etti ve G3 kökü altında yeni sertifika vermeyi durdurdu. Şirket, etkilenen ara sertifikaların çoğunun üretimde kullanılmadığını ve son kullanıcılara sertifika verildiğine dair kanıt bulmadığını söylüyor. Ancak anahtarlar Nisan 2025'ten beri kurtarılabilir durumdaydı.
- Mozilla: 17 Ekim'de OneCRL ile sertifikaları engelledi (güncelleme veya yeniden başlatma gerekmeden). 20 Ekim'de Firefox 158.0.1 ve ESR güncellemeleri yayınlandı.
- Google Chrome: TLS sertifikası verme yetkisi olan altı ara sertifikayı aynı gün engelledi.
- Apple: 19 Ekim'de koruma ekledi.
- Go: 1.27.3 ve 1.26.10 sürümleri sorunu CVE-2026-111943 olarak ele alıyor.
Kendi sistemlerinizde kontrol listesi
Kendi sertifika deposunu kullanan veya iptal kontrolü yapmayan yazılımlar, güncellenene kadar bu ara sertifikalara güvenmeye devam edebilir. BleepingComputer'ın tablosundaki bazı yamalı sürümler:
Kod:
NSS 3.131.1
Python certifi 2026.10.19
pip 26.2.2
uv 0.13.4
Go 1.27.3 / 1.26.10
rustls-webpki 0.103.16
webpki-roots 1.0.10
Electron 44.9.1 / 43.8.1 / 42.11.16
Composer ca-bundle 1.4.16 / 1.6.0
Alpine ca-certificates 20261020-r0
curl CA bundle 2026-10-20
Debian, FreeBSD, Node.js, Bun: haber tarihinde "bekliyor"Kod:
# Linux/Python ortamında hızlı sürüm kontrolü
python3 -c "import certifi; print(certifi.__version__)"
pip --version
go version 2>/dev/null
dpkg -l ca-certificates 2>/dev/null | tail -1Ders
Kriptografide en zayıf halka çoğu zaman matematik değil, operasyondur: anahtar üretimi, etiketleme, betik hataları ve denetim. HSM içinde üretilen, üretim sonrası istatistiksel kontrolden geçirilen ve sertifika şeffaflığı (CT) loglarıyla izlenen anahtarlar bu tür hataları erken yakalamanın yoludur.
Sizin kurumda sertifika deposu güncellemeleri nasıl yönetiliyor? Konteyner imajlarında ca-certificates paketini ne sıklıkla yeniliyorsunuz?
Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.
Kaynaklar
