The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/hacking/unix/crackin1.txt

Text File | 2003-06-11 | 6.6 KB | 138 lines

Greetings!  This has been written as informative document which will likely
be used by two groups of people:  new crackers, and new administrators who
would like to know about likely points of attack.  This is written entirely
from the cracker's perspective and tells _how_ to gain access, there are
however Administrator's notes that give ideas on what an Admin can do to
make it harder on the new cracker.  The author of this document is _not_ a
master cracker, and has very little knowledge at the system level of cracking.

Here we go:

So you want to crack a Unix system?  Well the big assumption that you already
have access to _some_ Unix system will be made.  Here are the following items
that you can achieve in order of greatness:

1.  Root password.  Kind of the Holy Grail, with this you can do just about
anything.  The only difference that will exist between you and the _real_
admin is tha he will have physical access to the machine.

2.  Root access.  As above except you don't know the password.

3.  User X's password.  A particular target user's password, item 1 is the
same thing with the target user being root.

4.  User X's account access.  Same as above but you don't know their password.

5.  Some user's password.  Just some random user, you don't pick them, you
got them because they were easy.

6.  Some user's account access.  Same as above but you don't know their
password.

7.  Wreaking havoc with tools already available to you, such as deleting
other's files, crashing the system, etc.


Here are some basic tools you should have:

1.  Dan Farmer's COPS scripts, and/or TAMU's Tiger Scripts.

2.  Crack (Unix password cracker than run on several machines at once)

3.  CrackerJack (A DOS or OS/2 program that cracks Unix passwords)

4.  A fair knowledge of Unix.  If you don't know the basic commands,
learn them.  If you don't know how to write shell scripts or C code,
learn the basics of that, those topics are not covered here.

Others:  Depending on the level of complexity you wish to delve into,
getting access to past CERT advisories and anything put out by 8lgm
could also be useful.  Also subscribe to comp.security.unix newsgroup.


We'll start by cracking your local system.  Getting a specific user
is very difficult to do.  We will start with getting access to _some_
user.  That way you can perform all future hacking from that user's
account, reducing the likelyhood of things being traced back to you.

Get the passwd file.  There is typically two ways to do this.  It is
either stored in /etc/passwd, and you simply cat the file.  Or, you
type "ypcat passwd" and it will pull it off a ypserver.  You will
want to redirect the output to a file so you can crack it.  Some
systems are starting to move toward "shadowed" password files, I've
never seen one of these, but apparently only root can read the passwd
file on such a system, if that is the case, the following won't help
you.

Now that you have the passwd file, it's time to start cracking.  In
most cases it is not wise to run Crack on system because it runs for
long periods and is likely to be seen.  However, if this option is
available to you, it can be very effective since it can crack many
passwords much quicker than the alternative since it has the ability
to run on multiple systems.  One thing to do is to use the next method
to get _a_ account's password, then use that account to run Crack.
The alternative I have been referring to is CrackerJack, this is a
solid program that runs on DOS and OS/2 machines.  You simply have
to copy your passwd file to the PC with CrackerJack and give it a
dictionary file.  If you are in an educational environment, their
are often PC labs that are accessible at late hours.  You can use
several small dictionaries and run CrackerJack on several PC's, using
each PC for several hours.  This is a very effective way to crack.
The documentation with both of these is fairly complete, so no detail
will be given on how to do the above.

**Administrator's note:  Ways to prevent the above include:
* Using a shadowed passwd file, so Joe User can't get a look at it
(I think, never seen one, as mentioned earlier).
* There are several programs available that will do a quickcheck
when a user tries to change their password to make sure they don't
have it as something stupid.
* Run Crack.  If you are the administrator, you can easily run it
across all machines on your lan during low-use hours (1am - 5am)
This being done on a regular basis (I'd recommend monthly if not
weekly, it can be automated with a cron job) can keep weak passwords
off your system.  If you are in an educational setting, new users
tend to come in large groups (semester starts), this is the ideal
time for the cracker to attack, since their are lots of new, usually
clueless users with weak passwords.  You should up _your_ checking
during these times.
**

Okay!  That's one way to gain access to someone else's account, let's
move on to another.  The key here is:  If you can get user X to run
program Y, you can gain access to their account, this includes root.
First we'll go into what program Y would need to do:

1. Create a SUID shell script.  This attack is my least favorite
since many systems are set up so that SUID scripts don't work from
most filesystems.  However, /tmp seems to be an oversite in most
cases.  Generally SUID programs can exist and be run from /tmp.
The idea behind SUID is that when the program is run, it runs under
the owner's account.  So if the program executes a shell, that shell
is owned by the owner of the file, making the runner of the file
that person (for all practical purposes).  You can make a program
SUID by doing a "chmod 6xxx filename", the xxx would be the normal
chmod settings, "man chmod" for more info.

2. Add you to their .rhosts file.  Reasoning:  Whenever your try
to rlogin to someone else's account, the rlogin program will look
in that users home directory for a .rhosts file.  If the party
trying to rlogin in listed in that file, from a particular machine,
also listed in that file, rlogin will not ask for a password.
.rhosts is set up like the following:
<machinename> <username>

3. The above two will get you access to their account, the following
will give you a way to do the above two.  You can add a line to their
.login, .cshrc, or .logout file so that will execute a program everytime
they login.  One idea is illustrated in the following pseudocode:

if /tmp/backdoor exists run /tmp/backdoor

That way you only create /tmp/backdoor as needed and they don't get
an error when it is not there.


To be continued.....