unix- a hacking tutorial.sir

黑客培训教程

could do just that.  Say .. Scythian came across the file, and was in the root
user group.  He could read write or execute the file.  Now, say datawiz came
across it, but was in the "users" group.  The group permissions would not
apply to him, meaning he would have no permissions, so he couldn't touch
the file, right?  Sorta.  There is a third group of permissions, and this is
the "other" group.  This means that the permissions in the "other" group
apply to everyone but the owner, and the users in the same group as the file.
Look at the directory entry above.  the r-x-rwxr-- is the permissions line.
The first three characters are the permissions for the owner (r-x).  The
"r-x" translates to "Read and execute permissions, but no write permissions"
the second set of three, r-xRWXr-- (the ones in capital letters) are the group
permissions.  Those three characters mean "Read, write, and execution allowed"
The 3rd set, r-xrwxR-- is the permissions for everyone else.  It means
"Reading allowed, but nothing else".  A directory would look something like
this:
 $ ls -l
 drwxr-xr-x sirhack     root  342 March 11  src

A directory has a "d" at the beggining of the permissions line.  Now, the
owner of the directory (sirhack) can read from the directory, write in the
directory, and execute programs from the directory.  The root group and every-
one else can only read from the directory, and execute off the directory.
So, If I changed the directory to be executable only, this is
what it would look like:
 $ chmod go-r
 $ ls
 drwx--x--x sirhack   root  342  March 11  src

Now, if someone went into the directory besides "sirhack", they could only
execute programs in the directory.  If they did an "ls" to get a directory
of src, when they were inside src, it would say "cannot read directory".
If there is a file that is readable in the directory, but the directory is
not readable, it is sometimes possible to read the file anyway.

If you do not have execute permissions in a directory, you won't be able to
execute anything in the directory, most of the time.

_____________________________________________________________________________

--------------
Hacking:
--------------
        The first step in hacking a UNIX is to get into the operating system
by finding a valid account/password.  The object of hacking is usually to
get root (full privileges), so if you're lucky enough to get in as root,
you need not read anymore of this hacking phile , and get into the
"Having Fun" Section.  Hacking can also be just to get other's accounts also.

Getting IN
----------
        The first thing to do is to GET IN to the Unix.  I mean, get past
the login prompt.  That is the very first thing.  When you come across a UNIX,
sometimes it will identify itself by saying something like,
"Young INC. Company UNIX"

or Just
"Young Inc.  Please login"

        Here is where you try the defaults I listed.  If you get in with those
you can get into the more advanced hacking (getting root). If you do something
wrong at login, you'll get the message
"login incorrect"
This was meant to confuse hackers, or keep the wondering.  Why?
Well, you don't know if you've enterred an account that does not exist, or one
that does exist, and got the wrong password.  If you login as root and it says
"Not on Console", you have a problem.  You have to login as someone else,
and use SU to become root.

   Now, this is where you have to think.  If you cannot get in with a
default, you are obviously going to have to find something else to
login as.  Some systems provide a good way to do this by allowing the use
of command logins.  These are ones which simply execute a command, then
logoff.  However, the commands they execute are usually useful.  For instance
there are three common command logins that tell you who is online at the
present time.  They are:
        who
        rwho
        finger

    If you ever successfully get one of these to work, you can write down
the usernames of those online, and try to logon as them.  Lots of unsuspecting
users use there login name as their password.  For instance, the user
"bob" may have a password named "bob" or "bob1".   This, as you know, is
not smart, but they don't expect a hacking spree to be carried out on
them.  They merely want to be able to login fast.
   If a command login does not exist, or is not useful at all, you will
have to brainstorm.  A good thing to try is to use the name of the unix
that it is identified as.  For instance, Young INC's Unix may have an account
named "young"
        Young, INC.  Please Login.
        login: young
        UNIX SYSTEM V REL 3.2
        (c)1984 AT&T..
        ..
        ..
        ..

   Some unixes have an account open named "test".  This is also a default,
but surprisingly enough, it is sometimes left open.  It is good to try to
use it.  Remember, brainstorming is the key to a unix that has no apparent
defaults open.  Think of things that may go along with the Unix.  type
in stuff like "info", "password", "dial", "bbs" and other things that
may pertain to the system.  "att" is present on some machines also.

