------------------------------------------------------------------------------
Unix for the Moderate
-------------------------------------------------------------------------------
By: The Urvile, Necron 99, and a host of me.
-------------------------------------------------------------------------------
Disclaimer:
This is mainly for system five. I do reference BSD occasionally, but I
mark those. All those little weird brands (i.e., DEC's Ultrix, Xenix, and
so on) can go to hell.
Security: (Improving yours.)
-Whenever logging onto a system, you should always do the following:
$ who -u
$ ps -ef
$ ps -u root
or BSD:
$ who; w; ps uaxg
This prints out who is on, who is active, what is going on presently,
everything in the background, and so on.
And the ever popular:
$ find / -name "*log*" -print
This lists out all the files with the name 'log' in it. If you do find a
process that is logging what you do, or an odd log file, change it as soon
as you can.
If you think someone may be looking at you and you don't want to leave
(Useful for school computers) then go into something that allows shell
breaks, or use redirection to your advantage:
$ cat < /etc/passwd
That puts 'cat' on the ps, not 'cat /etc/passwd'.
If you're running a setuid process, and don't want it to show up on a ps
(Not a very nice thing to have happen), then:
$ super_shell
# exec sh
Runs the setuid shell (super_shell) and puts something 'over' it. You may
also want to run 'sh' again if you are nervous, because if you break out of
an exec'ed process, you die. Neat, huh?
Improving your id:
-First on, you should issue the command 'id' & it will tell you you your
uid and euid. (BSD: whoami; >/tmp/xxxx;ls -l /tmp/xxxx will tell you your
id [whoami] and your euid [ls -l].), terribly useful for checking on setuid
programs to see if you have root euid privs. Also, do this:
$ find / -perm -4000 -exec /bin/ls -lad {} ";"
Yes, this finds and does an extended list of all the files that have the
setuid bit on them, like /bin/login, /bin/passwd, and so on. If any of
them look nonstandard, play with them, you never can tell what a ^| will do
to them sometimes. Also, if any are writeable and executable, copy sh over
them, and you'll have a setuid root shell. Just be sure to copy whatever
was there back, otherwise your stay will probably be shortened a bit.
-What, you have the bin passwd?
Well, game over. You have control of the system. Everything in the bin
directory is owned by bin (with the exception of a few things), so you can
modify them at will. Since cron executes a few programs as root every once
in a while, such as /bin/sync, try this:
Now, as soon as cron runs /bin/sync, you'll have a setuid shell in
/tmp/sroot. Feel free to hide it.
-the 'at' & 'cron' commands:
Look at the 'at' dir. Usually /usr/spool/cron/atjobs. If you can run 'at'
(check by typing 'at'), and 'lasttimedone' is writable, then: submit a
blank 'at' job, edit 'lastimedone' to do what you want it to do, and move
lasttimedone over your entry (like 88.00.00.00). Then the commands you put
in lasttimedone will be ran as that file's owner. Cron: in
/usr/spool/cron/cronjobs, there are a list of people running cron jobs.
Cat root's, and see if he runs any of the programs owned by you (Without
doing a su xxx -c "xxx"). For matter, check all the crons. If you can
take one system login, you should be able to get the rest, in time.
-The disk files.
These are rather odd. If you have read permission on the disks in /dev,
then you can read any file on the system. All you have to do is find it in
there somewhere. If the disk is writeable, if you use /etc/fsbd, you can
modify any file on the system into whatever you want, such as by changing
the permissions on /bin/sh to 4555. Since this is pretty difficult to
understand (and I don't get it fully), then I won't bother with it any
more.
-Trivial su.
You know with su you can log into anyone else's account if you know their
passwords or if you're root. There are still a number of system 5's that
have uid 0, null passwd, rsh accounts on them. Just be sure to remove your
entry in /usr/adm/sulog.
-Trojan horses? On Unix?
Yes, but because of the shell variable PATH, we are generally out of luck,
because it usually searches /bin and /usr/bin first. However, if the first
field is a colon, files in the present directory are searched first. Which
means if you put a modified version of 'ls' there, hey. If this isn't the
case, you will have to try something more blatant, like putting it in a
game (see Shooting Shark's file a while back). If you have a system login,
you may be able to get something done like that. See cron.
Taking over:
Once you have root privs, you should read all the mail in /usr/mail, just
to sure nothing interesting is up, or anyone is passing another systems
passwds about. You may want to add another entry to the passwd file, but
that's relatively dangerous to the life of your machine. Be sure not to
have anything out of the ordinary as the entry (i.e., No uid 0).
Get a copy of the login program (available at your nearest decent BBS, I
hope) of that same version of Unix, and modify it a bit: on system 5,
here's a modification pretty common: in the routine to check correct
passwds, on the line before the actual pw check, put a if
(!(strcmp(pswd,"woof"))) return(1); to check for your 'backdoor', enabling
you to log on as any valid user that isn't uid 0 (On system 5).
Neato things:
-Have you ever been on a system that you couldn't get root or read the
Systems/L.sys file? Well, this is a cheap way to overcome it: 'uuname'
will list all machines reachable by your Unix, then (Assuming they aren't
Direct, and the modem is available):
$ cu -d host.you.want [or]
$ uucico -x99 -r1 -shost.you.want
Both will do about the same for us. This will fill your screen with lots
of trivial material, but will eventually get to the point of printing the
phone number to the other system. -d enables the cu diagnostics, -x99
enables the uucico highest debug, and -R1 says 'uucp master'.
Back a year or two, almost everywhere had their uucp passwd set to the same
thing as their nuucp passwd (Thanks to the Systems file), so it was a
breeze getting in. Even nowadays, some places do it.. You never can tell.
-Uucp:
I personally don't like the uucp things. Uucico and uux are limited by the
Permissions file, and in most cases, that means you can't do anything
except get & take from the uucppublic dirs. Then again, if the
permission/L.cmd is blank, you should be able to take what files that you
want. I still don't like it.
-Sending mail:
Sometimes, the mail program checks only the shell var LOGNAME, so change
it, export it, and you may be able to send mail as anyone. (Mainly early
system 5's.)
$ LOGNAME="root";export LOGNAME
-Printing out all the files on the system:
Useful if you're interested in the filenames.
$ find / -print >file_list&
And then do a 'grep text file_list' to find any files with 'text' in their
names. Like grep [.]c file_list, grep host file_list....
-Printing out all restricted files:
Useful when you have root. As a normal user, do:
$ find / -print >/dev/null&
This prints out all nonaccessable directories, so become root and see what
they are hiding.
-Printing out all the files in a directory:
Better looking than ls -R:
$ find . -print
It starts at the present dir, and goes all the way down. Catches all
'.files', too.
-Rsh:
Well in the case of having an account with rsh only, check your 'set'. If
SHELL is not /bin/sh, and you are able to run anything with a shell escape
(ex, ed, vi, write, mail...), you should be put into sh if you do a '!sh'.
If you have write permission on your .profile, change it, because rsh is
ran after checking profile.
-Humor:
On a system 5, do a:
$ cat "food in cans"
or on a csh, do:
% hey unix, got a match?
Well, I didn't say it was great.
Password hacking:
-Salt:
In a standard /etc/passwd file, passwords are 13 characters long. This is
an 11 char encrypted passwd and a 2 char encryption modifier (salt), which
is used to change the des algorithm in one of 4096<?> ways. Which means
there is no decent way to go and reverse hack it. Yet.
On normal system 5 Unix, passwords are supposed to be 6-8 characters long
and have both numeric and alphabetic characters in them, which makes a
dictionary hacker pretty worthless. However, if a user keeps insisting his
password is going to be 'dog,' usually the system will comply (depending on
version). I have yet to try it, but having the hacker try the normal
entry, and then the entry terminated by [0-9] is said to have remarkable
results, if you don't mind the 10-fold increase in time.
Final notes:
Yes, I have left a lot out. That seems to be the rage nowadays.. If you
have noticed something wrong, or didn't like this, feel free to tell me.
If you can find me.
-------------------------------------------------------------------------------
Hi Ho. Here ends part one. <Of one?>
-------------------------------------------------------------------------------
Produced and directed by: Urvile & Necron 99
----------------------------------------------------------- (c) ToK inc., 1988
