7 Eylül 2014 Pazar

Netsparker Web Uygulamaları Güvenlik Tarayıcısı Analizi

Netsparker
Netsparker Web Application Vulnerability Scanner
                  Biz güvenlik uzmanları araştırmalarımızı ve sızma testlerini yaparken yapay zeka araçlara çok fazla güvenmediğimizden dolayı öncelikle birçok bulguyu manuel olarak bulmaya özen gösteriyoruz. Bu manuel taramaları gerçekleştirmeden öncesinde ve sonrasında tabi ki gözden kaçan detaylar için otomatize araçların kullanılması işlerimizi kolaylaştırıyor. Piyasada bulunan web application vulnerability scanner (WVS) olarak isimlendirdiğimiz araçlar incelendiğinde, bunlardan başlıca öne çıkan araçlarda önem verilen konuların başında tabiki bulunan güvenlik açığının doğruluk (False-Positive) oranı vardır.
Piyasada gerçekten iyi bir doğruluk oranına sahip olan Netsparker tarayıcısını inceledim ve incelemelerimde gözüme çarpan şeyleri sizinle paylaşmak istiyorum.
Öncelikle Netsparker 'ı kuracağınız bilgisayarda eğer Net framework 4.0 yüklü değilse program çalışması için gerek duyduğu bu frameworkün kurulmasını istiyor.
Eğer siz de güncel olmayan (Windows update leri açık olmayan) bir bilgisayarda Net framework 4.0 'ı kurmaya çalışırsanız aşağıdaki gibi bir hata ile karşılaşabilirsiniz:

HRESULT 0xc8000222
HRESULT 0xc8000222 Hatası

Hatanın giderilmesi için internette bulduğum şu çözümü sırayla uygularsanız sonuca varırsınız:

HRESULT  0xc8000222 Hatası çözümü:
> Başlata tıklayın.
> "Programları ve Dosyaları Ara" bölümüne cmd yazın listeye gelen arama sonucundaki  cmd.exe'nin üstüne sağ tıklayın ve açılan pencereden Yönetici Olarak Çalıştır 'ı seçin.
> Komut istemi satırına net stop WuAuServ yazın ve enter tuşuna basın böylece windows update hizmetini durduracaksınız.
> Windows tuşu + R tuşlarına basın. Çalıştır açılacaktır.  %windir% yazın ve enter tuşuna bastığınızda windows klasörü gelecektir.
> Açılan Windows klasörünün içinde bulunan SoftwareDistribution isimli klasörü bulun ve sağ tuşla tıklayın ve yeniden adlandırın. Klasör adını örneğin SD2 yapın.
> "Programları ve Dosyaları Ara" bölümünden 2.adımda yaptığımız gibi cmd yi tekrar yönetici olarak çalıştırın.
> Komut satırına  net start WuAuServ yazın enter tuşuna basın böylece Windows update yeniden başlatılacaktır.
> Bilgisayarı yeniden başlatın.
> Kurulumu şimdi tekrar deneyin.


                Diğer çoğu güvenlik tarayıcısında olmayan birçok özgün özelliği Netsparker 'da bulmanız mümkün. Program kullanıcıya birçok seçenek sunarak oldukça esnek bırakılmış.
Mesela crawling dediğimiz dizinlerin listelenmesi, yani url lerin keşfi bölümü bile kullanıcının isteğine göre attack ile beraber yapılsın veya yapılmasın diye seçeneklendirilmiş. Örneğin crawling & attacking seçeneği aynı anda bulunmasa bir websitesinin ne kadar uzun sürede crawling edileceğini bilmediğinizden dolayı bu süreç oldukça uzun sürebilir ve güvenlik açıklarını bulma kısmı attack sürecine çok çok geç başlayabilirdiniz. Bu yüzden bir süre url topladıktan sonra crawling & attacking sürecine geçme seçeneği varsayılan özellik olarak aktif. Aynı şekilde ben bir uygulamanın dizinlerini listelettirmek istiyorsam gereksiz sorgular olmadan sadece crawling seçeneğini de kullanabiliyorum.
Bu program piyasada rakibi olan Acunetix gibi programlara nazaran daha az sorgu ile iş yapıyor. Bu da hoşuma giden özelliklerden bir tanesi oldu. Gönderilen paketleri incelediğinizde az sayıda sorguyla yapılabilecek işlerde israfa kaçılmamış. Fakat yine de özellikle blind sql tespitinde farklı bir algoritma ile sorgular daha da azaltılabilir.

                Programda karşılaştığım eksiklerden bir tanesi user-agent üzerinde bulunabilecek muhtemel güvenlik açıklarını taramaması. Bildiğiniz üzere user-agent stringi manuel olarak tarayıcıda değişiklik yapılarak gönderilebilir. Bazı webmasterlar bu user-agent stringini websiteleri üzerinde veritabanlarında, sayfaya yansıyan veya yansımayan bölümlerinde değerlendirirken filitrelemeye tabi tutmayabiliyorlar. Burada bulunabilecek muhtemel güvenlik açıklarının tespiti için güvenlik tarayıcılarında user-agent taraması oldukça önemlidir. Çoğu tarayıcı, sorguların kendi programından yapıldığını loglar üzerinde göstermek adına sadece özel bir user-agent tanımlayarak gönderiyor. Bu gönderilen user-agent sorguları içerisinde tabi ki diğer inputlarda yapıldığı gibi güvenlik testleri yapılmalı ve sonuçları değerlendirilmelidir.
Netsparker ile user-agent değişkeninde sql injection güvenlik açığı bıraktığım bir uygulamamı taradım fakat bulgularda bununla ilgili bir tespite rastlayamadım. Bazı websitelerinde yine user-agent değişkeni sayfa içerisinde ziyaretçilerin tarayıcı bilgilerini sayfa içerisinde göstermek adına kullanılıyor, burada bu değişkenin filitreden geçirilmediği alanlarda xss açıklarının tespiti için de tarayıcı tarafından user-agent taraması önemlidir.
Programın yeni sürümlerinde bununla ilgili bir çalışma yapılması güzel olacaktır.

             XSS güvenlik açıklarını tararken json çıktılarını muhtemel xss açığı olarak bildirmesine bir çözüm üretilmeli. Bu çözüm güvenlik açığı doğruluğu (false/positive) oranına ciddi katkı sağlayacaktır.
