=======================================
T H E N E W F O N E E X P R E S S
=======================================
The newsletter of the Society for the Freedom of Information (SFI)
Electronic Edition
Central distribution site is Secret Society BBS
(314) 831-9039, WWIVNet 3460, 24hrs
-----------------------------------------------------------------------------
The publisher, SFI, distribution site(s), and authors contributing to the NFX
are protected by the Bill of Rights in the U.S. Constitution, which
specifically protects freedom of speech and freedom of the press. The
information provided in this magazine is for informational purposes only, and
the publisher, SFI, distribution site(s) and authors are not responsible for
any problems resulting from the use of this information. Nor is SFI
responsible for consequences resulting from authors' actions. This
disclaimer is retroactive to all previous issues of the NFX.
We accept article submissions of nearly any sort, about
hack/phreak/anarchy/gov't/nets/etc. Send mail to the publisher (The
Cavalier) at any of these addresses:
WWIVnet [15@3460]
WWIVlink [442@13468]
VMB (301) 771-1151. hit #, then 140.
Ripco [send mail to Silicon Avalanche]
Daydream Nation [send mail to Silicon Avalanche]
Internet [
[email protected] or
[email protected]]
The printed edition of the newsletter is available for $14 (U.S.) per year on
paper or $2 (U.S.) for a single copy. Send mail to the New Fone Express,
Jackson House Rm 206, President's Park, 10309 Senatorial Lane, Fairfax, VA
22030. Don't forget your name and address.
To download the New Fone Express, call Secret Society at (314) 831-9039 and
log on as NFX, password NFX, phone# 0000, or see the distribution list
elsewhere in this magazine.
-----------------------------------------------------------------------------
Highlights for Issue #5/October 1991
====================================
* SFI's Reason for Existence ... typed by the Cavalier
(see article #1)
* AT&T NY Phone Crash ... typed by the Cavalier
(see article #2)
* Using Novell Netware 2.2 ... by the Cavalier
(see article #3)
* Beginners' ED ... by the Cavalier
(see article #4)
* "The Law Comes to Cyberspace" ... typed by the Cavalier
(see article #5)
* Newsletter Policy ... by the NFX 'staff'
(see article #6)
* Distribution Site List ... edited
(see article #7)
* Editorial ... by the Cavalier
(see article #8)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
SFI's Reason for Existence
This feature is our 'mission statement,' if you will - the reasons for
the existence of the Society for the Freedom of Information. Thanks to
Olorin the White and Silicon Avalanche for helping us to more precisely
define our purpose.
We (the founders of SFI) have noticed a growing trend in the attempt to
conceal or in other words protect information that, if revealed, would
promote personal and group understanding of technology that might otherwise
go un-documented. Although we very much acknowledge the right to privacy, we
submit that this right only extends to a certain point: The moment a piece
of information has the capability of benefitting the general public in their
understanding of the world around them, the piece of information should be
free to all who would care to inspect it. Attempts to reach this goal should
be initially reached by a general exchange of information via the
establishment of a newsletter and eventually through the establishment of a
BBS, or other such means of electronic discussion and exchange. Also,
attempts to provide equal access to information through a network gateway or
a public network should be promoted and actively searched for.
We are not terrorists; nor law-scoffing individuals by nature. We
simply believe in the fundamental international right to equal and free
access to information that can have a bearing on or can enrich people's
lives, and will try to bring about the implementation of this right by any
means available to us. ><
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
AT&T NY Phone Crash
Phone failure stalls air traffic
Disruption in N.Y. felt nationwide
By Kimberly Hayes Taylor and Steve Marshall - USA TODAY
Air traffic in and out of New York City resumed late Tuesday after a
phone-service failure virtually shut down three airports for almost four
hours. Hundreds of flights coast to coast were delayed or canceled when
controllers at John F. Kennedy, La Guardia and Newark (New Jersey) airports
lost the link that allows communication among themselves or with other U.S.
airports. Communications between pilots and air-traffic controllers travel
over telephone lines to ground-based radio equipment. AT&T spokesman Herb
Linnen blamed an internal power failure in a long-distance switching office
in Manhattan. Hours after the 4:50 PM EDT failure, 40 planes loaded with
passengers were sitting on the runway at Kennedy, 35 at Newark, 30 at La
Guardia. "During the height of the thing, at least 300 aircraft were delayed
at metropolitan airports," said Bob Fulton, a spokesperson for the Federal
Aviation Administration. Included: flights taking off "from California to
Florida" and headed for New York, said FAA's Fred Farrar. Farrar said planes
had to be grounded for safety. Without telephone communication, they would
"fly willy-nilly." Among diverted flights: a British Airways supersonic
Concorde from London, which landed at Bradley airport outside Hartford, Conn.
Passenger reaction: at Washington's National Airport, Dominique Becoeur of
Paris was "reading, drinking, and thinking" while waiting for a flight to New
York. At La Guardia, Ernie Baugh, of Chattanooga, Tenn., said, "I think I
will go and have another beer." Flights were reported resuming by 9 p.m.
EDT. Linnen said AT&T was busy Tuesday night restoring long-distance service
in and out of New York City, which had been interrupted. Some international
service also had been affected.
(end of article one, 9/18/91)
THE BIG HANG-UP
Phone crash grounds airplanes, raises anger
Phone snag likely won't ground fliers after Oct.
By John Schneidawind - USA TODAY
The Federal Administration Aviation has some good news for travelers who
were stranded at airports, or delayed for hours, the past two days by the New
York City telephone outage. If a similar phone disaster strikes next month,
hardly any fliers will know the difference. That's because AT&T is close to
completing installation of a network of microwave dishes that will
supplement, if not replace, the phone lines AT&T uses to relay calls between
air-traffic controllers in different cities. Tuesday evening, flights in and
out of some of the nation's busiest airports - Kennedy, La Guardia, and
Newark, N.J. - were grounded because FAA controllers couldn't communicate
with one another. For much of the 1980's, land-based fiber optic lines have
been slowly replacing microwave phone dishes phone companies long have used
to transmit telephone calls. That's because fiber-optic wires were thought
to provide clearer calls than microwave technology. Now, it's becoming
apparent that sending some or most telephone calls via wireless microwave
might ease the burden handled by fiber-optic cables. In addition, a
microwave call could be transmitted point-to-point, bypassing an inoperative
switching center when a breakdown or catastrophe occurs.
(end of article two, 9/19/91)
Customers demand an explanation
Experts say outages could continue if systems aren't upgraded
By John Schneidawind and Mark Land - USA TODAY
The telephone network crashed again Tuesday, this time crippling New
York, the world's financial capital. The culprit, a power shortage at an
AT&T switching center, left more than 1 million residents without telephone
service for up to seven hours. Now the victims, including hundred of people
stranded at New York airports, are demanding to know: What's going on? The
USA is supposed to have the world's most reliable telephone network. Yet
this summer alone, outages have struck Pittsburgh, Los Angeles, Washington,
and other cities, disrupting service for more than 11 million people. Why,
suddenly, is our telephone network so vulnerable? To answer those questions,
USA TODAY has pieced together what happened Tuesday and why. We also look
ahead: Experts say the problems could reoccur unless major changes are made
in the way the nation's phone networks operate. Why did the network melt
down in New York? Blame the heat, at least in part. Like anything else, the
phone networks run on electricity. Tuesday's 93-degree heat meant lots of
power was needed to air-condition the skyscrapers in lower Manhattan. So at
10 a.m., a worried Con Edison - New York's public utility - asked AT&T to
draw electricity for its call-switching computers at 33 Thomas St. from
AT&T's own diesel-fueled generators. That was a routine request, but then
disaster struck. During the attempted changeover, a sudden surge of
electricity knocked out several key devices known as power rectifiers, which
failed to switch AT&T's computers from Con Ed's power to AT&T's diesel power.
Instead, AT&T's computers began to draw electricity from a battery-operated
backup system. Negligence also played a major role. AT&T admitted Wednesday
that when the attempted power shift took place, no one physically checked to
see that the system was operating on diesel turbines - a routine procedure.
Had they checked, they probably would have noticed the system was running on
a battery reserve that lasts only about six hours. Also, audio and visual
alarms at the switching center apparently went unnoticed. Still, the crash
never would have happened had AT&T been able to switch back to Con Edison's
power grid at 4:30 p.m., as planned. For some reason, it couldn't. The
system then automatically reverted to the battery reserve, which ran out of
juice about 20 minutes later, causing the computers to crash. Why did that
relatively isolated failure disrupt airline traffic throughout the USA? The
Federal Aviation Administration uses AT&T lines to relay air-traffic
information from its control center on Long Island to airports from Boston to
Washington, D.C. - including New York's three metro airports. With those
phone lines down, air-traffic controllers couldn't be sure where planes were,
and neither could the planes' pilots. That meant planes at the three
airports couldn't take off. Connecting flights at other U.S. airports had to
be delayed, and dozens of flights were canceled hour by hour. How many of
these switching centers are there? Could this happen somewhere else? There
used to be thousands of AT&T switching centers throughout the country. But
advances in computer technology let AT&T handle even more calls with fewer
switching centers. Today, there are about 100 such computerized switches -
including three in lower Manhattan - which AT&T uses to route calls
throughout the country. Just one of AT&T's switches can handle 700,000 calls
an hour. Switches five years ago handled just 180,000 calls per hour. The
more powerful systems complete calls much more quickly and provide much
clearer connections. But with greater call-handling power concentrated in
fewer places, there's a greater potential for major phone-service outages.
What caused the other recent phone outages? Were those power failures, too?
No, the culprit in almost every instance was a computer-programming error,
commonly known as a bug. Such errors are buried in the millions of lines of
computer code used to create a call-switching program. Eliminating every
software bug in AT&T's signaling network would be almost impossible because
each program contains up to 5 million typed lines of code. As a comparison,
a program that runs on a personal computer contains just 1,000 lines of code.
One mistake, even a misplaced punctuation mark, can wreak havoc on any
computer system, including a telephone network. <TRUNCATED by TC.>
(end of article three, 9/18/91) ><
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Using Novell NetWare 2.2
This article covers the fundamentals of the use and administration of
Novell's NetWare v2.2. Note that while most of the procedures outlined in
this document are also applicable to NetWare v3.xx (for the 386 only), there
may be some slight differences in structure, etc. Also, if you are working
with an ELS-I, ELS-II, Adv. NetWare 2.15, or an SFT NetWare network, you will
find minor discrepancies in command operation. ELS-I is the least similar,
but the general principles and menu-drive system utilities should be the
same.
Overview
--------
NetWare v2.2 (hereafter referred to as 'NetWare') is part of the most
common PC local-area network product line in use today. It has earned the
reputation of being the fastest and most reliable LAN server software
available today, with a workstation shell that is among the smallest in the
industry. Capable of using any computer from 4.77-mHz 8088s to 40-mHz 80486s
running DOS versions 3 through 5, it has gained wide favor among the business
world -- indeed, many companies consider support for NetWare a must.
Requirements
------------
NetWare requires a 286- or 386-based computer with at least 2 MB of
memory to run as a file server. It can be run in either dedicated or non-
dedicated mode. This file server should be backed up with an uninterruptible
power supply, and if dedicated, it should ideally be physically protected.
NetWare also needs two special memory-resident utilities to boot up on every
workstation; the protocol handler (e.g. IPX, SPX, etc) and DOS3, DOS4, or
DOS5, depending on the DOS version used. The underlying network topology can
be configured in many ways; NetWare does not mind if you have an Ethernet
star configuration, a ArcNet bus topology, or a Token Ring network to operate
with. NetWare comes with a large set of manuals in small three-ring binders
to read, although not too many people do. NetWare is considered sufficiently
hard to install and administer that many people simply hire an outside
consultant. Note also that Netware servers have the advantage (from many
points of view) of acting like an advanced disk subsystem to the
workstations: All programs on a network are executed by the workstation's
processor, not the file server's.
Installed Defaults
------------------
The account defaults for a NetWare system are SUPERVISOR and GUEST.
SUPERVISOR has administrative access, or all rights in every directory.
GUEST has a security equivalence to the group EVERYONE, which has a set of
easily modifiable default rights. Upon installation, the system will set up
four default directories: SYSTEM, LOGIN, PUBLIC, and DOS (this may also be
MSDOS, DOS33, DOS5, etc.) Since the network shell operates over DOS, using
NetWare is the same thing as using DOS, with the exception of extended file
attributes. Both of these accounts are initially left unpassworded.
DEFAULT DIRECTORY STRUCTURE:
\ ------SYSTEM (PAUDIT, mail dirs, bindery files, etc.)
!
!--PUBLIC (FILER, SESSION, SYSCON, NSNIPES, other pub. utils)
!
!--LOGIN (LOGIN.EXE, SLIST.EXE, CONSOLE.COM, misc. login)
!
!--MSDOS (DOS commands)
The file server's hard drives are usually F: through Z:. An exception
to this rule is when using non-standard LASTDRIVE settings in the workstation
CONFIG.SYS file; however, the vast majority of NetWare setups use F: as the
NetWare drive. Other drive letters may be mapped to subdirectories (like the
DOS SUBST command) or search drives (like the DOS PATH statement). For
example, the drive letter G: can be assigned to the F:\PUBLIC directory.
Generally, the search drives are at the end of the alphabet. X:, for
example, could be a search drive for the F:\SYSTEM subdirectory. The user
might never actually switch to the X: drive, but by its presence as a search
drive it is automatically looked-through for commands.
Novell Utility Overview
-----------------------
Most of the Novell utilities that come with the file server are menu-
driven and easy to use. They are all written using the same C menuing
library, the name of which slips my mind. The menu structures are simple:
when presented with a list (say, of users) hitting ENTER on a user name will
edit it. Hitting Insert will insert a user in the list. Hitting Delete will
erase the user that the cursor is on. Online help is available by pressing
F1.
The most prominent utility is SYSCON, or System Configuration. This
program controls user access to the server. With SYSCON, the administrator
or system entry specialist (SES) can set the times a person can log in, their
password, their login script, how much they are billed per K used of disk
space, etc.
The second-most important utility to the administrator/SES is FCONSOLE,
or File Server Console. This program allows you to control file server
functions from a workstation, allowing the remote administrator to monitor
server statistics, broadcast console messages, knock users off the network,
shutdown the file server, etc.
PAUDIT and SECURITY, although not menu-based utilities, are extremely
important. PAUDIT displays a network log of sorts, describing logins/outs at
all workstations, intruder lockouts, important network actions, etc.
SECURITY attempts to analyze the network for security holes, checking various
aspects of the system configuration and reporting to the administrator any
security holes it finds.
Two others, SESSION and FILER, allow the user to easily send messages
in-between users, perform maintenance on their account, and list other users
on the server (SESSION), while FILER allows the user to easily examine the
subdirectories and files they have access to.
One last important addition: MENU. This program is a menu interpreter
for the network that uses menu script files. These files can be named almost
anything, and they are accessed by MENU filename.ext. The script files
generally have an appearance as follows:
%Main Menu,10,10
WordPerfect 5.1
f:
cd\wp51
wp
cd\
Use SESSION
session
Logout
logout
The % sign indicates a new window with a title of Main Menu starting at
the X,Y position 10,10. Occasionally a color attribute will follow the
screen position. The left-justified items are the menu selections that
appear to the user. The tab-justified commands are put into a temporary
batch file by the menu processor and executed when the selection is chosen.
Quite a simple and easy-to-understand language.
Accessing the Network
---------------------
To access a Novell network from a workstation, the workstation must
either have a "Remote Reset" boot-up PROM in the network adapter, or it must
have the two sets of Novell drivers, mentioned earlier (IPX, NET5, etc.). If
the workstation is diskless, it will have a Remote Reset PROM to boot up
with. This ROM allows the workstation to access the F:\LOGIN subdirectory on
the server, which will have a standard AUTOEXEC file for the workstations to
boot up with. A sure sign of a Remote Reset PROM is the computer startup
message, which will generally give a message saying that it has a boot-up ROM
in it. In most cases, the ROM itself is located on the network adapter and
is removable. If the workstation boots up from a hard drive, it has the
option of not connecting to the network at all: the Novell workstation
drivers are TSRs, not CONFIG.SYS-style drivers, so the Novell drivers could
be contained in a batch file. A floppy-based workstation will almost always
have the traditional set of Novell drivers on the disk, and most floppy
workstation users leave the network bootup disk in the drive. The most
vulnerable types of workstations are the hard/floppy disk-based ones. But
the arguably safest point of access into a Novell network is through a dial-
in phone line.
With a hard drive system on the workstation, the SES can generally comb
through the local directories looking for helpful hints and utilities. A
proficiency in MS-DOS is extremely helpful for accessing a Novell network.
Often, a user might leave his account and password in a so-called 'hidden'
area of the hard drive, in case he forgets. Or perhaps he might have saved
some mail there from another user, containing information he would want to
keep handy. Hard drives are naturally conducive to having the traditional
'shell monitor' interrupt hack installed on them. And of course, there is
the occasional rebellious employee, who keeps NETCRACK on his own system so
he can spy on the big boys! Whatever the case, a hard drive-containing
workstation is very serviceable.
Next down the line is the floppy-based workstation. Although this type
of workstation is far less likely to contain anything of interest on the
disk, floppy-drive workstations are also far less likely to contain any sort
of boot-up local password protection. Not to mention, the user may have a
collection of floppies somewhere in the room, with potentially useful
information. However, it takes a lot of time and some personally-supplied
utilities to make much sense of them. With a few modifications, the shell
monitor interrupt TSR can be made to work via a floppy system, but the risk
of detection is somewhat higher. This type of workstation lends itself to
the NETCRACK approach as well, assuming the SES has it on a compatible
floppy.
The diskless workstation is quite the irritant of the three, forcing a
SES to meticulously hand-hack the accounts in question. Diskless
workstations are by their very nature impervious to any sort of viral
invasion, and system administrators like them for their entry-resistant
qualities. However, this does not mean they are impossible to attack by any
means. If the SES has the time, the expertise, and the tools, he can open
the case of the workstation, pop the Remote Reset PROM, install a floppy
controller card (which in some cases could already be there), and install a
floppy drive. For several reasons, this approach is limited to the creative.
Another utility freely available on the network F:\LOGIN directory is SLIST.
SLIST will list other servers accessible from the workstation, giving the SES
a second network to attempt entry on. The LOGIN command is obviously the key
to the whole operation. You know it's Netware when it asks you:
Enter your login name:
Enter your password:
Hitting ENTER at both prompts will generally return you to the DOS
prompt, unless an incredibly security-aware administrator has encased the
LOGIN command in a specially-treated batch file. (I'm not going to go into
the process for doing so here, considering once in it, there is no way to
break out.) To find all the parameters for the LOGIN command, type LOGIN /?.
The most useful parameter for LOGIN is the Noscript parameter, which will put
you directly at the Novell prompt when access is gained to the server -
aborting the script files that normally execute after you log on, in case the
user/administrator has inserted something uncouth, like a non-exitable menu.
All this would be well and good if it weren't for some of Netware's
intrusion-resistant features. The administrator (through SYSCON) can define
limits for incorrect logins, at which point that workstation will be locked
out for an amount of time determined by the administrator. He can also set
minimum periods of time in which a user must change his/her password. These
features make life hard for the non-technologically advanced hand-hacker, so
creativity is a must.
Life After LOGIN
----------------
After a successful LOGIN, the system login script is executed. Defined
by the administrator through SYSCON, this file written in Novell's script
language generally bades the user good morning/afternoon/evening, MAPs
subdirectories to drive letters and sets up search drives, and terminates.
Then the user login script kicks in, setting up personal MAPped drives,
firing phasers a few times, and either exiting to a menu or to the DOS
prompt. Simple login scripts run along these lines:
DOS VERIFY ON
MAP G: = F:\WP51
MAP H: = F:\PUBLIC
(end of system login script)
FIRE PHASERS 3 TIMES
MAP I: = F:\MYDIR
DRIVE I:
EXIT "MENU"
(end of user login script)
Login scripts are more complicated than that; but those two are general
guidelines on what to expect to see. Well, maybe not the FIRE PHASERS, but
it DOES exist, and is often abbreviated to FIRE. The first login script
would be the system login script, which turns the DOS verify flag on and MAPs
the logical G: drive to the F:\WP51 directory and the H: drive to the
F:\PUBLIC directory. (Sidenote: Although the G and H logical drives are
mapped to those two directories, they are not limited to those two
directories.) The second login script would be the user login script, making
three phaser noises, MAPping the I: drive to the directory F:\MYDIR,
switching to drive I:, and exiting and executing the file MENU.*. Note here
that pathnames may NOT be included in an EXIT.
If exited to a DOS prompt, the user may then come and go as he pleases
through the directories he has rights in. To determine one's rights in a
directory, type RIGHTS (assuming there is a search drive MAPped to the
F:\PUBLIC directory). To logoff, type LOGOUT. To use Nsnipes, a very
important Novell game (er..utility), type NSNIPES.
Physical Access to the File Server
----------------------------------
No doubt the serious SES will be wondering by now what the file server
is doing at this time. Assuming the file server is running as a dedicated
server (Netware 2.2, ELS-x), you will be at the : prompt. This prompt is
more or less worthless, with the exception of three commands: MONITOR, DOWN,
and CLEAR STATION. The command MONITOR will display the first six
workstations in windows on the screen and display a list of the five most
recent file accesses they have made. If the network has more than six
workstations, the next group of six can be displayed with MONITOR 7, and the
next with MONITOR 18, etc. The other command is DOWN, which does exactly
what it looks like it's supposed to do - shutdown the file server. If users
are currently using the server with active files open, the system will
display the warning "ACTIVE FILES OPEN, HALT NETWORK?" at which point you
are free to decide the fate of the server. Note that shutting the server
down while files are active runs the risk of severely damaging the active
files. The command CLEAR STATION will in effect knock a particular
workstation off the network, in case it has crashed or has been possessed by
evil spirits. The syntax is CLEAR STATION x, where x is the number of the
workstation that corresponds to the window on the MONITOR screen. This
command is also executable through FCONSOLE.
Dialing into Netware
--------------------
There are several products, both hardware and software, that allow
remote connections to a Netware LAN. I'm not going to go through them,
because I haven't had any experience with them, but I can point in the right
direction: the July 1991 Byte magazine has a review of six products. They
range in speed and LAN-external security, but it is interesting to note that
none of them support callbacks and some even dump you into a DOS prompt at
the F:\LOGIN prompt.
I hope you've been able to make some sense out of this rudimentary
guide. As I hope you've inferred, there are various software products out
there designed to make an SES's task easier. If there's anyone out there
with suggestions, or people who know if I've screwed up somewhere, feel free
to drop me a line. And remember, there is no substitute for experience. ><
[TC: The Cavalier can be reached at any of the addresses in the header.]
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Beginners' ED
This article will cover some of the basic functions of Unix's simple
text editor, ED. The Unix system this example was used on is a straight BSD
4.2 using the C shell. By the way, I don't claim to be at all an expert on
Unix, but since I've had a little bit of experience with ED, I figured it was
worth putting out an overview of this common editor.
ED is a Unix-based text editor that comes standard with virtually every
version of Unix sold. It has been superseded by VI, a full-screen editor,
but ED is a lot easier to use with a glass TTY terminal. In some ways, ED is
similar to EDLIN -- the text editor that comes with MS-DOS. Like EDLIN, most
commands in ED can be preceded with 'addresses,' or line numbers to perform
the specified operation on. For example, the command 2,4d would delete lines
2 through 4. ED also has special metacharacters, most notably the $ and the
. The dollar sign substitutes in to the command the last line number in the
file, so typing 2,$d would delete lines 2 through the end of the file,
leaving you with line 1. The period indicates the current line that the
editor is on. So, in other words, if you just made a change to line 4, and
typed .,6d, ED would delete lines 4 through 6. There are other
metacharacters, but the $ is arguably of the most importance to the beginner
at ED. Another convention in ED is to use a lone period on a blank line to
terminate input. For example, when inserting lines, let's say you are
inserting before line 6. (So your command would be 6i.) You would type:
6i
Blah, blah. This text is inserted before line 6. SFI iz grate.
