10 Haziran 2012 Pazar

Uzaktan Dosya Ekleme (RFI)

Uzaktan Dosya Ekleme (RFI) ataklarına karşı zayıflıkları olan kod, saldırganın sunucunun güvenliğini tehlikeye düşürebilecek kadar tehlikeli düşmanca kodlar ve veriler yüklemesine yol açar. Kötü amaçlı dosya çalıştırılması kullanıcıdan dosya adı veya dosya kabul eden PHP, XML veya herhangi bir çerçeveyi (framework) etkileyebilir.

Zararlı dosya çalıştırma zayıflığı, çok sayıda uygulamada bulunur. Bu açık, geliştiricilerin çoğunlukla sisteme girilen dosyalara güvenmelerinden kaynaklı olduğundan, potansiyel olarak zararlı olabilecek girişler ile buna bağlı fonksiyonları da beraberinde kabul etmelerinden kaynaklanır. Birçok platformda kullanılan uygulamalarda, URL'ler veya sistem kaynakları gibi, dış kaynaklı nesnelerin kullanımına izin verilir. Veriler yeterince incelenmediğinde, izinsiz erişimlere ve kötü niyetli içerik ile web sunucuya istek göndermeye neden olur.


Bu saldırgana aşağıda belirtilenleri yapma izni verir:
Uzaktan kod çalıştırma
Uzaktan rootkit kurma ve sistemin tamamını ele geçirme

Windows üzerinde, PHP'nin SMB dosyası kullanılarak dahili sistem ele geçirilebilir.
Bu saldırı özellike PHP'de yaygındır, ve üst düzeyde dikkat gerektirir. Bu açık tipi, stream veya dosya fonksiyonu kullanılması ile önem kazanmaktadır. Burada kullanıcı kaynaklı dosya isimleri kullanıcının inisiyatifine bırakılmaması gerekir.

Ortak zayıflık yapısı:

include $_REQUEST['filename’];

Bu sadece uzaktaki saldırgan betiklerin değerlendirilmesini sağlamaz,aynı zamanda yerel dosya sunucularına erişmesini (Eğer PHP Windows işletim sistemi üzerinde çalışıyorsa) PHP'nin dosya sistemindeki SMB desteğinden dolayı sağlar.

Saldırı içeren diğer yöntemler:
1. Kötü niyetli oturum dosyaları, günlük verileri veya resimler sisteme yüklenen platformlar (Tipik forum yazılımları)

2. Sıkıştırma veya gerçek zamanlı ses yayını yapmakta kullanılan, zlib:// veya ogg:// gibi PHP URL bayrağının incelenmediği ve uzaktan kaynak kullanımına ( _url_fopen veya allow_url_include ) izin verildiği platformlar.

3. php://input veya POST isteğinden veri alınan PHP wrapper'ları kullanıldığında

4.PHP verisi kullanıldığında : wrapper, data:;base64,PD9waHAgcGhwaW5mbygpOz8+ gibi…

Bu liste daha da uzatılabilir. (ve periyodik olarak güncellenebilir). Burada önemli olan, güvenliği sağlam olarak tasarlanmış bir yapıda, kullanıcı kaynaklı veri girişlerinin, sunucu tarafındaki dosya isimleri ve erişimleri ile etkileşimini göz önünde bulundurmaktır.

PHP örneklerine karşın bu saldırılar farklı yollarla .NET ve J2EE platformlarına da yapılabilir. Bu platformlarda uygulamalar yazılırken özellikle kod erişim güvenliği mekanizmasına dikkat edilmeli,dosya isimleri ihtiyacı karşılayacak biçimde yapılandırılmalı ve kullanıcıya güvenlik kontrollerine etki edebileceği izinler verilmemelidir.

Örneğin, bir saldırgan XML ayrıştırıcısını kullanarak kötü niyetli bir DTD nesnesini yükleyebilir. Bir Avustralyalı güvenlik firması bu yöntemi kullanarak, güvenlik duvarının ardındaki ağ kapılarının (port) nasıl tarandığını göstermiştir.

Bu zayıflıktan kaynaklı oluşacak hasar, kullanıcının erişim bölgeleri ile sistemin arasındaki izolasyonun kontrolü ile direk ilişkilidir. PHP çok düşük bir izolasyona sahiptir ve kullanıcı erişim bölgesi yapısında veya güvenlik mimarisinde böyle bir izolasyon yoktur.

Zararlı olabilecek saldırılar diğer platformlarda sınırlı veya kısmen güvenlidir. Kapsamlı bir kullanıcı erişim bölgesi bir JVM platformunda, güvenlik yöneticisi çalışır durumda ve doğru bir şekilde yapılandırılmış ise mümkündür.

Uzaktan çalışabilir içeriğin önlenmesi için uygulama mimarisinin ve tasarım evrelerinin dikkatle planlanması ve tam bir testten geçmesi gerekmektedir. Genellikle, iyi yazılmış uygulamalar kullanıcı kaynaklı veri girişlerinde dosya ismi ve herhangi sunucu tabanlı kaynakların ( örneğin resimler, XML ve XLS dönüştürülmüş dokümanlar veya betik eklentileri) kullanımına izin vermemenin yanında, güvenlik duvarına, İnternet veya yerel ağ ile diğer sunuculara yeni bağlantılar oluşturulmasını engelleyen kurallar eklenmelidir. Bununla beraber, kullanıcı kaynaklı girişlerde ihtiyaç duyulan uygulamalar çalışmaya devam edecektir.

Dikkat edilmesi gereken noktalar :
● Bir dolaylı nesne referans haritası kullanın (Indirect Object Reference Map)
Örneğin, bir dosya ismi bir kez kullanılsın ve referans olarak kullanılacak bir bölüm HASH değerini sağlasın.
<select name=”language”>
<option value=”English”>English</option>
 Yukarıdaki “tag” yerine
<select name=”language”>
<option value=”78463a384a5aa4fad5fa73e2f506ecfc”>English</option>
kullanımı gibi.

Dolaylı nesne referanslarının birer birer deneme (brute force) saldırısı ile zayıflayacağı dikkate alınmalıdır. Buna alternatif olarak, 1,2,3 gibi bir indeks değeri kullanan ve sıralı bir şekilde devam eden parametreler kontrol edilebilir.

● Belirgin bir kusur kontrol mekanizması kullanın: Kullandığınız dil destekliyorsa, kusur kontrol mekanizması kullanın. Başka bir şekilde bir değişken isimlendirme şeması yardımıyla kusurları kontrol edin :
$hostile = &$_POST; // refer to POST variables, not $_REQUEST
$safe[‘filename’]= validate_file_name($hostile[‘unsafe_filename’]); //
make it safe

Bu yüzden, kötü niyetli operasyonlar açıkça tanımlanmalı:
require_once($_POST[‘unsafe_filename’] . ‘inc.php’); (Yanlış)
require_once($safe[‘filename’] . ‘inc.php’); (Doğru)

● Kullanıcı girişlerini kontrol edecek güçlü mekanizmalar kullanın ve gelen verinin "iyi olduğu kabul edildi" stratejisi oluşturun.

● Firewall'a kurallar ekleyin :  Harici web sitelerine ve dahili sistemlere yeni bağlantıları engelleyecek firewall kuralları oluşturun. Yüksek güvenlikli sistemler için, VLAN veya özel alt ağ (subnet) ile web sunucusunu izole edin.

● Kullanıcı kaynaklı dosyaları ve dosya isimlerini kontrol edin: Kontrol etmenin yanında diğer kontrolleri devre dışı bırakın, örneğin oturum nesnesindeki veriler bir kusurdur. Bunun yanında değişkenler, resimler, PDF raporları ,geçici dosyalar,vb. içerikte kusur içerecektir.

● Bir  chroot veya diğer kullanıcı alanı tanımlama mekanizmaları  kullanılmalı.  Diğer uygulamalardan kullanıcıları izole edebilecek sanal makine yapısı kullanılabilir.

● PHP: allow_url_fopen ve allow_url_include değerlerini, php.ini dosyasından kapalı duruma getirin ve PHP'nin bu fonksiyonu yerel olarak içermediğini de kontrol edin. Birkaç uygulama için, bu işlev ve ayarlar açık olması gerekebilir.

● PHP: register_globals değerini kapatın, E_STRICT değerini kullanarak başlangıç değerinde olmayan değişkenleri bulun.

● PHP:  Bütün dosyaları ve stream fonksiyonlarını  (stream_*)  dikkat ile inceleyin.Bu fonksiyonlar kullanıcıların gönderdiği  veriler içerisinde herhangi bir dosya ismi  argümanı almamasını sağlamak amacıyla kontrol edilmelidir:
include()   include_once()   require()   require_once()   fopen()
imagecreatefromXXX()   file()   file_get_contents()   copy()   delete()
unlink() upload_tmp_dir() $_FILES move_uploaded_file()
Kullanılan dil için belirli öneriler:

● PHP: system() eval() passthru() veya backtick operatörü içeren veriniz varsa çok dikkatli olmanız gerekmektedir.

● J2EE için "güvenlik yönetimi" çalışır durumda olmalı ve düzgün bir biçimde yapılandırılmalı, uygulamanın izinleri gözden geçirilmelidir.

● ASP.NET için güvenlik dokümanlarını okuyun. Uygulamanızı tasarlarken parçalara ayırarak güvenliğini sağlayın, böylece uygulamanızın  büyük bölümü içerisindeki olası zayıflıkları izole edebilirsiniz.

Hiç yorum yok:

Yorum Gönder