Syslogs » DNS Cache Poisoning

Ana Sayfa » Security » DNS Cache Poisoning

19 Ağustos 2008 tarihinde Çağrı Ersen tarafından yayınlandı. | | Translate to English

DNS Cache Poisoning

(Henüz Puan Verilmedi. Oy kullanarak siz de katkı yapabilirsiniz.)

Warning: mysqli_query(): (HY000/3): Error writing file '/tmp/MYzZ5tKc' (Errcode: 28 - No space left on device) in /usr/share/nginx/html/syslogs/wp-includes/class-wpdb.php on line 2349

Geçenlerde, Huzeyfe Önal'ın bloğunda yeni yayınlanan bir güvenlik açığının haberini okudum ve ilgimi çektiğinden dolayı teknik detayları öğrenmek için biraz araştırdım. Hazır okumuş ve teknik detaylar konusunda fikir edinmişken paylaşmak istedim.

DNS cache poisoning olarak geçen bu zafiyet önlem alınmamış DNS serverları kolayca etkileyebilecek türden bir açık. Bu nedenle önemsenmesi ve gerekli güvenlik önlemlerinin alınması gerekiyor.

Ne gibi önlemler alınabileceğinden önce, bu zafiyetin tam olarak ne olduğu ve nasıl yapıldığına değinmek istiyorum. Zira, bir dns serverınız varsa ve gerekli önlemleri almamışsanız bu zafiyetten etkilenebilir ve dns serverınızı kullanan kişilere yanlış sorgu sonuçları dönmesine neden olabilirsiniz. İşte konunun teknik detayları:

DNS Cache Poisoning olarak adlandırılan bu zafiyet aslında ilk olarak 1993 yılında keşfedilmiş bir açık; geçenlerde yayınlanmış olanı ise yeni bir versiyonu. Geçenlerde yayınlanan veryion ile ilgili US-CERT sayfasına aşağıda belirtilen kaynakça bölümünden erişebilirsiniz.

Konunun teknik detaylarını teorik olarak sadece yazmak aslında pek de açıklayıcı olmuyor; bu nedenle okuduğum pek çok kaynakta da izlendiği üzere örnekler üzerinden anlatma yolu, zafiyetin teknik detaylarını kavramak için epey yararlı olacaktır.

Malum bir dns sorgusu yaptığınız zaman, DNS serverınız -eğer recursive sorgulara izin veriyorsa- ilgili alan adına ait kayıdın kendi üzerinde tanımlı olup olmadığına bakar ve kendi üzerinde bulunan bir kayıt olmaması durumunda kök dns sunucularına bir sorgu göndererek alan adını temsil eden dns sunucusuna ait ipyi alır ve daha sonra bu sunucuya ilgili alan adı için bir query daha gönderir; en sonunda da aldığı cevabı size iletir. Örnekte anlatılan query çeşidi recursivedir ve kendi üzerinde bulunmayan kayıtların cevaplarını sizin yerinize gidip ilgili sunucudan alır.

Zafiyeti anlatan http://www.avertlabs.com/research/blog/index.php/2008/07/23/the-cat-is-out-of-the-bag-dns-bug/ adresinde yayınlanan güzel bir grafik var; daha iyi anlamak için faydalı olacaktır:

Recursive dns query'lerde izlenen yol grafikte anlatıldığı gibidir. Ek bilgi olması açısından non-recursive querylere de değinmek iyi olur. Non-recursive diye tabir edilen query çeşidinde, eğer bir kayıt sorguyu gönderdiğiniz dns sunucuda yoksa gene kök sunucuya danışıp ilgili alan adına ait DNS serverın ipsini alır ve size “Bu alan adına ait kayıtlar bende değil ama kayıtları tutan dns'in ip adresi şudur, gidip ona sor” mealinde bir cevap gönderir; sizin clientiniz de ilgili ip'ye queryi tekrar göndererek cevabı alır. Bu noktada, non-recursive sorgular için dns serverınız etliye sütlüye pek karışmadığından dolayı zafiyetten etkilenme durumu olmaz. Zaten zafiyetten etkilenmemek için alınması gereken önlemlerden birisi de bu recursive sorgulara izin vermemek olarak geçiyor.

