phrack/phrack25/5.txt

                                ==Phrack Inc.==

                     Volume Three, Issue 25, File 5 of 11

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


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

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


When Cracking A System Remember --

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


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

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


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

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


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


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

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


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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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

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


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

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

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


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


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


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


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

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


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


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

===============================================================