[Simple 90's BOF Tricks] Stack buffer overflows advanced | chapter.1

Hello people around the world! Sorry for the long time to do a new blog post, i had so much work, ctf's, certificates, most people never seen this blog... that's make me really sad too.. whatever.. i'll try to start this tutorial series with objective to share my little knowledge about Stack buffer overflows and related.

I have plans to post most of my knowledge acquired during my OSCE, CTF's, self studing and so on.
The ideia behind this tutorials series are to explain the most detailed, possible and RESUMED exploitation techniques which are normally used on real world. Those techniques are all outdated ( yes, it is!! most of them)  once all of this stack stuffs are not exploitable anymore on big applications, such as: browsers, kernel drivers, etc. Most of the modern exploits are written to explore the dynamic memory called heap. Those  heap exploits have your own classifications like stack overflows, such as: Use-After-Free, Double-Free, Heap overflow and so on. We will NOT focus on heap stuff in this series, because it is not necessary at moment.

Also, i'll NOT explain detailed how the CPU and the memory works as well. This series are ONLY for demostrate techniques for this type of attack! PLEASE, if you have any questions, try to read the awesome corelan articles, it could save you on this florest, trust me!.

https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/

Sooo... let's begins!

Series chapters:

[Simple 90's BOF Tricks] Stack buffer overflows advanced | chapter.1
    -> Windows & Linux

[Ret2Libc] Stack buffer overflows advanced | chapter.2
    -> Linux

[NSEH and SEH?] Stack buffer overflows advanced | chapter.3
    -> Windows

[Egghunters] Stack buffer overflows advanced | chapter.4

    -> Windows & Linux

[We don't need JUMPS!] Stack buffer overflows advanced | chapter.5

    -> Windows

[Someone said ASLR Bypass?] Stack buffer overflows advanced | chapter.6

    -> Windows & Linux

[Alphanumeric and manually encoding!] Stack buffer overflows advanced | chapter.7

    -> Windows

[DEP Bypass FTW!] Stack buffer overflows advanced | chapter.8

    -> Windows & Linux

------------------------------------------------------------------------------------------------------------------------------------------

So.. maybe you have heard about stack.. ESP.. registers...overflows.. those kind of things are really hard if you try to understand deepest, but resuming, let's try to look the stack like a simple box, with so many opcodes, right? and our registers like simply pen pointers, easy to get it right? So.. a stack is a box which contains opcodes, but what exactly are opcodes?

- Opcodes are nothing more or less than bytes located on memory which perform actions on the processor when called.

e.g: If you try to execute the opcode \x41 on the x86 CPU for example, the CPU will understand that byte such as INC ECX. Also, If you send the opcodes \x54\xC3, it will be executed by the CPU push esp ; ret.

"But... What the h4x00r is this INC ECX, PUSH ESP... ooh what!!? i don't get it.."

- Calm down, brah... have a look on this repository please!

https://github.com/w4fz5uck5/assembly/blob/master/h0w_t0_n4sm.txt

This repo is about the basics of basics of basics..... how the x86 CPU works as well. I confess that maybe i wrote something wrong on the TXT file, let me know if you have found something that i could revise, thanks!.

Ok! now let's make a deal, if you don't understand something, go back to the link above and try to find a way to understand what i'm trying to explain, ok? cool!

Backing to the post, plurururu...(Time portal effects ;p).

- Registers are simply pointers to some location in the memory, which could be possible to make calculations, managment of strings, operations, etc. 

e.g:

EAX = 0xdeadbeef  <- pointing to address 0xdeadbeef in the memory

EBX = 0xcafebabe  < - pointing to address 0xcafebabe in the memory

  

Most of time, the buffer overflow occurs when a buffer . a.k.a:

char *buffer[2000];

strcpy(buffer, user_input);

Is overflowed by another function, in this case strcpy. It function is one of the most dangerous functions to copy content for a buffer, because his function does not check the user_input length, which means if an user send the value :

strcpy(buffer, "A" * 4000) 

Certainly something gonna break... and in this case, the buffer will be overflowed and the EIP -> CPU Instruction pointer, will be changed to 0x41414141.

That is the BASICS! 

How i said, i will no discuss it on this series, so let's continue!

The problem with broken EIP addresses:

After the buffer overflowed and you got control about EIP, you should get your own shell and so on right? BUT, if you have problems like... Ok! you controlled EIP but the value of your A's on there are 0x414141de... not 0x41414141... what to do in this moment?!?!

Answer:

Simply calculate the difference between the two values. e.g:

>>> hex(0x414141de - 0x41414141)

'0x9d'

>>> hex(0x41414141  - 0x9d)

'0x414140a4'

# pseudo python exploit code

junk = "A" * 2000

overflow_EIP = struct.pack("I", 0x414140a4)

s.send(junk + overflow_EIP)

.....

EIP = 0x41414141

If you noticed, the EIP normally are adding 0x9d bytes to your current value, we just need to substract this values of our 0x41414141 address. This thing can be done by using struct.pack too:

# pseudo python exploit code

junk = "A" * 2000

overflow_EIP = struct.pack("I", 0x41414141-0x9d) # better to read! 

s.send(junk + overflow_EIP)

.....

EIP = 0x41414141

 Another awesome trick is the all possibilities to jump to our stack (ESP):

CALL ESP

JMP ESP

PUSH ESP ; RET

BUT wait! You don't need to jump to stack every time... stack (ESP) is ONLY the most utilized for it, you also could jump to another registers too, without any problems! ;)

Let's imagine the follow exploit flow:

- You send:

junk =   "AAAABBBBCCCCDDDDEEEEFFFFGGGG....."  # 2000 bytes length

junk += "AAAA"
s.send(junk)

- ImmDBG Registers Screen:

| EAX = "EEEEFFFFGGGG......"
| ECX = 0x00000000

| EDX = 0x00000000
| EBX = 0x42bfd4f21

| ESP  = 0x42d11d8d

| EBP =  0x00000000

| ESI  =  0x00000000
| EDI  =  0x00000000

| 

| EIP = 0x41414141

As you can see, the EAX register is pointing to our E's located in our junk variable. Within a normal usage of a common exploit, and knowing that EIP is overflowed by 2004 bytes, you could simply send:

junk =   "A" * 2000  

junk += 0xdeadbeef   # application JUMP ESP address

s.send(junk)

- ImmDBG Register Screen:

| EAX = "EEEEFFFFGGGG......" # shellcode bytes
| ECX = 0x00000000

| EDX = 0x00000000
| EBX = 0x42bfd4f21

| ESP  = 0x42d11d8d

| EBP =  0x00000000

| ESI  =  0x00000000
| EDI  =  0x00000000

| 

| EIP = 0xdeadbeef

BUT, knowing that EAX is pointing to our E's.. You also could find (with mona.py plugin) a JMP EAX!! it will result in a jump to the content located on EAX register... in this case, executing the opcode \x45  which is INC EBP. 

Did you get the behind ideia? wow! no?... easy! change our E's to our shellcode!

First, find your gadget!: 

!mona jmp -r eax -cp nonull

<alt+l>

Copy the address from the immDBG logging screen.

junk =   "A" * 1500

junk += shellcode      # shellcode size 500

junk += 0xcafebabe  # application JUMP EAX address

s.send(junk)

- ImmDBG Register Screen:

| EAX = "%!5^^^}AS}{......" # shellcode bytes
| ECX = 0x00000000

| EDX = 0x00000000
| EBX = 0x42bfd4f21

| ESP  = 0x42d11d8d

| EBP =  0x00000000

| ESI  =  0x00000000
| EDI  =  0x00000000

| 

| EIP = 0xcafebabe

EIP -> JUMP EAX -> Execute EAX bytes content.....3....2...1....!!! BOOM!

Boom!! Calc poped up!

The only problem with this method is... your junk size must to be more than the shellcode size that you could jump over! so... if your junk size is 200 bytes, it is not the mostly recommend method to jump back, because you will not have length for a reverse shell (for example) to be executed in there.

So... We have reached the final of this chapter,  I hope this little blog post could be interesting and clarified some annoying things that happen alot within my exploit test cases.

For the another blog post, we will discuss some interesting things about NSEH and SEH. It will be a fully windows exploitation with a real ( but outdated ) softwares! 

Thanks people for your time! see you soon.. \o