3257 lines
146 KiB
Plaintext
3257 lines
146 KiB
Plaintext
|
Founded By: | _ _______
|
||
|
|
Guardian Of Time | __ N.I.A. _ ___ ___ Are you on any WAN? are
|
||
|
|
Judge Dredd | ____ ___ ___ ___ ___ you on Bitnet, Internet
|
||
|
|
------------------+ _____ ___ ___ ___ ___ Compuserve, MCI Mail,
|
||
|
|
\ / ___ ___ ___ ___ ___________ Sprintmail, Applelink,
|
||
|
|
+---------+ ___ ___ ___ ___ ___________ Easynet, MilNet,
|
||
|
|
| 05MON18 | ___ ______ ___ ___ ___ FidoNet, et al.?
|
||
|
|
| File 74 | ___ _____ ___ ___ ___ If so please drop us a
|
||
|
|
+---------+ ____ _ __ ___ line at
|
||
|
|
___ _ ___ nia@nuchat.sccsi.com
|
||
|
|
Internal Affairs BBS __ NIA074
|
||
|
|
_ Network Information Access
|
||
|
|
Ignorance, There's No Excuse.
|
||
|
|
|
||
|
|
NIA Issue 074 Volume 2
|
||
|
|
|
||
|
|
|
||
|
|
"I didn't invent the Unix security problem. I just optimized it."
|
||
|
|
|
||
|
|
|
||
|
|
Greetings. This newsletter is published on a non-regular basis and
|
||
|
|
is only a hobby by the editors, not a job. No responsibility is taken by
|
||
|
|
the editors for this newsletter, all of that and the credit goes to the
|
||
|
|
contributers. We are changing format again to go with the changing times.
|
||
|
|
First of all, there will be NO news unless it is first hand accounts of it.
|
||
|
|
If you want news, there are plenty of other electronic 'zines and more
|
||
|
|
efficient ways of getting it than to wait for an NIA issue to come out.
|
||
|
|
Second, the articles are going to be getting technical. There is only
|
||
|
|
so many intro/basics we can publish/re-print.
|
||
|
|
We are looking for contributions. All articles submitted must be in a
|
||
|
|
regular format for the magazine. There is a one month review time for the
|
||
|
|
article to be chosen. There is an additional one month revise time if the
|
||
|
|
article is chosen. We do keep copies of everything that is sent to us so if
|
||
|
|
it is not published in the immediate issue than it could be published in a
|
||
|
|
later issue (in which case you will be notified). The readers make the
|
||
|
|
magazine, so if you want to see better issues then do some research and
|
||
|
|
send us reports.
|
||
|
|
|
||
|
|
------------------------------------------------------------------------------
|
||
|
|
1. Introduction ......................................................Editors
|
||
|
|
2. Security Problems in TCP/IP Suite [01/02] ...................S.M. Bellovin
|
||
|
|
3. Security Problems in TCP/IP Suite [02/02] ...................S.M. Bellovin
|
||
|
|
4. Firewalls: The Design of Secure Internet Gateway ............Bill Cheswick
|
||
|
|
5. Notes on Centigram Systems ......................................Anonymous
|
||
|
|
6. How to Steal Information .......................................The Butler
|
||
|
|
7. Killer Chips: Physical Virus ...................Jean-Bernard Condat [CCCF]
|
||
|
|
------------------------------------------------------------------------------
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
NIA074 / File 02
|
||
|
|
|
||
|
|
Security Problems in the TCP/IP Protocol Suite
|
||
|
|
|
||
|
|
Part I of II
|
||
|
|
|
||
|
|
S.M. Bellovin
|
||
|
|
|
||
|
|
AT&T Bell Laboratories
|
||
|
|
|
||
|
|
ABSTRACT
|
||
|
|
|
||
|
|
The TCP/IP protocol suite, which is very
|
||
|
|
widely used today, was developed under
|
||
|
|
the sponsorship of the Department of
|
||
|
|
Defense. Despite that, there are a
|
||
|
|
number of serious security flaws
|
||
|
|
inherent in the protocols, regardless of
|
||
|
|
the correctness of any implementations.
|
||
|
|
We describe a variety of attacks based
|
||
|
|
on these flaws, including sequence
|
||
|
|
number spoofing, routing attacks, source
|
||
|
|
address spoofing, and authentication
|
||
|
|
attacks. We also present defenses
|
||
|
|
against these attacks, and conclude with
|
||
|
|
a discussion of broad-spectrum defenses
|
||
|
|
such as encryption.
|
||
|
|
|
||
|
|
1. INTRODUCTION
|
||
|
|
|
||
|
|
The TCP/IP protocol suite[1][2], which is very widely used
|
||
|
|
today, was developed under the sponsorship of the Department
|
||
|
|
of Defense. Despite that, there are a number of serious
|
||
|
|
security flaws inherent in the protocols. Some of these
|
||
|
|
flaws exist because hosts rely on IP source address for
|
||
|
|
authentication; the Berkeley "r-utilities"[3] are a
|
||
|
|
notable example. Others exist because network control
|
||
|
|
mechanisms, and in particular routing protocols, have
|
||
|
|
minimal or non-existent authentication.
|
||
|
|
|
||
|
|
When describing such attacks, our basic assumption is that
|
||
|
|
the attacker has more or less complete control over some
|
||
|
|
machine connected to the Internet. This may be due to flaws
|
||
|
|
in that machine's own protection mechanisms, or it may be
|
||
|
|
|
||
|
|
__________
|
||
|
|
|
||
|
|
* Author's address: Room 3C-536B AT&T Bell Laboratories,
|
||
|
|
600 Mountain Avenue, Murray Hill, New Jersey 07974.
|
||
|
|
|
||
|
|
Reprinted from Computer Communication Review Vol. 19
|
||
|
|
No. 2, p.32-48, April 1989.
|
||
|
|
|
||
|
|
because that machine is a microcomputer, and inherently
|
||
|
|
unprotected. Indeed, the attacker may even be a rogue
|
||
|
|
system administrator.
|
||
|
|
|
||
|
|
1.1 Exclusions
|
||
|
|
|
||
|
|
We are not concerned with flaws in particular
|
||
|
|
implementations of the protocols, such as those used by the
|
||
|
|
Internet "worm"[4][5][6]. Rather, we discuss generic
|
||
|
|
problems with the protocols themselves. As will be seen,
|
||
|
|
careful implementation techniques can alleviate or prevent
|
||
|
|
some of these problems. Some of the protocols we discuss
|
||
|
|
are derived from Berkeley's version of the UNIXr system;
|
||
|
|
others are generic Internet protocols.
|
||
|
|
|
||
|
|
We are also not concerned with classic network attacks, such
|
||
|
|
as physical eavesdropping, or altered or injected messages.
|
||
|
|
We discuss such problems only in so far as they are
|
||
|
|
facilitated or possible because of protocol problems.
|
||
|
|
|
||
|
|
For the most part, there is no discussion here of vendor-
|
||
|
|
specific protocols. We do discuss some problems with
|
||
|
|
Berkeley's protocols, since these have become de facto
|
||
|
|
standards for many vendors, and not just for UNIX systems.
|
||
|
|
|
||
|
|
|
||
|
|
2. TCP SEQUENCE NUMBER PREDICTION
|
||
|
|
|
||
|
|
One of the more fascinating security holes was first
|
||
|
|
described by Morris[7]. Briefly, he used TCP sequence
|
||
|
|
number prediction to construct a TCP packet sequence without
|
||
|
|
ever receiving any responses from the server. This allowed
|
||
|
|
him to spoof a trusted host on a local network.
|
||
|
|
|
||
|
|
The normal TCP connection establishment sequence involves a
|
||
|
|
3-way handshake. The client selects and transmits an
|
||
|
|
initial sequence number ISNC, the server acknowledges it and
|
||
|
|
sends its own sequence number ISNS, and the client
|
||
|
|
acknowledges that. Following those three messages, data
|
||
|
|
transmission may take place. The exchange may be shown
|
||
|
|
schematically as follows:
|
||
|
|
|
||
|
|
C->S:SYN(ISNC)
|
||
|
|
S->C:SYN(ISNS),ACK(ISNC)
|
||
|
|
C->S:ACK(ISNS)
|
||
|
|
C->S:data
|
||
|
|
and/or
|
||
|
|
S->C:data
|
||
|
|
|
||
|
|
That is, for a conversation to take place, C must first hear
|
||
|
|
ISNS, a more or less random number.
|
||
|
|
|
||
|
|
Suppose, though, that there was a way for an intruder X to
|
||
|
|
predict ISNS. In that case, it could send the following
|
||
|
|
sequence to impersonate trusted host T:
|
||
|
|
|
||
|
|
X->S:SYN(ISNX),SRC=T
|
||
|
|
S->T:SYN(ISNS),ACK(ISNX)
|
||
|
|
X->S:ACK(ISNS),SRC=T
|
||
|
|
X->S:ACK(ISNS),SRC=T,nasty-data
|
||
|
|
|
||
|
|
Even though the message S->T does not go to X, X was able to
|
||
|
|
know its contents, and hence could send data. If X were to
|
||
|
|
perform this attack on a connection that allows command
|
||
|
|
execution (i.e., the Berkeley rsh server), malicious
|
||
|
|
commands could be executed.
|
||
|
|
|
||
|
|
How, then, to predict the random ISN? In Berkeley systems,
|
||
|
|
the initial sequence number variable is incremented by a
|
||
|
|
constant amount once per second, and by half that amount
|
||
|
|
each time a connection is initiated. Thus, if one initiates
|
||
|
|
a legitimate connection and observes the ISNS used, one can
|
||
|
|
calculate, with a high degree of confidence, ISNS' used on
|
||
|
|
the next connection attempt.
|
||
|
|
|
||
|
|
Morris points out that the reply message
|
||
|
|
|
||
|
|
S->T:SYN(ISNS),ACK(ISNX)
|
||
|
|
|
||
|
|
does not in fact vanish down a black hole; rather, the real
|
||
|
|
host T will receive it and attempt to reset the connection.
|
||
|
|
This is not a serious obstacle. Morris found that by
|
||
|
|
impersonating a server port on T, and by flooding that port
|
||
|
|
with apparent connection requests, he could generate queue
|
||
|
|
overflows that would make it likely that the S->T message
|
||
|
|
would be lost. Alternatively, one could wait until T was
|
||
|
|
down for routine maintenance or a reboot.
|
||
|
|
|
||
|
|
A variant on this TCP sequence number attack, not described
|
||
|
|
by Morris, exploits the netstat[8] service. In this attack,
|
||
|
|
the intruder impersonates a host that is down. If netstat
|
||
|
|
is available on the target host, it may supply the necessary
|
||
|
|
sequence number information on another port; this eliminates
|
||
|
|
all need to guess1.
|
||
|
|
__________
|
||
|
|
|
||
|
|
1. The netstat protocol is obsolete, but is still present
|
||
|
|
on some Internet hosts. Security concerns were not
|
||
|
|
|
||
|
|
Defenses
|
||
|
|
Obviously, the key to this attack is the relatively coarse
|
||
|
|
rate of change of the initial sequence number variable on
|
||
|
|
Berkeley systems. The TCP specification requires that this
|
||
|
|
variable be incremented approximately 250,000 times per
|
||
|
|
second; Berkeley is using a much slower rate. However, the
|
||
|
|
critical factor is the granularity, not the average rate.
|
||
|
|
The change from an increment of 128 per second in 4.2BSD to
|
||
|
|
125,000 per second in 4.3BSD is meaningless, even though the
|
||
|
|
latter is within a factor of two of the specified rate.
|
||
|
|
|
||
|
|
Let us consider whether a counter that operated at a true
|
||
|
|
250,000 hz rate would help. For simplicity's sake, we will
|
||
|
|
ignore the problem of other connections occurring, and only
|
||
|
|
consider the fixed rate of change of this counter.
|
||
|
|
|
||
|
|
To learn a current sequence number, one must send a SYN
|
||
|
|
packet, and receive a response, as follows:
|
||
|
|
|
||
|
|
X->S: SYN(ISNX)
|
||
|
|
S->X: SYN(ISNS),ACK(ISNX) (1)
|
||
|
|
|
||
|
|
The first spoof packet, which triggers generation of the
|
||
|
|
next sequence number, can immediately follow the server's
|
||
|
|
response to the probe packet:
|
||
|
|
|
||
|
|
X->S: SYN(ISNX),SRC=T (2)
|
||
|
|
|
||
|
|
The sequence number ISNS used in the response
|
||
|
|
|
||
|
|
S->T: SYN(ISNS),ACK(ISNX)
|
||
|
|
|
||
|
|
is uniquely determined by the time between the origination
|
||
|
|
of message (0) and the receipt at the server of message (0).
|
||
|
|
But this number is precisely the round-trip time between X
|
||
|
|
and S. Thus, if the spoofer can accurately measure (and
|
||
|
|
predict) that time, even a 4-second clock will not defeat
|
||
|
|
this attack.
|
||
|
|
|
||
|
|
How accurately can the trip time be measured? If we assume
|
||
|
|
that stability is good, we can probably bound it within 10
|
||
|
|
milliseconds or so. Clearly, the Internet does not exhibit
|
||
|
|
such stability over the long-term[9], but it is often good
|
||
|
|
enough over the short term.2 There is thus an uncertainty of
|
||
|
|
____________________________________________________________
|
||
|
|
|
||
|
|
behind its elimination.
|
||
|
|
|
||
|
|
2500 in the possible value for ISNS. If each trial takes 5
|
||
|
|
seconds, to allow time to re-measure the round-trip time, an
|
||
|
|
intruder would have a reasonable likelihood of succeeding in
|
||
|
|
7500 seconds, and a near-certainty within a day. More
|
||
|
|
predictable (i.e., higher quality) networks, or more
|
||
|
|
accurate measurements, would improve the odds even further
|
||
|
|
in the intruder's favor. Clearly, simply following the
|
||
|
|
letter of the TCP specification is not good enough.
|
||
|
|
|
||
|
|
We have thus far tacitly assumed that no processing takes
|
||
|
|
places on the target host. In fact, some processing does
|
||
|
|
take place when a new request comes in; the amount of
|
||
|
|
variability in this processing is critical. On a 6 MIPS
|
||
|
|
machine, one tick -- 4 M-seconds -- is about 25
|
||
|
|
instructions. There is thus considerable sensitivity to the
|
||
|
|
exact instruction path followed. High-priority interrupts,
|
||
|
|
or a slightly different TCB allocation sequence, will have a
|
||
|
|
comparatively large effect on the actual value of the next
|
||
|
|
sequence number. This randomizing effect is of considerable
|
||
|
|
advantage to the target. It should be noted, though, that
|
||
|
|
faster machines are more vulnerable to this attack, since
|
||
|
|
the variability of the instruction path will take less real
|
||
|
|
time, and hence affect the increment less. And of course,
|
||
|
|
CPU speeds are increasing rapidly.
|
||
|
|
|
||
|
|
This suggests another solution to sequence number attacks:
|
||
|
|
randomizing the increment. Care must be taken to use
|
||
|
|
sufficient bits; if, say, only the low-order 8 bits were
|
||
|
|
picked randomly, and the granularity of the increment was
|
||
|
|
coarse, the intruder's work factor is only multiplied by
|
||
|
|
256. A combination of a fine-granularity increment and a
|
||
|
|
small random number generator, or just a 32-bit generator,
|
||
|
|
is better. Note, though, that many pseudo-random number
|
||
|
|
generators are easily invertible[10]. In fact, given that
|
||
|
|
most such generators work via feedback of their output, the
|
||
|
|
enemy could simply compute the next "random" number to be
|
||
|
|
picked. Some hybrid techniques have promise -- using a 32-
|
||
|
|
bit generator, for example, but only emitting 16 bits of it
|
||
|
|
-- but brute-force attacks could succeed at determining the
|
||
|
|
seed. One would need at least 16 bits of random data in
|
||
|
|
____________________________________________________________
|
||
|
|
|
||
|
|
2. At the moment, the Internet may not have such stability
|
||
|
|
even over the short-term, especially on long-haul
|
||
|
|
connections. It is not comforting to know that the
|
||
|
|
security of a network relies on its low quality of
|
||
|
|
service.
|
||
|
|
|
||
|
|
|
||
|
|
each increment, and perhaps more, to defeat probes from the
|
||
|
|
network, but that might leave too few bits to guard against
|
||
|
|
a search for the seed. More research or simulations are
|
||
|
|
needed to determine the proper parameters.
|
||
|
|
|
||
|
|
Rather than go to such lengths, it is simpler to use a
|
||
|
|
cryptographic algorithm (or device) for ISNS generation.
|
||
|
|
The Data Encryption Standard[11] (DES) in electronic
|
||
|
|
codebook mode[12] is an attractive choice as the ISNS
|
||
|
|
source, with a simple counter as input. Alternatively, DES
|
||
|
|
could be used in output feedback mode without an additional
|
||
|
|
counter. Either way, great care must be taken to select the
|
||
|
|
key used. The time-of-day at boot time is not adequate;
|
||
|
|
sufficiently good information about reboot times is often
|
||
|
|
available to an intruder, thereby permitting a brute-force
|
||
|
|
attack. If, however, the reboot time is encrypted with a
|
||
|
|
per-host secret key, the generator cannot be cracked with
|
||
|
|
any reasonable effort.
|
||
|
|
|
||
|
|
Performance of the initial sequence number generator is not
|
||
|
|
a problem. New sequence numbers are needed only once per
|
||
|
|
connection, and even a software implementation of DES will
|
||
|
|
suffice. Encryption times of 2.3 milliseconds on a 1 MIPS
|
||
|
|
processor have been reported[13].
|
||
|
|
|
||
|
|
An additional defense involves good logging and alerting
|
||
|
|
mechanisms. Measurements of the round-trip time --
|
||
|
|
essential for attacking RFC-compliant hosts -- would most
|
||
|
|
likely be carried out using ICMP Ping messages; a
|
||
|
|
"transponder" function could log excessive ping requests.
|
||
|
|
Other, perhaps more applicable, timing measurement
|
||
|
|
techniques would involve attempted TCP connections; these
|
||
|
|
connections are conspicuously short-lived, and may not even
|
||
|
|
complete SYN processing. Similarly, spoofing an active host
|
||
|
|
will eventually generate unusual types of RST packets; these
|
||
|
|
should not occur often, and should be logged.
|
||
|
|
|
||
|
|
3. THE JOY OF ROUTING
|
||
|
|
|
||
|
|
Abuse of the routing mechanisms and protocols is probably
|
||
|
|
the simplest protocol-based attack available. There are a
|
||
|
|
variety of ways to do this, depending on the exact routing
|
||
|
|
protocols used. Some of these attacks succeed only if the
|
||
|
|
remote host does source address-based authentication; others
|
||
|
|
can be used for more powerful attacks.
|
||
|
|
|
||
|
|
A number of the attacks described below can also be used to
|
||
|
|
accomplish denial of service by confusing the routing tables
|
||
|
|
on a host or gateway. The details are straight-forward
|
||
|
|
corollaries of the penetration mechanisms, and will not be
|
||
|
|
described further.
|
||
|
|
|
||
|
|
3.1 Source Routing
|
||
|
|
|
||
|
|
If available, the easiest mechanism to abuse is IP source
|
||
|
|
routing. Assume that the target host uses the reverse of
|
||
|
|
the source route provided in a TCP open request for return
|
||
|
|
traffic. Such behavior is utterly reasonable; if the
|
||
|
|
originator of the connection wishes to specify a particular
|
||
|
|
path for some reason -- say, because the automatic route is
|
||
|
|
dead -- replies may not reach the originator if a different
|
||
|
|
path is followed.
|
||
|
|
|
||
|
|
The attacker can then pick any IP source address desired,
|
||
|
|
including that of a trusted machine on the target's local
|
||
|
|
network. Any facilities available to such machines become
|
||
|
|
available to the attacker.
|
||
|
|
|
||
|
|
Defenses
|
||
|
|
It is rather hard to defend against this sort of attack.
|
||
|
|
The best idea would be for the gateways into the local net
|
||
|
|
to reject external packets that claim to be from the local
|
||
|
|
net. This is less practical than it might seem since some
|
||
|
|
Ethernet3 network adapters receive their own transmissions,
|
||
|
|
and this feature is relied upon by some higher-level
|
||
|
|
protocols. Furthermore, this solution fails completely if
|
||
|
|
an organization has two trusted networks connected via a
|
||
|
|
multi-organization backbone. Other users on the backbone
|
||
|
|
may not be trustable to the same extent that local users are
|
||
|
|
presumed to be, or perhaps their vulnerability to outside
|
||
|
|
attack is higher. Arguably, such topologies should be
|
||
|
|
avoided in any event.
|
||
|
|
|
||
|
|
A simpler method might be to reject pre-authorized
|
||
|
|
connections if source routing information was present. This
|
||
|
|
presumes that there are few legitimate reasons for using
|
||
|
|
this IP option, especially for relatively normal operations.
|
||
|
|
A variation on this defense would be to analyze the source
|
||
|
|
route and accept it if only trusted gateways were listed;
|
||
|
|
that way, the final gateway could be counted on to deliver
|
||
|
|
the packet only to the true destination host. The
|
||
|
|
complexity of this idea is probably not worthwhile.
|
||
|
|
__________
|
||
|
|
|
||
|
|
3. Ethernet is a registered trademark of Xerox Corporation.
|
||
|
|
|
||
|
|
Some protocols (i.e., Berkeley's rlogin and rsh) permit
|
||
|
|
ordinary users to extend trust to remote host/user
|
||
|
|
combinations. In that case, individual users, rather than
|
||
|
|
an entire system, may be targeted by source routing
|
||
|
|
attacks.4 Suspicious gateways[14] will not help here, as the
|
||
|
|
host being spoofed may not be within the security domain
|
||
|
|
protected by the gateways.
|
||
|
|
|
||
|
|
3.2 Routing Attacks
|
||
|
|
|
||
|
|
The Routing Information Protocol[15] (RIP) is used to
|
||
|
|
propagate routing information on local networks, especially
|
||
|
|
broadcast media. Typically, the information received is
|
||
|
|
unchecked. This allows an intruder to send bogus routing
|
||
|
|
information to a target host, and to each of the gateways
|
||
|
|
along the way, to impersonate a particular host. The most
|
||
|
|
likely attack of this sort would be to claim a route to a
|
||
|
|
particular unused host, rather than to a network; this would
|
||
|
|
cause all packets destined for that host to be sent to the
|
||
|
|
intruder's machine. (Diverting packets for an entire
|
||
|
|
network might be too noticeable; impersonating an idle
|
||
|
|
work-station is comparatively risk-free.) Once this is
|
||
|
|
done, protocols that rely on address-based authentication
|
||
|
|
are effectively compromised.
|
||
|
|
|
||
|
|
This attack can yield more subtle, and more serious,
|
||
|
|
benefits to the attacker as well. Assume that the attacker
|
||
|
|
claims a route to an active host or workstation instead.
|
||
|
|
All packets for that host will be routed to the intruder's
|
||
|
|
machine for inspection and possible alteration. They are
|
||
|
|
then resent, using IP source address routing, to the
|
||
|
|
intended destination. An outsider may thus capture
|
||
|
|
passwords and other sensitive data. This mode of attack is
|
||
|
|
unique in that it affects outbound calls as well; thus, a
|
||
|
|
user calling out from the targeted host can be tricked into
|
||
|
|
divulging a password. Most of the earlier attacks discussed
|
||
|
|
are used to forge a source address; this one is focused on
|
||
|
|
the destination address.
|
||
|
|
__________
|
||
|
|
|
||
|
|
4. Permitting ordinary users to extend trust is probably
|
||
|
|
wrong in any event, regardless of abuse of the
|
||
|
|
protocols. But such concerns are beyond the scope of
|
||
|
|
this paper.
|
||
|
|
|
||
|
|
Defenses
|
||
|
|
A RIP attack is somewhat easier to defend against than the
|
||
|
|
source-routing attacks, though some defenses are similar. A
|
||
|
|
paranoid gateway -- one that filters packets based on source
|
||
|
|
or destination address -- will block any form of host-
|
||
|
|
spoofing (including TCP sequence number attacks), since the
|
||
|
|
offending packets can never make it through. But there are
|
||
|
|
other ways to deal with RIP problems.
|
||
|
|
|
||
|
|
One defense is for RIP to be more skeptical about the routes
|
||
|
|
it accepts. In most environments, there is no good reason
|
||
|
|
to accept new routes to your own local networks. A router
|
||
|
|
that makes this check can easily detect intrusion attempts.
|
||
|
|
Unfortunately, some implementations rely on hearing their
|
||
|
|
own broadcasts to retain their knowledge of directly-
|
||
|
|
attached networks. The idea, presumably, is that they can
|
||
|
|
use other networks to route around local outages. While
|
||
|
|
fault-tolerance is in general a good idea, the actual
|
||
|
|
utility of this technique is low in many environments
|
||
|
|
compared with the risks.
|
||
|
|
|
||
|
|
It would be useful to be able to authenticate RIP packets;
|
||
|
|
in the absence of inexpensive public-key signature schemes,
|
||
|
|
this is difficult for a broadcast protocol. Even if it were
|
||
|
|
done, its utility is limited; a receiver can only
|
||
|
|
authenticate the immediate sender, which in turn may have
|
||
|
|
been deceived by gateways further upstream.
|
||
|
|
|
||
|
|
Even if the local routers don't implement defense
|
||
|
|
mechanisms, RIP attacks carry another risk: the bogus
|
||
|
|
routing entries are visible over a wide area. Any router
|
||
|
|
(as opposed to host) that receives such data will
|
||
|
|
rebroadcast it; a suspicious administrator almost anywhere
|
||
|
|
on the local collection of networks could notice the
|
||
|
|
anomaly. Good log generation would help, but it is hard to
|
||
|
|
distinguish a genuine intrusion from the routing instability
|
||
|
|
that can accompany a gateway crash.
|
||
|
|
|
||
|
|
3.3 Exterior Gateway Protocol
|
||
|
|
|
||
|
|
The Exterior Gateway Protocol (EGP)[16] is intended for
|
||
|
|
communications between the core gateways and so-called
|
||
|
|
exterior gateways. An exterior gateway, after going through
|
||
|
|
a neighbor acquisition protocol, is periodically polled by
|
||
|
|
the core; it responds with information about the networks it
|
||
|
|
serves. These networks must all be part of its autonomous
|
||
|
|
system. Similarly, the gateway periodically requests
|
||
|
|
routing information from the core gateway. Data is not
|
||
|
|
normally sent except in response to a poll; furthermore,
|
||
|
|
since each poll carries a sequence number that must be
|
||
|
|
echoed by the response, it is rather difficult for an
|
||
|
|
intruder to inject a false route update. Exterior gateways
|
||
|
|
are allowed to send exactly one spontaneous update between
|
||
|
|
any two polls; this, too, must carry the sequence number of
|
||
|
|
the last poll received. It is thus comparatively difficult
|
||
|
|
to interfere in an on-going EGP conversation.
|
||
|
|
|
||
|
|
One possible attack would be to impersonate a second
|
||
|
|
exterior gateway for the same autonomous system. This may
|
||
|
|
not succeed, as the core gateways could be equipped with a
|
||
|
|
list of legitimate gateways to each autonomous system. Such
|
||
|
|
checks are not currently done, however. Even if they were,
|
||
|
|
they could be authenticated only by source IP address.
|
||
|
|
|
||
|
|
A more powerful attack would be to claim reachability for
|
||
|
|
some network where the real gateway is down. That is, if
|
||
|
|
gateway G normally handles traffic for network N, and G is
|
||
|
|
down, gateway G' could advertise a route to that network.
|
||
|
|
This would allow password capture by assorted mechanisms.
|
||
|
|
The main defense against this attack is topological (and
|
||
|
|
quite restrictive): exterior gateways must be on the same
|
||
|
|
network as the core; thus, the intruder would need to
|
||
|
|
subvert not just any host, but an existing gateway or host
|
||
|
|
that is directly on the main net.
|
||
|
|
|
||
|
|
A sequence number attack, similar to those used against TCP,
|
||
|
|
might be attempted; the difficulty here is in predicting
|
||
|
|
what numbers the core gateway is using. In TCP, one can
|
||
|
|
establish arbitrary connections to probe for information; in
|
||
|
|
EGP, only a few hosts may speak to the core. (More
|
||
|
|
accurately, the core could only speak to a few particular
|
||
|
|
hosts, though as noted such checks are not currently
|
||
|
|
implemented.) It may thus be hard to get the raw data
|
||
|
|
needed for such an attack.
|
||
|
|
|
||
|
|
3.4 The Internet Control Message Protocol
|
||
|
|
|
||
|
|
The Internet Control Message Protocol (ICMP)[17] is the
|
||
|
|
basic network management tool of the TCP/IP protocol suite.
|
||
|
|
It would seem to carry a rich potential for abuse.
|
||
|
|
Surprisingly, ICMP attacks are rather difficult; still,
|
||
|
|
there are often holes that may be exploited.
|
||
|
|
|
||
|
|
The first, and most obvious target, is the ICMP Redirect
|
||
|
|
message; it is used by gateways to advise hosts of better
|
||
|
|
routes. As such it can often be abused in the same way that
|
||
|
|
RIP can be. The complication is that a Redirect message
|
||
|
|
must be tied to a particular, existing connection; it cannot
|
||
|
|
be used to make an unsolicited change to the host's routing
|
||
|
|
tables. Furthermore, Redirects are only applicable within a
|
||
|
|
limited topology; they may be sent only from the first
|
||
|
|
gateway along the path to the originating host. A later
|
||
|
|
gateway may not advise that host, nor may it use ICMP
|
||
|
|
Redirect to control other gateways.
|
||
|
|
|
||
|
|
Suppose, though, that an intruder has penetrated a secondary
|
||
|
|
gateway available to a target host, but not the primary one.
|
||
|
|
(It may suffice to penetrate an ordinary host on the
|
||
|
|
target's local network, and have it claim to be a gateway.)
|
||
|
|
Assume further that the intruder wishes to set up a false
|
||
|
|
route to trusted host T through that compromised secondary
|
||
|
|
gateway. The following sequence may then be followed. Send
|
||
|
|
a false TCP open packet to the target host, claiming to be
|
||
|
|
from T. The target will respond with its own open packet,
|
||
|
|
routing it through the secure primary gateway. While this
|
||
|
|
is in transit, a false Redirect may be sent, claiming to be
|
||
|
|
from the primary gateway, and referring to the bogus
|
||
|
|
connection. This packet will appear to be a legitimate
|
||
|
|
control message; hence the routing change it contains will
|
||
|
|
be accepted. If the target host makes this change to its
|
||
|
|
global routing tables, rather than just to the per-
|
||
|
|
connection cached route, the intruder may proceed with
|
||
|
|
spoofing host T.
|
||
|
|
|
||
|
|
Some hosts do not perform enough validity checks on ICMP
|
||
|
|
Redirect messages; in such cases, the impact of this attack
|
||
|
|
becomes similar to RIP-based attacks.
|
||
|
|
|
||
|
|
ICMP may also be used for targeted denial of service
|
||
|
|
attacks. Several of its messages, such as Destination
|
||
|
|
Unreachable and Time to Live Exceeded, may be used to reset
|
||
|
|
existing connections. If the intruder knows the local and
|
||
|
|
remote port numbers of a TCP connection, an ICMP packet
|
||
|
|
aimed at that connection may be forged5. Such information
|
||
|
|
is sometimes available through the netstat service.
|
||
|
|
|
||
|
|
A more global denial of service attack can be launched by
|
||
|
|
sending a fraudulent Subnet Mask Reply message. Some hosts
|
||
|
|
will accept any such message, whether they have sent a query
|
||
|
|
or not; a false one could effectively block all
|
||
|
|
communications with the target host.
|
||
|
|
__________
|
||
|
|
|
||
|
|
5. In fact, such programs are available today; they are
|
||
|
|
used as administrative tools to reset hung TCP
|
||
|
|
connections.
|
||
|
|
|
||
|
|
Defenses
|
||
|
|
Most ICMP attacks are easy to defend against with just a
|
||
|
|
modicum of paranoia. If a host is careful about checking
|
||
|
|
that a message really does refer to a particular connection,
|
||
|
|
most such attacks will not succeed. In the case of TCP,
|
||
|
|
this includes verifying that the ICMP packet contains a
|
||
|
|
plausible sequence number in the returned-packet portion.
|
||
|
|
These checks are less applicable to UDP, though.
|
||
|
|
|
||
|
|
A defense against Redirect attacks merits additional
|
||
|
|
attention, since such attacks can be more serious.
|
||
|
|
Probably, the best option is to restrict route changes to
|
||
|
|
the specified connection; the global routing table should
|
||
|
|
not be modified in response to ICMP Redirect messages6.
|
||
|
|
|
||
|
|
Finally, it is worth considering whether ICMP Redirects are
|
||
|
|
even useful in today's environment. They are only usable on
|
||
|
|
local networks with more than one gateway to the outside
|
||
|
|
world. But it is comparatively easy to maintain complete
|
||
|
|
and correct local routing information. Redirect messages
|
||
|
|
would be most useful from the core gateways to local
|
||
|
|
exterior gateways, as that would allow such local gateways
|
||
|
|
to have less than complete knowledge of the Internet; this
|
||
|
|
use is disallowed, however.
|
||
|
|
|
||
|
|
Subnet Mask attacks can be blocked if the Reply packet is
|
||
|
|
honored only at the appropriate time. In general, a host
|
||
|
|
wants to see such a message only at boot time, and only if
|
||
|
|
it had issued a query; a stale reply, or an unsolicited
|
||
|
|
reply, should be rejected out of hand. There is little
|
||
|
|
defense against a forged reply to a genuine Subnet Mask
|
||
|
|
query, as a host that has sent such a query typically has
|
||
|
|
few resources with which to validate the response. If the
|
||
|
|
genuine response is not blocked by the intruder, though, the
|
||
|
|
target will receive multiple replies; a check to ensure that
|
||
|
|
all replies agree would guard against administrative errors
|
||
|
|
as well.
|
||
|
|
__________
|
||
|
|
|
||
|
|
6. This has other benefits as well, especially in
|
||
|
|
environments where ICMP-initiated route changes are not
|
||
|
|
timed out. The author has seen situations where RIP
|
||
|
|
instability following a gateway crash has led to
|
||
|
|
erroneous ICMP Redirect messages. These had the effect
|
||
|
|
of permanently corrupting the routing tables on other
|
||
|
|
hosts.
|
||
|
|
|
||
|
|
4. THE "AUTHENTICATION" SERVER
|
||
|
|
|
||
|
|
As an alternative to address-based authentication, some
|
||
|
|
implementations use the Authentication Server[18]. A server
|
||
|
|
that wishes to know the identity of its client may contact
|
||
|
|
the client host's Authentication Server7, and ask it for
|
||
|
|
information about the user owning a particular connection.
|
||
|
|
This method is inherently more secure than simple address-
|
||
|
|
based authentication, as it uses a second TCP connection not
|
||
|
|
under control of the attacker. It thus can defeat sequence
|
||
|
|
number attacks and source routing attacks. There are
|
||
|
|
certain risks, however.
|
||
|
|
|
||
|
|
The first, and most obvious, is that not all hosts are
|
||
|
|
competent to run authentication servers. If the client host
|
||
|
|
is not secure, it does not matter who the user is claimed to
|
||
|
|
be; the answer cannot be trusted. Second, the
|
||
|
|
authentication message itself can be compromised by routing
|
||
|
|
table attacks. If RIP has been used to alter the target's
|
||
|
|
idea of how to reach some host, the authentication query
|
||
|
|
will rely on the same altered routing data. Finally, if the
|
||
|
|
target host is down, a variant on the TCP sequence number
|
||
|
|
attack may be used; after the server sends out a TCP open
|
||
|
|
request to the presumed authentication server, the attacker
|
||
|
|
can complete the open sequence and send a false reply. If
|
||
|
|
the target runs a netstat server, this is even easier; as
|
||
|
|
noted, netstat will often supply the necessary sequence
|
||
|
|
numbers with no need to guess.
|
||
|
|
|
||
|
|
A less-obvious risk is that a fake authentication server can
|
||
|
|
always reply "no". This constitutes a denial of service
|
||
|
|
attack.
|
||
|
|
|
||
|
|
Defenses
|
||
|
|
A server that wishes to rely on another host's idea of a
|
||
|
|
user should use a more secure means of validation, such as
|
||
|
|
the Needham-Schroeder algorithm[20][21][22]. TCP by itself
|
||
|
|
is inadequate.
|
||
|
|
__________
|
||
|
|
|
||
|
|
7. The Internet Activities Board does not currently
|
||
|
|
recommend the Authentication Server for
|
||
|
|
implementation[19]. However, the decision was not made
|
||
|
|
because of security problems[5].
|
||
|
|
|
||
|
|
5. HERE BE DRAGONS
|
||
|
|
|
||
|
|
Some protocols, while not inherently flawed, are
|
||
|
|
nevertheless susceptible to abuse. A wise implementor would
|
||
|
|
do well to take these problems into account when providing
|
||
|
|
the service.
|
||
|
|
|
||
|
|
5.1 The "Finger" Service
|
||
|
|
|
||
|
|
Many systems implement a finger service[23]. This server
|
||
|
|
will display useful information about users, such as their
|
||
|
|
full names, phone numbers, office numbers, etc.
|
||
|
|
Unfortunately, such data provides useful grist for the mill
|
||
|
|
of a password cracker.[24] By running such a service, a
|
||
|
|
system administrator is giving away this data.
|
||
|
|
|
||
|
|
5.2 Electronic Mail
|
||
|
|
|
||
|
|
Electronic mail is probably the most valuable service on the
|
||
|
|
Internet. Nevertheless, it is quite vulnerable to misuse.
|
||
|
|
As normally implemented[25][26], the mail server provides no
|
||
|
|
authentication mechanisms. This leaves the door wide open
|
||
|
|
to faked messages. RFC 822 does support an Encrypted header
|
||
|
|
line, but this is not widely used. (However, see RFC
|
||
|
|
1040[27] for a discussion of a proposed new encryption
|
||
|
|
standard for electronic mail.)
|
||
|
|
|
||
|
|
5.2.1 The Post Office Protocol
|
||
|
|
|
||
|
|
The The Post Office Protocol (POP)[28] allows a remote user
|
||
|
|
to retrieve mail stored on a central server machine.
|
||
|
|
Authentication is by means of a single command containing
|
||
|
|
both the user name and the password. However, combining the
|
||
|
|
two on a single command mandates the use of conventional
|
||
|
|
passwords. And such passwords are becoming less popular;
|
||
|
|
they are too vulnerable to wire-tappers, intentional or
|
||
|
|
accidental disclosure, etc.
|
||
|
|
|
||
|
|
As an alternative, many sites are adopting "one-time
|
||
|
|
passwords"8. With one-time passwords, the host and some
|
||
|
|
device available to the user share a cryptographic key. The
|
||
|
|
host issues a random challenge; both sides encrypt this
|
||
|
|
number, and the user transmits it back to the host. Since
|
||
|
|
__________
|
||
|
|
|
||
|
|
8. One-time passwords were apparently first used for
|
||
|
|
military IFF (Identification Friend or Foe) systems[29].
|
||
|
|
|
||
|
|
the challenge is random, the reply is unique to that
|
||
|
|
session, thereby defeating eavesdroppers. And since the
|
||
|
|
user does not know the key -- it is irretrievably stored in
|
||
|
|
the device -- the password cannot be given away without
|
||
|
|
depriving the user of the ability to log in.
|
||
|
|
|
||
|
|
The newest version of POP[30] has split the user name and
|
||
|
|
password into two commands, which is useful. However, it
|
||
|
|
also defines an optional mechanism for preauthenticated
|
||
|
|
connections, typically using Berkeley's mechanisms.
|
||
|
|
Commendably, the security risks of this variant are
|
||
|
|
mentioned explicitly in the document.
|
||
|
|
|
||
|
|
5.2.2 PCMAIL
|
||
|
|
|
||
|
|
The PCMAIL protocol[31] uses authentication mechanisms
|
||
|
|
similar to those in POP2. In one major respect, PCMAIL is
|
||
|
|
more dangerous: it supports a password-change command.
|
||
|
|
This request requires that both the old and new passwords be
|
||
|
|
transmitted unencrypted.
|
||
|
|
|
||
|
|
5.3 The Domain Name System
|
||
|
|
|
||
|
|
The Domain Name System (DNS)[32][33] provides for a
|
||
|
|
distributed database mapping host names to IP addresses. An
|
||
|
|
intruder who interferes with the proper operation of the DNS
|
||
|
|
can mount a variety of attacks, including denial of service
|
||
|
|
and password collection. There are a number of
|
||
|
|
vulnerabilities.
|
||
|
|
|
||
|
|
In some resolver implementations, it is possible to mount a
|
||
|
|
sequence number attack against a particular user. When the
|
||
|
|
target user attempts to connect to a remote machine, an
|
||
|
|
attacker can generate a domain server response to the
|
||
|
|
target's query. This requires knowing both the UDP port
|
||
|
|
used by the client's resolver and the DNS sequence number
|
||
|
|
used for the query. The latter is often quite easy to
|
||
|
|
obtain, though, since some resolvers always start their
|
||
|
|
sequence numbers with 0. And the former may be obtainable
|
||
|
|
via netstat or some analogous host command.
|
||
|
|
|
||
|
|
A combined attack on the domain system and the routing
|
||
|
|
mechanisms can be catastrophic. The intruder can intercept
|
||
|
|
virtually all requests to translate names to IP addresses,
|
||
|
|
and supply the address of a subverted machine instead; this
|
||
|
|
would allow the intruder to spy on all traffic, and build a
|
||
|
|
nice collection of passwords if desired.
|
||
|
|
|
||
|
|
For this reason, domain servers are high-value targets; a
|
||
|
|
sufficiently determined attacker might find it useful to
|
||
|
|
take over a server by other means, including subverting the
|
||
|
|
machine one is on, or even physically interfering with its
|
||
|
|
link to the Internet. There is no network defense against
|
||
|
|
the former, which suggests that domain servers should only
|
||
|
|
run on highly secure machines; the latter issue may be
|
||
|
|
addressed by using authentication techniques on domain
|
||
|
|
server responses.
|
||
|
|
|
||
|
|
The DNS, even when functioning correctly, can be used for
|
||
|
|
some types of spying. The normal mode of operation of the
|
||
|
|
DNS is to make specific queries, and receive specific
|
||
|
|
responses. However, a zone transfer (AXFR) request exists
|
||
|
|
that can be used to download an entire section of the
|
||
|
|
database; by applying this recursively, a complete map of
|
||
|
|
the name space can be produced. Such a database represents
|
||
|
|
a potential security risk; if, for example, an intruder
|
||
|
|
knows that a particular brand of host or operating system
|
||
|
|
has a particular vulnerability, that database can be
|
||
|
|
consulted to find all such targets. Other uses for such a
|
||
|
|
database include espionage; the number and type of machines
|
||
|
|
in a particular organization, for example, can give away
|
||
|
|
valuable data about the size of the organization, and hence
|
||
|
|
the resources committed to a particular project.
|
||
|
|
|
||
|
|
Fortunately, the domain system includes an error code for
|
||
|
|
"refused"; an administrative prohibition against such zone
|
||
|
|
transfers is explicitly recognized as a legitimate reason
|
||
|
|
for refusal. This code should be employed for zone transfer
|
||
|
|
requests from any host not known to be a legitimate
|
||
|
|
secondary server. Unfortunately, there is no authentication
|
||
|
|
mechanism provided in the AXFR request; source address
|
||
|
|
authentication is the best that can be done.
|
||
|
|
|
||
|
|
Recently, a compatible authentication extension to the DNS
|
||
|
|
has been devised at M.I.T. The Hesiod name server[34] uses
|
||
|
|
Kerberos[35] tickets to authenticate queries and responses.
|
||
|
|
The additional information section of the query carries an
|
||
|
|
encrypted ticket, which includes a session key; this key,
|
||
|
|
known only to Hesiod and the client, is used to compute a
|
||
|
|
cryptographic checksum of the both the query and the
|
||
|
|
response. These checksums are also sent in the additional
|
||
|
|
information field.
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
NIA074 / File 03
|
||
|
|
|
||
|
|
Security Problems in the TCP/IP Protocol Suite
|
||
|
|
|
||
|
|
Part II of II
|
||
|
|
|
||
|
|
S.M. Bellovin
|
||
|
|
|
||
|
|
AT&T Bell Laboratories
|
||
|
|
|
||
|
|
|
||
|
|
5.4 The File Transfer Protocol
|
||
|
|
|
||
|
|
The File Transfer Protocol (FTP)[36] itself is not flawed.
|
||
|
|
However, a few aspects of the implementation merit some
|
||
|
|
care.
|
||
|
|
|
||
|
|
5.4.1 FTP Authentication
|
||
|
|
|
||
|
|
FTP relies on a login and password combination for
|
||
|
|
authentication. As noted, simple passwords are increasingly
|
||
|
|
seen as inadequate; more and more sites are adopting one-
|
||
|
|
time passwords. Nothing in the FTP specification precludes
|
||
|
|
such an authentication method. It is vital, however, that
|
||
|
|
the "331" response to a USER subcommand be displayed to
|
||
|
|
the user; this message would presumably contain the
|
||
|
|
challenge. An FTP implementation that concealed this
|
||
|
|
response could not be used in this mode; if such
|
||
|
|
implementations are (or become) common, it may be necessary
|
||
|
|
to use a new reply code to indicate that the user must see
|
||
|
|
the content of the challenge.
|
||
|
|
|
||
|
|
5.4.2 Anonymous FTP
|
||
|
|
|
||
|
|
A second problem area is "anonymous FTP". While not
|
||
|
|
required by the FTP specification, anonymous FTP is a
|
||
|
|
treasured part of the oral tradition of the Internet.
|
||
|
|
Nevertheless, it should be implemented with care.
|
||
|
|
|
||
|
|
One part of the problem is the implementation technique
|
||
|
|
chosen. Some implementations of FTP require creation of a
|
||
|
|
partial replica of the directory tree; care must be taken to
|
||
|
|
ensure that these files are not subject to compromise. Nor
|
||
|
|
should they contain any sensitive information, such as
|
||
|
|
encrypted passwords.
|
||
|
|
|
||
|
|
The second problem is that anonymous FTP is truly anonymous;
|
||
|
|
there is no record of who has requested what information.
|
||
|
|
Mail-based servers will provide that data; they also provide
|
||
|
|
useful techniques for load-limiting9, background transfers,
|
||
|
|
etc.
|
||
|
|
|
||
|
|
5.5 Simple Network Management Protocol
|
||
|
|
|
||
|
|
The Simple Network Management Protocol (SNMP)[37] has
|
||
|
|
recently been defined to aid in network management.
|
||
|
|
Clearly, access to such a resource must be heavily
|
||
|
|
protected. The RFC states this, but also allows for a null
|
||
|
|
__________
|
||
|
|
|
||
|
|
9. Recently, a host was temporarily rendered unusable by
|
||
|
|
massive numbers of FTP requests for a popular technical
|
||
|
|
report. If this were deliberate, it would be considered
|
||
|
|
a successful denial of service attack.
|
||
|
|
|
||
|
|
authentication service; this is a bad idea. Even a "read-
|
||
|
|
only" mode is dangerous; it may expose the target host to
|
||
|
|
netstat-type attacks if the particular Management
|
||
|
|
Information Base (MIB)[38] used includes sequence numbers.
|
||
|
|
(The current standardized version does not; however, the MIB
|
||
|
|
is explicitly declared to be extensible.)
|
||
|
|
|
||
|
|
5.6 Remote Booting
|
||
|
|
|
||
|
|
Two sets of protocols are used today to boot diskless
|
||
|
|
workstations and gateways, Reverse ARP (RARP)[39] with the
|
||
|
|
Trivial File Transfer Protocol (TFTP)[40] and BOOTP[41] with
|
||
|
|
TFTP. A system being booted is a tempting target; if one
|
||
|
|
can subvert the boot process, a new kernel with altered
|
||
|
|
protection mechanisms can be substituted. RARP-based
|
||
|
|
booting is riskier because it relies on Ethernet-like
|
||
|
|
networks, with all the vulnerabilities adhering thereto.
|
||
|
|
One can achieve a modest improvement in security by ensuring
|
||
|
|
that the booting machine uses a random number for its UDP
|
||
|
|
source port; otherwise, an attacker can impersonate the
|
||
|
|
server and send false DATA packets.
|
||
|
|
|
||
|
|
BOOTP adds an additional layer of security by including a
|
||
|
|
4-byte random transaction id. This prevents an attacker
|
||
|
|
from generating false replies to a workstation known to be
|
||
|
|
rebooting. It is vital that these numbers indeed be random;
|
||
|
|
this can be difficult in a system that is freshly powered
|
||
|
|
up, and hence with little or no unpredictable state. Care
|
||
|
|
should be taken when booting through gateways; the more
|
||
|
|
networks traversed, the greater the opportunity for
|
||
|
|
impersonation.
|
||
|
|
|
||
|
|
The greatest measure of protection is that normally, the
|
||
|
|
attacker has only a single chance; a system being booted
|
||
|
|
does not stay in that state. If, however, communications
|
||
|
|
between the client and the standard server may be
|
||
|
|
interrupted, larger-scale attacks may be mounted.
|
||
|
|
|
||
|
|
6. TRIVIAL ATTACKS
|
||
|
|
|
||
|
|
A few attacks are almost too trivial to mention;
|
||
|
|
nevertheless, completeness demands that they at least be
|
||
|
|
noted.
|
||
|
|
|
||
|
|
6.1 Vulnerability of the Local Network
|
||
|
|
|
||
|
|
Some local-area networks, notably the Ethernet networks, are
|
||
|
|
extremely vulnerable to eavesdropping and host-spoofing. If
|
||
|
|
such networks are used, physical access must be strictly
|
||
|
|
controlled. It is also unwise to trust any hosts on such
|
||
|
|
networks if any machine on the network is accessible to
|
||
|
|
untrusted personnel, unless authentication servers are used.
|
||
|
|
|
||
|
|
If the local network uses the Address Resolution Protocol
|
||
|
|
(ARP)[42] more subtle forms of host-spoofing are possible.
|
||
|
|
In particular, it becomes trivial to intercept, modify, and
|
||
|
|
forward packets, rather than just taking over the host's
|
||
|
|
role or simply spying on all traffic.
|
||
|
|
|
||
|
|
It is possible to launch denial of service attacks by
|
||
|
|
triggering broadcast storms. There are a variety of ways to
|
||
|
|
do this; it is quite easy if most or all of the hosts on the
|
||
|
|
network are acting as gateways. The attacker can broadcast
|
||
|
|
a packet destined for a non-existent IP address. Each host,
|
||
|
|
upon receiving it, will attempt to forward it to the proper
|
||
|
|
destination. This alone will represent a significant amount
|
||
|
|
of traffic, as each host will generate a broadcast ARP query
|
||
|
|
for the destination. The attacker can follow up by
|
||
|
|
broadcasting an ARP reply claiming that the broadcast
|
||
|
|
Ethernet address is the proper way to reach that
|
||
|
|
destination. Each suspectible host will then not only
|
||
|
|
resend the bogus packet, it will also receive many more
|
||
|
|
copies of it from the other suspectible hosts on the
|
||
|
|
network.
|
||
|
|
|
||
|
|
6.2 The Trivial File Transfer Protocol
|
||
|
|
|
||
|
|
TFTP[40] permits file transfers without any attempt at
|
||
|
|
authentication. Thus, any publicly-readable file in the
|
||
|
|
entire universe is accessible. It is the responsibility of
|
||
|
|
the implementor and/or the system administrator to make that
|
||
|
|
universe as small as possible.
|
||
|
|
|
||
|
|
6.3 Reserved Ports
|
||
|
|
|
||
|
|
Berkeley-derived TCPs and UDPs have the notion of a
|
||
|
|
"privileged port". That is, port numbers lower than 1024
|
||
|
|
may only be allocated to privileged processes. This
|
||
|
|
restriction is used as part of the authentication mechanism.
|
||
|
|
However, neither the TCP nor the UDP specifications contain
|
||
|
|
any such concept, nor is such a concept even meaningful on a
|
||
|
|
single-user computer. Administrators should never rely on
|
||
|
|
the Berkeley authentication schemes when talking to such
|
||
|
|
machines.
|
||
|
|
|
||
|
|
7. COMPREHENSIVE DEFENSES
|
||
|
|
|
||
|
|
Thus far, we have described defenses against a variety of
|
||
|
|
individual attacks. Several techniques are broad-spectrum
|
||
|
|
defenses; they may be employed to guard against not only
|
||
|
|
these attacks, but many others as well.
|
||
|
|
|
||
|
|
7.1 Authentication
|
||
|
|
|
||
|
|
Many of the intrusions described above succeed only because
|
||
|
|
the target host uses the IP source address for
|
||
|
|
authentication, and assumes it to be genuine.
|
||
|
|
Unfortunately, there are sufficiently many ways to spoof
|
||
|
|
this address that such techniques are all but worthless.
|
||
|
|
Put another way, source address authentication is the
|
||
|
|
equivalent of a file cabinet secured with an S100 lock; it
|
||
|
|
may reduce the temptation level for more-or-less honest
|
||
|
|
passers-by, but will do little or nothing to deter anyone
|
||
|
|
even slightly serious about gaining entry.
|
||
|
|
|
||
|
|
Some form of cryptographic authentication is needed. There
|
||
|
|
are several possible approaches. Perhaps the best-known is
|
||
|
|
the Needham-Schroeder algorithm[20][21][22]. It relies on
|
||
|
|
each host sharing a key with an authentication server; a
|
||
|
|
host wishing to establish a connection obtains a session key
|
||
|
|
from the authentication server and passes a sealed version
|
||
|
|
along to the destination. At the conclusion of the dialog,
|
||
|
|
each side is convinced of the identity of the other.
|
||
|
|
Versions of the algorithm exist for both private-key and
|
||
|
|
public-key[43] cryptosystems.
|
||
|
|
|
||
|
|
How do these schemes fit together with TCP/IP? One answer
|
||
|
|
is obvious: with them, preauthenticated connections can be
|
||
|
|
implemented safely; without them, they are quite risky. A
|
||
|
|
second answer is that the DNS provides an ideal base for
|
||
|
|
authentication systems, as it already incorporates the
|
||
|
|
necessary name structure, redundancy, etc. To be sure, key
|
||
|
|
distribution responses must be authenticated and/or
|
||
|
|
encrypted; as noted, the former seems to be necessary in any
|
||
|
|
event.
|
||
|
|
|
||
|
|
In some environments, care must be taken to use the session
|
||
|
|
key to encrypt the entire conversation; if this is not done,
|
||
|
|
an attacker can take over a connection via the mechanisms
|
||
|
|
described earlier.
|
||
|
|
|
||
|
|
7.2 Encryption
|
||
|
|
|
||
|
|
Suitable encryption can defend against most of the attacks
|
||
|
|
outlined above. But encryption devices are expensive, often
|
||
|
|
slow, hard to administer, and uncommon in the civilian
|
||
|
|
sector. There are different ways to apply encryption; each
|
||
|
|
has its strengths and weaknesses. A comprehensive treatment
|
||
|
|
of encryption is beyond the scope of this paper; interested
|
||
|
|
readers should consult Voydock and Kent[44] or Davies and
|
||
|
|
Price[45].
|
||
|
|
|
||
|
|
Link-level encryption -- encrypting each packet as it leaves
|
||
|
|
the host computer -- is an excellent method of guarding
|
||
|
|
against disclosure of information. It also works well
|
||
|
|
against physical intrusions; an attacker who tapped in to an
|
||
|
|
Ethernet cable, for example, would not be able to inject
|
||
|
|
spurious packets. Similarly, an intruder who cut the line
|
||
|
|
to a name server would not be able to impersonate it. The
|
||
|
|
number of entities that share a given key determines the
|
||
|
|
security of the network; typically, a key distribution
|
||
|
|
center will allocate keys to each pair of communicating
|
||
|
|
hosts.
|
||
|
|
|
||
|
|
Link-level encryption has some weaknesses, however.
|
||
|
|
Broadcast packets are difficult to secure; in the absence of
|
||
|
|
fast public-key cryptosystems, the ability to decode an
|
||
|
|
encrypted broadcast implies the ability to send such a
|
||
|
|
broadcast, impersonating any host on the network.
|
||
|
|
Furthermore, link-level encryption, by definition, is not
|
||
|
|
end-to-end; security of a conversation across gateways
|
||
|
|
implies trust in the gateways and assurance that the full
|
||
|
|
concatenated internet is similarly protected. (This latter
|
||
|
|
constraint may be enforced administratively, as is done in
|
||
|
|
the military sector.) If such constraints are not met,
|
||
|
|
tactics such as source-routing attacks or RIP-spoofing may
|
||
|
|
be employed. Paranoid gateways can be deployed at the
|
||
|
|
entrance to security domains; these might, for example,
|
||
|
|
block incoming RIP packets or source-routed packets.
|
||
|
|
|
||
|
|
Many portions of the DARPA Internet employ forms of link
|
||
|
|
encryption. All Defense Data Network (DDN) IMP-to-IMP
|
||
|
|
trunks use DES encryption, even for non-classified traffic;
|
||
|
|
classified lines use more secure cryptosystems[46]. These,
|
||
|
|
however, are point-to-point lines, which are comparatively
|
||
|
|
easy to protect.
|
||
|
|
|
||
|
|
A multi-point link encryption device for TCP/IP is the
|
||
|
|
Blacker Front End (BFE)[47]. The BFE looks to the host like
|
||
|
|
an X.25 DDN interface, and sits between the host and the
|
||
|
|
actual DDN line. When it receives a call request packet
|
||
|
|
specifying a new destination, it contacts an Access Control
|
||
|
|
Center (ACC) for permission, and a Key Distribution Center
|
||
|
|
(KDC) for cryptographic keys. If the local host is denied
|
||
|
|
permission to talk to the remote host, an appropriate
|
||
|
|
diagnostic code is returned. A special "Emergency Mode"
|
||
|
|
is available for communications to a restricted set of
|
||
|
|
destinations at times when the link to the KDC or ACC is not
|
||
|
|
working.
|
||
|
|
|
||
|
|
The permission-checking can, to some extent, protect against
|
||
|
|
the DNS attacks described earlier. Even if a host has been
|
||
|
|
mislead about the proper IP address for a particular
|
||
|
|
destination, the BFE will ensure that a totally unauthorized
|
||
|
|
host does not receive sensitive data. That is, assume that
|
||
|
|
a host wishes to send Top Secret data to some host foo. A
|
||
|
|
DNS attack might mislead the host into connecting to
|
||
|
|
penetrated host 4.0.0.4, rather than 1.0.0.1. If 4.0.0.4 is
|
||
|
|
not cleared for Top Secret material, or is not allowed
|
||
|
|
communications with the local host, the connection attempt
|
||
|
|
will fail. To be sure, a denial of service attack has taken
|
||
|
|
place; this, in the military world, is far less serious than
|
||
|
|
information loss.
|
||
|
|
|
||
|
|
The BFE also translates the original ("Red") IP address to
|
||
|
|
an encrypted ("Black") address, using a translation table
|
||
|
|
supplied by the ACC. This is done to foil traffic analysis
|
||
|
|
techniques, the bane of all multi-point link encryption
|
||
|
|
schemes.
|
||
|
|
|
||
|
|
End-to-end encryption, above the TCP level, may be used to
|
||
|
|
secure any conversation, regardless of the number of hops or
|
||
|
|
the quality of the links. This is probably appropriate for
|
||
|
|
centralized network management applications, or other
|
||
|
|
point-to-point transfers. Key distribution and management
|
||
|
|
is a greater problem, since there are more pairs of
|
||
|
|
correspondents involved. Furthermore, since encryption and
|
||
|
|
decryption are done before initiation or after termination
|
||
|
|
of the TCP processing, host-level software must arrange for
|
||
|
|
the translation; this implies extra overhead for each such
|
||
|
|
conversation10.
|
||
|
|
|
||
|
|
End-to-end encryption is vulnerable to denial of service
|
||
|
|
attacks, since fraudulently-injected packets can pass the
|
||
|
|
__________
|
||
|
|
|
||
|
|
10. We are assuming that TCP is handled by the host, and not
|
||
|
|
by a front-end processor.
|
||
|
|
|
||
|
|
TCP checksum tests and make it to the application. A
|
||
|
|
combination of end-to-end encryption and link-level
|
||
|
|
encryption can be employed to guard against this. An
|
||
|
|
intriguing alternative would be to encrypt the data portion
|
||
|
|
of the TCP segment, but not the header; the TCP checksum
|
||
|
|
would be calculated on the cleartext, and hence would detect
|
||
|
|
spurious packets. Unfortunately, such a change would be
|
||
|
|
incompatible with other implementations of TCP, and could
|
||
|
|
not be done transparently at application level.
|
||
|
|
|
||
|
|
Regardless of the method used, a major benefit of encrypted
|
||
|
|
communications is the implied authentication they provide.
|
||
|
|
If one assumes that the key distribution center is secure,
|
||
|
|
and the key distribution protocols are adequate, the very
|
||
|
|
ability to communicate carries with it a strong assurance
|
||
|
|
that one can trust the source host's IP address for
|
||
|
|
identification.
|
||
|
|
|
||
|
|
This implied authentication can be especially important in
|
||
|
|
high-threat situations. A routing attack can be used to
|
||
|
|
"take over" an existing connection; the intruder can
|
||
|
|
effectively cut the connection at the subverted machine,
|
||
|
|
send dangerous commands to the far end, and all the while
|
||
|
|
translate sequence numbers on packets passed through so as
|
||
|
|
to disguise the intrusion.
|
||
|
|
|
||
|
|
It should be noted, of course, that any of these encryption
|
||
|
|
schemes provide privacy. Often that is the primary goal of
|
||
|
|
such systems.
|
||
|
|
|
||
|
|
7.3 Trusted Systems
|
||
|
|
|
||
|
|
Given that TCP/IP is a Defense Department protocol suite, it
|
||
|
|
is worth asking to what extent the Orange Book[48] and Red
|
||
|
|
Book[49] criteria would protect a host from the attacks
|
||
|
|
described above. That is, suppose that a target host (and
|
||
|
|
the gateways!) were rated B1 or higher. Could these attacks
|
||
|
|
succeed? The answer is a complex one, and depends on the
|
||
|
|
assumptions we are willing to make. In general, hosts and
|
||
|
|
routers rated at B2 or higher are immune to the attacks
|
||
|
|
described here, while C2-level systems are susceptible.
|
||
|
|
B1-level systems are vulnerable to some of these attacks,
|
||
|
|
but not all.
|
||
|
|
|
||
|
|
In order to understand how TCP/IP is used in secure
|
||
|
|
environments, a brief tutorial on the military security
|
||
|
|
model is necessary. All objects in the computer system,
|
||
|
|
such as files or network channels, and all data exported
|
||
|
|
from them, must have a label indicating the sensitivity of
|
||
|
|
the information in them. This label includes hierarchical
|
||
|
|
components (i.e., Confidential, Secret, and Top Secret) and
|
||
|
|
non-hierarchical components. Subjects -- i.e., processes
|
||
|
|
within the computer system -- are similarly labeled. A
|
||
|
|
subject may read an object if its label has a higher or
|
||
|
|
equal hierarchical level and if all of the object's non-
|
||
|
|
hierarchical components are included in the subject's label.
|
||
|
|
In other words, the process must have sufficient clearance
|
||
|
|
for the information in a file. Similarly, a subject may
|
||
|
|
write to an object if the object has a higher or equal level
|
||
|
|
and the object's non-hierarchical components include all of
|
||
|
|
those in the subject's level. That is, the sensitivity
|
||
|
|
level of the file must be at least as high as that of the
|
||
|
|
process. If it were not, a program with a high clearance
|
||
|
|
could write classified data to a file that is readable by a
|
||
|
|
process with a low security clearance.
|
||
|
|
|
||
|
|
A corollary to this is that for read/write access to any
|
||
|
|
file, its security label must exactly match that of the
|
||
|
|
process. The same applies to any form of bidirectional
|
||
|
|
interprocess communication (i.e., a TCP virtual circuit):
|
||
|
|
both ends must have identical labels.
|
||
|
|
|
||
|
|
We can now see how to apply this model to the TCP/IP
|
||
|
|
protocol suite. When a process creates a TCP connection,
|
||
|
|
that connection is given the process's label. This label is
|
||
|
|
encoded in the IP security option. The remote TCP must
|
||
|
|
ensure that the label on received packets matches that of
|
||
|
|
the receiving process. Servers awaiting connections may be
|
||
|
|
eligible to run at multiple levels; when the connection is
|
||
|
|
instantiated, however, the process must be forced to the
|
||
|
|
level of the connection request packet.
|
||
|
|
|
||
|
|
IP also makes use of the security option[50]. A packet may
|
||
|
|
not be sent over a link with a lower clearance level. If a
|
||
|
|
link is rated for Secret traffic, it may carry Unclassified
|
||
|
|
or Confidential traffic, but it may not carry Top Secret
|
||
|
|
data. Thus, the security option constrains routing
|
||
|
|
decisions. The security level of a link depends on its
|
||
|
|
inherent characteristics, the strength of any encryption
|
||
|
|
algorithms used, the security levels of the hosts on that
|
||
|
|
network, and even the location of the facility. For
|
||
|
|
example, an Ethernet cable located in a submarine is much
|
||
|
|
more secure than if the same cable were running through a
|
||
|
|
dormitory room in a university.
|
||
|
|
|
||
|
|
Several points follow from these constraints. First, TCP-
|
||
|
|
level attacks can only achieve penetration at the level of
|
||
|
|
the attacker. That is, an attacker at the Unclassified
|
||
|
|
level could only achieve Unclassified privileges on the
|
||
|
|
target system, regardless of which network attack was
|
||
|
|
used11. Incoming packets with an invalid security marking
|
||
|
|
would be rejected by the gateways.
|
||
|
|
|
||
|
|
Attacks based on any form of source-address authentication
|
||
|
|
should be rejected as well. The Orange Book requires that
|
||
|
|
systems provide secure means of identification and
|
||
|
|
authentication; as we have shown, simple reliance on the IP
|
||
|
|
address is not adequate. As of the B1 level, authentication
|
||
|
|
information must be protected by cryptographic checksums
|
||
|
|
when transmitted from machine to machine12.
|
||
|
|
|
||
|
|
The authentication server is still problematic; it can be
|
||
|
|
spoofed by a sequence number attack, especially if netstat
|
||
|
|
is available. This sort of attack could easily be combined
|
||
|
|
with source routing for full interactive access. Again,
|
||
|
|
cryptographic checksums would add significant strength.
|
||
|
|
|
||
|
|
B1-level systems are not automatically immune from routing
|
||
|
|
attacks; RIP-spoofing could corrupt their routing tables
|
||
|
|
just as easily. As seen, that would allow an intruder to
|
||
|
|
capture passwords, perhaps even some used on other trusted
|
||
|
|
systems. To be sure, the initial penetration is still
|
||
|
|
restricted by the security labelling, but that may not block
|
||
|
|
future logins captured by these means.
|
||
|
|
|
||
|
|
Routing attacks can also be used for denial of service.
|
||
|
|
Specifically, if the route to a secure destination is
|
||
|
|
changed to require use of an insecure link, the two hosts
|
||
|
|
will not be able to communicate. This change would probably
|
||
|
|
be detected rather quickly, though, since the gateway that
|
||
|
|
noticed the misrouted packet would flag it as a security
|
||
|
|
problem.
|
||
|
|
|
||
|
|
At the B2 level, secure transmission of routing control
|
||
|
|
information is required. Similar requirements apply to
|
||
|
|
other network control information, such as ICMP packets.
|
||
|
|
|
||
|
|
__________
|
||
|
|
|
||
|
|
11. We are assuming, of course, that the penetrated system
|
||
|
|
does not have bugs of its own that would allow further
|
||
|
|
access.
|
||
|
|
|
||
|
|
12. More precisely, user identification information must be
|
||
|
|
protected to an equal extent with data sensitivity
|
||
|
|
labels. Under certain circumstances, described in the
|
||
|
|
Red Book, cryptographic checks may be omitted. In
|
||
|
|
general, though, they are required.
|
||
|
|
|
||
|
|
Several attacks we have described rely on data derived from
|
||
|
|
"information servers", such as netstat and finger. While
|
||
|
|
these, if carefully done, may not represent a direct
|
||
|
|
penetration threat in the civilian sense, they are often
|
||
|
|
seen to represent a covert channel that may be used to leak
|
||
|
|
information. Thus, many B-division systems do not implement
|
||
|
|
such servers.
|
||
|
|
|
||
|
|
In a practical sense, some of the technical features we have
|
||
|
|
described may not apply in the military world.
|
||
|
|
Administrative rules[51] tend to prohibit risky sorts of
|
||
|
|
interconnections; uncleared personnel are not likely to have
|
||
|
|
even indirect access to systems containing Top Secret data.
|
||
|
|
Such rules are, most likely, an accurate commentary on
|
||
|
|
anyone's ability to validate any computer system of non-
|
||
|
|
trivial size.
|
||
|
|
|
||
|
|
8. CONCLUSIONS
|
||
|
|
|
||
|
|
Several points are immediately obvious from this analysis.
|
||
|
|
The first, surely, is that in general, relying on the IP
|
||
|
|
source address for authentication is extremely dangerous13.
|
||
|
|
Fortunately, the Internet community is starting to accept
|
||
|
|
this on more than an intellectual level. The Berkeley
|
||
|
|
manuals[3] have always stated that the authentication
|
||
|
|
protocol was very weak, but it is only recently that serious
|
||
|
|
attempts (i.e., Kerberos[35] and SunOS 4.0's DES
|
||
|
|
authentication mode[52]) have been made to correct the
|
||
|
|
problem. Kerberos and SunOS 4.0 have their weaknesses, but
|
||
|
|
both are far better than their predecessor. More recently,
|
||
|
|
an extension to the Network Time Protocol (NTP)[53] has been
|
||
|
|
proposed that includes a cryptographic checksum[54].
|
||
|
|
|
||
|
|
A second broad class of problems is sequence number attacks.
|
||
|
|
If a protocol depends on sequence numbers -- and most do --
|
||
|
|
it is vital that they be chosen unpredictably. It is worth
|
||
|
|
considerable effort to ensure that these numbers are not
|
||
|
|
knowable even to other users on the same system.
|
||
|
|
__________
|
||
|
|
|
||
|
|
13. There are some exceptions to this rule. If the entire
|
||
|
|
network, and all of its components (hosts, gateways,
|
||
|
|
cables, etc.) are physically protected, and if all of
|
||
|
|
the operating systems are sufficiently secure, there
|
||
|
|
would seem to be little risk.
|
||
|
|
|
||
|
|
We may generalize this by by stating that hosts should not
|
||
|
|
give away knowledge gratuitously. A finger server, for
|
||
|
|
example, would be much safer if it only supplied information
|
||
|
|
about a known user, rather than supplying information about
|
||
|
|
everyone logged on. Even then, some censorship might be
|
||
|
|
appropriate; a refusal to supply the last login date and
|
||
|
|
other sensitive information would be appropriate if the
|
||
|
|
account was not used recently. (Never-used accounts often
|
||
|
|
have simple default passwords. Infrequently-used accounts
|
||
|
|
are often set up less carefully by the owner.) We have also
|
||
|
|
seen how netstat may be abused; indeed, the combination of
|
||
|
|
netstat with the authentication server is the single
|
||
|
|
strongest attack using the standardized Internet protocols.
|
||
|
|
|
||
|
|
Finally, network control mechanisms are dangerous, and must
|
||
|
|
be carefully guarded. Static routes are not feasible in a
|
||
|
|
large-scale network, but intelligent use of default routes
|
||
|
|
and verifiable point-to-point routing protocols (i.e., EGP)
|
||
|
|
are far less vulnerable than broadcast-based routing.
|
||
|
|
|
||
|
|
9. ACKNOWLEDGEMENTS
|
||
|
|
|
||
|
|
Dave Presotto, Bob Gilligan, Gene Tsudik, and especially
|
||
|
|
Deborah Estrin made a number of useful suggestions and
|
||
|
|
corrections to a draft of this paper.
|
||
|
|
|
||
|
|
REFERENCES
|
||
|
|
|
||
|
|
1. E.J. Feinler, O.J. Jacobsen, M.K. Stahl, C.A. Ward, eds.
|
||
|
|
DDN Protocol Handbook. DDN Network Information Center,
|
||
|
|
SRI International, 1985.
|
||
|
|
|
||
|
|
2. Comer, D. Internetworking with TCP/IP: Principles,
|
||
|
|
Protocols, and Architecture. Prentice Hall, 1988
|
||
|
|
|
||
|
|
3. Computer Systems Research Group. UNIX User's Reference
|
||
|
|
Manual (URM). 4.3 Berkeley Software Distribution
|
||
|
|
Virtual Vax-11 Version. Computer Science Division,
|
||
|
|
Department of Electrical Engineering and Computer
|
||
|
|
Science, University of California, Berkeley. 1986.
|
||
|
|
|
||
|
|
4. Spafford, E.H. The Internet Worm Program: An Analysis.
|
||
|
|
Purdue Technical Report CSD-TR-823, Department of
|
||
|
|
Computer Sciences Purdue University, West Lafayette, IN.
|
||
|
|
1988
|
||
|
|
|
||
|
|
5. Seeley, D. A Tour of the Worm. Department of Computer
|
||
|
|
Science, University of Utah. 1988.
|
||
|
|
|
||
|
|
6. Eichin, M. and Rochlis, J. With Microscope and
|
||
|
|
Tweezers: An Analysis of the Internet Virus of November
|
||
|
|
1988. Massachussetts Institute of Technology, 1988.
|
||
|
|
|
||
|
|
7. Morris, R.T. 1985. A Weakness in the 4.2BSD UNIX
|
||
|
|
TCP/IP Software. Computing Science Technical Report No.
|
||
|
|
117, AT&T Bell Laboratories, Murray Hill, New Jersey.
|
||
|
|
|
||
|
|
8. Reynolds, J.K., and J. Postel. Assigned Numbers. RFC
|
||
|
|
990, 1986
|
||
|
|
|
||
|
|
9. Mills, D.L. Internet Delay Experiments, RFC 889, 1983.
|
||
|
|
|
||
|
|
10. Blum, M. and Micali, S. "How to Generate
|
||
|
|
Cryptographically Strong Sequences of Pseudo-Random
|
||
|
|
Bits". SIAM J Computing, vol. 13, no. 4, pp. 850-864,
|
||
|
|
Nov. 1984.
|
||
|
|
|
||
|
|
11. US Federal Information Processing Standards Publication
|
||
|
|
(FIPS PUB) 46, Data Encryption Standard, 15 January
|
||
|
|
1977.
|
||
|
|
|
||
|
|
12. US Federal Information Processing Standards Publication
|
||
|
|
(FIPS PUB) 81. DES Modes of Operation, 2 December 1980.
|
||
|
|
|
||
|
|
13. Bishop, M. An Application of a Fast Data Encryption
|
||
|
|
Standard Implementation. Technical Report PCS-TR88-138,
|
||
|
|
Department of Mathematics and Computer Science,
|
||
|
|
Dartmouth College, Hanover, NH. 1988.
|
||
|
|
|
||
|
|
14. Mogul, J. "Simple and Flexible Datagram Access
|
||
|
|
Controls for UNIX-based Gateways", Proceedings, Summer
|
||
|
|
USENIX, 1989, Baltimore, Maryland (to appear).
|
||
|
|
|
||
|
|
15. Hedrick, C. Routing Information Protocol. RFC 1058,
|
||
|
|
1988.
|
||
|
|
|
||
|
|
16. Mills, D.L. Exterior Gateway Protocol Formal
|
||
|
|
Specification. RFC 904, 1984.
|
||
|
|
|
||
|
|
17. Postel, J. Internet Control Message Protocol. RFC 792,
|
||
|
|
1981.
|
||
|
|
|
||
|
|
18. St. Johns, M. Authentication Server. RFC 931, 1985.
|
||
|
|
|
||
|
|
19. Defense Advanced Research Projects Agency, Internet
|
||
|
|
Activities Board. IAB Official Protocol Standards. RFC
|
||
|
|
1083, 1988
|
||
|
|
|
||
|
|
19. Postel, J. Private communication. 1989.
|
||
|
|
|
||
|
|
20. Needham, R.M. and Schroeder, M.D. "Using Encryption
|
||
|
|
for Authentication in Large Networks of Computers".
|
||
|
|
Communications of the ACM, vol. 21, no. 12, pp. 993-999,
|
||
|
|
December 1978.
|
||
|
|
|
||
|
|
21. Denning, D.E. and Sacco, G.M. "Timestamps in Key
|
||
|
|
Distribution Protocols", Communications of the ACM,
|
||
|
|
vol. 24, no. 8, pp. 533-536, August 1981.
|
||
|
|
|
||
|
|
22. Needham, R.M. and Schroeder, M.D. "Authentication
|
||
|
|
Revisited", Operating Systems Review, vol. 21, no. 1,
|
||
|
|
p. 7, January 1987.
|
||
|
|
|
||
|
|
23. Harrenstien, K. NAME/FINGER Protocol, RFC 742, 1977.
|
||
|
|
|
||
|
|
24. Grampp, F.T. and Morris, R.H. "UNIX Operating System
|
||
|
|
Security", AT&T Bell Laboratories Technical Journal,
|
||
|
|
vol. 63, no. 8, part 2, October, 1984.
|
||
|
|
|
||
|
|
25. Crocker, D. Standard for the Format of ARPA-Internet
|
||
|
|
Text Messages. RFC 822, 1982.
|
||
|
|
|
||
|
|
26. Postel, J. Simple Mail Transfer Protocol. RFC 821,
|
||
|
|
1982.
|
||
|
|
|
||
|
|
27. Linn, J. Privacy Enhancement for Internet Electronic
|
||
|
|
Mail: Part I: Message Encipherment and Authentication
|
||
|
|
Procedures. RFC 1040, 1988.
|
||
|
|
|
||
|
|
28. Butler, M.; Postel, J.B.; Chase, D.; Goldberger, J.;
|
||
|
|
Reynolds, J.K. Post Office Protocol - Version 2. RFC
|
||
|
|
937, 1985.
|
||
|
|
|
||
|
|
29. Diffie, W. "The First Ten Years of Public Key
|
||
|
|
Cryptography". Proc. IEEE, vol. 76, no. 5, pp. 560-
|
||
|
|
577, May 1988.
|
||
|
|
|
||
|
|
30. Rose, M. Post Office Protocol - Version 3. RFC 1081,
|
||
|
|
1988
|
||
|
|
|
||
|
|
31. Lambert, M.L. PCMAIL: A Distributed Mail System for
|
||
|
|
Personal Computers. RFC 1056, 1988
|
||
|
|
|
||
|
|
32. Mockapetris, P. Domain Names - Concepts and Facilities.
|
||
|
|
RFC 1034, 1987.
|
||
|
|
|
||
|
|
33. Mockapetris, P. Domain Names - Implementations and
|
||
|
|
Specifications. RFC 1035, 1987.
|
||
|
|
|
||
|
|
34. Dyer, S.P. "Hesiod", Proceedings, Winter USENIX,
|
||
|
|
1988, Dallas, Texas.
|
||
|
|
|
||
|
|
35. Steiner, J.G, Neuman, C., Schiller, J.I. "Kerberos: An
|
||
|
|
Authentication Service for Open Network Systems",
|
||
|
|
Proceedings, Winter USENIX, 1988, Dallas, Texas.
|
||
|
|
|
||
|
|
36. Postel, J. File Transfer Protocol. RFC 959, 1985.
|
||
|
|
|
||
|
|
37. Case, J., Fedor, M., Schoffstall, J., and Davin, J. A
|
||
|
|
Simple Network Management Protocol. RFC 1067, 1988.
|
||
|
|
|
||
|
|
38. McCloghrie, K. and Rose, M. Management Information Base
|
||
|
|
for Network Management of TCP/IP-based Internets. RFC
|
||
|
|
1066. 1988.
|
||
|
|
|
||
|
|
39. Finlayson, R.; Mann, T.; Mogul, J.; Theimer, M. Reverse
|
||
|
|
Address Resolution Protocol. RFC 903, 1984.
|
||
|
|
|
||
|
|
40. Sollins, K.R. The TFTP Protocol (Revision 2). RFC 783,
|
||
|
|
1981.
|
||
|
|
|
||
|
|
41. Croft, W.J.; Gilmore, J. Bootstrap Protocol. RFC 951,
|
||
|
|
1985.
|
||
|
|
|
||
|
|
42. Plummer, D.C. An Ethernet Address Resolution Protocol.
|
||
|
|
RFC 826, 1982.
|
||
|
|
|
||
|
|
43. Diffie, W. and Hellman, M.E. "New Directions in
|
||
|
|
Cryptography." IEEE Transactions on Information
|
||
|
|
Theory, vol. IT-22, no. 6, pp. 644-654.
|
||
|
|
|
||
|
|
44. Voydock, V.L. and Kent, S.T. "Security Mechanisms in
|
||
|
|
High-Level Network Protocols". ACM Computer Surveys,
|
||
|
|
vol. 15, no. 2, pp. 135-171, June 1983.
|
||
|
|
|
||
|
|
45. Davies, D.W. and Price, W.L. Security for Computer
|
||
|
|
Networks: An Introduction to Data Security in
|
||
|
|
Teleprocessing and Electronic Funds Transfer. Wiley.
|
||
|
|
1984.
|
||
|
|
|
||
|
|
46. Defense Communications Agency. Defense Data Network
|
||
|
|
Subscriber Security Guide. 1983.
|
||
|
|
|
||
|
|
47. "Blacker Front End Interface Control Document", in DDN
|
||
|
|
Protocol Handbook. DDN Network Information Center, SRI
|
||
|
|
International, vol. 1, 1985.
|
||
|
|
|
||
|
|
48. DoD Computer Security Center. DoD Trusted Computer
|
||
|
|
System Evaluation Criteria, 1983, CSC-STD-001-83.
|
||
|
|
|
||
|
|
49. National Computer Security Center. Trusted Network
|
||
|
|
Interpretation of the Trusted Computer System Evaluation
|
||
|
|
Criteria. NCSC-TG-005, Version 1, July 31, 1987.
|
||
|
|
|
||
|
|
50. St. Johns, M. Draft Revised IP Security Option. RFC
|
||
|
|
1038, 1988.
|
||
|
|
|
||
|
|
51. DoD Computer Security Center. Technical Rationale
|
||
|
|
Behind CSC-STD-003-85: Computer Security Requirements,
|
||
|
|
CSC-STD-004-83, 1983.
|
||
|
|
|
||
|
|
52. Taylor, B. and Goldberg, D. "Secure Networking in the
|
||
|
|
Sun Environment". Proceedings, Summer USENIX, 1986,
|
||
|
|
Atlanta, Georgia.
|
||
|
|
|
||
|
|
53. Mills, D.L. Network Time Protocol (Version 1)
|
||
|
|
Specification and Implementation. RFC 1059, 1988.
|
||
|
|
|
||
|
|
54. Mills, D.L. Mailing list message
|
||
|
|
<8901192354.aa03743@Huey.UDEL.EDU>, January 19, 1989.
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
The Design of a Secure Internet Gateway
|
||
|
|
|
||
|
|
Bill Cheswick
|
||
|
|
10 September 1991
|
||
|
|
TECHNICAL MEMORANDUM
|
||
|
|
|
||
|
|
Abstract
|
||
|
|
--------
|
||
|
|
The Internet supports a vast and growing community of computer users
|
||
|
|
around the world.
|
||
|
|
Unfortunately, this network can provide anonymous access to this
|
||
|
|
community by unscrupulous, careless, or dangerous people.
|
||
|
|
On any given Internet there is a certain percentage of poorly-maintained
|
||
|
|
systems.
|
||
|
|
AT&T has a large internal
|
||
|
|
Internet that we wish to protect from outside attacks, while providing
|
||
|
|
useful services between the two.
|
||
|
|
|
||
|
|
This paper describes our Internet gateway. It is an application-level
|
||
|
|
gateway that passes mail and many of the common Internet services
|
||
|
|
between our internal machines and the Internet. This is accomplished
|
||
|
|
without IP connectivity using a pair of machines: a trusted internal
|
||
|
|
machine and an untrusted external gateway. These are connected by a private
|
||
|
|
link. The internal machine provides a few carefully-guarded services
|
||
|
|
to the external gateway. This configuration helps protect the internal
|
||
|
|
internet even if the external machine is fully compromised.
|
||
|
|
|
||
|
|
This is a slightly-updated version of the paper presented at the 1990
|
||
|
|
summer Usenix at Anaheim.
|
||
|
|
|
||
|
|
Introduction
|
||
|
|
------------
|
||
|
|
The design of a Corporate gateway to the Internet must deal with the
|
||
|
|
classical tradeoff between security and convenience. Most institutions
|
||
|
|
opt for convenience and use a simple router between their internal
|
||
|
|
internets and the rest of the world. This is dangerous.
|
||
|
|
Strangers on the Internet can reach and test every internal machine.
|
||
|
|
With workstations sitting on many desks, system administration is
|
||
|
|
often decentralized and neglected. Passwords are weak or missing.
|
||
|
|
A professor or researcher often may install the operating system
|
||
|
|
and forget it, leaving well-known security holes uncorrected.
|
||
|
|
For example, a sweep of 1,300 machines inside Bell Labs around
|
||
|
|
the time of the Internet Worm found over 300 that had at least one of
|
||
|
|
several known security holes.
|
||
|
|
|
||
|
|
When we first obtained a connection to the ARPAnet, Dave Presotto
|
||
|
|
configured our gateway machine (named arpa) as an application-level
|
||
|
|
gateway. For two years this machine was the sole official link
|
||
|
|
to the Internet for AT&T. Until its disconnection in 1989, this VAX 750 handled
|
||
|
|
all the Internet mail traffic and other services for the company.
|
||
|
|
Arpa had Ethernet connections to both the inside and outside Internets, just
|
||
|
|
like a router. It could also make and accept calls on our corporate Datakit
|
||
|
|
network.
|
||
|
|
|
||
|
|
Dave took a number of steps to make our gateway more secure.
|
||
|
|
He turned off IP forwarding in the kernel so packets could not
|
||
|
|
travel between the Internets. He installed a kernel modification
|
||
|
|
that limited TCP connections from arpa to the inside network to smtp, uucp,
|
||
|
|
named, and hostname ports. And he rejected the sendmail mailer as too
|
||
|
|
complicated and dangerous: the Upas [cite upas] mailer was installed
|
||
|
|
in its place. We removed a number of non-essential daemons, including the
|
||
|
|
finger server.
|
||
|
|
|
||
|
|
To give insiders access to the Internet, a gate service
|
||
|
|
was installed on arpa. Insiders could call this service and
|
||
|
|
supply an Internet address. The gate connected to a socket of a remote
|
||
|
|
Internet host and then copied bytes between the two connections. It was
|
||
|
|
easy to provide atelnet, a version of telnet that used the gate service.
|
||
|
|
Aftp supplied FTP services: it was the standard ftp modified so both the
|
||
|
|
command and data connections were initiated from the inside. (The standard
|
||
|
|
ftp would have tried to make the data connection from arpa to the inside, a
|
||
|
|
connection prohibited by arpa's kernel.)
|
||
|
|
|
||
|
|
This configuration successfully resisted the Internet worm. We ran neither
|
||
|
|
sendmail nor fingerd, the two programs exploited by the worm. [cite seeley] The
|
||
|
|
internal internet was spared the infection. (Actually, there was a second,
|
||
|
|
unguarded IP link to the Outside. We got lucky: only a few machines
|
||
|
|
at the other end knew of the link, and their machines were shut down
|
||
|
|
before the worm could creep across.)
|
||
|
|
|
||
|
|
Had arpa been infected, the worm could have reached the inside
|
||
|
|
machines. The initial smtp sendmail connection was permitted,
|
||
|
|
and the worm's second connection would have been initiated from the
|
||
|
|
inside target machine into arpa, the permitted direction.
|
||
|
|
|
||
|
|
|
||
|
|
The new gateway
|
||
|
|
--- --- -------
|
||
|
|
All of arpa's protection has, by design, left the internal AT&T machines
|
||
|
|
untested---a sort of crunchy shell around a soft, chewy center.
|
||
|
|
We run security scans on internal machines and bother system administrators
|
||
|
|
when holes are found. Still, it would be nice to have a gateway that is
|
||
|
|
demonstrably secure to protect the internal machines. For peace of mind,
|
||
|
|
the gateway design should not rely on vendors' code more than absolutely
|
||
|
|
necessary. We would like the internal machines protected even if an invader
|
||
|
|
breaks into the gateway machine, becomes root, and creates and runs a new
|
||
|
|
kernel.
|
||
|
|
|
||
|
|
We had to replace arpa. The VAX 750 ran with typical load averages of seven
|
||
|
|
to twelve jobs throughout the day. When the load average hit about
|
||
|
|
fifteen, the old Datakit driver expired, wedging the Datakit ports and
|
||
|
|
requiring a reboot.
|
||
|
|
|
||
|
|
A new machine gave the opportunity for a clean start.
|
||
|
|
We could re-think the security arrangements to improve on arpa's shortcomings.
|
||
|
|
|
||
|
|
Our new gateway machine, named inet, is a MIPS M/120 running RISC/OS,
|
||
|
|
a System V implementation with Berkeley enhancements. Various daemons and
|
||
|
|
critical programs have been obtained from other sources, checked,
|
||
|
|
and installed.
|
||
|
|
|
||
|
|
We store nothing vital or secret on inet, since we assume that it may be
|
||
|
|
defeated in unforeseen ways. It does not run uucp---systems files and dialers
|
||
|
|
could fall into the wrong hands. There are few system administration accounts,
|
||
|
|
and user accounts are discouraged.
|
||
|
|
Inet is not used for other tasks.
|
||
|
|
It is backed up regularly, and scanned for unauthorized changes and
|
||
|
|
common system administration mistakes.
|
||
|
|
Though we don't trust inet, we protect it as much as we can.
|
||
|
|
|
||
|
|
Inet has a single Ethernet port which is connected to a router
|
||
|
|
on JVNCnet, our external regional network. It also has a connection to Datakit.
|
||
|
|
We have configured our Datakit controller to force all connections
|
||
|
|
from inet to a single internal machine, named r70.
|
||
|
|
R70 can redial, or splice connections to other internal machines. R70
|
||
|
|
provides a limited set of services to inet for reaching internal machines.
|
||
|
|
The list of services are:
|
||
|
|
1. connection to an approved machine's smtp port,
|
||
|
|
2. connection to a login or trusted-login Datakit destination
|
||
|
|
after passing a challenge-response test, and
|
||
|
|
3. connection to a logging service.
|
||
|
|
|
||
|
|
The key to the arrangement is a restricted channel from inet
|
||
|
|
to r70. This private channel was easily constructed using stock features of
|
||
|
|
our research Datakit controller. Other connection schemes could be implemented
|
||
|
|
using a simple multiplexed protocol over some back-to-back connection
|
||
|
|
between the machines, or a simple two-machine Ethernet would suffice.
|
||
|
|
If the last approach is used with TCP, the internal
|
||
|
|
machine must supply differing TCP services to its two Ethernet
|
||
|
|
interfaces. (I am not sure this is possible with stock commercial TCP
|
||
|
|
software. It wouldn't be too hard to modify inetd to do this.)
|
||
|
|
|
||
|
|
These functions do not load the internal machine too much;
|
||
|
|
it could have other uses like uucp, mail, or even normal user jobs.
|
||
|
|
But the services it provides the external machine are the key
|
||
|
|
to security, and must be protected well.
|
||
|
|
|
||
|
|
|
||
|
|
Outbound services
|
||
|
|
-------- --------
|
||
|
|
It is quite easy to implement most outbound services to the Internet.
|
||
|
|
Inet has a small program, named proxy (a descendant of arpa's
|
||
|
|
gate), that makes calls to the Internet on behalf of an inside machine
|
||
|
|
and relays bytes between the inside Datakit connection and the outside
|
||
|
|
Internet TCP connection. Proxy can also listen to a non-privileged socket
|
||
|
|
and report connections to an inside process. Several outbound services
|
||
|
|
are implemented using proxy, and more are easy to create.
|
||
|
|
In all cases, it appears to the remote Internet hosts that our gateway
|
||
|
|
machine is making the calls.
|
||
|
|
|
||
|
|
%%%% picture of a proxy call
|
||
|
|
|
||
|
|
Inet may be reached over the Datakit.
|
||
|
|
But how do internal machines reach inet over the Ethernet?
|
||
|
|
R70 responds to two IP addresses: its own, and an internal IP address for
|
||
|
|
inet. (Dave Presotto implemented this after a trivial change to the
|
||
|
|
Tenth Edition Research Unix connection server. [cite connection]
|
||
|
|
Calls to certain TCP ports on this internal IP address invoke dcon, a
|
||
|
|
program that simply relays the bytes between the TCP port
|
||
|
|
and Datakit connections on inet.
|
||
|
|
|
||
|
|
I have replaced the old aftp and atelnet with ptelnet and pftp. They work
|
||
|
|
in the same manner, but the new routines call a portable implementation of
|
||
|
|
ipcopen, a piece of the connection server. Ipcopen hides the details of
|
||
|
|
a connection (TCP sockets or Datakit), simplifying the application program.
|
||
|
|
For example:
|
||
|
|
ptelnet tcp!toucan
|
||
|
|
connects to machine toucan on our internet, and
|
||
|
|
ptelnet proxy!ernie.berkeley.edu
|
||
|
|
connects to ernie.berkeley.edu on the external Internet.
|
||
|
|
proxy! is the default.
|
||
|
|
The ipcopen implementation is not flawless:
|
||
|
|
some socket features such as out-of-band data and the urgent pointer
|
||
|
|
are missing because they are not supported by Datakit.
|
||
|
|
Ptelnet was stripped down to avoid these features.
|
||
|
|
|
||
|
|
%%%% figure of a proxy
|
||
|
|
|
||
|
|
Pftp provides FTP access in a similar manner. It is an updated
|
||
|
|
version of aftp from arpa. The ipcopen routines allow it to work over Datakit.
|
||
|
|
|
||
|
|
The proxy software is available
|
||
|
|
by anonymous FTP from toucan.zoo.att.com. The file is proxy.tar.Z.
|
||
|
|
|
||
|
|
% figure of pftp and ftp function
|
||
|
|
|
||
|
|
Outgoing mail is sent to inet via smtp over either Datakit or the
|
||
|
|
internal Internet. It is stored and forwarded from there. Upas
|
||
|
|
performs the mail gateway functions.
|
||
|
|
|
||
|
|
|
||
|
|
$ telnet research.att.com
|
||
|
|
Trying...
|
||
|
|
Connected to research.att.com.
|
||
|
|
Escape character is '^]'.
|
||
|
|
|
||
|
|
|
||
|
|
RISC/os (inet)
|
||
|
|
|
||
|
|
login: guard
|
||
|
|
RISC/os (UMIPS) 4.0 inet
|
||
|
|
Copyright 1986, MIPS Computer Systems
|
||
|
|
All Rights Reserved
|
||
|
|
Security Authentication check
|
||
|
|
|
||
|
|
login: ches
|
||
|
|
Enter response code for 90902479: 818b71fe
|
||
|
|
|
||
|
|
Destination please: coma
|
||
|
|
OKYou have mail.
|
||
|
|
coma=; date
|
||
|
|
Tue Nov 14 10:52:37 EST 1989
|
||
|
|
coma=;
|
||
|
|
Eof
|
||
|
|
Connection closed by foreign host.
|
||
|
|
$
|
||
|
|
|
||
|
|
*A connection session through the guard.*
|
||
|
|
|
||
|
|
|
||
|
|
Inbound services
|
||
|
|
------- --------
|
||
|
|
We provide incoming login and mail service. For incoming file transfer,
|
||
|
|
inet provides an anonymous FTP service.
|
||
|
|
|
||
|
|
We do not trust our passwords to the Internet: it is too easy to eavesdrop
|
||
|
|
or steal packets. See [cite smb] for a discussion of these security problems.
|
||
|
|
Login service requires a hand-held authenticator (HHA). These are
|
||
|
|
calculator-sized devices that contain DES encryption and a manually-loaded
|
||
|
|
64-bit key. They cost about $60.
|
||
|
|
|
||
|
|
Inbound login service is provided through an authentication manager on
|
||
|
|
r70. A session is shown in figure [ref connect].
|
||
|
|
To connect, the following sequence occurs:
|
||
|
|
1. The Internet caller uses telnet to connect to research.att.com
|
||
|
|
inet via telnet. The login name is tt guard.
|
||
|
|
2. The tt guard login connects to the authentication manager on r70
|
||
|
|
over the Datakit. It spends the rest of the connection
|
||
|
|
relaying bytes between the two connections.
|
||
|
|
3. The authentication manager on r70 requests a login name.
|
||
|
|
4. R70 sends a random challenge number, which the caller supplies.
|
||
|
|
5. The user enters the challenge into his HHA.
|
||
|
|
6 The HHA encrypts the challenge using a pre-loaded DES key,
|
||
|
|
and displays the response.
|
||
|
|
7. The user types the response. He has three tries to
|
||
|
|
answer a challenge correctly, and is disconnected if he fails.
|
||
|
|
8. The authorization manager prompts for a Datakit destination.
|
||
|
|
9. When the user enters the destination, the manager sends a redial
|
||
|
|
request to the Datakit controller with the given destination and
|
||
|
|
a service of `dcon'. For machines that trust r70, the `dcon'
|
||
|
|
service bypasses further logins and avoids further passwords.
|
||
|
|
10. The redial request transfers the call, switching r70 out of
|
||
|
|
the connection. Connections for a TCP host are handed to rlogin.
|
||
|
|
|
||
|
|
Users may wish to trust the gate machine and so avoid typing any passwords
|
||
|
|
over the internet. TCP callers can put r70-mhbb.research.att.com in their
|
||
|
|
.rhosts file. For Datakit connections using the standard DKHOST software,
|
||
|
|
they can log in through the guard once using ptelnet, and then request the
|
||
|
|
destination area/exchange/host.authorize.t.
|
||
|
|
This will connect them to their own machine's authorization server,
|
||
|
|
which will prompt them for a login and password. Obviously, this
|
||
|
|
should be done from a secure terminal, and not from out on the
|
||
|
|
Internet.
|
||
|
|
(Both of these practices are dangerous. Do you really want to trust
|
||
|
|
r70? It is probably safer than entering passwords on some alien
|
||
|
|
workstation out on the Internet. We frown on user-level authentication in
|
||
|
|
general, preferring to have the system administrator make and support these
|
||
|
|
judgements.)
|
||
|
|
|
||
|
|
Each user requires a DES key, and keys have an expiration date.
|
||
|
|
The key file is stored on r70 in a file readable only by root.
|
||
|
|
This is unfortunate, and the file will probably move into an authentication
|
||
|
|
manager somewhere.
|
||
|
|
|
||
|
|
Inbound mail is delivered directly to inet.
|
||
|
|
Inet checks the destination. If it is a trusted machine (i.e. its
|
||
|
|
smtp is trusted), a connection request is sent to r70. If not,
|
||
|
|
the mail is relayed through an accessible internal machine.
|
||
|
|
R70 will permit connections only to trusted smtp implementations.
|
||
|
|
The list is short because most internal machines run sendmail.
|
||
|
|
|
||
|
|
% so why do we need inet? Why not a Cisco with inet on the inside?
|
||
|
|
|
||
|
|
%% The restricted list of known 112 smtps should be justified both from
|
||
|
|
%% a security standpoint and a practicality one -- some smtps (i.e.,
|
||
|
|
%% sendmail on sunos) have security bugs. Thus, the techniques used
|
||
|
|
%% to let logins through are not acceptable for mail.
|
||
|
|
|
||
|
|
% what about network file system connections into inet? Another hole?
|
||
|
|
|
||
|
|
%% You may want to have two public ftp directories, though I'm not certain
|
||
|
|
%% exactly how to set things up this way without giving out inet logins.
|
||
|
|
%% 'pub' is mode 555 or 755 not owned by ftp; it's used for 'blessed'
|
||
|
|
%% outgoing packages that we advertise for pickup. 'incoming' is mode 333
|
||
|
|
%% or 733 -- i.e., not readable from the outside. If you know the
|
||
|
|
%% file name, you can pick it up, but you can't snoop for stuff. This
|
||
|
|
%% avoids things like you putting a file in there for me, but a cracker
|
||
|
|
%% plants a horse before I get to it. I've recommended a similar scheme
|
||
|
|
%% to the Comp Centers; they like it so far.
|
||
|
|
|
||
|
|
%% How does ftpd work without running as root? On Berkeley systems
|
||
|
|
%% at least, it can't function without being root when talking to
|
||
|
|
%% a client that doesn't generate PORT commands.
|
||
|
|
|
||
|
|
|
||
|
|
Protecting INET
|
||
|
|
---------- ----
|
||
|
|
The preceding precautions might imply that we expect our gateway
|
||
|
|
to be compromised at some point. In fact, we are taking great pains
|
||
|
|
to protect the machine, including the usual good system administration
|
||
|
|
steps needed to secure any Unix system [cite ritchie]: directory and file
|
||
|
|
permissions are checked, backups performed regularly, etc.
|
||
|
|
|
||
|
|
We have taken some steps to avoid denial-of-service attacks.
|
||
|
|
For example, the logs, the spool directory, and the publically-accessible
|
||
|
|
FTP directory are each on separate file systems. If a stranger fills
|
||
|
|
the public FTP directory, there is still room for the logs.
|
||
|
|
|
||
|
|
Here are some other steps taken:
|
||
|
|
|
||
|
|
1. All the important executable files are periodically
|
||
|
|
checksummed and checked for changes.
|
||
|
|
2. Most user accounts do not have passwords to be checked. They
|
||
|
|
obtain permission to login based on the source of the call.
|
||
|
|
3. User accounts are discouraged.
|
||
|
|
4. Non-essential network daemons have been removed: we don't need
|
||
|
|
to trust them.
|
||
|
|
5. Inetd(8) handles all network connections. Certain modifications
|
||
|
|
allow telnetd, smtpd, and ftpd to run with reduced permissions:
|
||
|
|
[cite ritchie] inetd handles the privileged stuff.
|
||
|
|
6. There is extensive logging of network activity, including connection
|
||
|
|
and login attempts. Logs are stored forever on a WORM-based backup
|
||
|
|
system.
|
||
|
|
7. Since the network daemons are so important to the security of the machine,
|
||
|
|
we obtained the latest BSD versions and examined, modified, and
|
||
|
|
installed them.
|
||
|
|
|
||
|
|
|
||
|
|
Gateway alternatives
|
||
|
|
------- ------------
|
||
|
|
There are several much simpler alternatives for an Internet gateway.
|
||
|
|
The simplest is a router, which just lets the packets through. Some
|
||
|
|
routers, like Cisco's, provide packet filtering that can block various
|
||
|
|
types of access to an institution.
|
||
|
|
|
||
|
|
We did not choose the router. Though the filtering is quite good, it's
|
||
|
|
not clear whether a clever worm could get through the permitted ports.
|
||
|
|
Can we trust the router?
|
||
|
|
If telnet access is allowed from the outside, inside machines are exposed
|
||
|
|
to password-guessing attacks. If telnet access is not allowed, an alternative
|
||
|
|
is needed anyway, requiring additional provisions. The router does not
|
||
|
|
provide logging to detect invasion attempts. And mail gating must be
|
||
|
|
provided by a machine somewhere: it is unreasonable to expect each internal
|
||
|
|
machine to be configured to handle all the varieties of external mail
|
||
|
|
addressing.
|
||
|
|
|
||
|
|
Many Internet sites use a gateway machine like a Sun. These machines forward
|
||
|
|
IP packets in both directions, and provide a mail gateway service.
|
||
|
|
The packet flow is still dangerous, though filtering is available.
|
||
|
|
Many internal machines may trust the gate machine, leaving them further
|
||
|
|
exposed if the gate machine is compromised.
|
||
|
|
|
||
|
|
|
||
|
|
Performance
|
||
|
|
-----------
|
||
|
|
The mail throughput of the new gateway has been gratifying,
|
||
|
|
though a VAX 750 is an easy act to follow. In many cases,
|
||
|
|
we have had replies to cross-country mail return in less than a minute.
|
||
|
|
It sometimes seems that the mail must have bounced. Inet has little
|
||
|
|
else to do, and a MIPS M/120 is a fast machine.
|
||
|
|
|
||
|
|
Pftp transfers are fastest over Datakit, since they avoid the
|
||
|
|
dcon gateway in r70. File transfers range from 17 to 44 Kb/sec.
|
||
|
|
TCP transfers through r70 run at 9 to 16 Kb/sec. By comparison,
|
||
|
|
thinspace ftp on inet runs at about 60--90 Kb/sec.
|
||
|
|
Clearly, security has its costs. But these are top speeds. The limiting
|
||
|
|
factor is often the external net or host. The throughput seems adequate, and
|
||
|
|
there have been no complaints.
|
||
|
|
|
||
|
|
% ftp> get /vmunix /dev/null
|
||
|
|
% 200 PORT command okay.
|
||
|
|
% 150 Opening data connection for /vmunix (192.20.225.2,2242) (707584 bytes).
|
||
|
|
% 226 Transfer complete.
|
||
|
|
% 707584 bytes received in 15.834 seconds (43.64 Kbytes/s)
|
||
|
|
|
||
|
|
%
|
||
|
|
% 19505 bytes from pilot.njin.net:
|
||
|
|
% dk to inet: 1.1 sec 17.3 K/sec
|
||
|
|
% TCP to inet: 1.4 sec 13.6 K/sec
|
||
|
|
% dk to att-in: 13 sec 1.5 K/sec
|
||
|
|
%
|
||
|
|
% 17403 bytes from uunet.uu.net:
|
||
|
|
% dk to inet: .84 sec 20.2 K/sec
|
||
|
|
% TCP to inet: 1.9 sec 8.9 K/sec
|
||
|
|
% dk to att-in: 9.2 sec 1.8 K/sec
|
||
|
|
%
|
||
|
|
%
|
||
|
|
|
||
|
|
|
||
|
|
Conclusions
|
||
|
|
-----------
|
||
|
|
The new gateway achieves a useful balance of utility and
|
||
|
|
security. Most internal users seem to be happy with pftp and
|
||
|
|
ptelnet. Some have asked for talk, resolver service and other UDP-based
|
||
|
|
protocols. These could be provided with non-proxy services
|
||
|
|
on inet accessible through Datakit. Steve Bellovin has cooked up a
|
||
|
|
scheme to support X through the gateway. The security implications are
|
||
|
|
frightening.
|
||
|
|
|
||
|
|
There are certainly limits to our security. If r70 and inet are subverted,
|
||
|
|
the inside machines could be attacked.
|
||
|
|
|
||
|
|
Insiders can easily import trouble such as Trojan horses or programs
|
||
|
|
infected with viruses. Our best defense is continued scanning of internal
|
||
|
|
machines for security holes in case such a program gets loose.
|
||
|
|
|
||
|
|
There is now a second AT&T internet gateway [cite horton].
|
||
|
|
Its configuration is based on this work.
|
||
|
|
These two front doors provide reasonable security to an isolated
|
||
|
|
internal internet. But AT&T is a large company, so we keep a constant watch to
|
||
|
|
assure that no other links are made to the external Internet. A locked front
|
||
|
|
door is useless if the back wall of the house is missing.
|
||
|
|
|
||
|
|
The incoming guarded telnet service is not perfect. The remote telnet
|
||
|
|
may be insecure, and the TCP connection itself could be stolen after
|
||
|
|
login is complete. Most internal AT&T machines do not accept r70's
|
||
|
|
judgement that the user is valid, and require their own login passwords.
|
||
|
|
These passwords travel over the Internet in the clear.
|
||
|
|
|
||
|
|
Our solution does have some drawbacks.
|
||
|
|
We rely on two machines and Datakit to keep things working. This
|
||
|
|
yields three points of failure, while the simpler approaches have
|
||
|
|
(in some sense) only one point of failure. The use of TCP-level gateways
|
||
|
|
does lower throughput. Though most users seem to be content with the
|
||
|
|
pftp response, it would be nice to speed it up some. The uptime of this
|
||
|
|
service is measured in months, and the mail transit time in seconds or minutes.
|
||
|
|
|
||
|
|
This paper is not an invitation to come
|
||
|
|
test the security of our gateway.
|
||
|
|
It is management's policy to call the
|
||
|
|
authorities when intruders are detected.
|
||
|
|
|
||
|
|
|
||
|
|
Acknowledgements
|
||
|
|
----------------
|
||
|
|
Many people have contributed to the support of
|
||
|
|
these gateways. Steve Bellovin did most of the initial work to get arpa
|
||
|
|
talking to the ARPAnet and Datakit.
|
||
|
|
Dave Presotto has supplied much of the software and most
|
||
|
|
of the paranoia to provide a secure gateway. Howard Trickey implemented
|
||
|
|
earlier versions of ptelnet and pftp.
|
||
|
|
Dennis Ritchie has kept a watchful eye and stepped in when things broke.
|
||
|
|
Steve Bellovin and others have provided numerous suggestions and warnings
|
||
|
|
on various networking and security topics.
|
||
|
|
Jim McKie ported many useful Research Unix [cite V10] functions and the
|
||
|
|
INCON Datakit driver to our MIPS computers, making life much easier for me.
|
||
|
|
|
||
|
|
|
||
|
|
1. The box is completely reset.
|
||
|
|
Enter a code digit and press "Enter":
|
||
|
|
|
||
|
|
digit & hexadecimal encryption & "error"
|
||
|
|
0 & yes & yes
|
||
|
|
1 & yes & no
|
||
|
|
4 & no & yes
|
||
|
|
5 & no & no
|
||
|
|
|
||
|
|
Hexadecimal encryption provides slightly higher security,
|
||
|
|
but it is easy to mistake "6" and "b". In decimal
|
||
|
|
mode, the hexadecimal characters "a"--"c" and "d"--"f"
|
||
|
|
are mapped to "2" and "3" respectively. The guard software
|
||
|
|
accepts either answer. The error mode displays "error"
|
||
|
|
if an invalid PIN is entered. Five invalid entries will
|
||
|
|
reset the box to . If "error" is off, the SNK
|
||
|
|
provides an invalid encryption. We use mode 4.
|
||
|
|
2. Enter the DES key. The key consists of eight
|
||
|
|
8-bit bytes typed in octal. Press "Enter."
|
||
|
|
3. Enters a 4 to 16-digit PIN, followed by "Enter."
|
||
|
|
4. Re-enter the PIN, followed by "Enter."
|
||
|
|
5. Enter the PIN followed by "Enter".
|
||
|
|
6. Enter the challenge, followed by "Enter".
|
||
|
|
The SNK displays the response.
|
||
|
|
|
||
|
|
Programming the Hand Held Authenticator
|
||
|
|
----------- --- ---- ---- -------------
|
||
|
|
We use the Securenet Key SNK-4. It is available from
|
||
|
|
|
||
|
|
Digital Pathways
|
||
|
|
221 West Grand Avenue
|
||
|
|
Montvale NJ 07645
|
||
|
|
|
||
|
|
It costs $60 in unit quantities. Its major competitor is the
|
||
|
|
SecureId card. The latter uses a time-based algorithm to generate
|
||
|
|
the key and requires substantial and expensive software in the
|
||
|
|
host. The SNK-4 needs a small program that uses the standard
|
||
|
|
encrypt function.
|
||
|
|
|
||
|
|
We program the SNK-4s by hand, though a PC-based system is
|
||
|
|
available as well. Figure [ref programming] details the programming
|
||
|
|
steps.
|
||
|
|
|
||
|
|
The SNK shuts off automatically after 30 seconds. Press
|
||
|
|
"On" to restart.
|
||
|
|
|
||
|
|
We have found that the battery runs down in the SNK if the
|
||
|
|
"On" button is pressed continuously, say, in luggage. The
|
||
|
|
bumps around the "On" switch don't protect the switch well
|
||
|
|
enough. We suggest storing the box in the original packing
|
||
|
|
material.
|
||
|
|
|
||
|
|
|
||
|
|
Bibliography
|
||
|
|
------------
|
||
|
|
upas
|
||
|
|
David Presotto.
|
||
|
|
Upas - a simpler approach to network mail.
|
||
|
|
USENIX Summer Conference Proceedings, pps.533-538, June 1985.
|
||
|
|
seeley
|
||
|
|
Donn Seeley.
|
||
|
|
A Tour of the Worm.
|
||
|
|
USENIX Winter Conference Proceedings, Jan. 1989.
|
||
|
|
connection
|
||
|
|
David Presotto and Dennis Ritchie.
|
||
|
|
Interprocess Communication in the Ninth Edition UNIX System.
|
||
|
|
Unix Programmer's Manual, Tenth Edition.
|
||
|
|
A. G. Hume and M. D. McIlroy, Editors.
|
||
|
|
AT&T Bell Laboratories, Murray Hill, NJ. 1990.
|
||
|
|
smb
|
||
|
|
Bellovin, S.M.
|
||
|
|
Security Problems in the TCP/IP Protocol Suite.
|
||
|
|
Computer Communications Review, Vol. 9, No. 2; April, 1989,
|
||
|
|
pps.32-48.
|
||
|
|
ritchie
|
||
|
|
Ritchie, Dennis M.
|
||
|
|
On the Security of UNIX.
|
||
|
|
Unix Programmer's Manual, Tenth Edition.
|
||
|
|
A. G. Hume and M. D. McIlroy, Editors.
|
||
|
|
AT&T Bell Laboratories, Murray Hill, NJ. 1990.
|
||
|
|
V10
|
||
|
|
Unix Programmer's Manual, Tenth Edition, Volumes One and Two.
|
||
|
|
A. G. Hume and M. D. McIlroy, Editors.
|
||
|
|
AT&T Bell Laboratories, Murray Hill, NJ. 1990.
|
||
|
|
horton
|
||
|
|
Horton, Mark R.
|
||
|
|
Charter for an Electronic Communication Gateway Service - Issue 1.
|
||
|
|
%MRH CB 45264 4276 1E-271
|
||
|
|
45264-881003.01IM.
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
NIA074 / File 5
|
||
|
|
|
||
|
|
Notes on Centigram Voice Mail system Consoles
|
||
|
|
|
||
|
|
Proper entry procedure, possible design flaw and serious security
|
||
|
|
bug:
|
||
|
|
|
||
|
|
Due to, I assume, more efficient task-handling and the
|
||
|
|
desire for a more 'Unix-like' environment, the developers at
|
||
|
|
Centigram needed for certain key functions to be available at all
|
||
|
|
times. For instance, the ^Z key acts as the 'escape' key (these
|
||
|
|
can be remapped, if desired). When necessary for some
|
||
|
|
applications to use an 'escape' procedure, pressing this key can,
|
||
|
|
in at leas cases, cause a drop to shell, or /cmds/qnxsh
|
||
|
|
(possibly /cmds/sh, as well, but I'm used to seeing qnxsh). If
|
||
|
|
this escape procedure were invoked during, say, /cmds/login, the
|
||
|
|
resulting drop to shell would by-pass the 'Enter Passcode:'
|
||
|
|
message. And it does.
|
||
|
|
|
||
|
|
After calling the Centigram, normal procedure is to hit ^Z
|
||
|
|
to activate the terminal, followed by the entry of the remote or
|
||
|
|
console passcodes, and then proceeding with normal console
|
||
|
|
activities. However, if ^Z is continually depressed during the
|
||
|
|
login sequence, the login program will abort and run /cmds/qnxsh.
|
||
|
|
The behavior may be somewhat erratic by the repeat use of the
|
||
|
|
escape key, but when the $ prompt appears, usually, it doesn't
|
||
|
|
deliberately go away without an 'exit' command or a ^D.
|
||
|
|
Typically, a login pattern can develop to accommodate the erratic
|
||
|
|
behavior something along the lines of: continuously depress ^Z
|
||
|
|
until $ prompt appears, hit return, possibly get 'Enter Passcode:'
|
||
|
|
message, hit return, and $ prompt appears again, set proper tty
|
||
|
|
setting, and change directory appropriately, and continue with
|
||
|
|
normal console functions.
|
||
|
|
|
||
|
|
Initial STTY Setting:
|
||
|
|
|
||
|
|
I've had problems with my terminal settings not being set
|
||
|
|
properly during the above entry procedure. I can correct this by
|
||
|
|
using the "stty +echo +edit" command, and, for my terminal, all
|
||
|
|
is restored. The correct values for STTY options and keys appear
|
||
|
|
to be:
|
||
|
|
|
||
|
|
Options: +echo +edit +etab +ers +edel +oflow +mapcr +hangup
|
||
|
|
break=03h esc=1Ah rub=7Fh can=18h eot=04h up=15h
|
||
|
|
|
||
|
|
down=
|
||
|
|
0Ah left=08h ins=0Eh del=0Bh
|
||
|
|
|
||
|
|
The keymap, of course, can be modified as desired, but the
|
||
|
|
options, especially +edit, appear to be necessary.
|
||
|
|
|
||
|
|
[A somewhat detailed description of the options could follow, or
|
||
|
|
maybe just a list and a brief review of the ones I care to
|
||
|
|
comment on]
|
||
|
|
|
||
|
|
Disks and directories:
|
||
|
|
|
||
|
|
The drives and directories are set up in a remotely MessDos
|
||
|
|
fashion. The output of a 'pwd' command looks similar to '4:/'.
|
||
|
|
'4;' represents the drive number, and '/' is the start of the
|
||
|
|
directory structure, '4:/' being the root directory for drive 4,
|
||
|
|
'3:/tmp' being the /tmp directory on drive 3, etc.
|
||
|
|
|
||
|
|
The two most important directories are 1:/cmds and 4:/cmds,
|
||
|
|
which contain, for the most part, the program files for all of
|
||
|
|
the performable commands on the system, excluding the commands
|
||
|
|
written into the shell. The directory 1:/cmds should look
|
||
|
|
similar to:
|
||
|
|
|
||
|
|
$ ls
|
||
|
|
backup drel ls rm talk
|
||
|
|
chattr eo mkdir rmdir tcap
|
||
|
|
choose fdformat mount runfloppy timer
|
||
|
|
clrhouse files p search tsk
|
||
|
|
cp frel pack sh unpack
|
||
|
|
date get_boolean patch slay ws
|
||
|
|
ddump led pwd sleep zap
|
||
|
|
diff led.init qnxsh spatch
|
||
|
|
dinit login query stty
|
||
|
|
|
||
|
|
This is a display of many useful commands. chattr changes
|
||
|
|
the read/write file attributes, cp is copy, ddump dumps disk
|
||
|
|
sectors in hex & ascii, led is the line editor, p is the file
|
||
|
|
print utility, and a variety of other things that you can
|
||
|
|
experiment with at your own leisure. DO NOT USE THE TALK
|
||
|
|
COMMAND. At least, be careful if you do. If you try to
|
||
|
|
communicate with your own terminal, it locks communication with
|
||
|
|
the shell, and upon hangup, for some reason, causes (well, in one
|
||
|
|
instance) a major system error and system-wide reboot, which,
|
||
|
|
quite frankly, made me say 'Oops. I'm not doing that again'
|
||
|
|
when I called to check on the actual voice mailboxes, and the
|
||
|
|
phone line just sat there, dead as old wood; and I was quite
|
||
|
|
relieved that it came back up after a few minutes.
|
||
|
|
|
||
|
|
The other directory, 4:/cmds, is filled with more specific
|
||
|
|
commands pertaining to functions within the voice mail system
|
||
|
|
itself. These programs are actually run from within other
|
||
|
|
programs, to produce an easy-to-understand menu system.
|
||
|
|
Normally, this menu system is immediately run after the entry
|
||
|
|
of the remote or console passcode, but it would not be run when
|
||
|
|
using the aforementioned security bug. It can be run from the
|
||
|
|
shell simply by typing the name of the program, 'console'.
|
||
|
|
|
||
|
|
Mounting and Initializing Drives:
|
||
|
|
|
||
|
|
The MOUNT command produces results similar to this when run
|
||
|
|
without arguments:
|
||
|
|
|
||
|
|
$ mount
|
||
|
|
Drive 1: Hard, 360k, offset = 256k, partition= Qnx
|
||
|
|
Drive 2: Floppy, 360k, p=1Drive 3: RamDisk, 96k, partition= Qnx
|
||
|
|
Drive 4: Hard, 6.1M, offset = 616k, partition= Qnx
|
||
|
|
$tty0 = $con, Serial at 03F8
|
||
|
|
$tty1 = $term1 , Serial at 02F8
|
||
|
|
$tty2 = $term2 , Serial at 0420
|
||
|
|
$tty3 = $mdm , Serial at 0428
|
||
|
|
|
||
|
|
The Hard and Floppy drives are fairly self-explanatory,
|
||
|
|
although I can't explain why they appear to be so small, nor do
|
||
|
|
I know where the voice recordings go, or if this list contain all
|
||
|
|
the space required for voice storage.
|
||
|
|
|
||
|
|
The Ramdisk, however, is a bit more interesting to me. The
|
||
|
|
mount command used for the above-mentioned disk 3 was:
|
||
|
|
|
||
|
|
$ mount ramdisk 3 s=96k -v
|
||
|
|
|
||
|
|
Although I'm not sure what the -v qualifier does, the rest
|
||
|
|
is fairly straightforward. I assume that the size of the drive
|
||
|
|
can be greater than 96k, although I haven't yet played with it to
|
||
|
|
see how far it can go. To initialize the drive, the following
|
||
|
|
command was used:
|
||
|
|
|
||
|
|
$ dinit 3
|
||
|
|
|
||
|
|
Quite simple, really. Now the drive is ready for use, so
|
||
|
|
one can 'mkdir 3:/tmp' or such and route files there as desired,
|
||
|
|
or use it for whatever purpose. If something is accidentally
|
||
|
|
redirected to the console with >$cons, you can use the line
|
||
|
|
editor 'led' to create a temporary file and then use the print
|
||
|
|
utility 'p' to clear the console's screen by using "p filename
|
||
|
|
>$cons", where filename contains a clear screen of 25 lines, or
|
||
|
|
an ANSI bomb (if appropriate), or a full-screen DobbsHead or
|
||
|
|
whatever you like.
|
||
|
|
|
||
|
|
EVMON and password collecting:
|
||
|
|
|
||
|
|
The evmon utility is responsible for informing the system
|
||
|
|
manager about the activity currently taking place within the
|
||
|
|
voice mail system. Run alone, evmon produces output similar to:
|
||
|
|
|
||
|
|
$ evmon
|
||
|
|
Type Ctrl-C to terminate.
|
||
|
|
ln 26 tt 3
|
||
|
|
ln 26 line break
|
||
|
|
ln 26 onhook
|
||
|
|
ln 28 ringing
|
||
|
|
ln 28 tt 8
|
||
|
|
ln 28 tt 7
|
||
|
|
ln 28 tt 6
|
||
|
|
ln 28 tt 2
|
||
|
|
ln 28 offhook
|
||
|
|
ln 28 tt *
|
||
|
|
ln 28 tt 2
|
||
|
|
ln 28 tt 0
|
||
|
|
ln 28 tt 3
|
||
|
|
ln 28 tt 0
|
||
|
|
ln 28 line break
|
||
|
|
ln 28 onhook
|
||
|
|
[...]
|
||
|
|
|
||
|
|
And so forth. This identifies a certain phone line, such as line
|
||
|
|
28, and a certain action taking place on the line, such as the
|
||
|
|
line ringing, going on or offhook, etc. The 'tt' stands (I
|
||
|
|
assume) for touch tone, and it is, of course, the tone currently
|
||
|
|
played on the line; which means that touchtone entry of passcodes
|
||
|
|
can be recorded and filed at will. In the above example, the
|
||
|
|
passcode for Mailbox 8762 is 2030 (the * key, along with the 0
|
||
|
|
key, can acts as the 'user entering mailbox' key; it can,
|
||
|
|
however, also be the abort key during passcode entry, and other
|
||
|
|
things as well). Now the user, of course, doesn't (usually) dial
|
||
|
|
8762 to enter his mailbox, he simply dials the mailbox number and
|
||
|
|
then * plus his passcode; the reason for this is the type of
|
||
|
|
signalling coming from the switch to this particular business
|
||
|
|
line was set-up for four digit touch tone ID to route the line to
|
||
|
|
the appropriate called number. This is not the only method of
|
||
|
|
signalling, however, as I've seen other businesses that use three
|
||
|
|
digit pulse signalling, for example, and there are others as
|
||
|
|
well. Each may have it's own eccentricities, but I would imagine
|
||
|
|
that the line ID would be displayed with EVMON in most cases.
|
||
|
|
|
||
|
|
Now, let's say we're online, and we want to play around, and
|
||
|
|
we want to collect passcodes. We've set up our Ramdisk to normal
|
||
|
|
size and we are ready to run evmon. We could run it, sit at our
|
||
|
|
terminal, and then record the output, but it's such a time
|
||
|
|
consuming task (this is 'real-time', after all) that sitting and
|
||
|
|
waiting be nearly pointless. So, we use the handy features of
|
||
|
|
run-in-background and file-redirection. (See, I told you we were
|
||
|
|
getting 'Unix-like'.)
|
||
|
|
|
||
|
|
$ evmon > 3:/tmp/output &
|
||
|
|
Type Ctrl-C to terminate.
|
||
|
|
5e1e
|
||
|
|
$ ...
|
||
|
|
|
||
|
|
5e1e is the task ID (TID) of the new evmon process. Now we
|
||
|
|
can go off and perform whatever lists we want, or just play in
|
||
|
|
the directories, or route DobbsHeads or whatever. When we decide
|
||
|
|
to end for the day, we simply stop EVMON, nab the file, remove
|
||
|
|
it, and if necessary, dismount the ramdisk.
|
||
|
|
|
||
|
|
$ kill 5e1e
|
||
|
|
$ p 3:/tmp/output
|
||
|
|
[ EVMON output would normally appear; if, however, ]
|
||
|
|
[ there is none, the file would be deleted during ]
|
||
|
|
[ the kill with an error message resulting ]
|
||
|
|
$ rm 3:/tmp/output
|
||
|
|
$ rmdir 3:/tmp
|
||
|
|
$ mount ramdisk 3
|
||
|
|
|
||
|
|
and now we can ^D or exit out of the shell and say good-bye.
|
||
|
|
|
||
|
|
The good thing about this EVMON procedure is that you don't
|
||
|
|
need to be online while it runs. You could start a task sometime
|
||
|
|
at night and then wait until the next day before you kill the
|
||
|
|
process and check your results. This usually produces large log
|
||
|
|
files anywhere from 40K to 200K, depending upon the amount of
|
||
|
|
system usage (these figures are rough estimates). If, however,
|
||
|
|
you start the EVMON task and leave it running, then the
|
||
|
|
administrator will not be able to start a new EVMON session until
|
||
|
|
the old task is killed. While this probably shouldn't be a
|
||
|
|
problem over the weekends, during business hours it may become a
|
||
|
|
little risky.
|
||
|
|
|
||
|
|
Remember though, that the risk might be worth it, especially
|
||
|
|
if the administrator decides to check his mailbox; you'd then
|
||
|
|
have his passcode, and possibly, remote telephone access to
|
||
|
|
system administrator functions via touch-tone on the mailbox
|
||
|
|
system.
|
||
|
|
|
||
|
|
Task management:
|
||
|
|
|
||
|
|
As we have just noted, any task like EVMON can be run in the
|
||
|
|
background by appending the command line with a &, the standard
|
||
|
|
unix 'run-in-background' character. A Task ID will echo back in
|
||
|
|
hexadecimal, quite comparable to the unix Process ID. The
|
||
|
|
program responsible for task management is called 'tsk' and
|
||
|
|
should be in 1:/cmds/tsk. Output from running tsk alone should
|
||
|
|
look something like:
|
||
|
|
|
||
|
|
$ tsk
|
||
|
|
Tty Program Tid State Blk Pri Flags Grp Mem Dad Bro Son
|
||
|
|
0 task 0001 READY ---- 1 ---IPLA----- 255 255 ---- ---- ----
|
||
|
|
0 fsys 0002 RECV 0000 3 ---IPLA----- 255 255 ---- ---- ----
|
||
|
|
0 dev 0003 RECV 0000 2 ---IPLA----- 255 255 ---- ---- ----
|
||
|
|
0 idle 0004 READY ---- 15 ----PLA----- 255 255 ---- ---- 0508
|
||
|
|
0 /cmds/timer 0607 RECV 0000 2 -S--P-AC---- 255 255 ---- ---- ----
|
||
|
|
0 /cmds/err_log 0509 RECV 0000 5 -S--P--C---- 255 255 0A0A ---- ----
|
||
|
|
0 /cmds/ovrseer 0A0A REPLY 0607 5 -S--P--C---- 255 255 ---- ---- 030C
|
||
|
|
0 /cmds/recorder 010B REPLY 0509 5 -S--P--C---- 255 255 0A0A 0509 ----
|
||
|
|
0 /cmds/master 030C REPLY 0607 5 -S--P--C---- 255 255 0A0A 010B 011C
|
||
|
|
[ ... a wide assortment of programs ... ]
|
||
|
|
0 /cmds/vmemo 011C REPLY 0110 13 -S-----C---- 255 255 030C 011B ----
|
||
|
|
3 /cmds/comm 0508 RECV 5622 8 ----P-A----- 255 255 0004 ---- 5622
|
||
|
|
3 /cmds/tsk 051D REPLY 0001 8 ------------ 255 255 301E ---- ----
|
||
|
|
3 /cmds/qnxsh 301E REPLY 0001 14 ---------E-- 255 255 5622 ---- 051D
|
||
|
|
3 /cmds/login 5622 REPLY 0003 8 -------C---- 255 255 0508 ---- 301E
|
||
|
|
|
||
|
|
|
||
|
|
Although I'm not quite sure at some of the specifics
|
||
|
|
displayed in this output, the important parts are obvious. The
|
||
|
|
first column is the tty number which corresponds to the $tty list
|
||
|
|
in 'mount' (meaning that the modem I've just called is $tty3, and
|
||
|
|
I am simultaneously running four tasks from that line); the
|
||
|
|
second column is the program name (without the drive
|
||
|
|
specification); the third column is the task ID; the middle
|
||
|
|
columns are unknown to me; and the last three represent the ties
|
||
|
|
and relations to other tasks (Parent task ID, another task ID
|
||
|
|
created from the same parent, and task ID of any program called).
|
||
|
|
|
||
|
|
Knowing this, it's easy to follow the tasks we've created
|
||
|
|
since login. Initially, task 0508, /cmds/comm, was run, which
|
||
|
|
presumably contains the requisite 'what should I do know that my
|
||
|
|
user has pressed a key?' functions, which called /cmds/login to
|
||
|
|
log the user in. Login was interrupted with ^Z and one of the
|
||
|
|
shells, qnxsh, was called to handle input from the user.
|
||
|
|
Finally, the typing of 'tsk' requires that the /cmds/tsk program
|
||
|
|
be given a task ID, and the output of the program is simply
|
||
|
|
confirming that it exists.
|
||
|
|
|
||
|
|
As mentioned, to kill a task from the shell, simply type
|
||
|
|
'kill [task-id]' where [task-id] is the four digit hexadecimal
|
||
|
|
number.
|
||
|
|
|
||
|
|
There are other functions of the tsk program, as well. The
|
||
|
|
help screen lists:
|
||
|
|
|
||
|
|
$ tsk ?
|
||
|
|
use: tsk [f={cmoprst}] [p=program] [t=tty] [u=userid]
|
||
|
|
tsk code [p=program]
|
||
|
|
tsk info
|
||
|
|
tsk mem t=tid
|
||
|
|
tsk names
|
||
|
|
tsk size [p=program] [t=tty] [u=userid]
|
||
|
|
tsk ports
|
||
|
|
tsk
|
||
|
|
tsk
|
||
|
|
tsk tree [+tid] [+all] [-net]
|
||
|
|
tsk users [p=program] [t=tty] [u=userid]
|
||
|
|
tsk vcs
|
||
|
|
tsk who tid ...
|
||
|
|
options: +qnx -header +physical [n=]node s=sort_field
|
||
|
|
|
||
|
|
I haven't seen all the information available from this, yet,
|
||
|
|
as the plain 'tsk' tells me everything I need to know; however,
|
||
|
|
you may want to play around, there's no telling what secrets are
|
||
|
|
hidden...
|
||
|
|
|
||
|
|
$ tsk tsk
|
||
|
|
Tsk tsk? Have I been a bad computer?
|
||
|
|
|
||
|
|
See what I mean?
|
||
|
|
|
||
|
|
ddump:
|
||
|
|
|
||
|
|
The ddump utility is used to display the contents on a
|
||
|
|
specified blocks of the disk. It's quite simple to use.
|
||
|
|
|
||
|
|
$ ddump ?
|
||
|
|
use: ddump drive block_number [-v]
|
||
|
|
|
||
|
|
Again, I'm not quite sure what the -v switch does, but the
|
||
|
|
instructions are very straightforward. Normal output looks
|
||
|
|
similar to:
|
||
|
|
|
||
|
|
$ ddump 3 3
|
||
|
|
Place diskette in drive 3 and hit <CR> <-- this message is always
|
||
|
|
displayed by ddump.
|
||
|
|
Block 00000003 Status: 00
|
||
|
|
000: 00 00 00 00 00 00 00 00 94 00 00 00 00 00 00 00 ................
|
||
|
|
010: 01 00 01 00 40 02 00 00 00 02 00 00 00 00 00 00 ....@...........
|
||
|
|
020: 00 01 00 FF FF 00 00 97 37 29 17 00 01 01 01 30 ........7).....0
|
||
|
|
030: C4 17 8E 62 69 74 6D 61 70 00 00 00 00 00 00 00 ...bitmap.......
|
||
|
|
040: 00 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
|
|
050: 00 00 00 FF FF 00 00 A5 37 29 17 00 01 01 17 30 ........7).....0
|
||
|
|
060: C4 25 8E 6C 6C 6C 00 00 00 00 00 00 00 00 00 00 .%.lll..........
|
||
|
|
070: 00 00 00 00 50 0E 00 00 00 0E 00 00 00 00 00 00 ....P...........
|
||
|
|
080: 00 01 00 FF FF 7E 05 A8 38 29 17 00 01 01 17 30 .....~..8).....0
|
||
|
|
090: C4 28 8F 61 62 63 00 00 00 00 00 00 00 00 00 00 .(.abc..........
|
||
|
|
0A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
|
|
0B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
|
|
[...etc...]
|
||
|
|
|
||
|
|
As you can probably notice, what we have here is the
|
||
|
|
directory track for the ramdisk. It lists three files, even
|
||
|
|
though the file abc no longer exists. The actual bytes have yet
|
||
|
|
to be decoded, but, as far as the ramdisk goes, I suspect that
|
||
|
|
they'll be memory related, and not physical block related; that
|
||
|
|
is, I suspect that some of the numbers given above correspond to
|
||
|
|
the memory address of the file, and not to the actual disk-block.
|
||
|
|
So, at least for the ramdisk, finding specific files may be
|
||
|
|
difficult. However, if you only have one file one the ramdisk
|
||
|
|
besides 'bitmap' (which appears to be mandatory across all the
|
||
|
|
disks), then the next file you create should reside on track 4
|
||
|
|
and continue working it's way up. Therefore, if you have evmon
|
||
|
|
running and redirected to a file on the ramdisk, in order to
|
||
|
|
check the contents, it's not necessary to kill the process, and
|
||
|
|
restart evmon, etc. Simply 'ddump 3 4', and you could get either
|
||
|
|
useless information (all the bytes are 00 or FF), or you could
|
||
|
|
get something like:
|
||
|
|
|
||
|
|
$ ddump 3 4
|
||
|
|
Place diskette in drive 3 and hit <CR>
|
||
|
|
|
||
|
|
Block 00000004 Status: 00
|
||
|
|
000: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 ................
|
||
|
|
010: 6C 6E 20 20 32 36 20 74 74 20 33 1E 6C 6E 20 20 ln 26 tt 3.ln
|
||
|
|
020: 32 36 20 6C 69 6E 65 20 62 72 65 61 6B 1E 6C 6E 26 line break.ln
|
||
|
|
030: 20 20 32 36 20 6F 6E 68 6F 6F 6B 1E 6C 6E 20 20 26 onhook.ln
|
||
|
|
040: 32 38 20 72 69 6E 67 69 6E 67 1E 6C 6E 20 20 32 28 ringing.ln 2
|
||
|
|
050: 38 20 74 74 20 38 1E 6C 6E 20 20 32 38 20 74 74 8 tt 8.ln 28 tt
|
||
|
|
060: 20 37 1E 6C 6E 20 20 32 38 20 74 74 20 36 1E 6C 7.ln 28 tt 6.l
|
||
|
|
070: 6E 20 20 32 38 20 74 74 20 32 1E 6C 6E 20 20 32 n 28 tt 2.ln 2
|
||
|
|
080: 38 20 6F 66 66 68 6F 6F 6B 1E 6C 6E 20 20 32 38 8 offhook.ln 28
|
||
|
|
090: 20 74 74 20 2A 1E 6C 6E 20 20 32 38 20 74 74 20 tt *.ln 28 tt
|
||
|
|
|
||
|
|
... and so forth, thus making sure that the file does have
|
||
|
|
some content. Depending upon the length of that content, you
|
||
|
|
could then choose to either keep the file running, or restart
|
||
|
|
evmon and buffer the previous output.
|
||
|
|
|
||
|
|
led:
|
||
|
|
|
||
|
|
The program 'led' is Centigram's answer to a standard text
|
||
|
|
editor. It is equivalent to 'ed' in unix or 'edlin' in MSDOS,
|
||
|
|
but it does have it's minor differences. led is used to create
|
||
|
|
text files, edit, existing log files, or edit executable shell
|
||
|
|
scripts. By typing 'led [filename]', you will enter the led
|
||
|
|
editor, and if a filename is specified, and it exists, the file
|
||
|
|
will be loaded and the editor set to line 1. If there is no
|
||
|
|
filename on the command line, or the file does not exist, of the
|
||
|
|
file is busy, then led begins editing a null file, an empty
|
||
|
|
buffer, without the corresponding filename. (Commands can also
|
||
|
|
be specified to be used in led after the filename is entered. If
|
||
|
|
needed, you can experiment with this.)
|
||
|
|
|
||
|
|
Notable commands from within led:
|
||
|
|
|
||
|
|
i insert
|
||
|
|
a append
|
||
|
|
w [filename] write to disk; if no file is named, attempt to
|
||
|
|
write to current file; if there is no current
|
||
|
|
file, do not write.
|
||
|
|
d delete current line
|
||
|
|
a number goto line numbered
|
||
|
|
q quit (if not saved, inform user to use 'qq')
|
||
|
|
qq Really quit
|
||
|
|
|
||
|
|
When inserting or appending, led will prompt you with a '.'
|
||
|
|
period. To end you entry, simply enter one period alone on a
|
||
|
|
line, and you will then return to command mode. When displaying
|
||
|
|
the current entry, led will prefix
|
||
|
|
all new, updated lines, with the 'i' character.
|
||
|
|
|
||
|
|
The key sequence to enter a Dobbshead into a file and
|
||
|
|
redirect it to the console, then, would be:
|
||
|
|
|
||
|
|
$ led 3:/dobbshead3:/dobbshead : unable to match file
|
||
|
|
i ___
|
||
|
|
. / \
|
||
|
|
. | o o |
|
||
|
|
. | Y |
|
||
|
|
U===== |
|
||
|
|
\___/
|
||
|
|
FUCK YOU!
|
||
|
|
q
|
||
|
|
?4 buffer has been modified, use qq to quit without saving
|
||
|
|
w 3:/dobbshead
|
||
|
|
7 [the number of lines in the file]
|
||
|
|
q
|
||
|
|
$ p 3:/dobbshead > $cons
|
||
|
|
$ rm 3:/dobbshead
|
||
|
|
|
||
|
|
Ok, so it's not quite the Dobbshead. Fuck you.
|
||
|
|
|
||
|
|
The console utility:
|
||
|
|
|
||
|
|
The program that acts as the menu driver for the Voice Mail
|
||
|
|
System Administration, the program that is normally run upon
|
||
|
|
correct passcode entry, is /cmds/console. This program will
|
||
|
|
simply produce a menu with a variety of sub-menu's that allow
|
||
|
|
the administrator to perform a wide assortment of tasks. Since
|
||
|
|
this is mostly self-explanatory, I'll let you find out about
|
||
|
|
these functions for youself; I will, however, add just a few
|
||
|
|
comments about the console utility. The first menu received
|
||
|
|
should look like this:
|
||
|
|
|
||
|
|
(c) All Software Copyright 1983, 1989 Centigram Corporation
|
||
|
|
All Rights Reserved.
|
||
|
|
|
||
|
|
MAIN MENU
|
||
|
|
|
||
|
|
(R) Mailbox maintenance
|
||
|
|
(R) Report generation
|
||
|
|
(S) System maintenance
|
||
|
|
(X) Exit
|
||
|
|
|
||
|
|
Enter letter in () to execute command.
|
||
|
|
When you need help later, type ?.
|
||
|
|
|
||
|
|
COMMAND (M/R/S/X):
|
||
|
|
|
||
|
|
The mailbox maintenance option is used when you want to
|
||
|
|
find specific information concerning mailboxes on the system.
|
||
|
|
For instance, to get a listing of all the mailboxes currently
|
||
|
|
being used on the system:
|
||
|
|
|
||
|
|
COMMAND (M/R/S/X): m
|
||
|
|
|
||
|
|
MAILBOX MAINTENANCE
|
||
|
|
|
||
|
|
(B) Mailbox block inquiry
|
||
|
|
(C) Create new mailboxes
|
||
|
|
(D) Delete mailboxes
|
||
|
|
(E) Mailbox dump
|
||
|
|
(I) Inquire about mailboxes
|
||
|
|
(L) List maintenance
|
||
|
|
(M) Modify mailboxes
|
||
|
|
(P) Set passcode/tutorial
|
||
|
|
(R) Rotational mailboxes
|
||
|
|
(S) Search for mailboxes
|
||
|
|
(X) Exit
|
||
|
|
|
||
|
|
If you need help later, type ?.
|
||
|
|
|
||
|
|
COMMAND (B/C/D/E/I/L/M/P/R/S/X): i
|
||
|
|
Report destination (c/s1/s2) [c]:
|
||
|
|
|
||
|
|
Mailbox to display: 0000-9999
|
||
|
|
|
||
|
|
>>> BOBTEL <<<
|
||
|
|
Mailbox Data Inquiry
|
||
|
|
Tue Mar 31, 1992 3:07 am
|
||
|
|
|
||
|
|
Box Msgs Unp Urg Rec Mins FCOS LCOS GCOS NCOS MWI Passwd
|
||
|
|
8001 1 1 0 0 0.0 5 5 1 1 None Y
|
||
|
|
8002 0 0 0 0 0.0 5 5 1 1 None Y (t)
|
||
|
|
8003 0 0 0 0 0.0 12 12 1 1 None
|
||
|
|
0 0 0.0 12 12 1 1 None Y
|
||
|
|
8006 6 6 0 0 0.7 12 12 1 1 None N
|
||
|
|
8008 0 0 0 0 0.0 5 5 1 1 None Y
|
||
|
|
8013 0 0 0 0 0.0 12 12 1 1 None 1234
|
||
|
|
8014 0 0 0 0 0.0 5 5 1 1 None Y
|
||
|
|
8016 0 0 0 0 0.0 12 12 1 1 None Y
|
||
|
|
[ ... etc ... ]
|
||
|
|
|
||
|
|
This simply lists every box along with the relevant
|
||
|
|
information concerning are the
|
||
|
|
Total number of messages, number of unplayed messages, number of
|
||
|
|
urgent messages, and number of received messages currently being
|
||
|
|
stored on the drive for the mailbox; Mins is the numbers of
|
||
|
|
minutes currently being used by those messages; F, L, G, and
|
||
|
|
NCOS are various classes of service for the mailboxes; MWI is
|
||
|
|
the message waiting indicator, or service light; and Passwd is
|
||
|
|
simply a Yes/No condition informing the administrator whether
|
||
|
|
the mailbox currently has a password. The'(t)' the password
|
||
|
|
field means the box is currently in tutorial mode, and the '1234'
|
||
|
|
that replaces the Y/N condition, I assume, means the box is set
|
||
|
|
to initial tutorial mode with simple passcode 1234 -- in other
|
||
|
|
words the box is available to be used by a new subscriber.
|
||
|
|
Mailboxes with FCOS of 1 should be looked for, these represent
|
||
|
|
administration or service mailboxes, although they are not
|
||
|
|
necessarily capable of performing system administration
|
||
|
|
functions.
|
||
|
|
|
||
|
|
The System maintenance option from the main menu is very
|
||
|
|
useful in that, if you don't have access to the qnxsh, you can
|
||
|
|
still run a number of tasks or print out any file you wish from
|
||
|
|
within the menu system. The System Mainenance menu looks like:
|
||
|
|
|
||
|
|
SYSTEM MAINTENANCE
|
||
|
|
|
||
|
|
(A) Automatic Wakeup
|
||
|
|
(B) Automated Receptionist Extensions
|
||
|
|
(D) Display modem passcode
|
||
|
|
(E) Enable modem/serial port
|
||
|
|
(F) Floppy backup
|
||
|
|
(G) Resynchronize HIS PMS room status
|
||
|
|
(H) Hard Disk Utilities
|
||
|
|
(L) Lights test
|
||
|
|
(M) Manual message purge
|
||
|
|
(N) System name
|
||
|
|
(P) Passcode
|
||
|
|
(R) Reconfiguration
|
||
|
|
(S) System shutdown
|
||
|
|
(T) Time and date
|
||
|
|
(U) Utility menu
|
||
|
|
(V) Call Detail Recorder
|
||
|
|
(W) Network menu
|
||
|
|
(X) Exit
|
||
|
|
|
||
|
|
Enter letter in () to execute command.
|
||
|
|
When you need help later, type ?.
|
||
|
|
|
||
|
|
COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X):
|
||
|
|
|
||
|
|
If you don't have access to the 'p' command, you can still
|
||
|
|
display any specific file on the drive that you wish to see.
|
||
|
|
Choose 'v', the Call Detail Recorder option, from above, and you
|
||
|
|
will get this menu:
|
||
|
|
|
||
|
|
COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): v
|
||
|
|
Warning: cdr is not running.
|
||
|
|
|
||
|
|
CALL DETAIL RECORDER MENU
|
||
|
|
|
||
|
|
(C) Configure CDR
|
||
|
|
(R) Run CDR
|
||
|
|
(T) Terminate CDR
|
||
|
|
(E) Run EVMON
|
||
|
|
(F) Terminate EVMON
|
||
|
|
(S) Show CDR log file
|
||
|
|
(D) Delete CDR log file
|
||
|
|
(X) Exit
|
||
|
|
|
||
|
|
If you need help later, type ?.
|
||
|
|
|
||
|
|
COMMAND (C/R/T/E/F/S/D/X):
|
||
|
|
|
||
|
|
From here, you can use (C) Configure CDR to set the log
|
||
|
|
file to any name that you want, and use (S) to print that file
|
||
|
|
to your terminal.
|
||
|
|
|
||
|
|
COMMAND (C/R/T/E/F/S/D/X): c
|
||
|
|
|
||
|
|
Answer the following question to configure call detail recorder
|
||
|
|
[ simply hit return until the last 'filename' question come up ]
|
||
|
|
VoiceMemo line numbers enabled:
|
||
|
|
HOST 1 lines:
|
||
|
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
||
|
|
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
|
||
|
|
VoiceMemo line numbers:
|
||
|
|
|
||
|
|
EVMON: HOST 1 lines to monitor:
|
||
|
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
||
|
|
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
|
||
|
|
EVMON:VoiceMemo line numbers:
|
||
|
|
Message levels are:
|
||
|
|
1: Detailed VoiceMemo
|
||
|
|
2: VoiceMemo
|
||
|
|
3: Pager
|
||
|
|
4: Receptionist
|
||
|
|
5: EVMON
|
||
|
|
6: Automatic WakeUp
|
||
|
|
7: Open Account Administrator
|
||
|
|
8: DTMF to PBX
|
||
|
|
9: Message Waiting Lamp
|
||
|
|
10: SL-1 integration
|
||
|
|
11: Centrex Integration
|
||
|
|
Message levels enabled:
|
||
|
|
2 3 7 9
|
||
|
|
Message levels:
|
||
|
|
cdr enable = [N]
|
||
|
|
Enter filename to save log data = [/logfile] /config/remote.cmds
|
||
|
|
|
||
|
|
Returning from the CDR configuration.
|
||
|
|
|
||
|
|
CALL DETAIL RECORDER MENU
|
||
|
|
|
||
|
|
(C) Configure CDR
|
||
|
|
(R) Run CDR
|
||
|
|
(T) Terminate CDR
|
||
|
|
(E) Run EVMON
|
||
|
|
(F) Terminate EVMON
|
||
|
|
(S) Show CDR log file
|
||
|
|
(D) Delete CDR log file
|
||
|
|
(X) Exit
|
||
|
|
|
||
|
|
If you need help later, type ?.
|
||
|
|
|
||
|
|
COMMAND (C/R/T/E/F/S/D/X): s
|
||
|
|
ad
|
||
|
|
cd
|
||
|
|
copy
|
||
|
|
date
|
||
|
|
dskchk
|
||
|
|
evmon
|
||
|
|
files
|
||
|
|
ls
|
||
|
|
mount
|
||
|
|
p
|
||
|
|
pwd
|
||
|
|
query
|
||
|
|
task
|
||
|
|
tcap
|
||
|
|
what
|
||
|
|
|
||
|
|
Don't forget to return the filename back to it's original
|
||
|
|
name, as shown in the [] field, after you have finished.
|
||
|
|
|
||
|
|
If you don't have access to the shell, you can also run
|
||
|
|
EVMON, from the CDR menu, using option E. It will simply start
|
||
|
|
the evmon process displaying to your terminal, interruptable by
|
||
|
|
the break character, ^C. This, unfortunately, cannot be
|
||
|
|
redirected or run in the background as tasks running from the
|
||
|
|
shell can. If, however, you have some time to kill you may want
|
||
|
|
to play with it.
|
||
|
|
|
||
|
|
Also from the System Maintenance menu, you can perform a
|
||
|
|
number of shell tasks without direct access to the shell. Option
|
||
|
|
(U), Utilities Menu, has an option called Task. This will allow
|
||
|
|
you limited shell access, possibly with redirection and '&' back-
|
||
|
|
grounding.
|
||
|
|
|
||
|
|
COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): U
|
||
|
|
|
||
|
|
UTILITY MENU
|
||
|
|
|
||
|
|
(B) Reboot
|
||
|
|
(H) History
|
||
|
|
(T) Task
|
||
|
|
(X) Exit
|
||
|
|
|
||
|
|
Enter letter in () to execute command.
|
||
|
|
When you need help later, type ?.
|
||
|
|
|
||
|
|
COMMAND (B/H/T/X): t
|
||
|
|
|
||
|
|
Choose the following commands:
|
||
|
|
ad cd copy date
|
||
|
|
dskchk evmon files ls
|
||
|
|
mount p pwd query
|
||
|
|
task tcap what
|
||
|
|
|
||
|
|
Enter a command name or 'X' to exit: pwd
|
||
|
|
1:/
|
||
|
|
|
||
|
|
Choose the following commands:
|
||
|
|
ad cd copy date
|
||
|
|
dskchk evmon files ls
|
||
|
|
mount p pwd query
|
||
|
|
task tcap what
|
||
|
|
|
||
|
|
Enter a command name or 'X' to exit: evmon
|
||
|
|
Type Ctrl-C to terminate.
|
||
|
|
ln 29 ringing
|
||
|
|
ln 29 tt 8
|
||
|
|
ln 29 tt 0
|
||
|
|
ln 29 tt 8
|
||
|
|
ln 29 tt 6
|
||
|
|
ln 29 offhook
|
||
|
|
ln 29 record ended
|
||
|
|
[ ... etc ... ]
|
||
|
|
|
||
|
|
A look at 'ad':
|
||
|
|
|
||
|
|
The program 'ad' is called to dump information on a variety
|
||
|
|
of things, the most useful being mailboxes. Dumps of specific
|
||
|
|
information about a mailbox can be done either in Mailbox format,
|
||
|
|
or Raw Dump format. Mailbox format looks like:
|
||
|
|
|
||
|
|
$ ad
|
||
|
|
Type #: 0
|
||
|
|
Mailbox #: 8486
|
||
|
|
(M)ailbox, (D)ump ? m
|
||
|
|
|
||
|
|
MAILBOX: 8486
|
||
|
|
|
||
|
|
Login status:
|
||
|
|
Bad logs = 3 Last log = 03/26/92 12:19 pmVersion = 0
|
||
|
|
|
||
|
|
Configuration:
|
||
|
|
Name # = 207314 Greeting = 207309 Greeting2 = 0
|
||
|
|
Passcode = XXXXXXXXXX Tutorial = N Extension = 8486
|
||
|
|
Ext index = 0 Attendant = Attend index = 0
|
||
|
|
Code = ID = BOBTECHM Night_treat = M Fcos = 12 Lcos = 12 Gcos = 1 Ncos = 1 Rot index = 0 Rot period = 0 Rot start = -- wkup defined = N wkup freq = 0 wkup_intvl = 0 wkup index = 0 wkup number =Contents: Motd_seq = 8 Motd_played = N User_msgs = 0 Caller_msgs = 4 Sent_cpx_msgs= 0 Sent_
|
||
|
|
fdx_msgs= 0
|
||
|
|
Sent_urg_msgs= 0 Tas_msgs = 0 Pages = 0
|
||
|
|
Receipt = 0 Sent_to_node = 0 Urg_to_node = 0
|
||
|
|
Net_urg_mlen = 0 Net_msgs_rcv = 0 Net_urg_rcv = 0
|
||
|
|
Net_sent_node= 0 Net_send_nurg= 0 Net_send_rcp = 0
|
||
|
|
Greet_count = 9 Successlogins= 1 Recpt_calls = 0
|
||
|
|
Recpt_complt = 0 Recpt_busy = 0 Recpt_rna = 0
|
||
|
|
Recpt_msgs = 0 Recpt_attend = 0 User_connect = 20
|
||
|
|
Clr_connect = 22 Callp_connect= 0 Disk_use = 498
|
||
|
|
Net_sent_mlen= 0 Net_rcvd_mlen= 0 Net_rcvd_urg = 0
|
||
|
|
Net_node_mlen= 0 Net_recip_mlen=0 Net_node_urg = 0
|
||
|
|
Text_msg_cnt = 0
|
||
|
|
|
||
|
|
|
||
|
|
Message Queues:
|
||
|
|
TYPE COUNT TOTAL HEAD TAIL TYPE COUNT TOTAL HEAD TAIL
|
||
|
|
Free 71 --- 58 55 Unplayed 0 --- -1 -1
|
||
|
|
Played 2 0.5 56 57 Urgent 0 --- -1 -1
|
||
|
|
Receipts 0 --- -1 -1 Undelivered 0 --- -1 -1
|
||
|
|
Future delivery 0 --- -1 -1 Call placement 0 --- -1 -1
|
||
|
|
|
||
|
|
Messages: 2
|
||
|
|
# msg # DATE TIME LENGTH SENDER PORT FLAGS MSG SIBL
|
||
|
|
(MINS) NXT PRV NXT PRV
|
||
|
|
Played Queue
|
||
|
|
56 207126 03/26/92 12:17 pm 0.5 000000000000000 27 ------P- 57 -1 -1 -1
|
||
|
|
|
||
|
|
57 207147 03/26/92 12:19 pm 0.1 000000000000000 29 ------P- -1 56 -1 -1
|
||
|
|
|
||
|
|
The Ramp format looks like:
|
||
|
|
$ ad
|
||
|
|
Type #: 0
|
||
|
|
Mailbox #: 8487
|
||
|
|
(M)ailbox, (D)ump ? d
|
||
|
|
|
||
|
|
HEX: 8487
|
||
|
|
000: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 34 38 |..............48|
|
||
|
|
030: 37 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |7...............|
|
||
|
|
040: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
050: 00 00 00 00 00 00 00 00 - 00 00 42 49 4f 54 45 43 |..........BOBTEC|
|
||
|
|
060: 48 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |H...............|
|
||
|
|
070: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
080: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 37 32 33 |.............723|
|
||
|
|
090: 36 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |6...............|
|
||
|
|
0a0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
0b0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
0c0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 |................|
|
||
|
|
[mostly deleted -- the list continues to hex fff.]
|
||
|
|
|
||
|
|
One of the unfortunate aspects is that the password is not
|
||
|
|
displayed in the Mailbox format (Awwww!). I can tell you now,
|
||
|
|
though, that it also isn't displayed anywhere in the Raw Dump
|
||
|
|
format. The program 'asetpass' was used to change the password
|
||
|
|
of a test mailbox, and both full dumps were downloaded and
|
||
|
|
compared; they matched exactly. So, it looks like the passcodes
|
||
|
|
are probably stored somewhere else, and the dump simply contains
|
||
|
|
a link to the appropriate offset; which meansthe only way, so
|
||
|
|
far, to get passcodes for mailboxes is to capture them in EVMON.
|
||
|
|
|
||
|
|
Intricacies of the login program:
|
||
|
|
|
||
|
|
The console login program is 1:/cmds/login. Although I
|
||
|
|
can't even recognize any valid 8080 series assembly in the
|
||
|
|
program (and I'm told the Centigram boxes run on the 8080
|
||
|
|
family), I did manage to find a few interesting tidbits inside of
|
||
|
|
it. Firstly, the console and remote passwords seems to be stored
|
||
|
|
in the file /config/rates; unfortunately, it's encrypted and I'm
|
||
|
|
not going to try to break the scheme. /config/rates looks like
|
||
|
|
this:
|
||
|
|
|
||
|
|
$ p /config/rates
|
||
|
|
\CE\FFC~C~\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00
|
||
|
|
\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\00\00\00\00\00\00\00
|
||
|
|
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
|
||
|
|
|
||
|
|
Accepting the \CE as some sort of control byte, this file is
|
||
|
|
divided up into about eight empty sections of five bytes a piece,
|
||
|
|
mostly null, indicating that, possibly, there are a number of
|
||
|
|
acceptable passcode combinations, or a number of different
|
||
|
|
functions with different passcodes. In this instance, only one
|
||
|
|
passcode appears to be selected. I am still unsure, however,
|
||
|
|
whether this is actually a password file, or a file that would
|
||
|
|
acts as a pointer to another space on the disk which contains the
|
||
|
|
actual password. I would assume, for this login program, that it
|
||
|
|
is actually an encrypted password.
|
||
|
|
|
||
|
|
Another very interesting thing sleeping within the confines
|
||
|
|
of the login program is the inconspicuous string 'QNX'. It sits
|
||
|
|
in the code between two 'Enter Passcode:' prompts, separated by
|
||
|
|
\00's. I believe this to be a system-wide backdoor placed into
|
||
|
|
the login program by Centigram, Corp. Such a thing does exist;
|
||
|
|
whenever Centigram wants to get into a certain mailbox system to
|
||
|
|
perform maintenance or solve a problem, they can. They may,
|
||
|
|
however, require the Serial number of the machine or of the Hard
|
||
|
|
Drive, in order to get this access. (This serial number would be
|
||
|
|
provided by the company requiring service.)
|
||
|
|
|
||
|
|
When logging in with QNX, a very strange thing happens.
|
||
|
|
|
||
|
|
(^Z)
|
||
|
|
Enter Passcode: (QNX^M) Enter Passcode:
|
||
|
|
|
||
|
|
A second passcode prompt appears, a prompt in which the
|
||
|
|
'QNX' passcode produces an Invalid Passcode message. I believe
|
||
|
|
that when Centigram logs in from remote, they use this procedure,
|
||
|
|
along with either a predetermined passcode, or a passcode
|
||
|
|
determined based on a serial number, to access the system. I
|
||
|
|
have not ever seen this procedure actually done, but it is the
|
||
|
|
best speculation that I can give.
|
||
|
|
|
||
|
|
I should also make note of a somewhat less important point.
|
||
|
|
Should the console have no passcodes assigned, a simple ^Z for
|
||
|
|
terminal activation will start the /cmds/console program, and
|
||
|
|
log the user directly in without prompting for a passcode. The
|
||
|
|
odds on finding a Centigram like this, nowadays, is probably as
|
||
|
|
remote as being struck by lightning, but personally, I can recall
|
||
|
|
a time a number of years back when a Florida company hadn't yet
|
||
|
|
passcode protected a Centigram. It was very fun to have such a
|
||
|
|
large number of people communicating back and forth in normal
|
||
|
|
voice; it was even more fun to hop on conferences with a number
|
||
|
|
of people and record the stupidity of the average Bell operator.
|
||
|
|
|
||
|
|
Special Keys or Strings:
|
||
|
|
|
||
|
|
There are a number of special characters or strings that are
|
||
|
|
important to either the shell or the program being executed.
|
||
|
|
Some of these are:
|
||
|
|
|
||
|
|
? after the program name, gives help list for that program.
|
||
|
|
& runs a task in the background
|
||
|
|
: sets the comment field (for text within shell scripts)
|
||
|
|
; command delimiter within the shell
|
||
|
|
> redirects output of a task to a file
|
||
|
|
< (theoretically) routes input from a file
|
||
|
|
$cons the 'filename' of the console (redirectable)
|
||
|
|
$tty# the 'filename' of tty number '#'
|
||
|
|
$mdm the 'filename' of the modem line
|
||
|
|
#$ ? produces a value like '1920', '321d'
|
||
|
|
probably the TID of the current process
|
||
|
|
## ? produces a value like 'ffff'
|
||
|
|
#% ? produces a value like '0020', '001d'
|
||
|
|
#& ? produces a value like '0000'
|
||
|
|
#? ? produces a value like '0000'
|
||
|
|
#* a null argument
|
||
|
|
#g ? produces a value like '00ff'
|
||
|
|
#i directly followed by a number, produces '0000'
|
||
|
|
not followed, produces the error 'non-existent integer
|
||
|
|
variable' probably used in conjunction with environment
|
||
|
|
variables
|
||
|
|
#k accepts a line from current input (stdin) to be
|
||
|
|
substituted on the command line
|
||
|
|
#m ? '00ff'
|
||
|
|
#n ? '0000'
|
||
|
|
#p ? '0042'
|
||
|
|
#s produces the error 'non-existent string variable'
|
||
|
|
probably used in conjunction with environment variables
|
||
|
|
#t ? '0003'
|
||
|
|
#u ? some string similar to 'system'
|
||
|
|
#D ? '0018'
|
||
|
|
#M ? '0004'
|
||
|
|
#Y ? '005c'
|
||
|
|
|
||
|
|
"Notes on Centigram Voice Mail system Consoles" was written
|
||
|
|
anonymously. There are no group affiliations tied to this file.
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
NIA074 / File 05
|
||
|
|
|
||
|
|
How to steal Information
|
||
|
|
|
||
|
|
The Butler...
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
Now that we have entered the "Information Age" we must realize that
|
||
|
|
information is an asset worth protecting. The problem is that what
|
||
|
|
some people consider trash others view as gold. That is why on any
|
||
|
|
given day you can find mounds of valuable information in most
|
||
|
|
companies trashcans, employees desks, and on floppy disks lying
|
||
|
|
around the office. This article will focus on the different ways
|
||
|
|
of gaining access to that information which is most often left
|
||
|
|
unprotected.
|
||
|
|
|
||
|
|
To begin with I will discuss the most vulnerable aspect of any
|
||
|
|
security plan, people. Individuals are the weakest link in any
|
||
|
|
security system whether it be a guard check point or a CN/A
|
||
|
|
operator, the reason this is so is because when ever a human is
|
||
|
|
brought into the picture to determine whether or not to give access
|
||
|
|
or information to another human more often than not a judgement
|
||
|
|
call has to be made. As human beings we have feelings like sorrow
|
||
|
|
and pity to deal with, and those feelings can and are exploited.
|
||
|
|
|
||
|
|
Now lets say you wanted to gain access to a certain building that
|
||
|
|
required some sort of Key-Card to open the door. With out having
|
||
|
|
one yourself you could either 1) steal one, 2) make your own, or 3)
|
||
|
|
walk in behind someone else who does have one. Number 3 is the one
|
||
|
|
I want to expand on here. I have used this method myself, for
|
||
|
|
legitimate purposes of course. By looking like you belong in said
|
||
|
|
building and waiting by the door with a confused and sad look on
|
||
|
|
your face you could say to someone "I left my Key-Card at home" and
|
||
|
|
just walk in behind them. Now this probably wouldn't work at a
|
||
|
|
small company but more likely at a large institution with several
|
||
|
|
entrances, use the back door! When I said look like you belong I
|
||
|
|
mean dress accordingly. i.e. to go to a high tech software company
|
||
|
|
you should be wearing a suit with a briefcase in hand. Just in
|
||
|
|
case why don't you case the establishment for a few days before
|
||
|
|
your attempt and make note of what the majority of employees are
|
||
|
|
wearing.
|
||
|
|
|
||
|
|
Another scenario could be at a industrial firm that you were
|
||
|
|
interested in. In this case we will try and play on another human
|
||
|
|
feeling, greed. Chances are in this situation the individuals
|
||
|
|
responsible for any and all computers are, well less than computer
|
||
|
|
literate. You could send them a letter in the mail advertising a
|
||
|
|
free cleaning and inspection of all personal computers on the
|
||
|
|
premises. This is an excellent way of gathering information from
|
||
|
|
heavily industrialized companies. Usually places where computers
|
||
|
|
are practically on the factory floor will be more than happy to let
|
||
|
|
you clean their machines. While doing so just copy to your hearts
|
||
|
|
content, or if you are adventurous you could take a portable and
|
||
|
|
connect it via a serial port or whatever and copy the entire hard
|
||
|
|
drive. Just tell them you are running some diagnostics.
|
||
|
|
|
||
|
|
The last scenario I will cover is another example of disguising
|
||
|
|
yourself. I know this one works and it seems that people are doing
|
||
|
|
it quite frequently. Just get a job with a janitorial firm and
|
||
|
|
sneak away from the actual work to do your bidding.
|
||
|
|
|
||
|
|
After gaining access to any company by whatever means you have to
|
||
|
|
know where to look. To begin with go to the largest office you can
|
||
|
|
find, usually in a corner with a good view. These prime offices
|
||
|
|
usually belong to those in the upper echelon of the company. Once
|
||
|
|
in the office you obviously should start with computers since you
|
||
|
|
can copy electronic information easier than hardcopy. Next you
|
||
|
|
should turn to the desk drawer and file cabinets in the office.
|
||
|
|
Check the rolodex for dialup #'s and passwords. Basically don't
|
||
|
|
leave any stone unturned. Depending on what you are looking for
|
||
|
|
you might want to start out in the Data Processing department since
|
||
|
|
their computers are the heart of the whole business. From there
|
||
|
|
you can plant trojan horses, copy proprietary software, or steal
|
||
|
|
specific data.
|
||
|
|
|
||
|
|
Some other means of disguise:
|
||
|
|
|
||
|
|
PC Repair Shop Technician
|
||
|
|
Software Demonstrator
|
||
|
|
|
||
|
|
All of the above items can be used for completely legal purposes
|
||
|
|
also.
|
||
|
|
|
||
|
|
The above have all been physical means of gathering information,
|
||
|
|
now lets turn to other ways.
|
||
|
|
|
||
|
|
|
||
|
|
Van Eck
|
||
|
|
|
||
|
|
With the proper equipment it is possible to capture every
|
||
|
|
electronic pulse that is sent out from a keyboard or a monitor
|
||
|
|
while you are hidden far away from the actual activity. The U.S.
|
||
|
|
Government calls this the Tempest project. If you are ever in a
|
||
|
|
government office just take a look at their computers. I know that
|
||
|
|
the armed services have all of their computers protected by heavy
|
||
|
|
metal shielding around all computers, even pc's in army recruiting
|
||
|
|
stations. Check the loompatics(sp) catalog for a book called Van-
|
||
|
|
-Eck Phreaking, it explains the whole process and the equipment
|
||
|
|
needed. This method would generally be used to steal usernames and
|
||
|
|
passwords.
|
||
|
|
|
||
|
|
|
||
|
|
Network Protocol Analyzers
|
||
|
|
|
||
|
|
If you have access to a Local Area Network you might already have
|
||
|
|
one of these puppies. A Network protocol analyzer is a device that
|
||
|
|
lets you examine every packet that is sent out over a network. I
|
||
|
|
am talking about Novell, Banyan and 3COM networks if you are
|
||
|
|
wondering. By using one of these you can capture every byte that
|
||
|
|
travels from any given workstation to the file server. This
|
||
|
|
equipment is very expensive but could well be worth it depending on
|
||
|
|
what you are after. This method could be used to steal everything
|
||
|
|
from usernames and passwords to actual data.
|
||
|
|
|
||
|
|
|
||
|
|
Keyboard & Monitor Capture program
|
||
|
|
|
||
|
|
I have never done this but I think it could be possible to write a
|
||
|
|
program (a trojan) that would capture everything that is entered
|
||
|
|
from the keyboard and everything that goes across the monitor and
|
||
|
|
save it in a hidden file somewhere on a network.
|
||
|
|
|
||
|
|
|
||
|
|
Old Reliable--Social Engineering
|
||
|
|
|
||
|
|
Now (with a known bug) we can social engineer electronically via
|
||
|
|
E-mail. The Telnet bug which allows you to send a message to
|
||
|
|
someone without them knowing the source can be very useful.
|
||
|
|
Unlimited applications.....And there is always the telephone for
|
||
|
|
the same purpose. Just make up a story and try it out. The
|
||
|
|
obvious "Hello I am the Sysop please change your password to ____"
|
||
|
|
is not what I am talking about. You need to be more creative like
|
||
|
|
posing as a salesman or a surveyor to get information that will
|
||
|
|
make your "Crack" easier.
|
||
|
|
|
||
|
|
|
||
|
|
I hope this helps you with your quest for knowledge!!!
|
||
|
|
|
||
|
|
|
||
|
|
The Butler...
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
||
|
|
|
||
|
|
NIA074 / File 07
|
||
|
|
|
||
|
|
Invisible Killer Chips Now Availible
|
||
|
|
|
||
|
|
Jean-Bernard Condat
|
||
|
|
General Secretary
|
||
|
|
Chaos Computer Club France
|
||
|
|
B.P. 8005
|
||
|
|
69351 Lyon Cedex 08, France
|
||
|
|
Tel.: +33 78 61 15 88
|
||
|
|
|
||
|
|
Intelligence Newsletter (10 rue du Sentier, 75002 Paris, France)
|
||
|
|
No. 186 (Jan. 29, 1992), page 2, ISSN 0997-7139
|
||
|
|
By: Jean-Bernard Condat (CCCF, B.P. 8005, 69351 Lyon Cedex 08, France)
|
||
|
|
|
||
|
|
|
||
|
|
The military use of computer viruses is often overblown, if not just
|
||
|
|
simple disinformation as in the recent Iraqi case. But researchers at
|
||
|
|
Boston University have developed and patented (U.S. patent 5 049 775)
|
||
|
|
an infinitely more offensive and effective anti-computer agent: the
|
||
|
|
silicon ant. Micro-electronics has perfected technologies for making
|
||
|
|
toys and machines so small that they are invisible.
|
||
|
|
|
||
|
|
Using piezoelectric ceramics which expand or contract under an
|
||
|
|
electric current, the researchers constructed a microscopic ship with
|
||
|
|
three "legs" on each side and a "cutter" in front. By alternating
|
||
|
|
current in different sides of each "leg", it bends forward or backward.
|
||
|
|
|
||
|
|
Under remote control the killer chips can be "walked" into a computer
|
||
|
|
and cut up other microscopic chips, turn around and "walk" away, leaving
|
||
|
|
invisible damage in the computer system. The killer chips could be solar
|
||
|
|
powered and therefore have an indefinite life-span.
|
||
|
|
|
||
|
|
|
||
|
|
PATENT DESCRIPTION
|
||
|
|
|
||
|
|
|
||
|
|
008245420 WPI Acc No: 90-132421/17
|
||
|
|
XRPX Acc No: N90-102550
|
||
|
|
Piezoelectric micro-machine or robot basic operating unit - made by
|
||
|
|
covering silicon cantilever beams projecting from frame with
|
||
|
|
piezoelectric material when applied voltages cause them to deflect
|
||
|
|
Patent Assignee: (UYBO-) BOSTON UNIV
|
||
|
|
Author (inventor): SMITS J G
|
||
|
|
Number of Patents: 002
|
||
|
|
Patent Family:
|
||
|
|
CC Number Kind Date Week
|
||
|
|
WO 9003665 A 900405 9017 (Basic)
|
||
|
|
US 5049775 A 910917 9140
|
||
|
|
Priority Data (CC,No,Date): US 251565 (880930);
|
||
|
|
Applications (CC,No,Date): WO 89US4129 (890921);
|
||
|
|
EP and/or WO Language: English
|
||
|
|
EP and/or WO Cited Patents:
|
||
|
|
No.SR.Pub
|
||
|
|
Designated States (National): JP (Regional): AT; BE; CH; DE; FR; GB; IT; LU
|
||
|
|
; NL; SE
|
||
|
|
Abstract (Basic): WO 9003665
|
||
|
|
An electrical micromachine is made by securing films (20,22) of
|
||
|
|
piezoelectric material to the top surfaces (16,18) of crystalline
|
||
|
|
silicon beams (12,14) projecting from a crystalline silicon body (10)
|
||
|
|
to form a bimorph structure. A potential applied across the ends
|
||
|
|
(24,26) of the piezoelectric films causes the beams to deflect. The
|
||
|
|
piezoelectric material used is zinc oxide.
|
||
|
|
A number of such micromachines can be assembled to form a robot,
|
||
|
|
and when a foot (30) is provided the machine can move itself along a
|
||
|
|
surface by sequential deflecting and straightening of the beams. The
|
||
|
|
foot can be associated with a toothed wheel to produce rotary motion.
|
||
|
|
The micromachine may be solar powered, and can be associated with
|
||
|
|
sensors or a microprocessor with programmable memory.
|
||
|
|
USE - Microsurgical tools, and robots for grasping, carrying or
|
||
|
|
cutting tasks. @(33pp Dwg.No.1/10)@
|
||
|
|
Abstract (US): 9140 US 5049775
|
||
|
|
The piezoelectric actuation machine comprises two cantilever beams
|
||
|
|
extending from a frame. The beams comprise a piezoelectric material
|
||
|
|
such that application of an electric potential across the material of
|
||
|
|
each beam rotationally diplaces the first and second beams relative to
|
||
|
|
each other.
|
||
|
|
An actuating member is secured between displaceable surfaces on
|
||
|
|
the beams and extends orthogonally from a plane through the beams such
|
||
|
|
that relative displacement of the beams displaces a portion of the
|
||
|
|
member in a direction orthogonal to beam displacement. A rigid object
|
||
|
|
contacting the displaced portion of the member is translated relative
|
||
|
|
to the member and the frame.
|
||
|
|
USE - For piezoelectric micromachines e.g. small robot or
|
||
|
|
cutting tool. @(17pp)@
|
||
|
|
File Segment: EPI
|
||
|
|
Derwent Class: S05; V06; X25; R46;
|
||
|
|
Int Pat Class: H01L-041/09
|
||
|
|
Manual Codes (EPI/S-X): S05-B; V06-M06D; X25-A03E
|
||
|
|
|
||
|
|
[Editor's Note: I have not investigated to see if this patent really does
|
||
|
|
exist due to the timing of the article so close to the release date. This
|
||
|
|
is a rush-in and I am basing all of its credibility to Chaos Computer
|
||
|
|
Club France (CCCF) and Jean-Bernard Condat.]
|
||
|
|
|
||
|
|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|
||
|
|
|
||
|
|
|