The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/hacking/unix/unix2.hal

Text File | 2003-06-11 | 12.2 KB | 236 lines

===============================================================================
                RUSH2112
                Presents
               A HALE Production
    H ackers    A gainst       L aw        E nforcement
             Call HALE Central. (619)472-0xxx
    Active HALE members are: Ripper, Trashman, Rush2112.
    The Underground Newsletter: Vol I.  Issue I, Part II
===============================================================================
Note:    Feel free to distribute the file provided none of its contents or
    credits are changed.
Date:    September 3, 1989.
Topic:    A Guide to Unix Systems, Part II.

    In Part I of TUN, I explained the very basic fundamentals of the
Unix operating system.  In Part II, which I'm sure a lot of you will be
more interested in, I will show you a sample run of how and what a hacker
would do (for example - what I would do) if I were on some unknown Unix
account.

I.  Access to a Unix account.
    First off, you need to find yourself an account.  Briefly, here are
some of the most popular methods I use some of which are hard and some of
which are easy.

    1.  You can try to hack one out at the login: prompt.  Of course this
is the old traditional method of trial and error and some standard login
accounts.  (It is suggested but as a last resort - though it has worked for me
in the past I opt for other routes to getting an account.)  Well, the first
thing of course when you hit a Unix system is  to try the standard accounts.
This would include: uucp, nuucp, daemon, ftp
    Some systems include public accounts that you may also want to try
as many of them give you shell access.
You might want to try: guest, info, bbs, games
    Sooner or later, you'll find a system that has a vulnerability like
non-passworded accounts or simple passwords for a login.  Some of the things
you should try are the login names as a password.  Even the magazine UNIX
Review claims it was surprised how entries in /etc/passwd on systems they
checked used login names as the actual passwords.  My own experiences shows
this is true.

    2.  You can get one if you know someone who already has a Unix account.
