The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 3 Issue 26

Saturday, 26 July 1986

Contents

o DIVAD
Herb Lin
o Royal wedding risks -- common change modes
Don Chiasson
o Security and dialbacks
David I. Emery via Herb Lin
o Info on RISKS (comp.risks)

DIVAD

<LIN@XX.LCS.MIT.EDU>
Sat, 26 Jul 1986 00:39 EDT
Some time ago there was a flap about whether or not DIVAD did or did not
shoot at a latrine fan.  [See Doug Schuler in RISKS-3.1, with subsequent
discussion in RISKS-3.3, 4, 5.]  I have documentation now from a person who
should know: Richard DeLauer, former Undersecretaty of Defense for Research
and Engineering in the first Reagan term.  He says it did, and that it was
supposed to do that.  See [MIT] Technology Review, July 1986, page 64.


Royal wedding risks -- common change modes

Don Chiasson <CHIASSON@DREA-XX.ARPA>
Fri 25 Jul 86 10:25:41-ADT
    Phenomena like this are well known by the CEGB (Central Electricity
Generating Board) engineers.  Operation of a power grid assumes that the
load does not change suddenly, indeed sudden changes can cause instability.
Anyway, it is well known in the U.K. (I'm not sure about the U.S. and
Canada) that the largest power surge is at the end of Coronation Street, or
one of the other soaps, when everyone gets up from the Telly and plugs in
the kettle to make tea.  I assume that's what happened at the end of the
wedding telecast.

    A similar thing happened in the U.S. a couple of years ago.  I
think it was somewhere in New Mexico or Arizona that there was a pause in
the super bowl game so a lot of people got up, went to the bathroom (all
that beer) and flushed at nearly the same time which caused some sewer
backups.
        Don Chiasson


Security and dialbacks

