UNIX Job Opening

by Orb

Hacking a UNIX machine comes in more flavors than merely grabbing a copy of /etc/passwd and scanning against it.  You can get a variety of accounts this way, but a well chosen password can evade even some of the most thorough tests.  So - how do you get to the other parts of the system?

One interesting trick is the infamous Trojan horse.  The heart of the Trojan horse lies in getting someone to execute code written by you.  In this case, the code will be the minimal routines required to give you access to the account of the person executing the code.

The following is an example of one such program for UNIX:

#!/bin/sh echo 'main(){system("/bin/sh");}' >test.c filename=.go`whoami` cc -o $filename test.c rm test.c chmod 6777 $filename

Whenever you execute a program, the program is run with the User ID (UID) of the person executing the program.  UNIX also provides a method of having the program be executed with the UID of the user executing (the parent process) but by the owner of the file itself.  This is accomplished by setting what is called the Set User ID (SUID) bit.

The above code exploits this in UNIX.

First, we create a simple C program which calls the UNIX shell sh.  (This is stored in the file test.c.)  Then we compile the test.c file into a file named by the form .goXXX where XXX is set to be the username of the person who ran our nice little program.  (The C file is then discarded.)

So far what we have is an executable file which calls a UNIX shell.  Nothing special - yet.  But, what if we set the SUID bit of the program we created to that of the person running the program?  Ah!  By using the UNIX chmod program, we set the SUID bit on the program.  Now, if we were to happen to come along and execute this program, we would be running a shell - but we would be running with our effective user ID set to that of the person who ran our silly little script.  In essence, you become this person.

What can you do from here?  Well, perhaps you want to install a better backdoor into this account.  Ms. Manners says that leaving lots of little SUID programs lying around is not good etiquette.  How exactly you go about this is a much larger topic, but use your imagination.

There are many variations to this theme.  Perhaps you want to have this file moved to some preselected directory so the person who created this file doesn't notice it.  Maybe you want it to send a mail message somewhere or signal a process already running so you will know that someone just fell into your trap.  Again, use your imagination.

All this is very interesting, but unless you can actually get someone to execute your code it doesn't exactly do you much good.  The first place to look is in the resources you have.  Suppose a password scan of the machine gave you the account of a person who is running IRC or some other program which many users link to.  You could simply just replace this program by your program but it would be a bit obvious even to the typical clueless IRC user that something is wrong.  So, you either should modify the program that everyone links to in order to do some version of the above, or call the real program after it does its task.  Perhaps some other users on the system have linked to your files without asking.  Well, it serves them right if you slip in something that just happens to give you access to their account.  You never made any guarantees about what is in your directory did you?

This leads into another way of slipping these in - just put them in some public place in your directory with a name that might cause someone to execute it.  Perhaps you want to exploit the possibility of a bad $PATH variable.  Might as well put it in a file called ls while you are at it.  Yes, some people still don't have their path set up good.  a.out files are commonly executed by prying eyes.  Put one in any directory that has .c files.  You might as well have one in /tmp (or whatever the commonly used equivalent on your system is) just for kicks.

The point I am making is that the possibilities are only limited by your imagination.  Even the most security minded users occasionally slip up and run things they didn't mean to.

There are a few problems though.  First, I would suggest rewriting the above script in C and creating a binary file.  People usually will look at scripts before they run them, but won't bother to examine an executable file.

Also, try to avoid anything that could be linked to you.  A cautious user might trace the execution of the program he is executing and realize what you did.  Basically, just be careful.  There is no need to go overboard.  Don't flood your system with Trojan horses.  Like all other forms of hacking you need a bit of patience.  Sooner or later people will fall into just about any trap you set.

Be very careful about leaving SUID programs lying around.  Some sysadmins regularly scan their systems for them, so you need to think up other types of backdoors if you intend to keep access to an account for any period of time.