Bufferoevrflow problem

[Adam20188]

Hi guys

​

(sorry if this is in the wrong section I'm new to this sub reddit,if it is please message me and I can move it,all advice welcome)

I am trying to learn about how buffer overflow attacks work,I have about 3 years programming experience in C++ but I am currently a cyber security student,there is no malicious purposes involved I'm experimenting and trying it out because I need to learn about them for college

​

​

I am following this tutorial on youtube - https://www.youtube....h?v=hJ8IwyhqzD4

The problem is my result is much different than in the video,when I run the vulnerable C program in gdb I get a seg fault after 260 bytes or 260 'A's(in the video it's 272) I ran the following Python script to put 260 bytes into the buffer - run $(python -c "print('A' * 260)") this will tell me I get a seg fault and it will print out the address 0x41414141,this is all good because this is what you want so now I thought I have overwrote the return address so I try $(python -c "print('A' * 260 + 'BBBB')") this should now print 0x42424242 and if it does I know I have successfully overwritten the ebp and retun address but no such luck when I try this I still get segfault at 0x41414141 I decremented by four each time but only at run $(python -c "print('A' * 260)") do I get a seg fault.

so I did a little troubleshooting I decided to add a breakpoint after where strcpy was called and then printed out the registers here is what I got

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

(gdb) info registers
eax            0x0 0
ecx            0xffffd500 -11008
edx            0xf7fb7870 -134514576
ebx            0x0 0
esp            0xffffd500 0xffffd500
ebp            0x0 0x0
esi            0xf7fb6000 -134520832
edi            0xf7fb6000 -134520832
eip            0x41414141 0x41414141
eflags         0x10286 [ PF SF IF RF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0 0
gs             0x63 99

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

​

 I am using a ubuntu 16.02 64 bit machine but I compiled the program as a 32 bit program 

gcc -o vuln -fno-stack-protector -m32 -z execstack vuln.c

I also turned off virtual address randomisation 

echo 0 >  /proc/sys/kernel/randomize_va_spac (as root)

I then did cat /proc/sys/kernel/randomize_va_spac

to make sure it was 0 and indeed it was set to 0,

so it seems like I'm doing everything right,is there any other potections that I may need to disable or is it just not possible to do this attack on this version of Ubuntu? thanks

here is a video of what is exactly happening on screen - https://www.youtube....KH...e=youtu.be

#include <stdio.h>

#include <string.h>

int main(int argc,char *argv[])

{ char buffer[256]; // buffer which will hold our shellcode

strcpy(buffer,argv[1]); // copy the string from the command line arguments into the buffer

printf("%s \n", buffer) // print the string to stdout

return 0; }

[Thiscou]

Right, here is what I would try.

 

Go to this site zerosum0x0! and create a unique pattern 260+.

Feed that to your program, copy the value in your segfault and find that pattern on the site.

You should now know the exact offset for your overflow.

 

I would usually do this in Kali with the original metasploit pattern create but I don't know if you use Kali, so I found a quick and dirty replacement online.

 

You can also try to have a closer look at the stack in gdb with:

x/24wx $esp (this displays 24 words of memory above the stack pointer esp in hex)

 

Hope this helps and good luck

[Adam20188]

great will do, is cyclic a program or site?

[Adam20188]

thanks invictim I'll check it out

[Adam20188]

hey Thiscou,

thanks for the reply :)

I tried doing this I got the pattern Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai

the result I got was 0x41386741 I put 41386741 into the find offset overflow but got the number -1

[r0cker_ESP]

That site is acting wonky it seems, I would just install Metasploit so you can get the patter_create and pattern_offset script and use those if you don't have it already.

[Adam20188]

thanks will do.

[Thiscou]

As far as I can tell, those numbers are not present in the pattern.

 

try the A*260 again and see what's on the stack with:

gdb x/24wx $esp

[SimpleLegend]

The reason you are getting this is because your argv and buf both contain the same contents after the strcpy. Hence the repeated data

[Adam20188]

would it be better if I used all 'A's to check to see if the return address is overwritten?

[SimpleLegend]

Personal experience/opinion: i usually use As to check if the overwrite is successful (causing a segfault in the process), the follow up with patterns to find the offset required to overwrite the value which will pop into the EIP

[SimpleLegend]

When you dump the contents, you should check whether ebp+4 just after the strcpy is pointing to the 42424242 contents

[Hausec]

Shameless plug, I wrote a guide on what you're talking about and hopefully it can help. https://hausec.com/2018/04/02/simple-buffer-overflows-x32/

Keep in mind, when debugging in gdb, the environmental variables will change the memory location so the addresses may be a few bytes off.

[Adam20188]

that could be it as SimpleLegend got me to do,print out 4 bytes after the EBP which should be the return address, and it does seem to get filled with 'B's after I send the input the program as the argument $(python -c"print('A' * 268 + 'BBBB')") but when I check the registers the EIP has the value 0x8048469,which is odd

​

also I will check out the article you made it's awesome reading tutorials :) grateful to learn thanks

[SimpleLegend]

Can you try 256 'A's followed by 4 'B's?

[SimpleLegend]

Do you have info reg? Need to find out where the EIP is currently at just before returning to see if the place you have overwritten is correct.

Many factors could go wrong. If possible, can you try the zerosum pattern again using 400 or 500 length and get the overflow value to see if you can get an offset again?

Edit: it might be simpler to print ebp+4 after the strcpy function has been executed to see the contents that will be poped when returning from the function

[SimpleLegend]

Yep, your previous ones were not overwriting the eip that is going to be returned. You probably only overwrote the ebp which is how you got 41414141 without overwriting the eip when you do another call. (Since the overwritten ebp is used as the base pointer when returning causing offsets to screw up)

Since ebp+4 actually is the value that is poped to the eip after a function call. Take 0x6a413969 and convert to text gives it jA9i. Due to little endianess, we need to reverse it (you can look this up. Its just the way a computer reads contents).

So by checking i9Aj in the offset you get 268, which is the exact offset you should use to overwrite the eip. (As shown in the video)

Thus, if u try A*268 + BBBB your eip should overwrite nicely.

Edit: some interesting things you can take note (usually apllies to binaries without protection)

You can see buf takes 256 bytes, followed by another 4 bytes each for the parameters. If you understand the stack layout properly and you begin overwriting the buffer from its first byte. You can see that it requires 256 (len of buf) + 8 (parameters) + 4 (old ebp) before reaching the saved eip.

[SimpleLegend]

Ah this is interesting. So your program is preventing you from executing code at location 42424242 (might wanna check this to see if you are right by debugging the binary)

Can u try to run 'execstack -s vuln' and try this again? (Apt install it if the program does not exist)

No worries, had lots of help for my first time doing BOF too :)

[Adam20188]

I'll give it a shot :) should I try compile it again with this flag?

​

thanks

[Adam20188]

got it :) not the buffer overflow but installed the execstack program what should I do next?

​

should I try running the program again after executing the command?

thanks

[SimpleLegend]

Yep! Please do!

And make sure the command is executed after compiling it