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.
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:
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 that 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.