(I find this works very well, by working from the inside you're guaranteed to
 get an account if you know what you're doing.)
    Of course the hack attack from the login: prompt could be fruitless
and you may never get an account this way so the best way to get into a Unix
system is from the inside.  This means of course you know someone on that
system with an account, who could help you find an account either by searching
the /etc/passwd for non-passworded account with shell access.  Or hunting the
entire file system for files with "other" and/or "group" privileges in hopes
of finding a password or some account names or other neat info to get you
started on Unix.

    3.  You can try a trojan horse program to gain someone's login and
password.  Some popular trojan horses are password capturing programs and
emulators that emulator the login screen.  This method by-far is the EASIEST
way to do it but it requires you have an account to run the trojan horse
from.  This can be done easily if your friend lets you use his account.  You
won't even have to tell him what you're using it for.

    I'll have more about this at a later date.  Maybe an issue on trojan
horses and emulators, etc.. is in order?

II.  Working with an account.
    Once you have access some important points to remember and do are:
    1.  Set history to 0 if on BSD or erase .history on Sys V before logoff
    2.  Turn off your messages.
    3.  Get a buffer of the /etc/passwd.
    4.  Get a buffer of the login process.
    5.  Get a buffer of the ENTIRE file system online.

    Assuming that you have gotten into someone else's account, the first
thing to do when you log in is shut your messages off with "mesg n" (messages
no).  This will turn off write permission to your tty in /dev/ttyXX (where XX
is your tty number).  It will prevent people from writing to you while you're
online buffering system information.  It will also stop people from
redirecting output to your tty.  Plus, you'll be busy so you want no
disturbances of any type.
    If you're on an account running csh you should set the history to 0.
You can do that with the command 'set history=0'.  History is just that... it
keeps a history of everything that you do, all the commands you pass to the
csh is stored.   Typing 'history' by itself will show you a list of previous
commands entered by the user.  By setting it to 0, it will not record your
commands from the shell.  On Sys V under Bourne shell, history is stored
sometimes in the "hidden file" .history in your home directory ($HOME/.history)
You should delete the file before logging off.
    Now you should get a copy of the password file.  This is easily
accomplished with 'cat /etc/passwd'.  Make sure you buffer the contents, you'll
need this for later.  You may also wish to get the /etc/group file, this file
has information on all the groups on the system along with members of each
group.  (I'll talk about groups in another file.)  Just type 'cat /etc/group'
and buffer its contents.
    Now comes the interesting part.  You'll want to get a listing of every
single file on the system and buffer it.  Here's what you would do:

$cd /
    (at this point open your buffer)
$find . -type f -exec ls -al {} \;
    (when this is finish, close your buffer)
    This will take quite a while if the system you're on has a lot of
files.  Basically, you are going to the root directory ('cd /') which is the
top of the directory tree hierarchy.  From there you will execute the 'find'
command which is a file find utility.  We are asking it to print out all the
filenames of type 'f' (which is normal file) from the current directory (which
is root) and all  directories below it (which is the rest of the directory
tree) and search all files recursively and pass its findings via -exec to
the "ls" utility which will list its file information (-al including file
attributes).. but anyway, if this is too complicated to follow, don't worry.
Try typing 'man find' for perhaps a better explanation.   Suffice it to say
you should now have buffered a listing of all files in the directory tree.
    Next take a look at your hidden files like .profile on Sys V or
.login and .cshrc on BSD Unix.  They contain login information such as commands
to automatically execute and perhaps some aliases definitions.  If there is
anything interesting you should buffer it.
    Find out who the hell is on at the time with the "who" command.  Then
find out what everyone is doing with the "ps" command.  For example on Sys V
Unix you might do something like this:

who -HTu    (see "man who" for what the full explanation of all switches)
    - basically this shows all users on currently and gives other
      information on their tty status like "mesg y" or "mesg n" (A + means
      messages are on, a - means messages are off.)  It will also report
      tty IDLE time, nice to know if someone is working or not.

After you see who's on, you'll want to know what they're doing.  This can be
done with the "ps" (Process Status) command:

ps -fu username    (read the on-line manual for full options)
    - where username is the login name of whoever it is that you wanted to
      check up on.
ps -fa | more
    - shows ALL processes on the system.  Piping through more will pause
      tty output every screenful.

    Using the "ps" utility is handy in getting some interesting paths to
programs run by users on the system as it shows the path to the entire process.
I have found many neat programs and utilities by watching what other people
do on the system with the "ps" command.
    At this point you are interested in getting your own account if
possible.  You have several options now.  You could install a trojan horse
program in hopes of getting an account or you may want to play around with
the account you have.
    Installing a trojan horse.  I'll be going into more details about
trojan horses in a future issue of TUN as there are many ways to do this.
You should check first to see that your Unix system has a C compiler on it.
(yes, you'll unfortunately have to know a little bit of programming so go
get those books on C and start reading!).  If it doesn't have a C compiler
you'll be out of luck, but not completely helpless, you could start writing
shell scripts (again probably another issue of TUN to cover shell scripts).
    If you want to play around on the system, here are a few things to do.
One of the most basic tricks of Unix is called i/o redirection.  This is a
process whereby you "redirect" standard input/output to some other device.
An example would be if I were to send a file to my screen to look at it, I
would redirect the output to another file, or screen, or printer, or any other
device on the system.  Let's go with redirection to a file for a simple first
step.  Suppose I had a text file called "textfile001".
To view to the screen I would type:

$cat textfile001

What happens when you type the 'cat' command is it views the file and send
its output to your tty or terminal screen.  Now if I were to do this:

$cat textfile001 > newfile

You can see that nothing happens to the screen and it will come back to the
main prompt.  However you will now have a new file called "newfile" whose
contents are those of textfile001.  The redirection symbol > told it to cat
the file textfile001 but redirect standard output to the file called "newfile".

    Using this principal, you can try to redirect things to people's tty's
or terminal screen.  (Note - redirection to tty's will not work on BSD Unix
ver 4.3 due to a bug fix.)  The way to do that is like this:

$cat textfile001 > /dev/ttyXX

Where XX is the tty number you wish the standard output to go to.  So for
example if I were to do a 'who' command and I find that there is a user name
'steve' on the system on 'tty12' I could send the text file to his tty with:

$cat textfile001 > /dev/tty12

Now the standard output of 'cat' will go to tty12 which belongs to user steve.
    Another trick to to redirect stty outputs to people's tty's.  The
stty command handles certains setups for your tty, including how to process
erase keys, interrupt keys, baud rate, hangups, etc...  For a list type
'man stty' to get the on-line manual entry for stty.  Anyways, the command
stty 0 will automatically terminate phone connection to the system (i.e. hang
you up).  So if you were to type:

$stty 0

You would gracefully exit the system with a &[1 NO CARRIER or some equivalent.
Now using redirection you can send your stty commands to other tty's.  So using
the above example of stty 0:

$stty 0 > /dev/tty12

will hang up user steve.  Unfortunately, due to the way Sys V handles stty
processing, this will not work on System V or later versions of BSD Unix
(4.3 to be exact.)
    Other nasty things to do is to cat binary files to people's tty.  Due
to the big file sizes of certain binary executables you should do redirection
in the background..that is with the & symbol at the end of the command line.
For example to send the "ls" binary file to user steve we would type:

$cat /bin/ls > /dev/tty12 &

Once typed in, you will get a Process ID (PID) or job number (on BSD) for
the background job.  You will also get your prompt back so you can proceed
as normal while Unix is sending the ls binary to user steve.  To kill the
process you could type:

$kill -9 PID        where PID is the number returned to you from the
            background command.

On BSD:
$kill %jobnumber     for example if the job number returned was 1 then
            $kill %1  will do the job.

This is handy to remember since doing a ps -fu username on your username
will reveal you are sending him a binary file in the background.   You could
easily be dubbed the culprit messing with people's tty's.

    Well, at this point I would like to wrap up Part II.  If there are
typos my apologies.. it's late.   Part III will be a bit more technical but
hopefully you'll get something out of it.  I will be going over trojan horses
and emulators, and perhaps a discussion of file protections is in order and
of course how to get other people's files and give yourself more permission.
    This file is for informational purposes only.
    Brought to you by:
--------H.ackers--------A.gainst-----------L.aw---------E.nforcement-----------