Tabi ki json çıktılarının muhtemel xss açığı detay kısmında programın kendine ait doğruluk onay oranı düşük verilse de xss 'in tespitindeki metodoloji kodlarla biraz daha farklı yorumlanarak sunulabilir.

              Netsparker üzerinde yaptığım incelemelerde gözüme çarpan bir şey de admin panel bulucu modülü biraz daha zengin olabilir. Örneğin piyasada çok fazla sitede rastladığım "siteadı-admin" tipi varyasyonlarda bilgi toplama araçlarındaki bölüme eklenebilir. Mesela deneme.com/deneme-admin şeklinde birçok yönetim paneli dizini bulunduğunu şuana kadar yaptığım çalışmalardan biliyorum. Bunun gibi daha farklı admin panel wordlisti oluşturulabilir diye düşünüyorum.

             Olumlu veya olumsuz yansımaları tartışılabilir bir özelliği de server bazı sorgulara geç cevap verdiğinde o sorguyu es geçiyor. Burada es geçilen sorgu, programın taramanın son kısmında yaptığı açık doğrulama kontrolünde tekrar gözden geçirilmeli.

            Sonuç olarak ilk izlenimlerime göre Netsparker güvenlik tarayıcısını ben tavsiye edilebilecek kadar çok kullanışlı ve güzel buldum. Fiyat olarak şirketlere tavsiye edebileceğim bir fiyat aralığında. Eğer bilgi-işlem personelinizin pentest doğrulama ve ilk müdahale ihtiyacını karşılama bakımından bir arayış içerisindeyseniz, seçiminizi öncelikle Netsparker yönünde kullanabilirsiniz. Netsparker 'ı kullandığım süreç içerisinde güncellemeleriyle gelen yeni dahil ettiği ve göze çarpan kullanışlı fonksiyonlarını öneri olarak yazıma dahil edeceğim. Ürünü verdiğim bağlantıdan indirebilirsiniz. Download Netsparker Demo

             Duyumlarıma göre yakın dostlarımdan Yasir Taşdemir 'in kodlama aşamasında olduğu ve birçok modülünü tamamladığını bildiğim TurkSec Scanner isimli bir web güvenlik tarayıcısı var. Şuana kadar kodladığı bölümlerini incelediğimde gerçekten çok farklı algoritmalarla piyasadaki araçlarla yarışabilecek türden iddialı gözüküyor. Hatta şuana kadar incelediğim araçlarda rastlamadığım türden farklı, kullanışlı algoritma ve sorguları var. İleride bu güvenlik tarayıcısının da diğer tarayıcılara göre olumlu ve olumsuz yanlarından bahsedeceğim.

Emrullah Akdemir ~

12 Nisan 2014 Cumartesi

OpenSSL Heartbeats / HeartBleed Güvenlik Açığı

OpenSSL Heartbeats / Heartbleed Vulnerability

Yakın zamanda bilişim gündeminin en üst sırasına yerleşen bir güvenlik açığı tespit edildi.
Bu zafiyetin adı "HeartBleed"... Bu zafiyet, ismini; OpenSSL kütüphanelerinde bulunan Heartbeats (Kalp atışları) adındaki bir eklentinin isminin güvenlik açığını tespit eden kişilerce değiştirilerek Heartbleed (Kalp kanaması) olarak adlandırılmasından alıyor, açığın temel kaynaklanma sebebi de Heartbeats ismi verilen bu eklenti...
Bu güvenlik açığı, uluslararası standart güvenlik açıkları kategorisinde CVE-2014-0160 olarak adlandırılıyor.
OpenSSL ise SSL/TLS protokol hizmeti sağlayan açık kaynak kodlu bir uygulama.
Kısaca sizin https üzerinden gönderilen verilerinizin şifrelenmesini sağlayan ve çoğu sistemde kullanılan bir uygulama diyebiliriz.
Bu zafiyetten şu an için etkilenen sistemler OpenSSL 'in aşağıdaki sürümleri olarak gözüküyor.

OpenSSL 1.0.1 ve OpenSSL 1.0.2-beta sürümleri

Peki ne oldu da bu açık bu kadar çok dillendirildi ve neden bir anda popüler hale geldi ?

Bu güvenlik zafiyeti gerçekten çok can yakan bir açık. Öyleki, düşünün sistemlerde https aktarımında şifreleme için kullanılan Openssl kurulu sistem kendi belleğinde belirli kullanıcılara iletilen cevapları tutuyor. Dışarıdan herhangi birisi https protokülüne küçük boyutlu bir istek yolladığı zaman random olarak belleğinde tuttuğu 64 kb 'a kadar veriyi dışarıdan sıradan istek yapan ve verinin gerçek sahibi olmayan o kişiye sunuyor.
Belleğinde tuttuğu verilerde ise cookieler (web sitelerinin sizin bilgilerinizi hatırlamasına yarayan çerez) , kullanıcı adları & şifreler, mail yazışmaları, get veya post istekleri (Sizin websitesi ile bilgi alışverişi yaptığınızda aktarımı gerçekleşen veriler), X-509 sertifika anahtarları gibi kritik veriler olabiliyor.
Bu verilerle saldırganlar sizin hesaplarınıza giriş yapabilir, şifrelerinizi açık bir şekilde görüntüleyebilir, kullandığınız ağlarda kriptolu tutulan verilerin çoğu elde edilen keyler ile decrypt edilebilir, eğer alışveriş yaptığınız siteler bu açıktan etkileniyor ise siteye alışveriş yaparken gönderdiğiniz kredi kartı bilgileriniz dahi bu açık ile elde edilebilir.
Üstelik bu açık kullanıldığında, sunucularınızdan verilerin bu açık üzerinden çekilip çekilmediğini anlamak çok çok zor.
Bu güvenlik açığının tam olarak ne zamandan beri kullanıldığı belli olmadığı için uzmanlar önemli websitelerinde kullandığınız şifrelerinizin değiştirilmesini öneriyor. Aslına bakarsanız bu güvenlik açığı ilk yayınlandığında panik haliyle birçok haberler yayınlandı ve birçok eksik bilgi yer alan haberlerlerle bilgi kirliliği yapılarak kullanıcılar daha da riske atıldı. Örneğin bu güvenlik açığı Yahoo gibi büyük bir mail sağlayıcı da halen devam ederken bazı websiteleri tüm sitelerdeki şifrelerin değiştirilmesini önerdi. Fakat bu durum birçok kullanıcıyı riske atan bir şeydir. Çünkü sizin güvenlik açığı barındıran bir siteye girerek şifrenizi değiştirmeniz bir önlem olamaz aksine sizin mağdur edilme riskinizi arttırır. Büyük sistemler eğer bu açıktan etkilendiler ise şifre değiştirme ve cookieleri sıfırlama işlemlerini kendileri yerine getirmeleri gerekiyor. Sizler eğer örneğin Yahoo veya Tumblr sistemine şifre değiştirmek maksadıyla girdi iseniz, sizin değişiklik için gönderdiğiniz bilgiler de risk altında olacak ve sizin cookie bilgilerinizin de ele geçirilme ihtimali artacaktır.
Hatta siz sıklıkla kullanmadığınız bir websitesine şifre değiştirme maksadı ile girdiğinizde tehlike altında olacaksınız.
Bu güvenlik açığından ilk haberdar olan şirketlerden Domaintools sistemini güncelleyerek, kullanıcılarının şifrelerini sıfırladı ve bilgilendirme maili yolladı. Google, Twitter vb. sosyal medya platformlarının bir çoğu bu açıktan direkt olarak açıktan etkilenmedikleriyle ilgili açıklamalar yayınladılar.
Bu konu hakkında sistemlerinin etkilenip etkilenmediğine dair açıklama yapan dünya devi şirketlerin duyurularını bu adresten öğrenebilirsiniz.
Fakat tehlike onlar için tam olarak geçmiş değil. Sonuçta bu sistemlerin birçoğu dolaylı olarak bu güvenlik açığını barındıran sistemlerle entegre çalışabiliyor ve bu güvenlik açığı birçok sunucuda giderilmez ise çok büyük sorunlara neden olacak gibi...
Daha önceden elde edilen verilerin decrypt edilerek bilgilerin ortaya çıkmayacağını şuan için birçok sosyal ağ garanti edemiyor.
Şuan için OpenSSL'i internet dünyasında %66 gibi sistemin kullandığı söyleniyor, bu da açığın büyüklüğünü görmemiz ve anlamamız açısından önemli bir nokta.
Ve şuanda birçok websitesi/sunucu bu güvenlik açığını halen gidermemiş durumda. Yani sizler site sahipleri veya kullanıcılar olarak https protokülünü kullanarak gönderdiğiniz maillerinizin, şifrelerinizin elde edilme riskiyle karşı karşıyasınız. Bu sistemi kullanıp kullanmadığını bile bilmediğiniz birçok websitesinde bilgileriniz başka tarafta loglanıyor ve izleniyor olabilir. Bu güvenlik açığının etkilerini uzun süre göreceğiz gibi gözüküyor.
Açığın giderilmesi için sunucu sahiplerinin OpenSSL sürümünü bir an önce güncellemeleri (openssl 1.0.1g) , güncelleme durumu şimdilik olmayanların ise -DOPENSSL_NO_HEARTBEATS parametresi ile openssl 'i sunucularında yeniden derleyerek açığın kaynaklandığı heartbeats eklentisini devre dışı bırakmaları gerekmekte.

