ASP.NET Oracle Padding Vulnerability

Yazı, http://blogs.microsoft.co.il/blogs/linqed/archive/2010/09/19/padding-oracle-asp-net-vulnerability-explanation.aspx adresindeki açıklamalar üzerine bina edilmiştir.

"Padding Oracle" açıklığı, Eylül 2010 gibi bulundu.

Terimler:
Çok kabaca anlatılacak olursa, kriptolama (encryption) algoritmaları, data blokları (genelde her blokta 8 ya da 16 byte) üzerinde çalışırlar. Geri kalan bytelar ise "padded", yani doldurulmuş/şişirilmiştir. Mesela 5 harfli "ahmet" kelimesi, 8 byte'lık bir bloğa tamamlanmak üzere 3 byte ile doldurulur.

"Oracle", şifreleme (kriptolojide şifreleme, encription veya decryption işlemleri sırasında kullanılan algoritma olarak kullanılır) içinde bir mekanizmadır; verilen şifre metininin (cyphertext) geçerli olup olmadığı (valid or invalid) cevabını verme kabiliyetine sahiptir. Buradan şu tarife ulaşılabilir: "Padding Oracle" verilen şifre metininin dolduruluşunun geçerli olup olmadığı cevabını verme yeteneğine sahip bir mekanizmadır. Yani konunun Oracle veritabanı yönetim sistemi ile uzaktan yaqkından bir alakası yoktur.

Yine kabaca anatılacak olursa, basit geçerli/geçersiz cevabı, güvenlik araştırmacılarına, "CBC-Mode with PKSC#5 padding" (takılmayalım) ile encrypt edilmiş neredeyse tüm şifre metinlerini decrypt edebilecek bir algoritma oluşturma izni vermiştir; encryption kombinasyonlarını (passphrase) bilmedikleri halde. Bu durum, kaba kuvvet saldırılarına benzemektedir, ancak çok daha az deneme yaparak, dakikalar içinde çözüme ulaşılabilmektedir. Saldıran uygulama her seferinde şifre metininden 1 byte değiştirerek Oracle'a gönderir ve "geçerli mi" diye sorar, ta ki o byte decrypt edilene kadar.

Olayın boyutlarını görmek açısından şu video izlenmeli: http://www.youtube.com/watch?v=yghiC_U2RaM

Padding Oracle, ASP.NET ile nasıl ilişkili?
Şifreler (encrypt algoritmaları), .Net framework içinde gömülüdür; geçersiz bir doldurma (padding) işleminde "Padding is invalid and cannot be removed" mesajı ile birlikte "System.Security.Cryptography.CryptographicException" fırlatılır.

Kriptolanmış bir takım hassas veriyi cookie içinde saklayan bir uygulama düşünelim. Saldırgan, şifre metni içeren bu cookie'yi okuyabilir ve byte'ları ile oynayarak simüle ettiği talepleri, değiştirdiği cookie ile birlikte sunucuya gönderir. Sonra dönen yanıtları analiz eder ve hangi yanıtın "geçerli" hangisinin "geçersiz" anlamına geldiği kararını vermeye çalışır (Bu noktada saldırının ne olduğunun anlaşılmaya başlaması umulur).

Bu açıklık sadece ASP.NET'te mi var?
Tabi ki hayır. Bu açıklık ilk olarak JSF framework'ü üzerinde tespit edilmiştir. Ayrıca geçersiz şifrelerde exception fırlatan Java'da da bu açıklık vardır.

Saldırının Etkileri:
Bu açıklığı kullanarak saldırgan, ASP.NET tarafından istemciye gönderilen kriptolanmış tüm hassas veriyi çözebilir / decrypt edebilir: cookie'ler, ViewState, URL cümleleri, gizli alanlar vs. Daha sonra saldırgan, kriptolama (encryption) kombinasyonlarını (passphrase) bulabilir, kriptolanmış veriyi değiştirerek sunucuya gönderebilir. Mesela saldırgan, kendisini sisteme sistem yöneticisi gibi tanıtabilir.

Ayrıca, web.config dosyasının indirilebilme yeteneğini de düşünmek gerekir. TODO: Bunun nasıl olabileceği hakkında detaylı araştırma yapmakta fayda var. Acunetix de açıklığın bu yönü üzerinde durmuş.

Engelleme adına yapılabilecekler:
Herşeyden önce, hassas verileri istemci tarafında tutmamak (cookie, ViewState, gizli alan vs) şiddetle tavsiye edilir.

http://www.owasp.org/index.php/ASP.NET_POET_Vulnerability adresinde tavsiye edilen ve edilmeyen çözüm / engelleme yolları sıralanmış. Buna göre tavsiye edilen çözüm önerisi, Microsoft tarafından yayınlanan official yama: http://www.microsoft.com/technet/security/advisory/2416728.mspx