ONCE INSIDE -- SPECIAL FILES
----------------------------
        There are several files that are very important to the UNIX
environment.  They are as follows:

/etc/passwd  - This is probably the most important file on a Unix.  Why?
               well, basically, it holds the valid usernames/passwords.
               This is important since only those listed in the passwd
               file can login, and even then some can't (will explain).
               The format for the passwordfile is this:

username:password:UserID:GroupID:description(or real name):homedir:shell

                Here are two sample entries:

sirhack:89fGc%^7&a,Ty:100:100:Sir Hackalot:/usr/sirhack:/bin/sh
demo::101:100:Test Account:/usr/demo:/usr/sh

                In the first line, sirhack is a valid user.  The second
                field, however, is supposed to be a password, right?  Well,
                it is, but it's encrypted with the DES encryption standard.
                the part that says "&a,Ty" may include a date after the comma
                (Ty) that tells unix when the password expires.  Yes, the
                date is encrypted into two alphanumeric characters (Ty).

                In the Second example, the demo account has no password.
                so at Login, you could type in:

login: demo
UNIX system V
(c)1984 AT&T
..
..

                But with sirhack, you'd have to enter a password.  Now,
                the password file is great, since a lot of times, you;ll
                be able to browse through it to look for unpassworded
                accounts.  Remember that some accounts can be restricted
                from logging in, as such:

bin:*:2:2:binaccount:/bin:/bin/sh

                The '*' means you won't be able to login with it.  Your
                only hope would be to run an SUID shell (explained later).

        A note about the DES encryption:  each unix makes its own unique
"keyword" to base encryption off of.  Most of the time its just random letters
and numbers.  Its chosen at installation time by the operating system.
        Now, decrypting DES encrypted things ain't easy.  Its pretty much
impossible.  Especially decrypting the password file (decrypting the password
field within the password file to be exact).  Always beware a hacker who
says he decrypted a password file.  He's full of shit.  Passwords are
never decrypted on unix, but rather, a system call is made to a function
called "crypt" from within the C language, and the string you enter as
the password gets encrypted, and compared to the encrypted password.  If
they match, you're in.  Now, there are password hackers, but they donot
decrypt the password file, but rather, encrypt words from a dictionary
and try them against every account (by crypting/comparing) until it finds
a match (later on!).  Remember, few, if none, have decrypted the password
file successfuly.

/etc/group - This file contains The valid groups.  The group file is usually
             defined as this:
             groupname:password:groupid:users in group

         Once again, passwords are encrypted here too.  If you see a blank
         in the password entry you can become part of that group by
         using the utility "newgrp". Now, there are some cases in
         which even groups with no password will allow only certain
         users to be assigned to the group via the newgrp command. Usually,
         if the last field is left blank, that means any user can use newgrp
         to get that group's access.  Otherwise, only the users specified in
         the last field can enter the group via newgrp.

        Newgrp is just a program that will change your group current
        group id you are logged on under to the one you specify.  The
        syntax for it is:  newgrp groupname
        Now, if you find a group un passworded, and use newgrp to
        enter it, and it asks for a password, you are not allowed to use
        the group.  I will explain this further in The "SU & Newgrp" section.

/etc/hosts - this file contains a list of hosts it is connected to thru
             a hardware network (like an x.25 link or something), or sometimes
             just thru UUCP.  This is a good file when you are hacking a
             large network, since it tells you systems you can use with
             rsh (Remote Shell, not restricted shell), rlogin, and telnet,
             as well as other ethernet/x.25 link programs.

/usr/adm/sulog (or su_log) - the file sulog (or su_log) may be found in
             Several directories, but it is usually in /usr/adm.  This file
             is what it sounds like.  Its a log file, for the program SU.
             What it is for is to keep a record of who uses SU and when.
             whenever you use SU, your best bet would be to edit this file
             if possible, and I'll tell you how and why in the section
             about using "su".

/usr/adm/loginlog
or /usr/adm/acct/loginlog -
        This is a log file, keeping track of the logins.
        Its purpose is merely for accounting and "security review".  Really,
        sometimes this file is never found, since a lot of systems keep the
        logging off.

/usr/adm/errlog
or errlog -     This is the error log.  It could be located anywhere.  It
                keeps track of all serious and even not so serious errors.
                Usually, it will contain an error code, then a situation.
                the error code can be from 1-10, the higher the number, the
                worse the error.  Error code 6 is usually used when you try
                to hack.  "login" logs your attempt in errlog with error code
                6.  Error code 10 means, in a nutshell, "SYSTEM CRASH".