<LIN@XX.LCS.MIT.EDU>
Fri, 25 Jul 1986 09:46 EDT
 MSG:  *MSG   5759  
 Date: 24 Jul 86 12:22:30 GMT
 From: frog!die at EDDIE.MIT.EDU (Dave Emery, Software)
 Re:   Security and dialbacks
 DISTRIB: *BBOARD

 Summary: Dialbacks aren't very secure (repost of old article)
 Apparently-To: codebreakers

 In article <906@hoptoad.uucp> gnu@hoptoad.UUCP writes:
 >Here are the two messages I have archived on the subject...

 >[I believe the definitive article in that discussion was by Lauren Weinstein,
 >vortex!lauren; perhaps he has a copy.

    What follows is the original article that started the discussion.
 I do not know whether it qualifies as the "definitive article"  as I
 think I remember Lauren and I both posted further comments.
                                - Dave
        ** ARTICLE FOLLOWS **

      ----------------------------------------------------------------------

    An increasingly popular technique for protecting dial-in ports from
 the ravages of hackers and other more sinister system penetrators is dial
 back operation wherein a legitimate user initiates a call to the system
 he desires to connect with, types in his user ID and perhaps a password,
 disconnects and waits for the system to call him back at a prearranged number.
 It is assumed that a penetrator will not be able to specify the dial back
 number (which is carefully protected), and so even if he is able to guess
 a user-name/password pair he cannot penetrate the system because he cannot
 do anything meaningful except type in a user-name and password when he is
 connected to the system. If he has a correct pair it is assumed the worst that
 could happen is a spurious call to some legitimate user which will do no harm
 and might even result in a security investigation.

    Many installations depend on dial-back operation of modems for
 their principle protection against penetration via their dial up ports
 on the incorrect presumption that there is no way a penetrator could
 get connected to the modem on the call back call unless he was able to
 tap directly into the line being called back.  Alas, this assumption
 is not always true - compromises in the design of modems and the
 telephone network unfortunately make it all too possible for a clever
 penetrator to get connected to the call back call and fool the modem 
 into thinking that it had in fact dialed the legitimate user.

    The problem areas are as follows:

        Caller control central offices

    Many older telephone central office switches implement caller
 control in which the release of the connection from a calling telephone
 to a called telephone is exclusively controlled by the originating
 telephone.  This means that if the penetrator simply failed to hang up
 a call to a modem on such a central office after he typed the legitimate
 user's user-name and password, the modem would be unable to hang up the
 connection.

    Almost all modems would simply go on-hook in this situation
 and not notice that the connection had not been broken.  If the same line
 was used to dial out on as the call came in on,  when the modem
 went to dial out to call the legitimate user back the it might not
 notice (there is no standard way of doing so electrically) that the
 penetrator was still connected on the line.  This means that the modem
 might attempt to dial and then wait for an answerback tone from the far 
 end modem. If the penetrator was kind enough to supply the answerback tone
 from his modem after he heard the system modem dial, he could make a 
 connection and penetrate the system. Of course aome modems incorporate dial
 tone detectors and ringback detectors and in fact wait for dial tone before
 dialing, and ringback after dialing but fooling those with a recording of
 dial tone (or a dial tone generator chip) should pose little problem.


        Trying to call out on a ringing line

    Some modems are dumb enough to pick up a ringing line and
 attempt to make a call out on it.   This fact could be used by a
 system penetrator to break dial back security even on joint control or
 called party control central offices.  A penetrator would merely have to
 dial in on the dial-out line (which would work even if it was a separate
 line as long as the penetrator was able to obtain it's number), just as
 the modem was about to dial out.  The same technique of waiting for
 dialing to complete and then supplying answerback tone could be used - and
 of course the same technique of supplying dial tone to a modem which waited
 for it would work here too.

    Calling the dial-out line would work especially well in cases where the
 software controlling the modem either disabled auto-answer during the period
 between dial-in and dial-back (and thus allowed the line to ring with no
 action being taken) or allowed the modem to answer the line (auto-answer
 enabled) and paid no attention to whether the line was already connected
 when it tried to dial out on it.


        The ring window

    However, even carefully written software can be
 fooled by the ring window problem.  Many central offices actually will connect
 an incoming call to a line if the line goes off hook just as the call comes
 in without first having put the 20 hz. ringing voltage on the line to make it
 ring.  The ring voltage in many telephone central offices is supplied
 asynchronously every 6 seconds to every line on which there is an incoming
 call that has not been answered, so if an incoming call reaches
 a line just an instant after the end of the ring period and the line
 clairvointly responds by going off hook it may never see any ring voltage.

    This means that a modem that picks up the line to dial out just as our
 penetrator dials in may not see any ring voltage and may therefore have no
 way of knowing that it is connected to an incoming call rather than
 the call originating circuitry of the switch.  And even if the switch
 always rings before connecting an incoming call, most modems have a
 window just as they are going off hook to originate a call when they
 will ignore transients (such as ringing voltage) on the assumption that
 they originate from the going-off-hook process. [The author is aware
 that some central offices reverse battery (the polarity of the voltage
 on the line) in the answer condition to distinguish it from the
 originate condition, but as this is by no means universal few if any
 modems take advantage of the information supplied] 


        In Summary

    It is thus impossible to say with any certainty that when a modem
 goes off hook and tries to dial out on a line which can accept incoming calls
 it really is connected to the switch and actually making an outgoing call.
 And because it is relatively easy for a system penetrator to fool the
 tone detecting circuitry in a modem into believing that it is seeing dial
 tone, ringback and so forth until he supplies answerback tone and connects
 and penetrates system security should not depend on this sort of dial-back.


        Some Recommendations

    Dial back using the same line used to dial in is not very secure
 and cannot be made completely secure with conventional modems.  Use of
 dithered (random) time delays between dial in and dial back combined with
 allowing the modem to answer during the wait period (with provisions made for
 recognizing the fact that this wasn't the originated call - perhaps by
 checking to see if the modem is in originate or answer mode) will
 substantially reduce this window of vulnerability but nothing can completely
 eliminate it.

    Obviously if one happens to be connected to an older caller control
 switch, using the same line for dial in and dial out isn't secure at 
 all.  It is easy to experimentally determine this, so it ought to be possible
 to avoid such situations.

    Dial back using a separate line (or line and modem) for dialing
 out is much better, provided that either the dial out line is sterile
 (not readily traceable by a penetrator to the target system) or that it is
 a one way line that cannot accept incoming calls at all.  Unfortunately the
 later technique is far superior to the former in most organizations as
 concealing the telephone number of dial out lines for long periods involves
 considerable risk.  The author has not tried to order a dial out only
 telephone line, so he is unaware of what special charges might be made for
 this service or even if it is available.

        A final word of warning

    In years past it was possible to access telephone company test
 and verification trunks in some areas of the country by using mf tones from so
 called "blue boxes". These test trunks connect to special ports on telephone
 switches that allow a test connection to be made to a line that doesn't
 disconnect when the line hangs up.   These test connections could
 be used to fool a dial out modem, even one on a dial out only line (since
 the telephone company needs a way to test it, they usually supply test
 connections to it even if the customer can't receive calls).

    Access to verification and test ports and trunks has been tightened
 (they are a kind of dial-a-wiretap so it ought to be pretty difficult)
 but in any as in any system there is always the danger that someone, through
 stupidity or ignorance if not mendacity will allow a system penetrator
 access to one.

        **  Some more recent comments **

    Since posting this I have had several people suggest use
 of PBX lines that can dial out but not be dialed into or outward WATS
 lines that also cannot be dialed.  Several people have also suggested
 use of call forwarding to forward incoming calls on the dial out
 line to the security office.  [This may not work too well in areas
 served by certain ESS's which ring the number from which calls are
 being forwarded once anyway in case someone forgot to cancel forwarding.
 Forwarding is also subject to being cancelled at random times by central
 office software reboots.]

    And since posting this I actually tried making some measurements
 of how wide the incoming call window is for the modems we use for dial
 in at CRDS.  It appears to be at least 2-3 seconds for US Robotics
 Courier 2400 baud modems.  I found I could defeat same-line-for-dial-out  
 dialback quite handily in a few dozen tries no matter what tricks I
 played with timing and watching modem status in the dial back login software.
 I eventually concluded that short of reprogramming the micro in the modem
 to be smarter about monitoring line state, there was little I could do at
 the login (getty) level to provide much security for same line dialback.

    Since it usually took a few tries to break in, it is possible to
 provide some slight security improvement by sharply limiting the number of
 unsucessful callbacks per user per day so that a hacker with only
 a couple of passwords would have to try over a significant period of time.

    Note that dialback on a dedicated dial-out only line is 
 somewhat secure.

        David I. Emery    Charles River Data Systems   617-626-1102
        983 Concord St., Framingham, MA 01701.
        uucp: decvax!frog!die

Please report problems with the web pages to the maintainer

Top