Anonymous Blackout DDoS Operasyonunun Teknik Detayları

Günlerdir internet durdurulabilir mi durdurulamaz mı, durdurulabilirse etkileri neler olur tartışmaları sürüyor. Interneti durdurmak için kullanılacak yöntem de internet’in omurgasında yer alan root DNS sunucuların hizmet veremez hale getirilmesi olarak belirlenmiş. Benzeri amaçlı saldırılar 2002 ve 2007 yıllarında yaşanmıştı. 2002 yılında büyük oranda dünyanın internet trafiği etkilenmiş olsa da 2007 yılında ciddi bir etkilenme olmamıştı (DNS Anycast’de geçildiği için).

Ünlü hacker grubu Anonymous 31 Mart’da dünyadaki çeşitli olayları protesto etmek için Internet’i durdurmak için saldırı gerçekleştireceğini açıkladı. Saldırı nedeni ve teknik olmayan detaylar için http://pastebin.com/NKbnh8q8 adresi incelebilir.

Saldırının adı Reflective DNS Amplification DDoS olarak geçiyor. Saldırıda saldırganların ip adresleri hedefe hiçbir paket göndermiyor. Bunun yerine internetde genel sorgulamaya açık DNS sunucuları kullanılarak sahte DNS paketleriyle tüm saldırılar ara DNS sunuculardan geliyormuş gibi gözüküyor.

Teknik olarak bu saldırı tipinin interneti durdurması günümüzde kullanılan Ayncast DNS altyapısından dolayı mümkün değil fakat saldırganların farklı ülkelerden ve belirli sayının üzerinde olması durumunda gerçekten böyle bir felaket yaşanabilir. Söz konusu saldırı tipi DDoS olunca teknik bilginin bir sınırı oluyor. Read more »

Genele Açık DNS Sunucuların Bulunması

Herkese açık DNS sunucular(public dns) kendisine gelen tüm istekleri cevaplamaya çalışan türde bir dns sunucu tipidir. Bu tip dns sunucular eğer gerçekten amacı genele hizmet vermek değilse genellikle eksik/yanlış yapılandırmanın sonucu ortaya çıkar.

Bir sunucunun genele açık hizmet(recursive DNS çözücü) verip vermediğini anlamanın en kolay yolu o DNS sunucusu üzerinden google.com, yahoo.com gibi o DNS sunucuda tutulmayan alan adlarını sorgulamaktır.

Eğer hedef DNS sunucu genele açık bir DNS sunucu olarak yapılandırıldıysa aşağıdakine benzer çıktı verecektir. Read more »

Güvenliği ciddiye alıyor musunuz? Bind DOS Zaafiyeti

