eMudhra Sertifika Olayı: Ara Sertifika Anahtarları Nasıl İstismar Edildi, Kurumlar Ne Yapmalı?
eMudhra’nın küresel TLS sertifika altyapısında kullanılan sekiz ara sertifikayla ilişkili özel anahtarların zayıf üretildiği ortaya çıktı. Bu anahtarları elde edebilecek bir saldırgan, teorik olarak güvenilir görünen sahte web sitesi sertifikaları düzenleyebilir veya etkilenen kod imzalama sertifikalarını kötüye kullanabilirdi. Google, Mozilla ve diğer kök sertifika programları ilgili sertifikaları engellemek için önlemler aldı. Broadcom da bazı güvenlik cihazlarında Trust Package’in elle güncellenmesini istiyor.
Olay nasıl ortaya çıktı?
Sorun, eMudhra’nın 30 Nisan 2025’te gerçekleştirdiği bir anahtar üretim süreciyle bağlantılı. Şirketin açıklamasına göre süreçteki bir wrap/unwrap adımı, güçlü anahtarların yanında ikinci ve zayıf bir anahtar seti oluşturdu. Kök sertifika depolarında yayımlanan anahtarlar bu zayıf setten geldi. eMudhra, anahtarların FIPS 140-2 Level 3 sertifikalı HSM’lerde üretildiğini ve sorunun HSM kullanılmamasından değil, anahtar üretim sürecindeki bir hatadan kaynaklandığını belirtiyor. Nihai kök neden incelemesi ise şirketin açıklamasına göre sürüyor.
CERT-In’in aktardığı teknik değerlendirmeye göre, etkilenen P-384 eliptik eğri anahtarlarının özel değerleri olması gerekenden çok daha küçüktü ve açık anahtar bilgilerinden elde edilebiliyordu. Bu, P-384 şifreleme algoritmasının kırıldığı anlamına gelmiyor; zafiyet, bu sertifikalar için anahtarların hatalı üretilmiş olmasından kaynaklanıyor.
Etkilenen sekiz ara sertifikanın altısı TLS, ikisi kod imzalama amacı taşıyordu. eMudhra, ara sertifikaların iptal edildiğini ve bunların son kullanıcı sertifikası düzenlemediğini bildiriyor. Google da altı TLS ara sertifikasına zincirlenen sertifikaların, engelleme öncesinde Certificate Transparency kayıtlarında görünmediğini açıkladı. 22 Ekim itibarıyla kamuya açık kaynaklarda, bu anahtarların saldırganlar tarafından kötüye kullanıldığı doğrulanmış değil.
Bir saldırgan bu zayıflıktan nasıl yararlanabilir?
Bir ara sertifika yetkilisinin (Intermediate CA) özel anahtarı, o yetkilinin altındaki sertifikaları imzalamak için kullanılır. Anahtara sahip olan saldırgan, teorik olarak hedeflediği bir alan adı için sahte TLS sertifikası düzenleyebilirdi. İstemci bu sertifika zincirine hala güveniyorsa, bağlantı kurduğu sunucunun gerçek olduğuna inanabilirdi.
Böyle bir saldırının başarıya ulaşması için yalnızca sahte sertifika oluşturmak yeterli olmazdı. Saldırganın kurbanın bağlantısını kendi kontrolündeki sunucuya yönlendirebilmesi veya trafiğin arasına girebilmesi de gerekirdi. Bu; örneğin DNS ya da yönlendirme altyapısının ele geçirilmesi, güvensiz bir ağda trafiğin yönlendirilmesi veya başka bir araya girme imkanı üzerinden gerçekleşebilirdi. Sahte sertifika kabul edilirse saldırgan bağlantıdaki verileri görmeye veya değiştirmeye çalışabilirdi.
Bu nedenle olay, her eMudhra sertifikası kullanan web sitesinin ele geçirildiği anlamına gelmiyor. Risk, etkilenen sertifika zincirine güvenmeye devam eden istemci ile saldırganın bağlantı trafiğine müdahale edebilme imkanının bir araya gelmesiyle oluşuyordu. Tarayıcıların sertifika engellemesi bu zincire güvenilmesini önlemek için devreye girdi. Google, Chrome’daki müdahalenin ara sertifika anahtarlarını temel alarak yapıldığını ve bu TLS ara sertifikalarına bağlı, engelleme öncesinde CT kayıtlarına girmiş sertifikalar görmediğini bildirdi.
İki kod imzalama anahtarının kötüye kullanılması da ayrı bir risk oluşturuyordu: Saldırgan, imzalı görünen zararlı yazılımlarla güven algısı yaratmaya çalışabilirdi. Bu yüzden kurumların yalnızca web tarayıcılarını değil, kod imzalama zincirlerini ve uygulama çalıştırma politikalarını da gözden geçirmesi gerekiyor.
Hangi sistemler ve hizmetler etkilenebilir?
Olay, eMudhra’nın küresel TLS güven zincirindeki belirli ara sertifikalarla sınırlı. CERT-In’e göre eMudhra’nın Hindistan’daki düzenlemeye tabi dijital imza sertifikası (DSC) ve eSign altyapısı olaydan etkilenmedi. eMudhra da emSigner, CertiNext, emCA, PrivaTrust ve SecurePass hizmetlerinin ayrı altyapıda çalıştığını ve etkilenmediğini belirtiyor.
Doğrudan etkilenen güven zincirlerine ek olarak, tarayıcıların ilgili kök sertifikayı güven depolarından çıkarması meşru TLS sertifikalarında kesintiye yol açabilir. Google, emSign ECC Root CA – G3 kök sertifikasının Chrome Root Store’dan kaldırılmasının Chrome’un bu depoyu kullanan cihazlarına 27 Ekim 2026’da ulaşmasının beklendiğini duyurdu. eMudhra ise bu köke bağlı sertifikalar kullanan bir müşteri ekosistemi için geçiş ve yenileme çalışması yürüttüğünü söylüyor. Dolayısıyla kurumlar yalnızca “sertifikamız doğrudan etkilenen ara CA’dan mı?” sorusunu değil, zincirin ilgili köke kadar uzanıp uzanmadığını da kontrol etmeli.
Kurumlar hangi önlemleri almalı?
1. Tarayıcı ve işletim sistemi güncellemelerini uygulayın
Chrome, Firefox, Android ve diğer istemciler için üreticilerin yayımladığı güvenlik ve güven deposu güncellemelerini yükleyin. Tarayıcıların güncel olması, uygulamaların veya sunucu işletim sistemlerinin de aynı güven iptal bilgilerini aldığı anlamına gelmeyebilir. Özel CA deposu kullanan uygulamaları ayrıca değerlendirin.
2. Sertifika zincirlerini envanterleyin
İnternete açık web siteleri, API uç noktaları, proxy bağlantıları ve kritik iç servislerde kullanılan TLS sertifikalarının issuer, ara CA ve kök CA bilgilerini kontrol edin. Sertifika zincirinde ilgili eMudhra ara sertifikaları veya emSign ECC Root CA – G3 bulunuyorsa, sertifikayı sağlayan tarafla görüşerek güvenilir başka bir PKI hiyerarşisinden yenileme planlayın.
Yenileme sonrasında yalnızca sertifikanın tarihine bakmayın; yeni sertifikanın gerçekten farklı ve güvenilen bir zincire bağlandığını doğrulayın.
3. Özel CA paketlerini ayrıca güncelleyin
Proxy’ler, ağ güvenlik cihazları, TLS kütüphaneleri, uygulama çalışma ortamları, container imajları ve gömülü cihazlar kendi CA paketlerini kullanabilir. Bu sistemler tarayıcıların iptal listelerini otomatik olarak almayabilir. Üreticinin güven paketi güncellemesini uygulayın ve cihazın ilgili sertifika zincirini artık kabul etmediğini doğrulayın. CERT-In de bağımsız CA depoları kullanan uygulama ve cihazların ayrıca incelenmesini öneriyor.
4. Kod imzalı dosyaları ve uygulama politikalarını gözden geçirin
Kritik uygulamaları çalıştırmadan önce imza durumunu, yayıncı bilgisini ve sertifika zincirini doğrulayın. İmzalı olması bir dosyanın tek başına güvenli olduğu anlamına gelmez. Kurumlar WDAC veya AppLocker gibi uygulama denetimlerini, yazılım dağıtım kaynaklarını ve dosya bütünlüğü kontrollerini gözden geçirebilir. Sertifika zincirinin iptal durumunu kontrol edin; doğrulama hatalarını geçici olarak yok sayan istisnalar tanımlamayın. CERT-In, kod imzalama güveninin de kontrol edilmesini öneriyor.
5. CT kayıtlarını ve beklenmeyen sertifika değişikliklerini izleyin
Kurumun alan adları için Certificate Transparency (CT) kayıtlarını izlemek, beklenmeyen sertifika düzenlemelerini fark etmeye yardımcı olur. Ayrıca web sunucularındaki sertifika değişiklikleri, DNS kayıtları ve olağan dışı TLS doğrulama hataları takip edilmelidir. CT izleme ek bir tespit katmanıdır; CA iptalini veya güven deposu güncellemesini uygulamanın yerine geçmez.
6. TLS doğrulama kontrollerini kapatmayın
Sertifika hatası veren bir uygulamada doğrulamayı devre dışı bırakmak, saldırgan araya girdiğinde bağlantının uyarısız kurulmasına yol açabilir. Sorun varsa önce sertifika zincirini, cihazın saatini, DNS/proxy yapılandırmasını ve güven paketinin durumunu inceleyin; güvenlik denetimini kapatarak çalışmayı sürdürmeyin.
eMudhra olayı, anahtar üretimindeki zayıflığın bir sertifika otoritesinin güven zincirini nasıl etkileyebileceğini gösteriyor. Tarayıcı üreticileri etkilenen TLS ara sertifikalarını engelledi ve ilgili kök sertifikayı da güven depolarından çıkarma sürecine başladı. Buna rağmen kurumsal uygulamalar, proxy cihazları ve özel CA paketleri güncel olmayabilir. Kurumlar güven depolarını yenilemeli, sertifika zincirlerini envanterlemeli, köke bağlı geçerli sertifikalar için geçiş planı yapmalı ve kod imzalama doğrulamasını da kontrol etmelidir. Kamuya açık kaynaklarda şu an için doğrulanmış kötüye kullanım bulunmaması, bu kontrollerin ertelenmesi gerektiği anlamına gelmiyor.
