Stack Buffer Overflow Exploit Yazma - ret2libc / Pentester

Video konu sonunda!

Bu konuda, exploit dünyasında çok yaygın olan Stack Based Buffer Overflow zafiyetini inceleyip, exploitini geliştireceğiz.

Stack Buffer Overflow Nedir?

Stack Buffer Overflow, Yığın tabanlı hafıza taşma açığı demektir. C programlarında, değişkenlere kapasitelerinden daha fazla veri yazmaya çalışırsak, crash olayı gerçekleşir. Daha sonra programın akışını değiştiririz. Bu akışı shellcode'a yönlendirirsek istediğimizi elde edebiliriz. Bu işlemleri yapabilmek, test edebilmek için debugger yazılımları kullanırız. Ben Kali Linux dağıtımında bulunan, gdb debugger ile işlem yapacağım. Zafiyetli C programımızın kaynak koduna bakalım.



Argüman olarak bir değer alınıyor, ardından bu değer fonksiyon içerisinde tanımlanan buf isimli 48 baytlık alana kopyalanıyor. Bizde eğer, 48 byte'dan yüksek veri girersek programa, Stack Buffer Overflow zafiyeti oluşuyor.

Bir Buffer Overflow işleminde genellikle, overwrite edilen EIP registerından sonra, ESP registerına shellcode yazılır, stack içerisinde, shellcode'dan önce ise bulunan adres, EIP'ye yazılır ve ESP registerındaki shellcode'a atlanır. Stack BoF exploit geliştirme işlemlerinde genellikle, JMP ESP gibi ESP adresine jump yapan bir instruction kullanılır, ki bu sayede exploit işlemi çok çok basitleşir.

Örnek vermek gerekirse, uygulamanın içersinde kullandığı library'de, JMP ESP instruction aranır, bu adres EIP'ye yazılır, sonra shellcode eklenir, ve shell kabuğuna erişilir. Ancak benim yapacağım uygulamada, "NX=No Executable" adlı bir koruma olduğundan stack içerisinde olan shellcode'a atlama işlemi mümkün olmuyor, o yüzden bizde; "retINTOlibc", diğer adıya "ret2libc" tekniğini uyguluyoruz.

Şimdi fazla laf kalabalığını bırakıp, explotimizi geliştirelim. Öncelikle ASLR adlı koruma mekanizmasını kapatalım. Bunun için;


komutu uygulanır, ardından;



Artık ASLR koruması kapalı ve exploit geliştirilebilir. GDB Debugger ile vuln adlı programımıza girelim, ve çalıştıralım.






NX korumasını kontrol edelim. Aktif olduğunu görüyorsunuz.



Ardından uygulamaya 48 byte'dan daha büyük veri yazıyoruz, benim denemelerim sonucu tam 70 byte ile EIP registerını kontrol edebiliyoruz.



Tam 70 tane A karakteri gönderince, stack BoF oluşuyor. EIP registerının durumuna bakalım.



"0x41414141" yani "A" karakterlerimizin, hex karşılığı demek oluyor, yani başarılı şekilde EIP'ye yazdık. Şimdi ise, hangi değerden sonra EIP adresini kontrol edebiliyoruz,
yani offset sınırı kaç onu bulalım. Ben deneme yanılma ile, tam 60 karakterden sonra girilen 4 byte'ın EIP registerına düştüğünü tespit ettim, inceleyelim.



60 adet A karakterinden sonra, 4 adet B karakteri yazınca, EIP registerı,
"0x42424242" değerini yani B karakterini işaret ediyor. Yani offset: 60



EIP registerını kontrol edebildiğimize göre, şimdi ret2libc tekniği ile exploitimizi geliştirelim. Benim uygulamada arayacaklarım;


Bu şekilde exploitimizi gerçekleştirip, "/bin/sh" çalıştırıp, shell kabuğuna düşeceğiz. Şimdi, tek tek, fonksiyonlarımızın adresini bulalım.



System ve exit fonkiyonlarından sonra, library içersindeki /bin/sh string adresini yazınca shell elde edeceğiz.



Adresleri yazış şeklime dikkat edin! "\x" den sonra, sondan başlayıp 2 karakteri yazarak başa geliyoruz.

Stack Buffer Overflow Exploit - ret2libc Tekniği


Bu exploitleri, serverlara yazmak için ise, python ile ekstra olarak, socket iile bağlanarak, test edip, gerisi aynı işlemler uygulanarak, python exploit scriptinizi yazarak, shell alabilirsiniz. Ben zafiyetli program ile aynı sistem içinde olduğum için, python socket ile yazmadım explotii.

Herhangi bir hatam olduysa kusuruma bakmayın, umarım yararlı olmuştur. En kısa sürede video gelecek.

VİDEO

