dns poisoning arşivleri - Hakan Uzuner
Etiket arşivi: dns poisoning
DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması
Internet’in temel protokollerinden olan DNS üzerinde çok ciddi bir açık bulunmuştur.
Son günlerde görünürlüğü, etkisi ve alınan önlemleri açısından çokça tartışılan, Dan Kaminsky tarafından bulunan DNS protokol açığı, belli başlı ürünler için çözülmüş olmasına rağmen, açıklığı suistimal edebilecek saldırı araçlarının ortaya çıkması ve hala tüm ağ ve bilgisayar markaları tarafından çözümlerin sunulmamış olmasından dolayı, daha uzunca bir süre güvenlik açısından bir sorun olmaya devam edecek gibi görünmektedir.
DNS açıklığı bundan üç yıl önce Ian Green adlı bir SANS öğrencisi tarafından farkedilmiş olsa da, Dan Kaminsky’nin açığın pratik uygulamasını farkederek yamaların yayınlandığının açıklaması 9 Temmuz 2008 tarihine, US-CERT tarafında duyurulmasıysa 7 Temmuz 2008 tarihine denk gelmektedir. Bundan takriben bir ay öncesinden beri bilinmesine rağmen açıklık gizli tutulmuş, belli başlı üreticiler çözümlerini koordineli bir şekilde oluşturana kadar herhangi bir açıklama yapılmayarak, açıklığın genel olarak suistimali ihtimali azaltılmıştır.
Internete bağlı tüm DNS sunucularının www.bilgiguvenligi.gov.tr adresinde yayınlamış olduğumuz açıklık ve saldırıyı anlatan makaleyi inceleyerek gerekli önlemlerin alınması tavsiye edilmektedir.
Yazanlar: Bahtiyar Bircan, Can Bican
DNS açıklığı bundan üç yıl önce Ian Green1 adlı bir SANS öğrencisi tarafından farkedilmiş olsa da, Dan Kaminsky’nin açığın pratik uygulamasını farkederek yamaların yayınlandığının açıklaması 9 Temmuz 20082 tarihine, US-CERT tarafından duyurulmasıysa 7 Temmuz 20083 tarihine denk gelmektedir. Bundan takriben bir ay öncesinden beri bilinmesine rağmen açıklık gizli tutulmuş, belli başlı üreticiler çözümlerini koordineli bir şekilde oluşturana kadar herhangi bir açıklama yapılmayarak, açıklığın genel olarak suistimali ihtimali azaltılmıştır. Bu açıklığın diğer açıklıklara kıyasla farklı yöntemler kullanarak çözülmesinin en büyük nedenlerinden biri de, Internet altyapısına arz ettiği tehlikedir: “Sıfırıncı gün saldırıları”nın hemen hemen tüm DNS sunucularını etkileyeceği düşünülürse, Internet altyapısında etkili olan başlıca markalar yamalarını üretmeden açıklığın açıklanması, ancak kötü niyetli bir hareket olabilirdi.
Bu yazıda, açıklığın niteliği ve olası tesiri hakkında bilgi verilecek, örnek bir saldırı gösterilecek ve alınabilecek önlemler belirtilecektir.
DNS (Domain Name System) Internet’teki alan isimlerinin (www.tubitak.gov.tr gibi) IP adreslerine (192.140.80.201 gibi) ve IP adreslerinin alan isimlerine dönüştürülmesinden sorumludur. Bu göreviyle Internet’e bağlı herhangi bir sistemin normal çalışmasında kritik bir bileşendir. DNS protokolünün tanımı ve gerçeklenmesi RFC 1035’te4 tanımlanmıştır.
DNS kullanılmaya başladığından beri sistemlerde en sık bulunan “önbellek zehirlenmesi”, bu yazının konusu olan DNS açıklığının da saldırdığı zayıflıktır. Önbellek zehirlenmesi, bir DNS sunucusuna yetkisiz bir kaynaktan veri yüklenmesine verilen genel isimdir. Hatalı yazılımla, yapılandırma hatalarıyla ya da DNS protokolünün açıklarıyla başarıyla iletilen özgün olmayan veri, sistem performansını artırmak için saldırılan sunucunun önbelleğine gelir ve böylece önbellek “zehirlenmiş” olur. Alan adının sunucusunun IP adresinin ya da alan adının NS kaydının yönlendirilmesine dayanan değişik yöntemlerle zehirlenme mümkündür. Bir üçüncü yöntem de, gerçek alan adı sunucusu yanıt vermeden, kötü niyetli sunucunun araya girerek yanıt vermesine dayananan, man-in-the-middle (araya girmek) türünden bir saldırıyla DNS sunucusunun önbelleğinin zehirlenmesidir. Bu tür saldırılar, sorgu yapıldığında asıl yanıt vermesi beklenen DNS sunucusundan önce saldırganın yanıt vermesi esasına dayanır.
Bir DNS mesajı, header (başlık), question(soru), answer(yanıt), authority(yetki), additional(ekler) olmak üzere beş bölümden oluşur. Bunlardan konuyla ilgili olan “header” bölümünün ilk 16 biti ID olarak isimlendirilmiş bir “nonce”5 olarak tanımlıdır ve sorguyu düzenleyen program tarafından doldurulan bir alandır. Bu alan, sorguya verilen yanıta da birebir kopyalanır ve böylece soru-yanıt eşleştirmesi sağlanabilir. Araya girilerek yapılan önbellek zehirlenmesi saldırıları, bu sayının tahmin edilmesine dayanır.
Önce Ian Green’in farkettiği ve Dan Kaminsky’nin farkındalığı artırarak uygulama seviyesinde çözümleri koordine ettiği açıklık, kullandığı yöntemler ve zafiyetler açısından yeni olmamasına rağmen, olası nonce’ların azlığı, sorguların kaynak kapılarının rastgele seçilmemesi ya da yetersiz rastgelelikte seçilmesi gibi durumların bir arada araştırılması sonucunda, etkili bir yöntem bulunduğunun görülmesinden sonra açıklık olarak belirlenmiştir.
Aşağıda gösterilen örnek bir saldırı sonrasında saldırılan DNS sunucusu sorgulara hatalı yanıtlar verebilir ve kullanıcıları istedikleri sunucular yerine saldırganın istediği sunuculara aktarabilir. Bunun sonucunda web trafiği, e-posta iletileri ve diğer önemli ağ üzerinden iletilen veriler saldırganın kontrolündeki sistemlere yönlendirilebilir.
Kullanılan DNS sunucusunun açıklığının bulunup bulunmadığı Dan Kaminsky’nin sayfasından (https://www.doxpara.com/) kontrol edilebilir.
1. Saldırı öncesi keşif :
(1) 192.168.1.26 IP adresli saldırgan hedef DNS sunucu üzerinden www.ntvmsnbc.com sayfasını sorgular.
(2) DNS sunucu , www.ntvmsnbc.com alan adı kendi üzerinde olmadığı için ntvmsnbc.com alan adından sorumlu olan ns1.ntvmsnbc.com sunucusundan alan adını sorgular.
(3) ns1.ntvmsnbc.com sunucusu, www.ntvmsnbc.com alan adı için geçerli olan 88.255.82.100 IP adresini yanıt olarak hedef DNS sunucusuna döndürür.
(4) DNS sunucusu da saldırgana www.ntvmsnbc.com alan adının IP adresi olan 88.255.82.100 adresini döndürür. Burada dikkat edilmesi gereken hedef DNS sunucusunun saldırgan ile haberleşirken istek ve cevaplarda aynı kaynak portu (6134) kullanması ve tahmin edilebilir TXID (0x6749) değerini kullanmasıdır. Hedef DNS sunucusundan gelen cevabın geçerli olması için istekte bulunurken kullanılan TXID değerinin cevap kısmında da aynen dönmesi gerekmektedir.
Yapılan sorgulamanın dig çıktısı aşağıdadır. :
Bu şekilde DNS sunucuda açık olduğu tespit edildikten sonra asıl saldırıya geçiyoruz.
Saldırı 3 adımda gerçekleştirilecektir.
2.1 Birinci aşamada saldırgan hedef DNS sunucuya ntvmsnbc.com alan adına ait bir çok alt alan ismi (abc1.ntvmsnbc.com , abc2.ntvmsnbc.com ….. xyz9832.ntvmsnbc.com ) için DNS sorgusu göndermektedir. Burada amaç hedef sunucunun ntvmsnbc.com alan adı için yetkişi sunucuya birçok sorguda bulunmasını sağlamaktır.
2.2 İkinci aşamada hedef DNS sunucu tüm alt alan isimleri için ns1.ntvmsnbc.com sunucusuna istekte bulunmaktadır. Ns1.ntvmsnbc.com sunucusu da tüm alanlar için geri cevaplarda bulunmaktadır. Fakat aynı zamanda saldırgan da hedef DNS sunucuya sanki ns1.ntvmsnbc.com sunucusundan geliyormuş gibi cevaplar göndermektedir. Bu cevaplarda www.ntvmsnbc.com alan adı için IP adresini kendisi göstermektedir ve her seferinde TXID alanını arttırarak tahmin etmeye çalışmaktadır.
Nihayet abc4.ntvmsnbc.com alan adı için saldırganın gönderdiği cevap paketlerinde TXID alanı tahmin edilmekte ve hedef DNS sunucu bu cevabın gerçek ns1.ntvmsnbc.com sunucusundan geldiğini Kabul etmektedir. Bu sayede saldırgan hedef DNS sunucusunun belleğini zehirlemiş oluyor.
2.3 Üçüncü adımda kurban zehirlenen DNS sunucuna www.ntvmsnbc.com adresini sorgulamaktadır (1) . DNS sunucu da önbelleğinde www.ntvmsnbc.com adresine ait kayıt olduğu için gerçek ns1.ntvmsnbc.com sunucusuna sormadan zehirlenmiş önbelleğindeki 192.168.1.26 adresini cevap olarak vermektedir (2) . Bu durumdan habersiz kurban gerçek www.ntvmsnbc.com sayfası yerine saldırganın oluşturduğu tuzak sayfayı ziyaret etmektedir. (3)
Saldırı yapıldıktan sonraki dig çıktısı aşağıdadır.
Sistemlerde recursive(özyinelemeli) DNS sunucularının hepsinin yamanması gerekmektedir. https://www.bilgiguvenligi.gov.tr/index.php?option=com_content&task=view&id=277&Itemid=16 adresindeki TR-CERT ve https://www.kb.cert.org/vuls/id/800113 adresindeki US-CERT uyarısında etkilenen sistemler, yamaların mevcut olup olmadığı ve nasıl edinileceği üzerine bilgi bulunmaktadır. Başta ADSL modem, access point cihazları gibi gömülü sistemlerde güncellemenin donanımca mümkün olmaması ya da güncelleme imkanının bulunmaması ve bazı markaların henüz sorunun çözümünde adım atmamasından dolayı, yamanın mümkün olmadığı durumlarda, aşağıda belirtilen önlemlerin uygulanabilirliği gözden geçirilmelidir.
Yamaların uygulanamadığı durumlarda, sunuculara özyinelemeli sorgu yapacak sistemler sınırlandırılarak saldırı kaynakları azaltılabilir. Fakat bu türden bir önlemden sonra bile sorgulamaya izni olan sistemlere erişimi olan saldırganlar açıklığı kullanarak önbellek zehirlemesi saldırısı yapabilirler.
Saldırının gerçekleşmesi için IP spoofing (aldatma) tekniği kullanılması gerektiğinden, sahte IP adreslerinin filtrelenmesi gerekmektedir. Filtrelemenin ayrıntıları için önerilebilecek RFC belgeleri aşağıdadır:
https://tools.ietf.org/html/rfc2827 – RFC2827
https://tools.ietf.org/html/rfc3704 – RFC3704
https://tools.ietf.org/html/rfc3013 – RFC3013
Yerel DNS Önbelleği Kullanılması
Erişimin ve trafiğin engellenmesi gibi önlemlerle birlikte, hem istemci hem de sunucu tarafında yerel önbellekler kullanılarak, Internet üzerindeki açıklığı olan sunuculara yapılan saldırılardan yerel ağdaki kullanıcıların en az düzeyde etkilenmesi sağlanmalıdır.
Güvenilmeyen sistemlerden gelen, özyineleme gerektiren sorgular engellenmelidir.
Port Address Translation (Kapı adresi tercümesi) uygulayan cihazlar genellikle bağlantı durumunu izleyebilmek için kaynak kapı adreslerini değiştirirler. NAT/PAT uygulamasında kullanılan bazı gömülü cihazlar, saldırıya karşı önerilen kaynak kapısının rastgeleliğinin uygulama tarafında artırılmasıyla kazanılan korumayı, kapı adreslerini yeniden ve daha etkisiz bir şekilde değiştirerek azaltabilir. Bu yüzden ağ üzerindeki NAT/PAT uygulamaları gözden geçirilmelidir.
Buna rağmen, uygun bir NAT uygulaması, rastgele kapı atanmasını sağlayabilir ve yamanmamış DNS sunucuları için de bir çözüm oluşturabilir. Iptables kullanarak önerilen bir çözüm https://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html adresinde bulunabilir. OpendBSD PF kullanılarak önerilen bir çözüm de https://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html adresinde bulunabilir.
DNS trafiğinin başka bir sunucuya yönlendirilmesi
DNS açıklık bulunan sunucular yamanamıyorsa tüm sorguları yamaları uygulanmış ve açıklıkları kapatılmış başka bir sunucuya yönlendirilmesi sağlanabilir. Yaygın kullanılan Microsoft DNS ve BIND sunucuları için bu işlemin nasıl yapılacağı aşağıdaki adreslerden bakılabilir :
DNS tarafından sunulan bilgilerin güvenli hale getirilmesi için, DNS verisinin kaynağını doğrulayan, ve veri bütünlüğünü sağlayan genişletmeler içeren DNSSEC, bu ve benzeri saldırılara karşı en etkili çözüm olarak görülmekle birlikte, henüz bir standart olarak yaygınlaşmamıştır. Buna rağmen, DNSSEC kullanan iki ağ arasında güvenli veri paylaşımının ve olası saldırıların önüne geçilmesi mümkündür. DNSSEC uzantıları hakkında daha geniş bilgiye https://www.dnssec.net/ adresinden ulaşılabilir.
Internetin sağlıklı çalışması için kritik protokollerden olan DNS in uygulanmasında çok ciddi bir açıklık bulunmuştur. Bu açıklık sayesinde recursive(özyinelemeli) özelliği bulunan DNS sunucular önbellek zehirlenmesi saldırısına maruz kalabilmektedir. Bu açıklığı kullanan araçların da ortaya çıkması ile durum daha da ciddi bir hal almıştır. Başarılı bir saldırı sonrasında bu DNS sunucuları kullanan kurbanlar istekte bulundukları sayfalar yerine saldırganların belirlemiş olduğu sayfalara yönlendirilebilmektedirler. Açıklık kapatılması için yaygın yazılım üreticileri tarafından çıkartılan yamaların uygulanması tavsiye edilmektedir. Yamalar uygulanamiyorsa veya yama mevcut değilse bu sunuculara erişimin kısıtlanması , yerel (internetten doğrudan ulaşılamayan ) DNS önbelleğinin kullanılması , DNS sunucuları önüne saldırıyı kesebilecek Linux Iptables veya OpenBSD PF yerleştirilmesi veya tüm trafiğin yamanmış, açıklığı olmayan bir sunucuya yönlendirilmesi tavsiye edilmektedir.
Güvenlik içinde DNS, DNS Önbellek Zehirlenmesi, dns poisoning, dns zehirleme etiketleriyle 04 Ağustos 2008 tarihinde Hakan Uzuner tarafınadan gönderildi.
Microsoft Azure (114)
Azure AD Connect Sync PowerShell Komutu
SimpliVity OmniCube Available Physical Capacity 20 Percent or Less – HPE SimpliVity Eski Yedekleri Nasıl Silerim?
1 Soru 1 Cevap: Exchange Server Mailbox Audit Log Hakkında