Ders 6 - Command Injection (High Level)
Bu yazıda güvenlik düzeyi High seviyesine yükseltilmiş DVWA'ya karşı Command Injection saldırısı yapılabilir mi yapılamaz mı sorusunun cevabı irdelenecektir.

Konuya giriş yapmadan önce bu yazının dahil olduğu dvwa eğitim serisindeki tüm makalelere şu adresten


bu yazının ilintili olduğu dvwa eğitim serisindeki diğer makalelere ise şu adreslerden


erişebilirsiniz.

Dersin Hedefi

Command Injection önlemlerinde yapılabilecek bir hata örneğine göz atın, atlatın ve command injection'a karşı nasıl korunulurun cevabını keşfedin.

Command Injection'a Karşı Önlemi Atlatma

İlk Command Injection dersinde bir command injection saldırısında bulunmuştuk ve bir sayfa hack'lemiştik. İkinci Command Injection dersinde seviyesi arttırılmış güvenliği atlatmanın yolunu göstermiştik. Bu Command Injection dersinde ise seviyenin bir kademe daha yükseltildiği bir sayfanın güvenliğini nasıl temin ettiğine bakacağız. High Level'ın kaynak kodu şu şekildedir:

Command Injection (High Level): 

<?php 

if( isset( $_POST[ 'Submit' ]  ) ) { 
    // Get input 
    $target = trim($_REQUEST[ 'ip' ]); 

    // Set blacklist 
    $substitutions = array( 
        '&'  => '', 
        ';'  => '', 
        '| ' => '', 
        '-'  => '', 
        '$'  => '', 
        '('  => '', 
        ')'  => '', 
        '`'  => '', 
        '||' => '', 
    ); 

    // Remove any of the charactars in the array (blacklist). 
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

    // Determine OS and execute the ping command. 
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) { 
        // Windows 
        $cmd = shell_exec( 'ping  ' . $target ); 
    } 
    else { 
        // *nix 
        $cmd = shell_exec( 'ping  -c 4 ' . $target ); 
    } 

    // Feedback for the end user 
    echo "
{$cmd}
"; 
} 

?>


Güvenlik Medium seviyesinde iken sadece && ve ; karakterleri metin kutusundan gelen veriden siliniyordu. Güvenlik High seviyesinde iken yukarıdaki $substitution dizisinden de görülebileceği gibi silinecek operatörlerin sayısı arttırılmıştır. Şimdi bir önceki derste kullandığımız sofistike yöntemin bu güvenlik seviyesini geçip geçemediğine bir bakalım. Geçen derste güvenliği atlatan kod şu şekilde idi:

1 &;& cat /etc/passwd

Bu numara bu sefer sökmeyecektir. Çünkü filtrelenecekler listesinde bu sefer && silinsin denilmemiş, & silinsin denilmiş. Dolayısıyla yukarıdaki kod str_replace() fonksiyonundan geçince şu hale dönüşecektir:

1 cat /etc/passwd

Yukarıdakini alan shell_exec() fonksiyonu bunu bir IP adresi diye alacaktır ve bu yorumlanamayacağı için de komut satırı hata verecektir ve bir çıktı döndürmeyecektir. Sonuç olarak ekrana enjekte edilmesini umduğumuz cat komutunun çıktısı yansımayacaktır.

Fakat kara liste güvenlik önlemine daha dikkatli bakalım. Web uygulama "high" güvenlik seviyesinde bu sefer farklı bir nedenden dolayı gol yiyecektir ve hack'lenebilir olacaktır.

11nci satırda | karakterini silme işlemi yerine | ve (boşluk) karakter dizisini silme işlemi uygulanmaktadır. Yani | operatörünün sağına klavye yazım hatası nedeniyle black list güvenlik önleminde boşluk karakteri eklenmiş. Bu hata saldırganların boşluk girmeden | karakterini kullanabileceği anlamına geliyor. Yani boşluk girmeden | karakterini kullanarak saldırganlar halen command injection saldırısı yapabilirler.

Örneğin high seviyede command injection metin kutusuna sonrasına boşluk bırakmadan enjekte edilecek komut girildiğinde sonuç başarılı olacaktır. 

1 |cat /etc/passwd


veya 

1|cat /etc/passwd


Bu iki kullanım ile de high seviye güvenlik önlemi atlatılabilecektir ve enjeksiyon çalışacaktır.







