eMudhra ara CA'sının ele geçirilmesi CT log izleme ve CAA kayıtları rehberini gündeme getirdi

Ne oldu

dev.to'da, 600 puandan fazla alan bir Hacker News başlığına atıf yapan bir yazı, eMudhra tarafından işletilen bir ara sertifika otoritesinin ele geçirilmesini anlatıyor. Yazara göre başlıktaki geliştiricilerin çoğu bunu tarayıcı üreticilerinin sorunu olarak görüp geçiştirmiş. Yazı bunun tam tersini savunuyor: bir ara CA anahtarını sızdırığında veya sertifikayı hatalı düzenlediğinde, bir saldırgan sizin alan adınız için tamamen geçerli bir sertifikaya sahip olabilir. Tarayıcı her zamanki asma kilidini gösterir, kullanıcılar olağan dışı bir şey fark etmez ve siz de bir şey gerçekten bozulana kadar habersiz kalırsınız.

Yazı, yazarın hiçbir maliyeti yok dediği ve aynı gün kurulabilecek üç karşı önlemi adım adım anlatıyor: Certificate Transparency loglarını izlemek, CAA DNS kayıtlarıyla sertifika düzenlenmesini kısıtlamak ve üretim sunucularınızın gerçekte sunduğu sertifika zincirlerini denetlemek.

Ele geçirilmiş bir CA neden sizin sorununuzdur

Yazıda açıklandığı gibi TLS güven modeli tasarımı gereği son derece açıktır. Tarayıcılar yüz civarında kök CA'ya güvenir, her biri birden çok ara CA'ya yetki devreder ve bu zincirdeki herhangi bir CA, alan adı sahibi açıkça aksini söylemedikçe herhangi bir alan adı için sertifika imzalayabilir. Alan adınızı belirli bir düzenleyiciye ayıran yerleşik bir kural yoktur.

Kısmi çözüm Certificate Transparency'dir. Yazıya göre 2018'den beri Chrome, herkese açık güvene sahip her sertifikanın bir Signed Certificate Timestamp taşımasını, yani bir genel CT loguna kaydedilmesini zorunlu kılıyor; Safari de benzer bir politikayı uyguluyor. Dolayısıyla tarayıcıların kabul edeceği sahte bir sertifika neredeyse kesinlikle genel bir logda duruyor. Tek yapmanız gereken ona bakmak.

Certificate Transparency loglarını izleyin

Önerilen araç, bir JSON uç noktası sunan ve Sectigo tarafından işletilen ücretsiz bir CT log toplayıcısı olan crt.sh. Yazar, cron'dan saatlik çalıştırılan bir Python scripti paylaşıyor: yapılandırılmış alan adlarına ait tüm sertifikaları çekiyor, Let's Encrypt ve Google Trust Services gibi izin verilen düzenleyicilerin beyaz listesini tutuyor ve listede olmayan bir düzenleyiciden yeni bir sertifika göründüğünde alarm veriyor. Script, uyarı durumunda sıfır olmayan bir çıkış kodu döndürüyor; böylece cron veya CI çıktıyı bir Slack veya Telegram webhook'una iletebiliyor.

Yazarın pratik notları: crt.sh çok sayıda sertifikası olan alan adlarında sık sık zaman aşımına uğradığından uzun zaman aşımları ve yeniden denemeler kullanın; ilk çalıştırma tüm sertifika geçmişinizi uyarı olarak işaretlediğinden, uyarıları etkinleştirmeden önce durum dosyasını bir kez hazırlayın; gerçek zamanlı kapsam isteyen ekipler certstream kütüphanesiyle CT akışlarına abone olabilir, ancak saatlik yoklama genellikle yeterlidir çünkü sahte sertifikalar dakikalar değil günler içinde sömürülme eğilimindedir.

CAA kayıtlarıyla düzenlemeyi kilitleyin

İzleme sorunları tespit eder; CAA (Certification Authority Authorization, RFC 8659) ise bunları önlemeyi amaçlar. Yazıya göre CA/Browser Forum, 2017'den beri her CA'nın sertifika düzenlemeden önce alan adının CAA kayıtlarını denetlemesini zorunlu kılıyor. Böylece bir DNS kaydı, bölgeniz için yalnızca örneğin Let's Encrypt ve Google Trust Services'ın sertifika düzenleyebileceğini, wildcard düzenlemenin tamamen yasak olduğunu ve ihlallerin bir iodef iletişim adresine bildirilmesi gerektiğini ilan edebilir. Tek bir dig +short CAA example.com komutu, bir bölgenin şu anda kısıtsız olup olmadığını, yani dünyadaki her CA'nın onun için sertifika düzenleyebileceğini gösterir.

Yazar sınırlar hakkında açık konuşuyor: bir CA tamamen ele geçirildiğinde CAA sizi kurtaramaz, çünkü imzalama anahtarına sahip bir saldırgan DNS'e danışmaz. Asıl değeri, çok daha yaygın hata biçimlerine karşıdır — hatalı alan adı doğrulaması, bir CA'ya karşı sosyal mühendislik ve alışılmadık ölçüde serbest bir otorite tarafından sertifika düzenlenmesi.

Sunduğunuz zincirleri denetleyin

Bir CA'nın iptal edildiği veya güvenilmez ilan edildiği haberi geldiğinde ilk soru, kendi sunucularınızın o zincirden sertifika sunup sunmadığıdır. Tahmin etmek yerine yazı, her ana makineye bağlanan, sunulan zinciri yaprak ve ara sertifikalara ayıran ve her birinin subject, issuer, geçerlilik süresi ve SHA-256 parmak izini yazdıran bir OpenSSL scripti sunuyor. Bu parmak izleri, tarayıcı üreticilerinin yayımladığı güvenilmez ara CA listeleriyle karşılaştırılabilir.

Yazar sık gözden kaçan bir noktayla bitiriyor: alan adınız için sahte bir sertifika mutlaka ele geçirilmiş bir CA'dan gelmez. Sık sık DNS bölgesi veya kayıt kuruluşu hesabı ele geçirilmiş ve saldırgan, tamamen meşru bir sertifika elde etmek için DNS-01 doğrulamasından sorunsuz geçmiştir. Bu yüzden son öneriler kayıt kuruluşunda iki faktörlü kimlik doğrulama, kritik alan adları için registry lock'lar ve tüm üretim alan adlarında CAA sorguları, saatlik CT izleme ve olay müdahale kitabında tutulan zincir denetim scriptini kapsayan daimi bir kontrol listesidir.

Neden önemli

Yazıda belirtildiği gibi eMudhra ilki değil ve sonuncusu da olmayacak: DigiNotar, Symantec ve TrustCor ondan önce gitti. Geliştiriciler CA'ların nasıl davrandığını kontrol edemez ama istismardan ne kadar erken haberdar olduklarını kontrol eder. CAA hatalı düzenlemeye karşı bir önleme katmanı sunar ve CT logları, önleme başarısız olduğunda bile işleyen bir tespit katmanı sağlar — saldırganın izlerinin, zarar verilmeden önce genel loglarda yayımlandığı nadir saldırı kategorilerinden biri.