28 replies to this topic

[Blackknight]

you cant use echo because it doesnt convert the hex values to ascii to pass to the buffer
and you can make a simple c program to get the enviorment variables address
char *hax;
hax=getenv(argv[1]);
if(hax==NULL) exit(1);
printf("%s locatated at %p\n,argv[1],hax);

[shaun2k2]

Listen to blackknight, he knows his shit.

1) Why did u use the perl command (echo `perl -e 'print "..."'`)? Can't you just use echo "HACK\x90\x1f\x0e\x40HACK\x27\xfe\xff\xbf\x22\xfb\xff\xbf"?

I believe blackknight already explained.
'echo' will just echo the exploit payload as it already is. Consider this:

[shaun@localhost shaun]$ echo `perl -e 'print "HACK"x7 . "\x90\x1f\x0e\x40HACK\x27\xfe\xff\xbf\x22\xfb\xff\xbf"'`
HACKHACKHACKHACKHACKHACKHACK@HACK'þÿ¿"ûÿ¿
[shaun@localhost shaun]$

Notice, the output is not the same as what we put into the perl one-liner. The hex values have been converted to their equivalent ASCII values.

Now, using the UNIX echo command:

[shaun@localhost shaun]$ echo "HACK"x7 . "\x90\x1f\x0e\x40HACK\x27\xfe\xff\xbf\x22\xfb\xff\xbf"
HACKx7 . \x90\x1f\x0e\x40HACK\x27\xfe\xff\xbf\x22\xfb\xff\xbf
[shaun@localhost shaun]$

The exploit buffer is printed "as-is". On another note, we also use 'perl -e' because sometimes we need to repeat garbage data (padding) or return addresses, hence the "HACK"x7. This repeats HACK 7 times. We use this garbage data for padding because 32 bytes are needed to overwrite the EIP register (32 bytes includes the new return address itself). Don't bug yourself about WHY 32 bytes are needed - I had already experimented with Blasta's example program for 5 minutes before writing the perl one-liner exploit - thus learning the amount of data required to zap out EIP.

2) How did u get the offsets of the chmod call and your two variables OURSH and OURMODE?

As blackknight was explaining, you can simply use the 'getenv()' library function in Linux, store the outpt in a pointer, and then use the %p printf format parameter to print the actual address of the desired variable.

I wrote a simple C program to get the address of a user-specified environmental variable - this is the one I used for the experiments I have presented briefly in this thread.

/* getenv.c - get address of an environmental variable. */
#include <stdio.h>
#include <stdlib.h>

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

        if(argc < 2) {
                printf("Usage: %s <environ_var>\n", argv[0]);
                exit(-1);
        }

        char *addr_ptr;

        addr_ptr = getenv(argv[1]);

        if(addr_ptr == NULL) {
                printf("Environmental variable %s does not exist!\n", argv[1]);
                exit(-1);
        }

        printf("%s is stored at address %p\n", argv[1], addr_ptr);
        return(0);
}

As blackknight stated earlier, to make exploitation via stack based buffer overflow vulnerabilities a lot easier, we often use environmental variables to store shellcode, eliminating the need for NOPs (often referred to as "NOP sleds" for obvious reasons). The almost exact address of the environmental variable holding shellcode or otherwise (i.e instead of shellcode, stuff needed for "return into libc" exploits) can be calculated quite easily, this address can be used to overwrite EIP, execution flow with jump to your environmental variable, and the shellcode will be executed.

For the other part of your question, the static addresses of LIBC functions on a particular machine (used when using the 'return into libc' technique I showed briefly) can be found quite easily using a debugging. Let me demonstrate:

[shaun@localhost shaun]$ cat <<EOF >> dummy.c
> int main() {
> system();
> }
> [shaun@localhost shaun]$ cat dummy.c
int main() {
system();
}
[shaun@localhost shaun]$ gcc dummy.c -o dummy
[shaun@localhost shaun]$ gdb dummy
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...
(gdb) break main
Breakpoint 1 at 0x8048342
(gdb) run
Starting program: /home/shaun/dummy

Breakpoint 1, 0x08048342 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} 0x40061310 <system>
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[shaun@localhost shaun]$

Above, I create a stupid dummy program calling 'system()' with a NULL argument. I compiled it, and then ran the GNU GDB debugger. It's essential that you become familiar with gdb, it's included with most all linux distributions.
I used gdb commands to set a break point on main(), ran the program, and then printed the address of the LIBC 'system()' function. The memory address of 'system()' on MY system just happens to be '0x40061310'. When you consider little-endian byte ordering, and convert to hex, you get the following:

\x10\x13\x06\x40

I know it's leet looking, but all it really is is 0x40061310 with the bytes reversed (because of little-endian byte ordering - the bytes have to be reversed) with '\x' before every value. Easy, huh? No probs.

Now that we have the address of 'system()' we can shove values into environmental variables and get the address of them using the above program I pasted. By doing this properly, it's quite easy to get a shell. Note that even if vulnprog was SUID root, the shell wouldn't be root, because system() executes commands via /bin/sh, which drops the privileges first. However, execl() could be called with only a little bit more work, or you could call 'chmod()' to set SUID privs on a desired program - hence my example of the previous page. I could've created a program which executes a shell (not with system()), and then exploit vulnprog to execute the chmod() call to set SUID privs on my shell-exec program. And since vulnprog was SUID root, my shell-exec program now runs with root privileges - even though I didn't exploit vulnprog to execute a shell, I still have a root shell waiting for me

Maybe I've just rambled on a bit.
Maybe we can get a lecture going in #gso-chat on our new irc server.

Blackknight - would you be willing to do a lecture with me for the guys? We could demonstrate the methods we just discussed; placing code in environmental variables, and overwriting EIP with the address of the environ variable. What do yer think?


-Shaun.

[Blackknight]

Yeah would be good to give to the community good bunch of guys..
I can even tell you howto write your own shellcode
and how the calls are made.. so you can pretty much write any shellcode you want
Will even tell you howto print it so u can easily import into a file...

Windows shellcode is a bit of a tedious task and requires screenshots normally.. so we should start off with linux and see where people are at and what needs to be done

But yeah post ideas on what you guys want the lecture to be about.. i can explain very indepth on how the whole process works. And explain why it works etc..
and tricks to avoid IDS detection

edit: Note when you are explotining using getenvaddr the env variable will be padding the shellcode etc.. so keep that in mind because if its not divisible by 4 you will have a segment overflow

[shaun2k2]

Blackknight has agreed to do a lecture with me. He'll be head-lecturer - we'll give details of when a little later.

We will keep a log of the lecture, so something can still be gained from it. Any questions that weren't asked because of absence can be asked in a thread we open, to distribute the IRC log.

To help combat the problem of misunderstandings and not having Linux, we are going to prepare lecture notes after the lecture is over, helping people further with concepts explained. We will also seperate the lecture into seperate parts, such as Windows, Linux, etc. Blackknight has access to Windows & Linux, so it shouldn't be a problem.




-Shaun.

[Blackknight]

and script god is right u never overwrite the eip.. you overwrite the stack frame pointer so it jumps to ur function after that function has finnished..
In asm you can actually right a lil piece of code that prevents this

[krackatoa]

Interesting discussion. I'd like to hear more about Windows stack based overflows while you guys are at it.

I've already read every Windows based text that I could find on the web. There hasn't really been a clear tutorial on windows using a simple C++ applet that actually details exploitation from start to cms shell or cmd execution.