Yaklaşık olarak üç ay önce tüm ISC Bind sürümlerini etkileyen bir açıklık yayınlandı.  Açıklık DNS servisini etkilediği için çok kritikti( dns’in çalismamasi ne demek? Mail alisverisinin durmasi, web sayfalarinin çalismamasi, ISP’ler için müsterilerinin internetinin gitmesi(müsteri için dns vs yoktur internet çalisiyor ya da çalismiyordur).

Bu açıklığa göre internetin %80 gibi büyük bir oranına dns hizmeti sağlayan Bind yazılımı kullananların verdikleri dns hizmeti  uzaktan tek bir dns paketiyle kapatılabiliyordu. Açıklığın çıktığı tarihlerde -tam da Türkiye’de 3G hizmetinin duyurulduğu gün- çoğu arkadaşımı bizzat arayarak sistemlerini yamalarını sağlamıştım. Kendi yöneticilerimize de konunun ciddiyetini anlatmak için exploiti düzenleyerek(uzaktan kimin gönderdiği belli olmayacak şekilde spoof ip ile) kendi sistemlerimizde test amaçlı çalıştırmıştık. Read more »

BIND 9 Dynamic Update DoS Zaafiyeti- Acil

Internetin Sonu mu geldi?

Internetin çalışması için gerekli en temel protokollerden birisi DNS’dir. DNS domain isimleriyle ip adresleri arasında çözümleme yaparak bizleri ulaşmak istediğimiz sitelere/sistemlere kolaylıkla ulaştırır. Bir nevi arkadaşlarımızın cep telefon numaralarını ezberlemek yerine adres defteri kullanmak gibi.

DNS çalışmadığı zaman ne olur?

E-posta sistemi çalışmaz, web sayfalarına isimlerini kullanarak (www.google.com gibi )girişler imkansız hale gelir, kısacası internet durur.

DNS Sunucu Yazılımları

DNS hizmeti veren çeşitli sunucu yazılımlar bulunmaktadır. ISC Bind, DjbDNS, Maradns, Microsoft DNS yazılımları bunlara örnektir. Bu yazılımlar arasında en yoğun kullanıma sahip olanı ISC Bind’dır. Internetin %80 lik gibi büyük bir kısmı Bind dns yazılımı kullanmaktadır.

DOS  Atakları

DOS(Denial Of Service) hizmet dışı bırakma saldırısıdır. Bir servis DOS’a maruz kalırsa çalışmaz, bir network DOS’a maruz kalırsa ulaşılamaz. DOS saldırıları risk açısından  sınıflandırıldığında acil kategorisinde yer alır.

BIND 9 Dynamic Update DoS Zaafiyeti

28/07/2009 tarihinde ISC Bind yazılım geliştiricileri tüm Bind 9 sürümlerini etkileyen acil bir güvenlik zaafiyeti duyurdular. Duyuruya göre eğer DNS sunucunuz Bind9 çalıştırıyorsa ve üzerinde  en az bir tane yetkili kayıt varsa bu açıklıktan etkileniyor demektir.

Aslında bu bind 9 çalıştıran tüm dns sunucularını etkiler anlamına geliyor. Bunun nedeni dns sunucunuz sadece caching yapıyorsa bile üzerinde localhost için girilmiş kayıtlar bulunacaktır ve açıklık bu kayıtları değerlendirerek sisteminizi devre dışı bırakabilir.

Güvenlik Açığı Nasıl Çalışıyor?

Açıklık dns sunucunuzdaki  ilgili zone tanımı(mesela:www.lifeoverip.net) için gönderilen özel hazırlanmış dynamic dns update paketlerini düzgün işleyememesinden kaynaklanıyor.

Açıklığın sonucu olarak dns servisi veren named prosesi duruyor. Yani DNS hizmeti veremez hale geliyorsunuz.

Önlem:

Güncelleme: Açıklığı gideren yeni sürüm bind paketleri yayınlandı. Güncelleme yaparak bu açıklıktan korunabilirsiniz.Aşağıdaki adresler güncel bind paketlerine ait.

http://ftp.isc.org/isc/bind9/9.6.1-P1/bind-9.6.1-P1.tar.gz

http://ftp.isc.org/isc/bind9/9.5.1-P3/bind-9.5.1-P3.tar.gz

http://ftp.isc.org/isc/bind9/9.4.3-P3/bind-9.4.3-P3.tar.gz

Güvenlik Duvarı/IPS: Güvenlik duvarı ya da Intrusion Prevention System üzerinden dns sunucularıan gelen nsupdate mesajlarını engelleyerek açıktan korunabilirsiniz.

Snort IDS İmzası:

alert udp any any -> $HOME_NET 53 (msg:"ET CURRENT_EVENTS ISC BIND9 Update DoS"; \
content:"|00 2a 08 68 6d 61 63 2d 6d 64 35 07 73 69 67 2d 61 6c 67 03 72 65 67 03 69 6e 74 00|"; \
content:"|35 99 52 00 4e|"; classtype:misc-attack; reference:url,downloads.securityfocus.com/vulnerabilities/exploits/35848.txt; reference:url,www.isc.org/node/474; sid:2009695; rev:1;)

Linux Iptables ile engelleme: Aşağıda yazan iptables kuralı ile açıklığı network seviyesinde engelleyebilirsiniz(kural denenmemiştir, debian tartışma listesinden alıntıdır).

#iptables -A INPUT -p udp –dport 53 -j DROP -m u32 –u32 ’30>>27&0xF=5′

Kötü senaryo: DNS UDP üzerinden çalışıyor, bu açıklığın exploiti de internette dolaşıyor. Hayata küsmüş kötü niyetli bir hacker internetin çalışmasını  birkaç yüz paketle sekteye uğratabilir ve dns paketlerinde rahatlıkla ip spoofing yapılabileceği için kimin yaptığı da bulunamaz.

Açıklık ile ilgili detay bilgiler: https://www.isc.org/node/474

Açıklığın testi;

Açıklığın testi için internet ortamında çeşitli exploitler dolaşıyor. Exploitlerden birinini kendi sistemlerimi test için uyarlayıp denedim, bir iki saniye içerisinde dns servisi crash oldu.

# perl dnstest.pl
;; HEADER SECTION
;; id = 51444
;; qr = 0    opcode = UPDATE    rcode = NOERROR
;; zocount = 0  prcount = 1  upcount = 1  adcount = 1

;; ZONE SECTION (1 record)
;; test.com.        IN      SOA

;; PREREQUISITE SECTION (1 record)
www.test.com.       0       IN      ANY     ; no data

;; UPDATE SECTION (1 record)
www.test.com.       0       ANY     ANY     ; no data

;; ADDITIONAL SECTION (1 record)
<key.   0       IN      ANY     ; rdlength = 0

Bu aşamadan sonra ilgili zonu barındıran dns sunucu sorgulara cevap veremez hale geliyor.

Aug  1 16:03:52 mail named[45293]: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:595: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Aug  1 16:03:52 mail named[45293]: exiting (due to assertion failure)
Aug  1 16:03:52 mail kernel: pid 45293 (named), uid 0: exited on signal 6 (core dumped)

DNS protokolunde sorun giderme – dig

Dig, nslookup ve host gibi dns sorgulama araçları yerine kullanılabilen gelişmiş bir araçtır. ISC tarafından geliştirilen BIND DNS sunucusu ile birlikte geliştirilir  ve uzun vadede Linux dağıtımlarında nslookup komutunun yerini alması beklenmektedir.  Dig komutu domains sorgulama için çalıştırıldığında  cevapla birlikte detay bilgiler de döner.

Bu detay bilgiler ek parametrelerle gizlenebilir.

# dig www.lifeoverip.net

; <<>> DiG 9.3.3 <<>> www.lifeoverip.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47172
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.lifeoverip.net.            IN      A

;; ANSWER SECTION:
www.lifeoverip.net.     14400   IN      A       80.93.212.86

;; AUTHORITY SECTION:
lifeoverip.net.         30637   IN      NS      ns3.tekrom.com.
lifeoverip.net.         30637   IN      NS      ns4.tekrom.com.

;; ADDITIONAL SECTION:
ns4.tekrom.com.         91164   IN      A       70.84.223.227
ns3.tekrom.com.         165971  IN      A       70.84.223.226

;; Query time: 213 msec
;; SERVER: 195.175.39.40#53(195.175.39.40)
;; WHEN: Sat Jan 24 10:56:14 2009
;; MSG SIZE  rcvd: 130

Çıktıların Detay açıklaması Read more »

Nmap NSE kullanarak DNS Cache Poisoning Zafiyeti Testleri

Bir önceki blog girdisinde NSE’in faydalarından ve basit kullanımından bahsetmiştim. Şimdi de çeşitli NSE scriptlerini kullanarak manuel ya da scriptlerle yaptığımız işleri Nmap’e nasıl havale edeceğimize bakalım. Ilk test sistemlerin DNS cache poisoning’e açık olup olmadığını test etmek. Bugün yaptığım bazı testler sonrası bu konunun oldukça önemli olduğunu anladım. Hatta derdimi anlatacak birileri bulsam tüm Türkiye’nin ip aralığını alıp bu testten gerçirmek isterdim ama arada bir arıza çıkar da sen bizim networkümüzü hangi hakla tararsın(Taramak? DNS sunucusuna çeşitli istekler göndermek illegal mıdır?) diye söylenir diye bu fikrimden şimdilik vazgeçtim.

İçinde birden fazla DNS sunucu barındıranların kendi sistemlerini test etmeleri için buraya Nmap ile testlerin nasıl yapılacağını yazayım belki birilerine faydası dokunur.
Dns cache poisoning açıklığını test etmek için hedef sistemde iki değer kontrol edilir. Birincisi dns sorgulamalarında kaynak portun değiştirilmesi, diğeri de dns sorgularındaki TXID değerinin yeteri kadar random/rastgele olması. Nmap ile bu iki değeri de kontrol edebiliriz. Hatta tek bir taramada her ikisi de kontrol edilebilir.

Önce kaynak port rastgeleliğini test edelim.

# nmap -P0 -sU -p 53 –script dns-random-srcport 100.100.100.2 -vv

Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-12 11:14 GMT
Initiating Parallel DNS resolution of 1 host. at 11:14
Completed Parallel DNS resolution of 1 host. at 11:14, 0.00s elapsed
Initiating UDP Scan at 11:14
Scanning (100.100.100.2) [1 port]
Completed UDP Scan at 11:14, 2.02s elapsed (1 total ports)
SCRIPT ENGINE: Initiating script scanning.
Initiating SCRIPT ENGINE at 11:14
Discovered open port 53/udp on 100.100.100.2
Completed SCRIPT ENGINE at 11:14, 5.83s elapsed
Host host- (100.100.100.2) appears to be up … good.
Scanned at 2009-01-12 11:14:39 GMT for 8s
Interesting ports on (100.100.100.2):
PORT STATE SERVICE
53/udp open domain
|_ dns-random-srcport: 100.100.100.2 is POOR: 52 queries in 108.6 seconds from 1 ports with std dev 0

Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.04 seconds
Raw packets sent: 2 (56B) | Rcvd: 0 (0B)

Benzer şekilde txid üretecinin tahmin edilebilirligini test etmek için

# nmap -P0 -sU -p 53 –script dns-random-txid 100.100.100.2 -vv
komutu kullanılabilir.

bt scripts # nmap -P0 -sU -p 53 –script dns-random-txid 100.100.100.5 -vv

Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-12 11:50 GMT
Initiating Parallel DNS resolution of 1 host. at 11:50
Completed Parallel DNS resolution of 1 host. at 11:50, 0.10s elapsed
Initiating UDP Scan at 11:50
Scanning 100.100.100.5 [1 port]
Completed UDP Scan at 11:50, 2.02s elapsed (1 total ports)
SCRIPT ENGINE: Initiating script scanning.
Initiating SCRIPT ENGINE at 11:50
Discovered open port 53/udp on 100.100.100.5
Completed SCRIPT ENGINE at 11:50, 5.80s elapsed
Host 100.100.100.5 appears to be up … good.
Scanned at 2009-01-12 11:50:48 GMT for 8s
Interesting ports on 100.100.100.5:
PORT STATE SERVICE
53/udp open domain
|_ dns-random-txid: x.y.z.t is GREAT: 26 queries in 5.3 seconds from 26 txids with std dev 17822

Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.09 seconds
Raw packets sent: 2 (56B) | Rcvd: 0 (0B)

Her iki testi de tek bir Nmap taraması ile gerçekleştirmek için scriptler arasına “, ” koyulması yeterli olacaktır.

Nmap tarafından dns ile ilgili yapılabilecek diğer taramalar.

bt scripts # ls dns*
dns-random-srcport.nse dns-random-txid.nse dns-recursion.nse dns-test-open-recursion.nse dns-zone-transfer.nse

Güvenligi gercekten ciddiye aliyor muyuz-DNS Cache poisoning acikligi

Yeni hazirladigim bir egitim icin DNS Cache Poisoning acikligini test eden uygulamalari test ediyordum. Normalde dig ya da nslookup kullanarak aciklik testini gostermeye calisiyorum fakat her zaman bu ikilinin parametreleri hatirlanamiyor. Dolayisi ile bu isi web uzerinden yapan bir servis isimi oldukca kolaylastiracakti. Internette bu sekilde cesitli servisler var fakat ben IANA’ninkini tercih ettim.

Verilen servisin ne kadar saglikli ciktilar urettigini test etmek isterken aklima acaba son acikliktan sonra hala dns sunucularinda gerekli onlemleri almamis birileri var mi diye merak ettim ve sonuc gercekten korkuttu. Aralarinda  devlet/özel üniversite Turkiye’nin en hassas kurumlari, telco sirketleri , medya sirketleri ve guvenlik uzerine is yapan sirketler ve bu konuda bilincli olacagini dusundugum arkadaslarin sistemleri olmak uzere 10-15 sisteme baktim .Cogu hala gerekli onlemi almamis gorunuyordu. Buradan benim cikardigim sonuc: guvenlik isini hakettigi kadar ciddiye almadigimizdir. Ne demis atalarimiz “bir musibet bin nasihatten evladir”. Henuz bizdeki hacker tayfasinin teknik kapasitesi web sayfalarini deface etmenin uzerine cikamadigi icin simdilik musibet konusunda rahatiz fakat ilerde bu bakis acisi degisecek ve web sayfalarindan istedigini elde edemeyeneler daha komplike saldiri yontemlerine basvuracak.

Aciklik ciktiktan sonra bunu duymamis olma ihtimalimiz yok ama nedense kendi sistemimize bir bakip bu zaafiyetten etkileniyor mu kontrol etmiyoruz -edenleri tenzih ederim-. Belki usengenclik belki “adam sendecilik” ne dersek diyelim  bir yerler eksiklik kaliyor hep…

Son gunlerin dns zaafiyetine Pf(Packet Filter) cozumu

Birkac gun once detaylarina buradan -ve teknik olarak buradan-erisebileceginiz bir DNS protokolu zaafiyeti yayinlandi. Zaafiyetin kotuye kullanilmasi sonucu bu acigi barindiran (Internetin %99′u diyebiliriz) dns sunucularin cachelerinin zehirlenmesi ihtimali var.

Yukarıda verdigim adreste zaafiyet icin onerilen maddelerden biri de DNS sunucularin sorgulama yaparken rastgele kaynak port kullanmalari idi. Bildigim kadari ile DJBdns haric bunu native saglayan dns sunucu/istemci yazilimi yok.

Packet Filter gibi Nat yaparken kaynak portlari degistirebilen(cogu Firewall bunu yapar) bir Firewall kullaniyorsaniz DNS sunucunuzun udp 53 cikislarini nat yaparak cikarirsaniz kaynak port numalari rastgele secilmis olur.

Asagidaki ornekleme OpenBSD named ve PF ile gerceklenmistir.

Read more »

OpenDNS kullanarak web sayfalarina icerik filtreleme

OpenDNS tarafindan uzun suredir ucretsiz  olarak verilen bir hizmet var: Domain tabanli icerik filtreleme. Kisaca yapi soyle calisiyor;

OpenDNS’e uye oluyorsunuz -> Uyelik sayfasindan ip araliginizi belirtiyorsunuz->Hangi kategorilerdeki iceriklerin bloklanacagini seciyorsunuz(Klasik icerik filtreleme sistemlerindeki gibi)->Sonra aginizda DNS sunucu olarak OpenDNS’în adreslerini veriyorsunuz ve boylece ek bir islem, yatirim yapmadan hizli bir icerik filtreleyiciye sahip oluyorsunuz.

OpenDNS’i kullanan istemci sayisinin 5 milyon oldugu ve bu sayinin hergecen gun arttigi dusunulurse yakin gelecekte piyasada dolasan icerik filtreleme sistemlerine ciddi bir rakip geliyor demektir.

Icerik filtreleme sistemlerde en onemli iki husus performans ve bloklanacak site veritabanidir.(Buna bir de loglama ve raporlama ekleyebiliriz). Performans konusunda OpenDNS’i gececek bir uygulama olmayacaktir zira daha dns sorgulama esnasinda istekler filtrelenecektir. Bu sistemi Spam engelleme icin kullandigimiz RBL Listelerine benzetebiliriz.

OpenDNS’în site veritabani henuz cok gelismis degil ama gonullu kullanicilar tarafindan her gecen gun siteler kategorilendiriliyor ve veritabani buyuyor.

Genel olarak dusunuldugunde hem ucretsiz olmasi hem de kurulum, bakim gibi kaynak gerektirecek islemleri olmamasi benim gozumde OpenDNS’i gelecegin icerik filtreleme sistemi olarakust siralara yerlestiriyor. Buyuk sirketler icin degil fakat orta olcekli ve kucuk olcekli sirketler icin denenesi bir cozum.

Tabi burada gozden kacirilmamasi gereken durum OpenDNS’in sizin tum DNS trafiginize hakim olmasi ki bu da sizin trafiginiz uzerinde istenilen islemin OpenDNS tarafindan yapilabilecegi manasina geliyor.

DNSstuff Alternatifleri

DNS ile ilgili sorunlarda ilk basvuru kaynagimiz dnsstuff’in ucretli hale gelmesinden sonra kendim icin benzer islevleri yereine getirebilecek bir sisteme ihtiyac duymaya basladim.

Konsol erisimimi oldugu zaman genelde dig komutu(arabirimde gorulen sorgulamalarin hemen  hepsini dig komutu ile basarmak mumkun) ile halledebiliyorum fakat her zaman her yerden konsola direkt erisimi mumkun olmuyor, dahasi sonuclarini baskalari ile paylasmak gerektiginde web uzerinden goruntulemek daha kolay oluyor. Read more »