/usr/adm/culog - This file contains entries that tell when you used cu,
                 where you called and so forth.  Another security thing.

/usr/mail/<userLogin> - this is where the program "mail" stores its mail.
                        to read a particular mailbox, so they are called,
                        you must be that user, in the user group "mail" or
                        root.  each mailbox is just a name.  for instance,
                        if my login was "sirhack" my mail file would usually
                        be: /usr/mail/sirhack

/usr/lib/cron/crontabs - This contains the instructions for cron, usually.
                         Will get into this later.

/etc/shadow - A "shadowed" password file.  Will talk about this later.


-- The BIN account --

       Well, right now, I'd like to take a moment to talk about the account
"bin".  While it is only a user level account, it is very powerful.  It is
the owner of most of the files, and on most systems, it owns /etc/passwd,
THE most important file on a unix.  See, the bin account owns most of the
"bin" (binary) files, as well as others used by the binary files, such
as login.  Now, knowing what you know about file permissions, if bin owns
the passwd file, you can edit passwd and add a root entry for yourself.
You could do this via the edit command:
$ ed passwd
10999 [The size of passwd varies]
* a
sirhak::0:0:Mr. Hackalot:/:/bin/sh
{control-d}
* w
* q
$

Then, you could say: exec login, then you could login as sirhack, and
you'd be root.

/\/\/\/\/\/\/\/\/
Hacking..........
/\/\/\/\/\/\/\/\/

--------------
Account Adding
--------------

        There are other programs that will add users to the system, instead
of ed.  But most of these programs will NOT allow a root level user to be
added, or anything less than a UID of 100.  One of these programs is
named "adduser".  Now, the reason I have stuck this little section in, is
for those who want to use a unix for something useful.  Say you want a
"mailing address".  If the unix has uucp on it, or is a big college,
chances are, it will do mail transfers.  You'll have to test the unix
by trying to send mail to a friend somewhere, or just mailing yourself.
If the mailer is identified as "smail" when you mail yourself (the program
name will be imbedded in the message) that probably means that the system
will send out UUCP mail.  This is a good way to keep in contact with people.
Now, this is why you'd want a semi-permanent account.  The way to achieve this
is by adding an account similar to those already on the system.  If all the
user-level accounts (UID >= 100) are three letter abbriviations, say
"btc" for Bill The Cat, or "brs" for bill ryan smith, add an account
via adduser, and make a name like sally jane marshall or something
(they don't expect hackers to put in female names) and have the account
named sjm.  See, in the account description (like Mr. Hackalot above), that
is where the real name is usually stored.  So, sjm might look like this:
     sjm::101:50:Sally Jane Marshall:/usr/sjm:/bin/sh
Of course, you will password protect this account, right?
Also, group id's don't have to be above 100, but you must put the account
into one that exists.  Now, once you login with this account, the first
thing you'd want to do is execute "passwd" to set a password up.  If you
don't, chances are someone else 'll do it for you (Then you'll be SOL).

-------------------
Set The User ID
-------------------

        This is porbably one of the most used schemes.  Setting up an "UID-
Shell". What does this mean?  Well, it basically means you are going
to set the user-bit on a program.  The program most commonly used is
a shell (csh,sh, ksh, etc).  Why?  Think about it:  You'll have access
to whatever the owner of the file does.  A UID shell sets the user-ID of
the person who executes it to the owner of the program.  So if root
owns a uid shell, then you become root when you run it.  This is an
alternate way to become root.

        Say you get in and modify the passwd file and make a root level
account unpassworded, so you can drop in.  Of course, you almost HAVE to
get rid of that account or else it WILL be noticed eventually.  So, what
you would do is set up a regular user account for yourself, then, make
a uid shell.  Usually you would use /bin/sh to do it.  After adding
the regular user to the passwd file, and setting up his home directory,
you could do something like this:
(assume you set up the account: shk)
 # cp /bin/sh /usr/shk/runme
 # chmod a+s /usr/shk/runme

Thats all there would be to it.  When you logged in as shk, you could just
type in:

 $ runme
 #

See?  You'd then be root.  Here is a thing to do: