informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/hacking/UNIX/unix.hal

433 lines
22 KiB
Plaintext
Raw Permalink Blame History

===============================================================================
RUSH2112
Presents
A HALE Production
H ackers A gainst L aw E nforcement
Call HALE Hq. (619)660-67xx
Active HALE members are: Ripper, Trashman, Rush2112.
The Underground Newsletter: Vol I. Issue I, Part I
===============================================================================
Note: Feel free to distribute the file provided none of its contents or
credits are changed.
Topic: A Guide to Unix Systems, Part I.
Date: September 1, 1989.
Foreword: This file is compiled from my experiences on both BSD and Sys V
Unix on VAX 750/780 mainframes, AT&T 3B20 and Pyramid Technology's
mainframes.
In today's world, as a hacker, you are nothing unless you learn some
of the more popular operating systems around used on minis, mainframes, super-
computers and the like. In this file I will attempt (to the best of my
ability) to introduce you to one of those operating systems - namely - the
world of Unix. It is hoped that by reading this file you can pick up perhaps
enough of a working knowledge so that if by chance in your hacking exploits you
come across a Unix system (and you will) you'll know what to do.
There is NO WAY to cover everything about Unix in a file so this will
be the first of many that I hope to release in the future. If I find there are
stuff I have not mentioned I will write more files as needed. In Part II, I
plan to give you a tutorial on what to do while you're on-line in regards to
hacking and using essential system utilities. Have fun.
Usually (unless modifified by the system administrator or one with such
privileges), you can tell if you've connected to a Unix system of some type by
the login prompt which looks like this:
login:
Pretty simple huh? Anyway, that is the standard login prompt, it may or may
not be preceded by a message telling you what type of Unix or system you have
connected to.
If you try to login with an illegal login name and/or an illegal
password the system will respond as such and as you to try again:
login:hacker
password:
login incorrect
login:
(Note the password is not echoed in any form)
In Part I of this Unix tutorial I'd like to start with an overview of
the Unix system before I get into some of the more interesting stuff (so bear
with me all you Unix experts). Then I will go through the login process and
the /etc/passwd file and how it is structured. This will not be an in-depth
look at all, merely an overview. Some day I will write an in-depth study to
accompany this file and the files that follow for the more advance user/hacker.
There are basically 2 types of Unix systems that you will most likely
come across. They are:
I. BSD Unix - from UC Berkeley's (B)erkeley (S)oftware (D)istributors
II. System V UNIX - from AT&T (how nice - I know all you phreakers are smiling!)
(Other spinoff's of the above 2 will not be discussed - such as Ultrix,
Minix, Xenix, etc...)
They are alike in many respects but both have their differences, hence
their are advantages and disadvantages to both of the systems, BSD and Sys V.
Perhaps the main difference between the two are the default shell that each
uses as the user interface to the system utilities.
BSD Unix defaults to the csh (C-Shell) while AT&T's Sys V uses the sh
(Bourne shell). But on both of these systems both shell types are available to
the user. A third optional shell which is also pretty popular is the ksh
(Korn shell). The way to recognize the default shells when you see them is by
their default prompt. The csh uses the % symbol as the prompt while the sh
uses the $ symbol as the prompt.
Now let's talk about files, shall we? The MOST important file of all
on ANY UNIX system is the password file. This file holds information about
all the accounts on the system, passwords, and other information. Without
this file no one can log in and use the system. You can find this file on any
system in the /etc directory. It is called simply 'passwd'. The full
pathname is /etc/passwd (of course).
The /etc/passwd file is stuctured as such:
Each user has an entry in the passwd file that holds his account information.
Among the information included on each user entry line is his login name,
his password (encrypted), his user id, his group id, his home directory, his
name, and his startup program if any. Basically it looks something like this:
------------------------ Sample /etc/passwd file --------------------------
General format of each entry:
login:password:user-ID:group-ID:info:home directory:startup program
root:Arllz76Dnq:0:0:The & of All Evil:/:/bin/csh
jsmith:Yi83amq9:102:100:John Smith:/usr/jsmith:/bin/sh
who::99:500:Who's on:/usr/ucb:/bin/who
daemon:r6Eeu:1:1:The DEVIL himself:/etc:/bin/csh
bin:mb033yt:3:3:The Keeper of the Flame:/etc:/bin/csh
info::508:501:Library user group:/usr2/info:/usr2/bin/rsh
.....
..... [ and so on ]
.....
----------------------------------------------------------------------------
Now we'll examine each entry. Remember that each field is separated
by the colon. So in the first entry in /etc/passwd given above, we can tell
the following about the entry.
login name is: root
Password (encrypted): Arllz76Dnq
User ID: 0
Group ID: 1
Info (usually owner): root
Home Directory: /
Startup Program: /bin/sh
The second entry in /etc/passwd looks like this:
login name is: jsmith
Password (encrypted): Yi83amq9
User ID: 102
Group ID: 100
Info (usually owner): John Smith
Home Directory: /usr/jsmith
Startup Program: /bin/sh
But now you get the general format...so let's discuss some things
about the field.
I. The login field
This is the login name that you use to login at the prompt of the Unix
system. During the login process, after you enter the login and the password
the system will then call routines to search the 1st field of each entry
in /etc/passwd to see if any login names match up with the one you have given
it. If none exists it will report the "login incorrect" message and start
prompting for a new login name and new password.
II. The Password field
If the login name is valid, Unix then takes your password entry and encrypts
it then compares it against the encrypted password in the 2nd field of the
login name entry (see I. The login field). If the two passwords match up, the
login process will continue, otherwise the "login incorrect" message will be
displayed. I'll explain later what goes on when comparisons of the encrypted
passwords take place. If the Password Field contains null :: then no password
is needed and the system logs you into the home directory and executes the
startup program. If the Password Field contains :,.: then upon login the
system will run the passwd utility and assign that account a password. (This
is nice if you're a system administrator, you create an account for your
friend then put the ",." in the password field and he'll set his own password
upon login.
III. The UID (UserID) field
If everything is correct (login name and password) then the system proceeds
to put your in your home directory. You are then given a UID from your entry
in the /etc/passwd file. All UID's fall in the range 0-65535 with 0 as the
superuser UID (see /etc/passwd example). The system reserves UID 0-99 for
special accounts. UID's are used by the system and its utilities to control
both access levels and file ownership (as determined by the ls utility - more
on that later).
IV. The GID (GroupID) field
The Group ID is used to associate the user with a certain group, used by
Unix primarily for access levels as determined by file protections. (i.e.
a member who is not in a group can not get group privileges on files for that
group, even though file protections for the file say all privileges to group
users.) GID's fall in the range 0-655535 with GID 1 being the default. All
GID's between 0-99 are reserved.
V. The Information field
This field usually holds the account owner's name though it can be used
for anything actually. I have seen it used to describe the account function
(see the sample /etc/passwd file on the entry for login name "who"), and also
to hold people's phone extension, etc..
VI. The Home Directory Field
This field should have the full pathname to your home directory. On many
UNIX systems it is usually in the format of /usr/{loginname} (See the
entry for login name "jsmith"). Not necessarily your PERMANENT home
directory, one can change it by reassigning an alternate path to the system
variable $HOME (on Sys V).
VII. The Program Field
Usually this field holds the startup program to execute once the login
procedure has been completed. If left blank then the default startup program
will be the shell assigned to the Unix system. In the our example /etc/passwd
file, the entry for login name who, will execute the who command in /bin/who
once you log in. However, after the command finishes executing, it will exit
the system as there is no password on the account, there is no way to stay
logged in. On the info account however, you will remain login until you type
exit or logout or CTRL-D as the program running there is a shell. Though not
a full Bourne shell or C-shell, the restricted shell (rsh) does allow to you
play around a little.
Well, that about does it for what I want to cover in Part I. Look for
Part II coming out real soon. I will be going into details what to do once
online with an account and how to go about getting an account. This file is
for informational purposes only.
------------------------------------------------------------------------------
Brought to you by: The Apple Bandit 10-89
===============================================================================
RUSH2112
Presents
A HALE Production
H ackers A gainst L aw E nforcement
Call HALE Central. (619)472-0xxx
Active HALE members are: Ripper, Trashman, Rush2112.
The Underground Newsletter: Vol I. Issue I, Part II
===============================================================================
Note: Feel free to distribute the file provided none of its contents or
credits are changed.
Date: September 3, 1989.
Topic: A Guide to Unix Systems, Part II.
In Part I of TUN, I explained the very basic fundamentals of the
Unix operating system. In Part II, which I'm sure a lot of you will be
more interested in, I will show you a sample run of how and what a hacker
would do (for example - what I would do) if I were on some unknown Unix
account.
I. Access to a Unix account.
First off, you need to find yourself an account. Briefly, here are
some of the most popular methods I use some of which are hard and some of
which are easy.
1. You can try to hack one out at the login: prompt. Of course this
is the old traditional method of trial and error and some standard login
accounts. (It is suggested but as a last resort - though it has worked for me
in the past I opt for other routes to getting an account.) Well, the first
thing of course when you hit a Unix system is to try the standard accounts.
This would include: uucp, nuucp, daemon, ftp
Some systems include public accounts that you may also want to try
as many of them give you shell access.
You might want to try: guest, info, bbs, games
Sooner or later, you'll find a system that has a vulnerability like
non-passworded accounts or simple passwords for a login. Some of the things
you should try are the login names as a password. Even the magazine UNIX
Review claims it was surprised how entries in /etc/passwd on systems they
checked used login names as the actual passwords. My own experiences shows
this is true.
2. You can get one if you know someone who already has a Unix account.
(I find this works very well, by working from the inside you're guaranteed to
get an account if you know what you're doing.)
Of course the hack attack from the login: prompt could be fruitless
and you may never get an account this way so the best way to get into a Unix
system is from the inside. This means of course you know someone on that
system with an account, who could help you find an account either by searching
the /etc/passwd for non-passworded account with shell access. Or hunting the
entire file system for files with "other" and/or "group" privileges in hopes
of finding a password or some account names or other neat info to get you
started on Unix.
3. You can try a trojan horse program to gain someone's login and
password. Some popular trojan horses are password capturing programs and
emulators that emulator the login screen. This method by-far is the EASIEST
way to do it but it requires you have an account to run the trojan horse
from. This can be done easily if your friend lets you use his account. You
won't even have to tell him what you're using it for.
I'll have more about this at a later date. Maybe an issue on trojan
horses and emulators, etc.. is in order?
II. Working with an account.
Once you have access some important points to remember and do are:
1. Set history to 0 if on BSD or erase .history on Sys V before logoff
2. Turn off your messages.
3. Get a buffer of the /etc/passwd.
4. Get a buffer of the login process.
5. Get a buffer of the ENTIRE file system online.
Assuming that you have gotten into someone else's account, the first
thing to do when you log in is shut your messages off with "mesg n" (messages
no). This will turn off write permission to your tty in /dev/ttyXX (where XX
is your tty number). It will prevent people from writing to you while you're
online buffering system information. It will also stop people from
redirecting output to your tty. Plus, you'll be busy so you want no
disturbances of any type.
If you're on an account running csh you should set the history to 0.
You can do that with the command 'set history=0'. History is just that... it
keeps a history of everything that you do, all the commands you pass to the
csh is stored. Typing 'history' by itself will show you a list of previous
commands entered by the user. By setting it to 0, it will not record your
commands from the shell. On Sys V under Bourne shell, history is stored
sometimes in the "hidden file" .history in your home directory ($HOME/.history)
You should delete the file before logging off.
Now you should get a copy of the password file. This is easily
accomplished with 'cat /etc/passwd'. Make sure you buffer the contents, you'll
need this for later. You may also wish to get the /etc/group file, this file
has information on all the groups on the system along with members of each
group. (I'll talk about groups in another file.) Just type 'cat /etc/group'
and buffer its contents.
Now comes the interesting part. You'll want to get a listing of every
single file on the system and buffer it. Here's what you would do:
$cd /
(at this point open your buffer)
$find . -type f -exec ls -al {} \;
(when this is finish, close your buffer)
This will take quite a while if the system you're on has a lot of
files. Basically, you are going to the root directory ('cd /') which is the
top of the directory tree hierarchy. From there you will execute the 'find'
command which is a file find utility. We are asking it to print out all the
filenames of type 'f' (which is normal file) from the current directory (which
is root) and all directories below it (which is the rest of the directory
tree) and search all files recursively and pass its findings via -exec to
the "ls" utility which will list its file information (-al including file
attributes).. but anyway, if this is too complicated to follow, don't worry.
Try typing 'man find' for perhaps a better explanation. Suffice it to say
you should now have buffered a listing of all files in the directory tree.
Next take a look at your hidden files like .profile on Sys V or
.login and .cshrc on BSD Unix. They contain login information such as commands
to automatically execute and perhaps some aliases definitions. If there is
anything interesting you should buffer it.
Find out who the hell is on at the time with the "who" command. Then
find out what everyone is doing with the "ps" command. For example on Sys V
Unix you might do something like this:
who -HTu (see "man who" for what the full explanation of all switches)
- basically this shows all users on currently and gives other
information on their tty status like "mesg y" or "mesg n" (A + means
messages are on, a - means messages are off.) It will also report
tty IDLE time, nice to know if someone is working or not.
After you see who's on, you'll want to know what they're doing. This can be
done with the "ps" (Process Status) command:
ps -fu username (read the on-line manual for full options)
- where username is the login name of whoever it is that you wanted to
check up on.
ps -fa | more
- shows ALL processes on the system. Piping through more will pause
tty output every screenful.
Using the "ps" utility is handy in getting some interesting paths to
programs run by users on the system as it shows the path to the entire process.
I have found many neat programs and utilities by watching what other people
do on the system with the "ps" command.
At this point you are interested in getting your own account if
possible. You have several options now. You could install a trojan horse
program in hopes of getting an account or you may want to play around with
the account you have.
Installing a trojan horse. I'll be going into more details about
trojan horses in a future issue of TUN as there are many ways to do this.
You should check first to see that your Unix system has a C compiler on it.
(yes, you'll unfortunately have to know a little bit of programming so go
get those books on C and start reading!). If it doesn't have a C compiler
you'll be out of luck, but not completely helpless, you could start writing
shell scripts (again probably another issue of TUN to cover shell scripts).
If you want to play around on the system, here are a few things to do.
One of the most basic tricks of Unix is called i/o redirection. This is a
process whereby you "redirect" standard input/output to some other device.
An example would be if I were to send a file to my screen to look at it, I
would redirect the output to another file, or screen, or printer, or any other
device on the system. Let's go with redirection to a file for a simple first
step. Suppose I had a text file called "textfile001".
To view to the screen I would type:
$cat textfile001
What happens when you type the 'cat' command is it views the file and send
its output to your tty or terminal screen. Now if I were to do this:
$cat textfile001 > newfile
You can see that nothing happens to the screen and it will come back to the
main prompt. However you will now have a new file called "newfile" whose
contents are those of textfile001. The redirection symbol > told it to cat
the file textfile001 but redirect standard output to the file called "newfile".
Using this principal, you can try to redirect things to people's tty's
or terminal screen. (Note - redirection to tty's will not work on BSD Unix
ver 4.3 due to a bug fix.) The way to do that is like this:
$cat textfile001 > /dev/ttyXX
Where XX is the tty number you wish the standard output to go to. So for
example if I were to do a 'who' command and I find that there is a user name
'steve' on the system on 'tty12' I could send the text file to his tty with:
$cat textfile001 > /dev/tty12
Now the standard output of 'cat' will go to tty12 which belongs to user steve.
Another trick to to redirect stty outputs to people's tty's. The
stty command handles certains setups for your tty, including how to process
erase keys, interrupt keys, baud rate, hangups, etc... For a list type
'man stty' to get the on-line manual entry for stty. Anyways, the command
stty 0 will automatically terminate phone connection to the system (i.e. hang
you up). So if you were to type:
$stty 0
You would gracefully exit the system with a &[1 NO CARRIER or some equivalent.
Now using redirection you can send your stty commands to other tty's. So using
the above example of stty 0:
$stty 0 > /dev/tty12
will hang up user steve. Unfortunately, due to the way Sys V handles stty
processing, this will not work on System V or later versions of BSD Unix
(4.3 to be exact.)
Other nasty things to do is to cat binary files to people's tty. Due
to the big file sizes of certain binary executables you should do redirection
in the background..that is with the & symbol at the end of the command line.
For example to send the "ls" binary file to user steve we would type:
$cat /bin/ls > /dev/tty12 &
Once typed in, you will get a Process ID (PID) or job number (on BSD) for
the background job. You will also get your prompt back so you can proceed
as normal while Unix is sending the ls binary to user steve. To kill the
process you could type:
$kill -9 PID where PID is the number returned to you from the
background command.
On BSD:
$kill %jobnumber for example if the job number returned was 1 then
$kill %1 will do the job.
This is handy to remember since doing a ps -fu username on your username
will reveal you are sending him a binary file in the background. You could
easily be dubbed the culprit messing with people's tty's.
Well, at this point I would like to wrap up Part II. If there are
typos my apologies.. it's late. Part III will be a bit more technical but
hopefully you'll get something out of it. I will be going over trojan horses
and emulators, and perhaps a discussion of file protections is in order and
of course how to get other people's files and give yourself more permission.
This file is for informational purposes only.
Brought to you by:
--------H.ackers--------A.gainst-----------L.aw---------E.nforcement-----------
Reference in New Issue View Git Blame Copy Permalink