Skip to main content

Write UP kksi pwn Exnow ヽ(゚Д゚)ノ (day 42)


2 hari yang lalu ada senior saya yang bermurah hati untuk ngasih soal CTF pwn dari kksi yang yang baru aja selesai. Karena merasa tertarik, ini saya bikin write up tentang challenge lagi biar yang lain bisa belajar lagi tentang CTF kategori pwn.

Langsung lanjut aja tanpa basa-basi yah

seperti biasa kita dapat sebuah file binary yang merupakan tipe ELF 64 bit


Kalau dijalanin seperti biasa, minta input dan ga keluarin apa2:


Ok kita langsung aja taruh di peda biar langsung kita analisa:


oke jadi di main functionnya itu dia manggil function nono, coba kita telusuri lebih lanjut lagi:


di dalam fungsi nono sendiri memakai function read untuk mebaca apa yang dimasukan oleh user, ini sedikit unik karena function read sendiri tidak memiliki kelemahan buffer overflow karena mempunyai "batasan" berapa bytes yang harus di baca oleh fungsi itu.

teman-teman bisa cek fungsi ini lebih detail dengan memakai "man read" di linux.


seperti yang diperlihatkan gambar diatas, read mengambil 3 parameter pertama untuk mengecek "file descriptor", kedua adalah variable yang menampung isi dari apa yang kita masukan dan ketiga adalah berapa besar function read akan membaca bytes yang harus dibaca.

walaupun read() dianggap tahan dengan buffer overflow karena ada "batasan" tapi tidak semudah itu, function ini tetap rentan jika programmer tidak jeli untuk mengalokasikan besar bytes yang harus dibaca.


mari kita teliti apa yang saya maksud:


Mari kita lihat instruksi "LEA" terlebih dahulu, intruksi ini sering dipakai agar program bisa mengalokasikan seberapa besar ruangan yang dibutuhkan sebuah variabel yang dilihat dari contoh diatas adalah 0x80 -> 128 bytes

nah abis itu kan fungsi read dipanggil dengan 3 parameter. Ingat ! kita menganalisa binari 64 bit jadi pemanggilan fungsi (calling convention) berbeda dengan 32 bit yang memakai intruksi "push" agar parameter nya bisa didorong ke stack, tapi di binari 64 bit program memakai register untuk menampung parameter seperti gambar diatas.

link: https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI

edx / rdx (parameter 3 => berapa besar alokasi bytes yang harus read baca, 0x200 -> 512 bytes)

rsi (parameter 2 => variabel yang akan menampung input dari kita yang mempunyai alokasi 128 bytes)

edi (parameter 1 => yang merupakan file descriptor yaitu 0 berarti STDIN)

jadi kita bisa satukan semua menjadi seperti ini:

input[128];
read(0,input,512);

hmmmm kelihatannya read function mengalokasikan memori yang dibaca terlalu besar dibandingkan dengan variable input yang bisa ditampung itu merupakan tanda kalau program ini rentan dengan buffer overflow.

kita bisa cek hipotesis diatas sebagai berikut:


sekarang tugas kita selanjutnya adalah mencari berapa banyak alokasi input yang harus kita masukan untuk bisa overwrite register RIP nya agar kita mengubah eksekusi program.

taruh breakpoint sebelum intruksi ret di function nono agar kita tahu posisi input kita di register stack dan return address dari function tersebut.


jalankan program dan kita akan tiba di breakpoint kita, buka register RSP nya dengan instruksi "x/100wx $rsp"


nah bisa dilihat input kita mulai dimasukan di register 0x7fffffffdb30 dan returna address kita ada di lokasi setelah 0x7fffffffdbb8 yaitu 0x00000000004005f3 perhatikan bahwa lokasi tersebut adalah lokasi instruksi yang ada di main, lokasi ini bertujuan agak program bisa mengeksekusi function main dengan baik

berapa banyak alokasi byte nya nih ?

tinggal kurangin 0x7fffffffdbb8 - 0x7fffffffdb30 = 136


oke jadi kita butuh alokasi 136 bytes biar bisa ubah RIP nya, teori ini bisa dites dengan cara berikut:


yeay kita berhasil mengubah arus dari RIP nya, selanjutnya apa ? hmmm kalau kita lihat di binarinya kita ngga bisa naruh shellcode buat keluarin shell. Tapi ada satu functions tersembunyi yang ternyata kalau kita panggil nanti bisa ngeluaring flag nya.




oke sudah cukup jelas yah kalau tugas kita terakhir hanya butuh untuk masukin RIP nya dengan lokasi function "yuhu".

ok jadi ini masalahnya, kalau dari informasi yang kita kumpulkan harusnya akan seperti ini


tapi anehnya program kita crash dan malah kena segfault lagi. Jadi apa yang kita lakukan, saya hanya pakai instruksi selanjutnya di function yuhu:


karena itu sebenernya masih dalam function prologue. Mungkin program nya error pake payload sebelumnya, karena stack register ada yang ngeganggu jalur exploit kita. Jadi tinggal diganti aja alamat nya jadi 0000000000400597 dan yeah kita berhasil mengubah eksekusi programnya


karena saya ngga punya flag nya jadi saya buat sendiri aja di lokal dengan isinya "mantap bos !"

enjoy yah semoga berguna :)


Comments

Popular posts from this blog

Having fun analyzing nginx log to find malicious attacker in the net (ง'̀-'́)ง (day 37)

  What makes you sleepless at night? is it because of a ghost or scary stories? is it because you have an important meeting tomorrow? or is it because you have an exam? For me, what keeps me up all night is that I keep thinking about what happens to a website that I just created, is it safe from an attacker (certainly not) or did I missing some security adjustments that lead to vulnerability? well I'm not the best secure programmer in the world, I'm still learning and there is a big possibility that I can make a mistake but for me, a mistake can be a valuable investment to myself or yourself to be better so from this idea, I want to know more about what attackers casually do when attacking a website. Here in this post, I'm going to show you how I analyzed attack to the website that I have permission to design and also some interesting findings that I could get from the analysis Background: All of this analysis comes from the traffic that is targeted to th...

Utilize Pwntools for crafting ROP chain :') (day 69)

who doesn't like pwntools? it is a very versatile tool and can be customized according to our need using the python script but did you need to know that pwntools itself can help us to automatically craft a rop chain for us? so in this post, I will show you how to make rop chain less painful and make pwntools do all the heavy lifting. To demonstrate this I will use the binary challenge callme 64 bit from ropemporium link: https://ropemporium.com/challenge/callme.html Crashing the app: Like any other exploitation process, we need to crash the program by generating a long string pattern to determine the offset. based on the information from the above figure we can see that we required to provide 40 bytes of offset Fun stuff: now this where the fun stuff began write the following python script: as in the guideline of the challenged said we need to chain the function call by first to call the callme_one function, callme_two function and then callme_three funct...

Bypassing stack canaries protection :') (day 51)

In my previous blogs, I show you guys how to bypass some common protection usually used in Linux binary such as NX and ASLR but this time we are going to take it to the next level we are going to talk about protection employ in the modern Linux OS which is "The Canaries" and how to bypass it. note: this post was not originally mined it was inspired by the following resources https://ctf-wiki.github.io/ctf-wiki/pwn/linux/mitigation/canary/ (Credit goes to the author) we are going to start this post about what is stack canaries and types of different implementation of it then move to the implementation about how to bypass this protection. We are going to focus on "leak canaries" technique What is stack canary: In layman terms, canaries are just another protection mechanism to prevent stack overflow implemented by appending 4/8 bytes value (depend on the architecture) into the stack when a function is entered. When the function is at the end of its exec...