Shell kodlamasında | operatörü ilk komutun stdout'unu sonraki komutun stdin'ine aktarmaya yarar. Yani ilk komutun çıktısı | operatörü ile ikinci komutu girdi olarak verilir. Burada ilk komut ping 1'dir. Bu komuttan gelen hata çıktısı enjekte ettiğimiz cat komutuna aktarılacaktır, fakat cat komutu arguman olarak /etc/passwd aldığından bu ilk komuttan gelen çıktıyı ele almayacaktır. Kendi çıktısını ekrana verecektir. Sonuç olarak | operatörü ile de enjeksiyonu kesintisiz şekilde sürdürebilmekteyiz.

Command Injection'a Karşı Önlem

High güvenlik seviyesinde yazım hatası yapılabileceği durum ele alınmıştır. Peki bu hatayı da yapmamış olsaydık bu güvenlik bizim için yeterli miydi? Cevap hayır. Daha da sıkı bir güvenlik önlemi vardır. Impossible seviyesine bir göz atalım.

Command Injection (Impossible): 

<?php

if( isset( $_POST[ 'Submit' ]  ) ) {
    // Check Anti-CSRF token
    checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

    // Get input
    $target = $_REQUEST[ 'ip' ];
    $target = stripslashes( $target );

    // Split the IP into 4 octects
    $octet = explode( ".", $target );

    // Check IF each octet is an integer
    if( ( is_numeric( $octet[0] ) ) && ( is_numeric( $octet[1] ) ) && ( is_numeric( $octet[2] ) ) && ( is_numeric( $octet[3] ) ) && ( sizeof( $octet ) == 4 ) ) {
        // If all 4 octets are int's put the IP back together.
        $target = $octet[0] . '.' . $octet[1] . '.' . $octet[2] . '.' . $octet[3];

        // Determine OS and execute the ping command.
        if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
            // Windows
            $cmd = shell_exec( 'ping  ' . $target );
        }
        else {
            // *nix
            $cmd = shell_exec( 'ping  -c 4 ' . $target );
        }

        // Feedback for the end user
        echo "<pre>{$cmd}</pre>";
    }
    else {
        // Ops. Let the user name theres a mistake
        echo '<pre>ERROR: You have entered an invalid IP.</pre>';
    }
}

// Generate Anti-CSRF token
generateSessionToken();

?>
12, 15 ve 17nci satırlarda çok sıkı bir güvenlik tedbiri alındığını görebilirsiniz. Girdi olarak gelen veri önce . karakterine göre parçalara (veri gerçekten de ip ise 4 parçaya) ayırılıyor. Her parça sayı mı diye kontrol ediliyor. Ardından kontrol edilen parçalar birleştiriliyor ve shell_exec() fonksiyonuna bu denetim sonrası veriliyor. Burada alınan önlem teorik açıdan daha sıkı bir önlemdir ve aşılamazdır. Dolayısıyla geliştiriciler command injection zafiyetlerine karşın bu v.b. beyaz liste önlemlerine başvurmalıdırlar.

Sonuç

Güvenlik Medium seviyesinde iken kara liste diye tabir edilen güvenlik prosedürü uygulanmıştır. Yani kara listede olanları filtrele, gerisini salıver mantığı... Bu yazının konusu olan High seviyesinde ise yine kara liste yöntemi uygulanmıştır, fakat kara listenin kapsamı genişletilmiş ve daha hassas oluşturulmuştur. Güvenlik camiasında bir de beyaz liste ile güvenlik sağlama yöntemi vardır. Bu yönteme göre sözgelimi metin kutusundan gelecek veri içerisinden beyaz listede olanları çek, gerisini sil mantığı güdülür. Kara liste ise bunun tam tersidir: "Kara listede olanları sil, gerisini çek". Güvenlik uzmanları tarafından beyaz liste önerilmektedir. Çünkü en kaliteli ve sağlam güvenlik beyaz liste ile temin edilebilir. Kara liste güvenliği belli bir miktar sağlar, fakat gelecekte gelebilecek yeni tür ataklara karşı savunmasızdır.
Bu yazı 15.01.2016 tarihinde, saat 16:36:40'de yazılmıştır. 23.03.2025 tarihi ve 05:59:53 saatinde ise güncellenmiştir.
Yazar : Hasan Fatih ŞİMŞEK Görüntülenme Sayısı : 3649
Yorumlar
Henüz yorum girilmemiştir.
Yorum Ekle
*
* (E-posta adresiniz yayınlanmayacaktır.)
*
*

#Arşiv

#Giriş
ID :
Şifre :