Konuyu çok fazla dağıtmadan cache poisoning'e dönelim. Yukarıdaki örnekte yapılan sorgu işleminden bahsederken söylemediğim bir durum daha var; örneğin www.cnn.com için recursive olarak bir query gönderdiğiniz zaman dns sunucunuz bu alan adına ait ip bilgisini gidip bularak size getiriyor ve bu bilgiyi bir müddetliğine saklamak üzere cache'ine alıyor. Böylece başka biri daha www.cnn.com için sorgu gönderdiği zaman aynı işlemleri tekrarlamak zorunda kalmıyor. İşte poisoning işleminin yapıldığı nokta burası.

Eğer siz www.cnn.com için recursive bir sorgu gönderdiğiniz zaman birisi, dns serverınız ve cnn.com'un dns serverının arasına girip, cnn.com dns'inden gelmesi gereken cevabı kendisi -yanlış ip içerir bir şekilde- göndermeyi başarırsa, dns serverınızın cacheini zehirlemiş olur. Bu durumda da siz ve dns serverınızı kullanan sizin gibi diğer tüm kişileri de istediği herhangi başka bir yere yönlendirme şansına sahip olur. İşte dns cache poisoning kısaca böyle yapılmaktadır.

Atakta bulunan kişilerin bu işlemi pratikte nasıl yaptıklarıyla ilgili detaylara değinmeden teroik olarak bilgi vereceğim. Zira ben de nasıl yapıldığını denemiş bir kişi değilim. Ancak saldırıdan korunmak için saldırının nasıl yapıldığı hakkında temel olarak bilgi edinmek fena olmaz.

Normal bir dns querysinde karşı tarafa gönderilen request paketi, “source ip”, “source port”, “destination ip”, “destination port”, “transaction ID” ve “question” bilgilerini içerir. Kısaca, eğer bir saldırgan, DNS serverınızdan çıkan bir request paketinin Transaction ID'sini ve Source Port'nu tahmin edebilirse, muhattap olduğunuz DNS serverdan gelmesi gereken response paketini taklit edip DNS Serverınıza yanlış cevap döndürebilir. Çünkü DNS Serverınız gönderdiği bir request'in cevabı olarak gelen paketi onaylamak için gelen response paketinin destination port'unun request paketinde belirtilen source port ile aynı olup olmadığına ve gelen Transaction ID'nin request paketindeki Transaction ID ile match edip etmediğine bakar. Eğer bu match işlemi doğrulanırsa DNS Server gelen paketin, gerçekten muhattap DNS sunucusunda geldiğini onaylar ve Cache'ine yazar, sonrasında da cliente gönderir.

Yukarıdaki cnn.com örneği üzerinden tekrar düşündüğümüz zaman konuyu daha iyi anlayabiliriz.

Cnn.com'un ip adresini öğrenmek için client pc'nizden (bundan sonra CP -Client PC- diyeceğim) recurvise sorgulara izin veren DNS serverınıza (bundan sonra CD -Client DNS- diyeceğim) bir request gönderdiniz. CD bu domainin kendi üzerinde tanımlı olup olmadığına bakıyor; haliyle tanımlı bir domain olmadığından ve cevabı bilmediğinden dolayı .com kök sunucusuna bu domaine ait kayıtları tutan DNS serverın ( bundan sonra AD -Authoritative DNS – diyeceğim) ip'sini aliyor; şimdi CD, AD'in ipsini bildiğine göre www.cnn.com'un IP adresini söylemesi için AD'ye, bir request paketi gönderiyor. Saldırı tam bu noktada gerçekleştirildiği için gönderilen paketin ve gelecek paketin içeriğinden olması gerekenleri daha da detaylandırmak iyi olur.

Mesela, Client DNS olarak tabir ettiğimiz DNS serverınızın IP'si 192.168.1.254 ve AD olarak tabir ettiğimiz cnn.com dns serverının IP'si ise 149.174.213.151 olsun. Bu durumda CD'den AD'ye gidecek request paketinin içeriği örneğin aşağıdaki olacak.

“Source IP = 192.168.1.254, Source Port =28912, Destination IP = 149.174.213.151, Destination Port = 53, Transaction ID = 29290, Question = www.cnn.com'un ip adresi nedir ?”

İçeriği yukarıdaki gibi olan udp request paketi CD'den AD'ye gönderildi ve AD'den response paketinin gelmesi bekleniyor. Normalde AD'den gelecek response paketinin içeriği ise şu olmalı;

“Source IP = 149.174.213.151, Source Port = 53, Destination IP = 192.168.1.254, Destination Port = 28912, Transaction ID = 29290, Answer = 64.236.91.21″

Örnekte görüldüğü gibi AD'de gelen paket içerisinde bulunan Destination Port, CD'nin gönderdiği paketteki Source Port ile örtüşüyor. Ayrıca her iki pakette de Transaction ID aynı. Bu durumda CD bu cevabın yetkili DNS serverdan geldiğini düşünecek ve aldığı cevabı -daha sonra aynı işlemi bir daha yapmamak için- Cache'ine yazacak ve CP'ye gönderecektir. Bu örnekte giden gelen paketlerin içerikleri ve eşleşen verilen ile ilgili aşağıdaki gibi güzel bir şema var.

Saldırıda bulunmak isteyen bir kişi yukarıdaki response paketini taklit etmek isterse ve response paketinin Destination Port'unu (yani request paketinin Source Port'u) ve Transaction ID'sini tahmin etmesi gerekecektir. Geri kalan verileri bilmesi için tahminde bulunmasına gerek yok. Zira, doğal olarak CD ve AD'nin IP'lerini biliyor olacaktır. Ayrıca response paketinin Source Port'u olan 53, genel olarak kullanılan DNS portu olduğundan bunu da bilmesi için fazla çaba harcamasına gerek yoktur. Diyelim ki saldırgan bir şekilde Transaction ID'yi ve request paketinin source portunu tahmin etti. Bu durumda AD'den önce davranıp aynı paketi yanlış answer içerecek şekilde dns serverınıza gönderebilir. Böylece Cache Poisoning saldırısını gerçekleştirmiş olur. Aşağıdaki şema, bu spoof edilmiş response paketinin CD'ye nasıl gönderildiğini göstermektedir.

Transaction ID ve Source Port'unun nasıl tahmin edilebileceğine gelince. Dediğim gibi teknik olarak nasıl yapıldığını hiç denemedim ancak Transaction ID maksimum 16 bitlik bir field içerdiği için bir saldırganın doğru ID'yi tahmin etmesi için astronomik miktarlarda denemeler yapmasına gerek yok; çeşitli metodlar kullanılarak bir kaç bin denemede sonuca ulaşmanın mümkün olduğu pek çok kaynakta anlatılmaktadır . Aynı şekilde request paketinde belirtilen source port'un tahmin edilmesi de özellikle kullanılan DNS server ile alakalı olarak çok ter dökülmeden gerçekleştirilebilen bir durum.

Son olarak, bu atağın kurbanı olmamak için DNS Serverınızın patchlerini geçmeniz yararınızadır. Ayrıca Local DNS cache kullanabilir, recursion sorgulamalara izin vermeyebilirsiniz. Bunun dışında DNS serverınızın kullandığı source portu randomize etmek için giden dns querylerinin source portunu firewall'dan NAT'layabilirsiniz Detaylı bilgi için aşağıdaki linklerden yararlanabilirsiniz.