Bu açık bulunan eklentinin default olarak yüklü geldiği işletim sistemleri aşağıdaki gibidir:

Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
CentOS 6.5, OpenSSL 1.0.1e-15
FreeBSD 10.0 – OpenSSL 1.0.1e 11 Feb 2013
Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
Fedora 18, OpenSSL 1.0.1e-4
OpenSUSE 12.2 (OpenSSL 1.0.1c)
NetBSD 5.0.2 (OpenSSL 1.0.1e)

Açığın keşfedilmesi ve giderilmesinde emeği geçen isimler ise şunlar:

Neel Mehta (Google Security Team)
Adam Langley
Bodo Moeller

Eğer siz bir internet kullanıcısı iseniz ve kullandığınız web sitelerinde bu güvenlik açığı var mı yok mu test etmek istiyorsanız bu websitesinden testini gerçekleştirebilirsiniz. Şu aralar internette dolaşırken çok dikkatli olsanız iyi edersiniz çünkü şuan çok popüler olan bu güvenlik zafiyetini kullanan hackerlardan birinin random kurbanı olabilirsiniz. Malesef sistem kaynaklı güvenlik zafiyetlerine karşı kullanıcıların ilk etapta yapabilecekleri çok fazla birşey olmuyor.

Emrullah Akdemir ~ 11.04.2014

11 Mart 2013 Pazartesi

Neden Redhack'e Karşıyım ?

Terörist Redhacke karşı açıklama
Neden Redhack'e Karşıyım...


İsmimi farklı bir şekilde gündeme tekrar taşımak isteyenlere cevap olarak bu yazıyı yazmayı uygun gördüm. Günümüzde,  devletini sevmenin , bayrağını sevmenin ve bu değerler için iyi yönde çalışmanın faşistlik olduğunu haykıranları görüyoruz , izliyoruz. Ve bu söylemleri haykıran gruplardan bir tanesi de elbette Redhack ve saz arkadaşları
Redhack isimli sözde hacker grubu ve sempatizanlarının çeşitli eylemlerle, çarpıtmalarla bizleri farklı gösterme çabası olumsuz sonuçlandıkça  elbette daha da saldırgan, agresif bir yapıya bürünmeleri oldukça doğaldır.
Karşıt görüşlü kişilere saygısı olmayan bu kişilerin, kendilerine karşı sempati beslemeyenlerden saygı beklemeleri oldukça ironiktir.
Ben şimdiye kadar belli bir görüşü temsil etsem de benim düşünceme karşıt görüşlü kişiler benim değerlerime dokunmadığı sürece onlara karşı belirli bir hassasiyet ile yaklaştım.
Daima saygı duydum ve karşıt görüşlerin de bir ülkenin gelişmesi adına var olması gerektiğini hep savundum.
Derdi, aslen hükümet ve kurumlarıyla değil de direkt olarak DEVLET ve  onun düzenli yapısı olan bu grupların o kadar çelişkili söylemleri ve eylemleri var ki bunları inanın saymakla bitiremem.
Daha önceki yazılarımda da belirttiğim gibi bu tür gruplar amaçlarının oldukça dışına taşmış durumda ve amaç olarak tamamen popüler bir kitle oluşturarak belirli bir sansür ortamını kendileri yaratma peşindeler.
Belirli çevrelerin tehdit ortamı oluşturduğunu söyleyen bu grup acaba;
Şunlar , şunlar yapılmaz ise elimizdeki belgeleri açıklarız.
Şu kişilere özgürlük gelmez ise şuralara şunu yaparız.

söylemleri ile tehdit değil de rica da bulunduklarını mı sanmaktalar ?
Anonymous grubunun zamanında yaptığı gibi prim yapmak için her türlü tehditi sergileyen bu grubun yaptığı baskı sizce belirttiği görüşlerle çelişmiyor mu ?
Şu ana kadar gördüğüm eylemlerinin tamamı duvara yazı yazmaktan ibarettir.
Ben kendi görüşümü kendi evimin duvarından istediğim gibi sergileyebilirim. Fakat bu özgürlüğümü başkasının hak kapsamına giren veya her görüşten insanların olduğu umuma açık bir yeri şahsi fikirlerim için kullanamam, onun meşru sınırları içerisinde bu eylemimi gerçekleştirmem meşru değildir bunun en azından meşru olduğunu kabul edemem.
Redhack’in de şuan yaptığı tam olarak budur. Yani başkalarının sınırları içerisine giren yerde kendi görüşünü sergilemek ve buna saygı duyulmasını beklemek…
Siz istediğiniz kadar karşıt görüşlü olun, istediğiniz kadar farklı bir bakış açısından dünyaya bakın;
Başkalarının değerlerine hakaret etmeden, onların düşüncelerine saygı göstererek istediğiniz gibi bu görüşlerinizi kendi sınırlarınız içerisinde sergileyebilirsiniz. Ben, buna kimsenin müdahale etmemesi gerektiğini savunurum. Fakat ben hiçbir şekilde kendi görüşüme ters bir kişinin gelip bahçemin duvarına yazı yazmasına da müsaade etmem ve bu tür kişilere de saygı göstermem asla beklenemez.
Belki  bu karalanan duvar boyanır yazılar kapanır ama karşıt görüşlere olan saygımı azaltan bu eylemler hiçbir şekilde benim ve çevrem üzerinde sempati kazanmaz.
Adımız defalarca belirli kesimler üzerinden karalanmaya , yıpratılmaya çalışıldı. Bunun örneklerini zamanla gördük. Bunlardan bir tanesi de tamamen legal çerçevede ilerlediğimiz ve devletimizi severek yaptığımız gönüllü işlerden bazılarının çarpıtılarak bazı medya organlarının malzemesi haline gelme durumuydu. Düşünün ki siz bilişim alanında birçok bilgi eksiği olduğunu bildiğiniz devlet kurumlarına , üniversitelere gönüllü  olarak gidip seminerler , konferanslar , elinizden geldiğince bilinçlendirme eğitimleri veriyorsunuz. Ve hiçbir maddi karşılık beklemeden yaptığınız bu işlerden dolayı verilen bu plaket , teşekkür belgesi vb. şeyler çarpıtılarak devletçi hacker , faşist hacker gibi söylemleriyle karşıt gruplar arasında hedef konumuna getiriliyorsunuz.
Sıradan bir polis meslek yüksek okulunda gidip ücretsiz bilişim semineri verdiğimiz ve karşılığında aldığımız bu plaketin , teşekkür belgesinin adı bazı kesimler tarafından şu an ne şekilde gösterilmeye çalışılıyor biliyor musunuz ?
Ben size söyleyeyim ;
Devlet , kendi hackerlarını ödüllendiriyor. Devlet bu kişilere Redhack’e karşı oldukları için ödül veriyor
Evet biz devlete bağlı , devletini seven kişiler olarak bundan gurur duyuyoruz. Siz bu teşekkürlerin amacını üstte verdiğim cümledeki gibi istediğiniz kadar çarpıtıp istediğiniz kadar bu olayları bir yerlere çekebilirsiniz. Devlete bağlı olup bu vatana gerçek hizmeti vermek devletçilikse , milliyetçilikse ve hatta sizin saçma gözü dönmüş tabirinizle faşistlikse, faşizm ise işte biz ‘O’ yuz.
Kaldı ki biz ödüllerimizi, teşekkürlerimizi sadece devletimizden değil aynı zamanda uluslar arası birçok şirketten de emeğimizle alarak bir yerlere geldik. Ha ama şimdi bu karşıt gruplar; “Google , Facebook , Microsoft gibi şirketler de sizi savunuyor onlar da cemaatçi , devletçi vb.” diyecekler…
Nitekim bu planları tutmayan kişiler şanslarını tekrar tekrar denemek için yine sahnede ama bu kez bir film/belgesel paçavrası ile devletini seven gönüllü olarak kendini vatanına adayan kişiler üzerinden prim yapma hevesindeler…
PKK’ ya terör örgütü diyemeyen , geçmiş röportajlarında DHKP-C & Tikko bağlantısını gizlemeden açıkca söyleyen , emperyalizme karşı olduğunu söyleyip asıl emperyalist hedeflerle uğraşmayan, eylemlerinde halka zarar veren , aynı görüşte olmayan kişileri devletçi , cemaatçi, faşist o cu bu cu diye önyargıyla kendine göre nitelendiren bir grup ile benim uzlaşamayacağım gayet açık ve nettir.
Önemli olan bu çamur atma felsefesinden uzaklaşıp benim şuan kendi duvarımdan görüşlerimle seslendiğim gibi kendi duvarından seslenişiyle halklara baskı kurmadan davasını savunan kişiler toplamaktır.
Gerçek yüzünü gizleyen , masumiyet maskesiymiş gibi gülen bir maske ardına gizlenen kişiler asla gerçeği savunuyorum diyemezler…
Çünkü o kişiler suçluluk psikolojisinin verdiği eziklikle, gerçek benliklerini kimliklerini açık edecek yüzde olmayan zavallılardır. Ve gerçek bir kimlik ile kendi doğrularını savunamazlar.
Deniz Gezmiş , Mahir Çayan vs. isimlerini anarlar fakat onlar gibi cesaretli değil onların tam aksine korkaktırlar. Ölümü bile göze alırız derler fakat savundukları dava da bahsettikleri ölüm onlar için Counter Strike oyunundaki gibi sanal bir ölümdür.
Ve benim bahçemin duvarına kendi görüşlerini yazacak kadar bilgisi olmayan o zavallılar çareyi, isimlerimizin üzerine çamur atma felsefesinde bulmuşlar.
Ama ben yine çok kızmıyorum. Siz de biliyorsunuz ki güneş balçıkla sıvanmaz.
İşimi iyi yaptığımı düşmanlarımın bana var gücüyle saldırmasından anlıyorum.