[ame]https://www.youtube.com/watch?v=mRsI-y6K8VQ&feature=youtu.be[/ame]

Emeğine Sağlık Çok Güzel Konu Olmuş.

Gözlerim böyle şeyleri görmeye alışık değil, lütfen bu kadar güzel konularla gelme alışmam gerek. :trl
Ellerine sağlık.

Emeğine sağlık fazla yararlı bir konu

emr3q' Alıntı:

Fazla Ezbere Geldi Neyse Emeğine Sağlık

Genişletmek için tıkla ...

Olayın sadece istismar kısmı ancak bu kadar anlatılabilirdi diye düşündüm Yoksa, exploit geliştirme işlemlerinde çok çok ekstra bilgi veriliyor, registerlar vs. Ama ben sade ve kısaca anlatmaya çalıştım. Teşekkür ederim yorumun için

Ellerine sağlık

Eline Sağlık

Eline sağlık keşke bu konuları daha önceden açsan ve hemen farketseydim o sıralar m.e.t.a.s.p.l.o.i.t'le çok uğraşırdım

Only RevenGe' Alıntı:

Eline sağlık keşke bu konuları daha önceden açsan ve hemen farketseydim o sıralar m.e.t.a.s.p.l.o.i.t'le çok uğraşırdım

Genişletmek için tıkla ...

Métasploitle mi uğraşırdın bu anlattığım olay, stack buffer overflow exploit geliştirme olayı, yani métasploit içerisinde yayınlanan bu tür zafiyetlerin nasıl oluştuğu ve nasıl exploit geliştirildiğini anlarsın aslında. Teşekkür ederim

Bilgi için teşekkürler, isminizden ve açtığınız konulardan dolayı buradan bir soru sormak istiyorum size.
Merak ettiğim şu bu buffer overflow'lar neden oluşuyor yani tamam nedenini biliyor ayrılan bellekten fazla input girince stack arasına çıkıyor girdiler ve komut olarak işleniyor kabaca ama yani C'de illa byte aralığı mı vermek zorundayız, e illa vermek zorundaysak bu belleği yormaz mı, başka bir yolu yok mu bunu önlemenin ve varsa da neden büyük şirketlerin popüler programlarında bile sıklıkla exploitler çıkıyor?

TurkishAttacker' Alıntı:

Bilgi için teşekkürler, isminizden ve açtığınız konulardan dolayı buradan bir soru sormak istiyorum size.
Merak ettiğim şu bu buffer overflow'lar neden oluşuyor yani tamam nedenini biliyor ayrılan bellekten fazla input girince stack arasına çıkıyor girdiler ve komut olarak işleniyor kabaca ama yani C'de illa byte aralığı mı vermek zorundayız, e illa vermek zorundaysak bu belleği yormaz mı, başka bir yolu yok mu bunu önlemenin ve varsa da neden büyük şirketlerin popüler programlarında bile sıklıkla exploitler çıkıyor?

Genişletmek için tıkla ...

Bu zamana kadar birçok koruma mekanizması geliştirilmiş, ASLR, DEP, CANARY, NX vs. Ama hackerlar'da rahat durmuyor ki, bunları da bypass ediyorlar, şuan da anlattığım konuda, hem ASLR koruma mekanizmasının kapatılması, hem No Executable adlı, stack'te shellcode çalıştırılmasına izin verilmeyen koruma mekanizmasının da atlatılmasını zaten ret2libc adlı bir teknikle gerçekleştirdik.

Bu zafiyet, zafiyetten haberi olmayan geliştiriciler olduğu sürece sıklıkla karşılaşılacaktır.
Önlemi için, strcpy() fonksiyonunun kullanımı yerine, strncpy() gibi güvenli fonksiyon tercihi yapılabilir. Yine bahsedilen koruma mekanizmalarının olması da önlem için etkili olur. Yine değişkenlerin sınır kontrollerinin yapılması gerekmektedir. bigiguvenliği.gov.tr'de bunun önlemi ile ilgili bir yazı bulunmakta, bakabilirsin.

Video konuya eklenmiştir.

dostum ellerine sağlık tam ilgimi çeken bi konu olmuş

Ellerine sağlık

Yeterince güzel anlatım ve bir okadar yararlı konu.

Eline sağlık güzel içerik olmuş

Belvando' Alıntı:

Yeterince güzel anlatım ve bir okadar yararlı konu.

Genişletmek için tıkla ...

Sağolasın ortak

macspace' Alıntı:

Eline sağlık güzel içerik olmuş

Genişletmek için tıkla ...

O kadar sevmissin ki, bunu iki kere yazdığından anlıyorum sağolasın

Eline sağlık:trl

Ellerine Sağlık Dostum Abone Oldum Konuna :trl

konu için teşekkürler

ellerne sağlk