.NET 10 Data Protection Güvenlik Açığı ve Acil Yama
Geçen hafta bir müşteriden gece yarısı telefon geldi. “Uygulamalar decrypt edemiyor, cookie’ler çözülmüyor, kullanıcılar sürekli oturumdan atılıyor.” İlk aklıma sertifika tarafı geldi, ya da key ring rotasyonu; hani klasik Data Protection derdi. Ama değilmiş. Meğer.NET 10.0.6 ile gelen bir regresyon, ASP.NET Core Data Protection katmanını sessizce bozmuş, üstelik işin garibi bu kırılma bir güvenlik açığını da ortaya çıkarmış.
📋 İçindekiler
-
Ben olsam şöyle giderdim: önce key ring’e erişen tüm servislerin listesini çıkarırım. Sonra downstream’den upstream’e doğru tek tek güncellerim, yanı zinciri tersinden yürütürüm; monitöring’i açık bırakır, decrypt hatalarını izlerim, bir yerde sapma görürsem de hemen frene basarım. Genelde bir saat içinde fleet toparlanıyor.
Küçük ekipseniz fazla kasmayın — tek bir
dotnet publish, üstüne Azure App Service’e deploy, olay kapanıyor (eh, fena değil). Hani şu Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor yazımda anlattığım otomatik tarama pipeline’ı var ya, işte tam böyle durumlarda baya iş görüyor; insanın elini kolunu boş yere yormuyor.Bu Olay Bize Ne Öğretiyor?
Bakın, Açık konuşayım: bu tarz hatalar her yazılımda çıkabiliyor. Microsoft’ta da oluyor, açık kaynak tarafta da (evet, doğru duydunuz). Mesele hata değil; asıl mesele, iş patladığında nasıl toparladığınız. Bu olayda Microsoft’un refleksi fena değildi, çünkü aspnetcore issue #66335 açıldıktan kısa süre sonra sorun ayıklandı. OOB güncelleme de çıktı.
Bence, Yine de içimde bir ukde kaldı. Bu bug.NET 10.0.0’dan beri vardı, yanı GA çıktığı günden beri oradaydı; altı küsur sürüm boyunca kimse yakalayamadı. HMAC doğrulaması kâğıt üstünde var gibi dururken pratikte çalışmayan bir kod production’da aylarca yaşamış öldü. İşte tam burada kriptografik kod için yazılan birim testlerinin neden bu kadar önemli olduğunu tekrar görüyorsunuz.
Bence doğru tarafa gidiliyor, evet. Microsoft’un şeffaf davranması, CVE yayımlaması. OOB güncelleme çıkarması gayet yerinde; ama managed encryptor katmanında daha sert integration test’ler hâlâ eksik dürüyor, hatta ben olsam bunun yanına biraz fuzzing de koyarım (çünkü bazen düzenli testler gözden kaçırıyor). Sız ne dersiniz?
Ha, bunu söylemeden geçmeyeyim..NET 11 Preview sürümlerini takip edenler için küçük bir not var; .NET 11 Preview 3: Gelen Yenilikler ve Sahadan Notlar yazımda anlattığım değişikliklerin içinde Data Protection tarafında da iyileştirmeler bulunuyor ve açıkçası.NET 11’de bu tip bir sorunun tekrar etme ihtimali daha düşük görünüyor.
Pratik Aksiyon Planı
Neyse, lafı uzatmadan gidelim: önce envanteri çıkarın, çünkü ortada ne var bilmiyorsanız sonraki adım biraz kör dövüşüne dönüyor. Hangi uygulama.NET 10 kullanıyor, hangisinde Data Protection açık, hangisi sadece kenardan bakıyor; bunları netleştirin (buna dikkat edin)
- Envanter çıkarın: Hangi uygulamalarınız.NET 10 kullanıyor? Hangilerinde Data Protection aktif?
- Sürüm kontrolü:
dotnet --infoçalıştırın. 10.0.7’nın altındaysanız etkilenisiniz. (bence en önemlisi) - Güncelleme: SDK veya en azından NuGet paketini 10.0.7’ye çekin.
- Test: Decrypt işlemlerinin düzgün çalıştığını doğrulayın. Bilhassa de 10.0.6 döneminde üretilen şifreli verilerin çözülebildiğinden emin olun. (bence en önemlisi)
- Deploy: Staging’de test ettikten sonra production’a alın. — bunu es geçmeyin
- Monitör: İlk 24 saat boyunca uygulama loglarında Data Protection ile ilgili exception’ları takip edin.
Sürüm tarafında da iş aslında basit, ama küçük bir detay var:
dotnet --infoçıktısına bakıp geçmeyin, gerçekten hangi SDK’nın devreye girdiğini anlayın; yoksa “bende sorun yoktu” deyip sonra gece yarısı loglara dalarsınız.Evet. Bitti gibi görünüyor ama değil; önce test etmeden production’a çıkmayın, özellikle de 10.0.6 döneminde oluşmuş şifreli veriler varsa, onların çözülüp çözülmediğini tek tek görün. Sonra staging’de deneyin, ardından canlıya alın ve ilk 24 saatte exception avına çıkın.
Ciddi bir iş bu. Ama çözümü de göz korkutmuyor; ertelemeyin yeter.
Sıkça Sorulan Sorular
CVE-2026-40372 ne, ve uygulamam için ne kadar tehlikeli?
Bu zafiyet, aslında ASP.NET Core Data Protection’daki HMAC doğrulamasının hatalı çalışmasından kaynaklanıyor. Yanı saldırgan şifreli veriyi manipüle ederek yetki yükseltme (elevation of privilege) yapabiliyor — itiraf edeyim, beklentimin üstündeydi —. Bence ciddiye alınması gereken bir açık — eğer.NET 10 kullanıyorsanız. Kullanıcı oturumu, cookie veya anti-forgery token gibi işlemler yapıyorsanız, hemen ilgilenin (ciddiyim)
.NET 9 veya.NET 8 kullananlar da etkileniyor mu?
Bakın, Hayır. Zafiyet sadece Microsoft.AspNetCore.DataProtection paketinin 10.0.0 ile 10.0.6 arasındaki sürümlerini etkiliyor..NET 9 ve öncesinde farklı bir managed encryptor implementasyonu kullanılıyor, yanı o tarafta sorun yok.
Güncelleme yaparsam mevcut oturumlar düşer mi?
Hayır, mevcut Data Protection key ring’ınız geçerliliğini koruyor. Üstelik tecrübeme göre bu tür güncellemeler genellikle oturumları etkilemiyor — hatta 10.0.6’da yaşanan decrypt hataları da 10.0.7 ile düzeliyor. Yanı güncelleme sonrası daha az sorunla karşılaşırsınız, daha fazla değil.
Out-of-band (OOB) güncelleme ne demek?
İnanın, Microsoft normalde güvenlik yamalarını ayın ikinci Salı günü yayınlıyor, hani bilinen Patch Tuesday takvimi. Ama açıkçası bazen bu takvim beklenemeyecek kadar kritik bir zafiyet çıkıyor. İşte o zaman Microsoft takvimi es geçip acil güncelleme çıkarıyor — buna out-of-band deniyor. OOB görüyorsanız, “ciddi bir şeyler var, hemen güncelle” diye okuyun.
Container ortamında ne yapmalıyım?
Base image’ınızı
mcr.microsoft.com/dotnet/aspnet:10.0.7olarak güncelleyin, image’ları rebuild edip deploy edin. Rolling deployment yapıyorsanız tüm pod’ların yeni image ile ayağa kalktığından emin olun — yarım yamalak bir geçiş istemezsiniz.Kaynaklar ve İleri Okuma
.NET 10.0.7 Out-of-Band Security Update —.NET Blog
aspnetcore issue #66335 — Decryption Regression Report
ASP.NET Core Data Protection — Microsoft Learn Resmî Dokümantasyonu (ki bu çoğu kişinin gözünden kaçıyor)
Cem A.
Tam da production’da .NET 10’a geçmeyi düşünüyordum, iyi ki beklemişim. Cookie’lerin çözülememesi demek tüm kullanıcıların oturumdan atılması demek, bunu canlıda yaşamak gerçekten felaket olurdu. CVE numarası da cabası, Microsoft bu yamayı ne kadar sürede çıkardı?
Cenk B.
Tam da production’da .NET 10’a geçmeyi düşünüyordum, iyi ki beklemişim. Cookie’lerin çözülememesi demek tüm kullanıcıların oturumdan atılması demek, bu ciddi bir şey. CVE numarasına bakılırsa yetki yükseltme kısmı daha da endişe verici, yamayı beklemeden geçmemek lazım.
Yorumlar kapalı.







2 comments