Emrullah Akdemir ~ 11.03.2013

1 Aralık 2012 Cumartesi

Google Blogger Unauthorized Forwarding Vulnerability - 2012

blogger hack
Google Services Vulnerability


Blogspot Unauthorized Forwarding
Hacking Blogspot / Blogger

Blogger / Blogspot Unauthorized Forwarding Vulnerability Nedir ?


Bu açık Google servislerinden ücretsiz blog oluşturmak için kullanılan Blogspot hizmetinin blog ayarları kısmında 2012 yılı içerisinde bulunan bir zaafiyetin adıdır. Açığın ismi zaafiyetin kullanılışına göre tarafımdan verilmiştir.

Bu Blogspot Hacking açığı ile Tüm Blogspot Adresleri Hacklenebilir miydi ?


Hayır. Bu açık ile sadece domain adını blogger ile birlikte kullanan kullanıcılardan domain yönlendirme ayarlarının yapılandırmasını tam yapmayan kullanıcılar etkilenebiliyordu. Yani bu açıktan ayarlar kısmında  "domain.com öğesini www.domain.com konumuna yönlendir." onay kutucuğu işaretli olmayan blogspot kullanıcıları etkilenebiliyordu.


Zaafiyet Tam olarak Nerede Bulunuyordu ?


Açık tam olarak Google Blogspot / Blogger servis ayarlarının Temel Ayarlar (#basicsettings) alanının içerisinde bulunan
Yayıncılık > Blog Adresi > Özel Alan Adı Ekle > Gelişmiş Ayarlar  kısmında bulunuyordu.











Açığın kaynaklanma sebebi neydi ?


Açığın kaynaklanma sebebi, Google Blogspot servisinin ayarlar bölümünde domain adı eklemek isteyen kullanıcıların Google güvenlik ekibinin boşluk karakterini bu alanda filitrelememesinden kaynaklanıyordu. Bununla birlikte sizin blogunuzun farklı subdomaini farklı bloglarda kullanılabilir olduğu için yapılandırmadaki birçok eksiklik dikkat çekiyor. Burada başka bir eksiklik ise Google ekibinin, yönlendirme yapılan domainin CNAME kaydının Google üzerine yönlendirilip yönlendirilmemesini önceden kontrol etmeksizin herhangi bir blogspot kullanıcısı tarafından eklenmesine olanak sağlamasıydı.
Bu sayede blogunuzun domain adını blogspot ayarlarına önceden ekleyip tanımlayan başka bir kullanıcı sizin blogunuzun CNAME kaydı blogspota yönlendirilir yönlendirilmez kendi blogspot adresini sizin domainiz üzerinden yayınlayabilirdi. Ve sizde kendi blogspot ayarlarınızdan kendi domain adınızı kendi blogspotunuzda kullanmak istediğinizde "bu alan adı kullanılıyor" uyarısıyla karşılaşabilirdiniz. Bu da blogspotun yapılandırılmasındaki eksiklerinden biriydi.

Açığın kullanımı nasıldı ?


* Saldırgan öncelikle sizin blogunuzun ayarlarındaki onay kutucuğunun seçili olup olmadığını tespit eder. Bu şekilde Google sunucularına yönlendirilmiş fakat eksik yapılandırması olan domainler/alt domainler aşağıdaki gibi bir hata verir.



* Saldırgan bu tespitten sonra,
Blogspot üyeliği üzerinden domain üzerinde göstermek istediği , yönlendirme yapacağı sahte sayfasını oluşturur.

* Oluşturulan blogun Temel Ayarlar (#basicsettings) alanının içerisinde bulunan Yayıncılık > Blog Adresi > Özel Alan Adı Ekle
kısmına hedefindeki kişinin yönlendirme yapılmaya elverişli CNAME kaydı Google 'a yönlendirilmiş domain adının önüne bir boşluk karakteri ekleyerek kaydeder.
Blogspot boşluk karakteriyle birlikte bu domain adını kabul eder. Boşluk değeri eklenmeden gönderilen değerler "Bu blog kullanılıyor" veya "Bir başka üst dizin kaydedin" gibisinden uyarılarla karşılaşır. Fakat Google Güvenlik ekibinin boşluk karakterini filitrelememesinden dolayı sizin blogunuzun yönlendirilme yapılmayan dizini farklı bir blog üzerinden yetkisiz olarak kullanılabilir hale gelir. (Genellikle www veya yalın domain)

Açık nasıl kapatıldı ?


Bu zaafiyet, Google Güvenlik ekibine yapılan uyarıdan sonra sessiz sedasız kapatıldı.
Diğer gönderilen açıklarla birlikte bu açık ile ilgili Google Güvenlik Ekibi tarafından geçte olsa yarı olumlu dönüş yapıldı. Google Blogger servisini domain adı ile birlikte kullanmak isteyenler için çift taraflı CNAME doğrulama sistemi getirildi.

Bu açık hakkında hiç video var mı?


Evet bu açık hakkında şuana kadar büyük sistemlerde elime geçen, gerek kendi bulduğum gerekse elde ettiğim tüm açıklarda video çektiğim gibi bunda da belirli bir video çektim.
Videoyu aşağıdan izleyebilirsiniz.
Not : Video , aceleyle çekildiğinden dolayı ufak birkaç ingilizce (Charachter , karakater) sözcük hatası olmuş.
Bununla birlikte videonun sonunda ilk açtığım tarayıcıda test sayfasının tam yüklenememesi mozillanın noscript eklentisinin devre dışı bırakılmadığından dolayıdır.
Videoyu vimeo üzerinden HD olarak izleyebilirsiniz.
İyi seyirler


Emrullah Akdemir



Misconfigured Blogspot Vulnerability 2012 from Emrullah on Vimeo.

27 Ağustos 2012 Pazartesi

Hacklenilen Microsoft Hesabını Tekrar Kullanmayın

Hacklenen Hotmail
Microsoft'un Güvenlik Anlayışı
Merhaba uzun zamandır blogumda yazı paylaşmıyordum. Microsoft güvenlik birimine yaptığım farklı birkaç uyarıdan sonra bu yazıyı paylaşmayı uygun gördüm.
Microsoft , Windowslive görünümüne geçmeden önce hotmail.com , live.com ve w.cn uzantılı bazı hesapların hacklenmesine kadar giden açığı keşfettiğim 2007-2008 döneminde bu açık tesadüfen Microsoft tarafından Windowslive sistemine geçilmesiyle giderilmişti.
Live.com alan adının eski arayüzünde bulunan bir url üzerinden kullanılan bu zaafiyet o zamanlarda çoğu hesapta işe yaramasada binlerce Microsoft kullanıcısını tehdit eder konumdaydı.
Sıfırlama alanında bulunan bu zaafiyetin, neden tüm Microsoft hesaplarına etki etmediğini , neden sadece sayılı uzantılardaki maillere etki ettiğini o dönemden beri anlayamasamda şu an için açıkcası pekte kafa yorduğum bir şey değil.
Windowslive sistemine geçen Microsoft , zaafiyetin bulunduğu alanda zaafiyetin kaynaklandığı değişkenlerden birinin değerini tam olarak hatırlayamamakla birlikte "IfYouReadThisYouMustEatToo" gibi bir değişken değeri ile gönderiyordu. Benim kendime göre algılayıp Türkçeye çevirdiğim haliyle "Eğer bu yazıyı okuyorsan 40 fırın ekmek yemelisin" gibi bir sözcükle o sayfada açık arayanlarla adeta dalga geçiyordu.
Eee tabi sadece benim bildiğim haliyle 6-7 ay boyunca kalmış bir açıktan sonra Microsoft ' un açığın bulunduğu sayfada böyle isimlendirilmiş bir değişken değeri göndermesine o zamanlar çok fazla gülmüştüm.
İşte o dönemlerde Hotmailin barındırdığı açıklardan bir tanesi de hacklenilmiş bir hesabın sahibi tarafından geri alındığında tüm bilgilerinin eski bilgilerden tamamen farklı olarak tekrar değişmesine rağmen saldırganın tekrar geri hacklemesi için hesap üzerinde bir arka kapı açılabilmesi idi.
Yani çalınmış bir Hotmail hesabının, gizli soru ve alternatif mail seçeneklerinden hariç bir yöntemle daha saldırgan tarafından devamlı hacklenebilir konumda olmasıydı.
Geçenlerde geçmişle ilgili maziye ait birçok güzel olay aklıma gelmişken bu olayı da hatırladım , tekrar denemek istedim ve sonuç :
Kötü niyetli kişilerin işine yarıyacak bu kurnaz yöntemin günümüzde de hala devam etmekte olduğunu gördüm.
Anlayacağınız başınızdan herhangi bir Microsoft ürünleri hesabınızın hacklenmesi olayı geçti ise ve bu hesabı sıfırlama yöntemi veya Microsoft müşteri desteği gibi herhangi bir seçenek ile geri alabildiyseniz size önerim kesinlikle bu mail hesabını tekrar kullanmayın!
Eğer mümkünse sıfırlama seçenekleri ile aldığınız bu hesabın içeriğini tamamen temizledikten sonra, gerekli önemli yerlerdeki maillerinizin adreslerini bu hesap üzerinden başka bir hesaba kaydırdıktan sonra, bir daha kullanmamak üzere bu hesabınızı kapatın.
İster Microsoft üyeliğiniz olsun, ister outlook.com , hotmail.com , hotmail.com.tr , windowslive.com , live.com vs vs. hangi uzantıda mailiniz olursa olsun tümünün hacklendikten sonra; siz ad , soyad , gizli soru , alternatif mail vs. bütün bilgilerinizi tamamen değiştirseniz bile saldırgan tarafından bir arka kapı ile sürekli geri alınmasının bir yöntemi var.
Geçmişte bu vakalarla sicili oldukça kabarık olan Microsoft'un parola sıfırlama bölümündeki bir başka açığını yine kendim blogumda bir video ile açıklamıştım.
Yine Microsoft'un başka bir güvenlik zaafiyeti ile karşı karşıyayız...
Ve inanın bunlar halka yansıyan bilgilerden sadece birkaçı. Ya halka açıklanmayan sadece blackmarketlerde kötü niyetli kişiler tarafından satılan yöntemlere ne demeli ? Microsoft , mail sağlayıcılığı işini eğer ciddiyetle yapacaksa bunu outlook.com gibi yatırımlarının yanında , sistemlerindeki güvenlik anlayışını da köklü bir değişimle onarmalı...
Ve son olarak , attığım birkaç zaafiyetten hariç bu zaafiyeti de Microsoft Güvenlik Departmanına bildirdiğimde aldığım cevap:

"Bildiriminiz için teşekkür ederiz
Ancak hesaba ilk erişiminiz olmaması nedeniyle bu bir güvenlik açığı olarak değerlendirilmiyor.

Saygılar
,"

Bu cevaptan sonra benim attığım cevap ise ;

...............
Bildiğiniz üzere geçtiğimiz günlerde sıfırlama bölümündeki bir açıktan dolayı tüm Microsoft hesapları tehlike altındaydı. Bu açığın bulunduğu ve kapatıldığı süre çok uzun bir süre. Bu süre içerisinde birçok Hotmail hesabında bu yöntemle arka kapı açılmış olabilir. Ve halen bu hesapları kullanan çok özel müşterileriniz bu zaafiyetten etkilenebilir. Bu müşterilerinizin hesaplarının etkilenmemesi için bu açığı gidermeniz gerekmekte. Aksi takdirde parola sıfırlama alanına koyduğunuz geri alma seçeneklerinden "Cep telefonu , Alternatif Mail , Gizli soru , Müşteri desteği" seçeneklerinden hiçbiri saldırganın uğraşacağı bir hedef yeri olmayacak ve hesaplar saldırgana ait başka bir yöntemle sürekli hacklenebilir durumda olacaklar.
Bildiğiniz gibi Cross Site Scripting açığı da direk olarak hesaplara etki eden bir açık değildir. Müşterilerin dikkatsizliği ile birleştirilerek hesabın çalınmasına kadar giden bu zaafiyetede biz bu bir güvenlik açığı değildir diyebilir miyiz ?

..............

Bu son mailimden sonra Microsoft tarafından herhangi bir geri dönüş olmadı.
Sistemin çoğu yerini değiştirme gibi bir şeyi göze alamadıklarından mıdır nedendir bilemem ama , anlayacağınız Microsoft'un güvenlik anlayışına göre sizin defalarca hesabınızın hacklenmesi birşey ifade etmiyor. Onlara göre sizin şirketinizin çok önemli maillerinin Hotmail üzerinde olması ve bunların çalınması hiçbir şey ifade etmiyor. Sizin yıllardır kullandığınız adresin sürekli başkaları tarafından ele geçirilmesi , bilgilerinizin alınması Microsoft için hiçbir anlam ifade etmiyor.

İşte bu yüzden diyorum ki Microsoft bu işi gerçekten bilmiyor.
Tıpkı yıllardır tarayıcı sektöründe yerinde sayıp, fazla yol katedemediği gibi...
Benim görevim kişisel güvenlik adına insanlara faydalı olabilmek. Sistem kaynaklı açıklarından dolayı madur olmamak için bu önerilerimi dikkate almanız dileklerimle...

~ Emrullah Akdemir

28 Mayıs 2012 Pazartesi

Facebook Mail Message Vuln. - Sending Message via Fake / Blackmail

Facebook Mesaj Mail Açığı
Facebook Mail

Son günlerde sıklıkla rastlayabileceğimiz bir olaydan bahsetmek istiyorum.
Facebook bildiğiniz üzere mail üzerinden Facebooktaki kişilere mesaj gönderme özelliği getirdi. Yani siz kendi Facebook a kayıtlı mailinizden bir arkadaşınızın Facebook uzantılı mailine gönderi yaptığınızda arkadaşınıza Facebook üzerinden mesaj halinde iletilebiliyor.
Peki bu yararlı olabilecek sistemin eksiklikleri var mı ?
Bu soruya verilecek cevabım evet. Çünkü bu sistem , sadece mail gönderenin mail adresine bakarak çalışmakta ve yanıltılması çok kolay bir sistem olarak şu an işlemekte.
Örneğin bu sistemi geçmenin en basit yolu fake bir mail sender form hazırlayıp gönderen kısmına kimin üzerinden gönderilecekse onun adresini yazarak çoğumuzun karamail olarak bildiği yöntemini uygulamak ve Facebook un bu sistemini yanıltmak.
Kötü niyetli kişi tarafından hazırlanan formda mail gönderim hali şu şekildedir.

Konu (Subject): Örnek
İsim (Name): Kimin Üzerinden Gönderiliyorsa O Kişinin Facebook ta ki Adı
Gönderen (From): kimin_uzerinden_atilacaksa@o_kisinin_facebooka_kayitli_maili.com
Kime (To): Yaniltmak_istenen_kisi@facebook.com
Mesaj (Messsage): Mesaj İçeriği

Bu şekilde bir mail form üzerinden mesaj gönderildiğinde istenilen kişinin üzerinden mesaj atılmış olacak.
Bu şekilde başkaları üzerinden mesaj atılarak stratejik derecedeki kişiler kandırılabilir ve sıkıntı oluşturacak durumlar oluşabilir. Bunun için dikkat etmekte yarar var.
Bunu önlemek için Facebook Güvenlik Ekibinin yapması gereken ilk şey facebook mail dışında hiçbir şekilde kullanıcıların birbirlerine başka mail sağlayıcı üzerinden mesaj atmamasını sağlamak. Yani hotmail , gmail vs . gibi mail sistemlerinden gelen mailleri mesaj olarak düşürmemek.
Bu sistemi kullanmak istiyorsa sadece facebook.com uzantılı maillerin birbirleriyle iletişimini sağlamalı.
Fakat bunu yaparken de mail gönderen sunucu ip , host ismi gibi bilgilere bakarak kontrolünü gerçekleştirmeli ve gelen maile karşı sistemi fake mail saldırılarından korunmalı. En azından "Gonderen Onaylanmadı" şeklinde verdiği uyarıyla birlikte gönderen kişinin gerçek profil kimliği olarak göstermemeli.
Şuan için gönderilen mesajdaki fake mail Facebook a kayıtlı ise onun profilinin resimleri gözüküyor ve bu tür mesajları ünlem işareti ile belirtiyor. Fakat onaysız gelen mesajlar için link ile desteklenmeyen , fake olduğunu gösteren ayrı bir önlem alınabilir.

Bu sistemin bir benzerini daha önce keşfetmiştik. Onda ki zaafiyet şu şekildeydi ; (mobile.facebook.com) üzerinde istediğiniz kişinin mail isminin kriptosunu çözerek (Bunu facebook un kaynağındaki js kodları üzerinden yapmak mümkündü) , istediğiniz kişinin duvarında fake mail üzerinden birşey paylaşmanız mümkündü. Açarsak biraz ; belirtilen maile dışarıdan herhangi bir mailden bir yazı yollandığında o kriptolu mail kime aitse onun duvarında kendine ait paylaşımlar yapılabiliyordu.
Bunun için yapılan uyarıdan sonra Facebook önlem olarak komple mobile kısmındaki random mail üreterek gönderme olayını uzun bir süre kaldırdı. Şu an için mobile daki aynı yapıyı incelemedim fakat Facebook güvenlik ekibi bu tür olaylarda sistemin tüm eksikliklerini gidermeden piyasaya sürerse daha çok başı ağrıyacak gibi gözüküyor.
Bu anlatılan zaafiyet için Facebook Güvenlik Departmanını bilgilendirenlerin olduğunu bildiğimden dolayı aynı uyarıyı tekrar olarak ben yapmayı düşünmedim. Aslına bakarsanız bu olay çok eski , açığın başkaları tarafından bulunma zamanı çok eski fakat son zamanlarda bu tür mesajlaşmaların arttığını , bununla ilgili şikayetlerin geldiğini ve Facebookun yapılan uyarılara karşı çok ciddi bir önlem almadığını görünce bununla ilgili bir bilgilendirme yapmayı da uygun gördüm.
Anlayacağınız son zamanlarda Mark Zuckerberg in Facebook hesabından mesaj alırsanız öncelikle biraz düşünün :)
Ekleme: Php mail sender dosyasını buradan indirebilirsiniz.

Emrullah Akdemir ~ 28.05.2012

6 Mayıs 2012 Pazar

Dns Hijacking Nedir ? Ne değildir ? Yenir mi İçilir mi ?

4 Mayıs 2012 de Gerçekleşen Hack Olayları Hakkında Makale...
Domain Hijacking
Dns Hijacking

Dns hijackingi bilmek için önce DNS ve Name Server tanımını bilmek gerekiyor.
Günümüzde pek çok kişinin eksik bildiği konulardan birisidir belki de DNS.
Pek çok kişinin kafasını da karıştıran yapısıyla da merak edilen konulardan olmuştur.
- Bazı ülkelerde gözüken sayfa neden bizim ülkemizde aynı şekilde gözükmüyor ?
- Dns güncelleme aralığı kıtadan kıtaya 24-48 saat gibi bir aralık olarak söylenmekte. Bu farkın kaynağı ne ? gibi sorular DNS yapısını anlamak isteyenlerin aklına gelen sorulardandır.

Dns (Domain name system) Nedir ?

"
İnternet ağını oluşturan her birim sadece kendine ait bir IP adresine sahiptir. Bu IP adresleri kullanıcıların kullanımı için www.site_ismi.com gibi kolay hatırlanır adreslere karşılık düşürülür. DNS sunucuları, internet adreslerinin IP adresi karşılığını kayıtlı tutmaktadır.
İnternette bulunan her nesnenin, etkileşime giren her sunucu ve ucun bir internet adresi olması gerekir. Bu adres, protokol seviyesinin IPv4 ve IPv6 olmasına göre 32 bit ya da 128 bit uzunluğundadır. Alan adı, bu 32 ya da 128 bit uzunluğundaki sayı yerine insanların anlayacağı, akılda tutacağı, kurumsal kimlik ve marka ile özdeşleştirebileceği isimlerin kullanılmasını sağlar. Örneğin tr.wikipedia.org alan adı ile 207.142.131.210 şeklindeki IP nosu ile bağlantıyı Alan Adı Sistemi sağlar. Sırayla; org, wikipedia.org ve tr.wikipedia.org içiçe geçmiş İnternet alanları ya da bölmeleridir.
Alan Adı Sistemi'nin yarattığı ilişkiler bire bir ilişki olmak zorunda değildir. Bir alan adına birden fazla IP adresi atanabilir. Bu yoğun talep olan hallerde geçerlidir. Wikipedia.org, yahoo.com, google.com gibi adreslerde bu çok olur. Ama daha yaygını, birçok alan adı tek bir IP'ye atanabilir. Buna da "Sanal Evsahipliği" (Virtual Hosting) denir.
Alan Adı Sistemi hiyararşik bir yapı gösterir. En üste .com, .org, .net, .int, .edu, .info, .biz, .aero, .travel, .jobs, .gov, .mil gibi "jenerik" üst düzey alanlarla (gTLD) .tr, .us, .de, .uk, .jp, .az gibi ülke alanlarından (ccTLD) oluşur. Buna son olarak .eu ve .asia gibi bölgesel birkaç üst düzey alan adı daha eklenmiştir.

DNS'in yapısı

DNS sistemi, isim sunucuları ve çözümleyicilerinden oluşur. İsim sunucuları olarak düzenlenen bilgisayarlar, host isimlerine karşılık gelen IP adresi bilgilerini tutarlar. Çözümleyiciler ise DNS istemcilerdir. DNS istemcilerde, DNS sunucu ya da sunucuların adresleri bulunur.
Bir DNS istemci bir bilgisayarın ismine karşılık IP adresini bulmak istediği zaman isim sunucuya başvurur. İsim sunucu, yani DNS sunucu da eğer kendi veritabanında öyle bir isim varsa, bu isme karşılık gelen IP adresini istemciye gönderir. DNS veritabanına kayıtların elle, tek tek girilmesi gerekir.
İnternet adresleri, ilk önce ülkelere göre ayrılır. Adreslerin sonundaki tr, de, uk gibi ifadeler adresin bulunduğu ülkeyi gösterir. Örneğin tr Türkiye'yi, de Almanya'yı, uk İngiltere'yi gösterir. ABD adresleri için bir ülke takısı kullanılmaz çünkü DNS ve benzeri uygulamaları oluşturan ülke ABD’dir. Öte yandan, ABD'ye özel kuruluşlar için us uzantısı oluşturulmuştur. İnternet adresleri ülkelere ayrılıdıktan sonra com, edu, gov gibi daha alt bölümlere ayrılır. Bu ifadeler DNS'te üst düzey (top-level) domain'lere karşılık gelir.

Resolving (Çözümleme) - Aranılan bir kaydı bulma işlemi

  • Mesela http://google.com.tr adresine karşılık gelen IPv4 adresinin 72.14.221.104 olmasının bulunması. Çözümleme yapan yazılımlar iki çeşit işlem yaparlar; özyineli çözümeme ve özyineli olmayan çözümleme. Sorgularda gönderilen RD (recursion required - özyineli gerekli) bitlerine göre sorgunun türü belirlenir. Özyineli olmayan sorgulara cevap veren sunucular cevap olarak ardışık isim sunucuları verirler.
Sonuç olarak yapılan bir sorgu özyineli değil ise http://google.com.tr için doğrudan 72.14.221.104 IP'si ya da "makina bulunamadı" cevabı verilebilir. Fakat özyineli bir sorguda cevabı bulmak için başka bir isim sunucusunun IP'sini verebilir.

Authoritive Nameserving (Yetkili İsim Sunumu)

  • Bir alan hakkında bilgi bulunduran sunucudur. Mesela yildiz.edu.tr alanının MX (Mail eXchanger), NS (Name Server), A (Address)(Bunlar - Resource Record - Özkaynak Kaydı olarak bilinir) kayıtlarının tutulduğu isim sunucusudur
"
(Wikipedia)

Recursive ve Authoritative DNS Yapısı ve Farkları

"
DNS Unicast olarak çalışır. İki tip sorgu tipi vardır, bunlar ;
Recursive : Kullanıcılar ( Clientlar ) DNS’e genellikle Recursive sorgu yaparlar. Client soru sorduğunda DNS Server bunu bulmak zorundadır. Cevabı bilmiyorsa bile bunu çeşitli sorgularla halletmeye çalışır ve mutlaka cevap vermek zorundadır. Bu Recursive sorgudur.
Iterative : Kullanıcı ( Client ) DNS Server’a Recusive sorgu atar. DNS root’a(noktaya) sorgu yaptığında bu iteratvie sorgudur. Çünkü DNS’in ROOT’a yaptığı sorguda ROOT sadece yönlendirme yapar. Tüm cevabı vermez. DNS başka bir kendi Domain’i dışındaki DNS’e Iterative sorgu sorar.

İkisi arasındaki en önemli fark Recursive sorgu sorgulanan çözümlemeyi DNS Server’a sonucu bulmaya zorlar, Iterative sorgu cevabın bulunmasına zorlamaz. Yönlendirmeyle geçiştirilebilir. Recursive sorgu yorucu olduğu için genelde kapalı tutulur.
DNS Server her sorguya cevap vermeyebilir. Authoritative Dns’ler cevap verebilir. Bu, cevap vermek yetkisine sahip olmak anlamına gelir. Cevap vermeye yetkisi olmayanlar ise Non – Authoritative DNS’lerdir. Non – Authoritative DNS’ler cevap veremez ama yönlendirme yaparlar. Her isim için için ayrı ayrı yetki mekanizması vardır ve her isim için ayrı ayrı authorization(yetkilendirme) vermek gerekir. DNS bir isimden yetkiliyken üstünde tanımlı başka bir isimden yetkili olmayabilir, bu da SOA kayıtları sayesinde belirlenir
"
(System Network)


Bu bilgilerden anlaşılacağı üzere kısaca özetlersek , siz bir alan adına girerken alan adı için istekte bulunursunuz örneğin google.com.tr arka planda yönlenen kısımda bilgisayarınız yerel dns leri üzerinden belirli bir ip ye istek gönderir. İstek gönderilen sunucu da bunu name serverlarında google.com.tr olarak çözümler ve sizi google.com.tr hangi name serverın ipsinde A değerinde tanımlı ise o sayfayı gösterir. (Detaylı bilgi için Sunucularda Name server yapısına bakınız). Eğer siz bir domain alan adını yönetmek isterseniz bunun için bir host tanımlamak gerekir ve siz bu host için name server lar tanımlamak durumundasınızdır.
Genelde websitesi olan arkadaşlar name serverlarının yönetiminde belirli bir host üzerine geçmek için bu değerleri domain firmasından değiştirirken arka planda neler gerçekleştiğini bilmez.
Örneğin google.com.tr için tanımlanan name serverlar ,
ns1.google.com
ns2.google.com
ns3.google.com
ns4.google.com
Şeklindedir. google.com serverlarında domain firmasından bu name serverlara yönlenen domainler işlenir. Yani arka planda A , MX gibi kayıtların tutulduğu ayrı ayarlar tanımlıdır. Ve bu ip ye gelen istekler gerekli domaine iletilir ve google.com serverında işlenir. Arka planda ns1.google.com ns2.google.com ns3.google.com ve ns4.google.com da bir sürü ayrı tanımlamalar mevcuttur bunlar server kurulumunda yapılan ayarlamalardır.
Yani siz bir domaine istek gönderdiğinizde bu domain sayfası açılması sürecinde sunucuya istek gönderilirken bu sorgu bir sürü yapı üzerinden çok hızlı bir şekilde geçerek ve işlenerek servis sağlanır.

Dns sistemini korumanın sadece belirli bir alanı korumak değil tamamiyle bir güvenlik dizisi alarak birbirine bağlı değişkenlerden oluştuğunu bilmek gerekiyor.
Örneğin tek başına DNSSec (DNS Security Extensions), in yeterli olmadığının bilinmesi belki de bu konudaki güvenlik konusuna giriş için en temel sebep oluyor. DNSSEC, DNS cache dediğimiz yani önbellek zehirleme gibi saldırılara karşı geliştirilmiş güvenlik eklentilerinden oluşan bir yapıdır. Fakat çoğu kişinin yanıldığının aksine DNSSEC , DDoS adını verdiğimiz Distributed Denial of Service ataklarına karşı bir koruma aracı değildir.
Burada belirtmemiz gereken şeylerden birisi de bir ülkenin internetini kesmenin yolunun DNS yapısına saldırmaktan geçtiğini bilmeyenler Turk Telekom , TIB  (Telekominikasyon iletişim başkanlığı) gibi sistemlerin websitelerine saldırarak kesilebileceğini iddia etselerde bu DNS yapısından bihaber kişilerin uydurduğu asparagas haberlerden biridir. Nitekim bununla ilgili haberleri de ülkemizde geçtiğimiz günlerde gördük.
Karıştırılmayacak konulardan bir tanesi de Turk Telekom gibi sistemlerin DNS yapısı ile Nic.tr gibi sistemlere domain yönetimi için verilen dns ler farklıdır. Buna dikkat etmemiz gerekiyor. Bu terimleri anlamak için DNS Query aşamaları , tipleri gibi konular dikkatlice incelenmelidir.
Dns başlı başına sizin bilgisayarınızdan çıkıştan itibaren alan adı üzerine varıncaya kadar yani Client ten servera bir sürü yapılarından geçen her alanda var olan bir yapıdır.
Yani dns ağ bağlantılarınızdan bazı engelli sitelere ulaşmak için değiştirdiğiniz ip aralıklarından ibaret değildir...

Gelelim DNS Hijacking işlemine...

Dns Hijacking Nedir ?

Dns hijacking ise üstte bir çok noktada tamamını anlatmadığım DNS yapısının her hangi bir devresinde
- Gerek merkez dns ler üzerinde , gerek kök dns sunucularda , gerek name serverı yönettiğiniz domain paneli üzerinde , gerekse host üzerinde name serverlarin tanımlı olduğu alanda  -  değişiklik yapılmasını sağlayan hacking türüdür.

Eğer siz her hangi bir websitesinin name server larının yönetimini ele geçirirseniz bu alan adının yönetiminin tamamen ele geçirildiği anlamına gelir. Önceleri Domain Hacking ismi verilen domain haklarının illegal yollarla üzerine geçirilmesi işleminin , günümüzde hak sahipliği anlaşmaları ile garantiye alınarak domainin asıl sahibinin geri alması üzerinde birçok kolaylıklar sağlandığını biliyoruz. Dns hijacking işleminde siz domain hak sahipliğini geçici süre alsanız bile bu kısmi domain hack olur ve domainin yönetimini kısa süreli de olsa elinizde bulundurmuş olursunuz.
Burada dikkat edilmesi gereken şeylerden bir tanesi de şudur. Dns Hijacking işlemi Dns Spoofing ile kesinlikle karıştırılmamalıdır. Arp saldırılarından olan Dns spoofing işleminde olay yerel dns lerle alakalıdır ve genelde yerel networkü ilgilendiren bir konudur.

Dns Hijacking ile neler yapılabilir?

Dns hijacking işlemi ile yapılabilecekler o kadar fazla ki şuan için hepsini saymak çok güç. Bu tamamen bu saldırıyı yapan kişi yada kişiler ile alakalı olabilecek bir durumdur. Örneğin , Bir ülkenin ülke alan adlarının yönetiminin olduğu name serverlara kötü niyetli saldırı yaparak başarıya ulaşan bir kişinin yapabileceklerinden bazıları...

* Öncelikle dış devlet destekli profesyonel bir saldırıda yapılabilecek ilk şey, ara name server sunucusu kullanıp yüksek trafiğe sahip bir Cloud Hosting sistemi ile kimsenin ilk başta bişey farketmemesini sağlayarak bir süre saldırının boyutunu arttırmak olurdu.
* Cloud hostingin bu saldırıda kullanılma amacı, dnslerin yönetimi değiştirilen name serverların gönderildiği alan adı üzerinden süzülerek hedef sitenin gerçek dns sunucusuna aktarılmasıdır ve bu şekilde yapılan bir saldırıda da bütün mailleşmeler dahil tüm istekler belirli bir süzgeçten geçirilerek gerçek sunucuya aktarılır. Bir nevi arada tüm kontrolleri ve incelemeleri yapan bir ara sunucu görevini görür ve gerçek adrese istekler normal olarak gittiğinden dolayı da ilk bakışta birşey anlaşılmaması sağlanır.

* Sadece Cloud Hosting servisi olmadan da direkt olarak sıradan name serverlarda tanımlı fake sayfalara yönlendirilerek kullanıcı bilgileri , şifreleri çalınması amaçlanabilir.

* Böylesine büyük organize bir saldırıda hedefte olabilecek başlıca önemli sistemler sırasıyla şunlardır:

~ O ülkenin tüm internet alt yapı sistemi
~ O ülkenin E-Devlet sistemi
~ Para , Döviz vs. işlemleri yapılan internet bankacılığı sistemleri
~ Mailleşmeleri dinlenmek üzere kurulan sistemin kurbanı olabilecek askeri , istihbarat birimleri , başbakanlık birimleri , kısacası devlet kurumlarının istisnasız tamamı...
~ Spekülasyon haber yapılarak ülkenin borsa da darbe almasına neden olacak resmi basın yayın organları ve ajanslar...
~ Ünlü ticari markalarının tamamı...
~ Federasyonlar , Dernekler , Önemli kuruluşlar...

Kısacası hacker filmlerinde gördüğünüz tüm senaryoyu abartısız yaşamak mümkün olurdu...
O yüzden geçtiğimiz gün yaşadığımız olaydan sonra Dns saldırılarını küçümseyenlere ve basite indirgeyenlere inat diyeceğim tek şey şudur...
Bir ülke için DNS candır , DNS namustur...

 ~ Emrullah Akdemir - 06.05.2012


Alexa Değeri