OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Michael H. Warfield (mhwiss.net)
Date: Thu May 03 2001 - 14:11:22 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
    majordomoiss.net Contact issforum-owneriss.net for help with any problems!
    ----------------------------------------------------------------------------

    All!

            This is kind of long. My appologies. I just want to try to
    update everyone on a list problem I've been investigating so that the
    ones who were suffering from it know what happened and why. I also want
    to make sure people bring problems like this to my attention ASAP.
    This probably went on longer than it should have.

            It came to my attention that a small percentage of list
    subscribers (several dozen out of the several thousand subscribers on
    this list) have been receiving duplicates of one particular recent
    message about "Internet Scanner: Estimating time required to complete
    a scan" dated April 27.

    For everybody:

            Please!

            When experiencing problems with message deliveries such as
    duplicate messages, please forward copies of the dupicates to me,
    preferrably to issforum-owneriss.net. I need message headers
    including "Received:", "Message-Id:", and "Delivered-To:" in order to
    track down most problems (I got extremely lucky, this time). The
    message headers are the audit trail which tells me how a message was
    processed. They are not normally displayed with a message by there
    is, normally, a way to display them and forward them, even with Windows
    based E-Mail clients.

            I personally maintain three accounts subscribed to this list to
    monitor the traffic and detect problems. Often, if you report a problem
    like this to me, I will have the data in one of those accounts as well.
    That was not the case, this time. None of my monitoring accounts were
    experiencing this problem.

    For the people experiencing the recent duplicates:

            I've analyzed this problem and stumbled over something "amusing".
    It's amusing from my point of view (largely because I'm an OLD FART with
    first hand experience with this particular problem). I'm sure it's not
    so amusing from the point of view of those suffering from the problem.
    What I stumbled onto is an old OLD problem. I'm sure that it could be
    even LESS amusing if someone were to take advantage of the problem and
    mount a denial of service attack against vulnerable spots. Consequently,
    I am not revealing any information about who may or may not be having
    this problem. I'm only going to detail out what the problem is.

            The problem turns out to be an old modem problem called "TIES"
    or "Time Independent Escape Sequence". One poster posted a message that
    included a line in his signature that began with three plus signs
    and ended with three plus signs. Three plus signs (optionally bracketed
    with a return) is the default escape sequence to cause TIES based modems
    to escape into command mode. This would eventually cause the network
    connection to break. Because it was at the very end of the message,
    apparently some mail systems were delivering the message anyways.
    Our system began reporting this error:

            "status=deferred (conversation with ************ timed out while
    sending end of data -- message may be sent more than once"

            So a message with three pluses on the very last line of the message
    was apparently causing some modem along the way to the recipients mail
    server to jump into command mode and time out the connection. Our system
    deferred the delivery for later while the recepients system obligingly
    delivered it.

            The offending message has been removed from the mail queue and the
    original poster was informed about what triggered the problem. That
    eliminates the current round of duplicates but does not solve the problem
    (the vulnerable modems out there). But, of course, there should be nothing
    wrong with what he posted and nothing is stopping anyone else from
    posting something similar (please don't). The real problem still exists
    for several dozen people, that there may be an AT-style TIES modem device
    in their network path that may be vulnerable to "TIES Bombing".

            A little history:

            TIES was an effort by a number of modem manufacturers to avoid the
    Hayes / Haywood (maybe it was Hayward - I never remember quite right from
    THAT long ago) patent on the <delay>+ + +<delay> escape to command mode
    for AT command set modems. The key to the patent was the <delay>. TIES
    manufacturers eliminated the delay and, thus, did NOT have to pay royalties
    on the patent. It also mean that, given the right conditions, their
    modems would jump into command mode when receiving a simple "+ + +" in
    the data stream. For some manufacturers, it was a "\r+ + +" while some
    required a "+ + +\r", the message in question hit both.

            (Note: I'm spacing out the pluses just to be sure I don't trip
    over some REALLY lame TIES modem. :-) )

            During the TIES wars, many years ago, some Hayes employees were
    known to include "+ + +ATH0" on a separate line (providing both leading and
    trailing newlines) in all of their USENET mail postings and E-Mail messages.
    Needless to say, this caused widespread random mayhem and didn't enhance
    the reputation of either Hayes nor the modem manufactures one bit.

            Now... Here is why I'm subjecting everyone to this little
    history lession...

            I recently (about 6 months ago) had an incident with some chumps
    "TIES bombing" an entire ISP. They were flood pinging his netblock with
    ICMP echo packets containing "\r+ + +ATH0\r" in the payload. What would
    happen was that, when a customer would connect in and get an IP address,
    the first ping would cause the ISP's (the outbound) modem to jump into
    command mode and then hang up the phone (they could create even MORE
    mayhem by issuing dial commands in the payload - think about it). The
    ISP was at a total loss trying to figure out why all his PPP dialins
    where hanging up within seconds of connecting till I suggested looking at
    this old problem. That was it. All of their banks of modems were TIES
    modems. They had to set the escape character to 255 or 127 to disable the
    escape. But that only fixed SOME of the connections. Some customers were
    still broken! The answer was simple! The echo packet was getting through
    and being echoed back. Then the customer's modem (transmitting back to the
    ISP) would see the + + +ATH0 and jump into command mode and hang up the
    phone. Both ends of the link had to be fixed to prevent TIES bombing.

            Even some high speed devices, such as ISDN modems, may be
    vulnerable to this problem.

            Everyone who was experiencing the duplicate message problem may
    be vulnerable to exactly this style of TIES bombing! This can turn into
    a real annoying denial of service attack that is real difficult to track
    down and trouble shoot. I can not tell from here, where the faulty
    modems are. They are out there, though.

            If you can identify the modems (they may be yours, the ISP you
    connect to, or some other link) here are some recommendations to
    implement or pass along...

            Disable the TIES escape recognition by setting the TIES escape
    character (S2 register) to the "disabled" value (127 for most modems,
    255 for some modems). This value can then be written out to the NVRAM
    of the modem.

            To guard against modems being reset back to the factory defaults
    (which would include setting S2=43, the '+' character) any software which
    manipulates the modem at the "AT" command level should also included the
    string "S2=127" or "S2=255", as appropriate for the modem, in the
    initialization sequence. This should be done for dial in initialization
    as well as dial out initialization.

            The Time Independent Escape Sequence (TIES) was developed as a way
    around patents held by Hayes Microcomputer Products back in the days when
    dominant connections were interactive and little binary data was being
    passed over the modems.

            TIES is a old technology which is intrinsicly incompatible with
    modern IP connected links with binary data, compressed data, or encryted
    data. It's subject to a variety of failures due to hostile action or
    just plain bad luck. All TIES modems, at both ends of IP dial-in connections
    need to have the TIES sequence disabled. Unfortunately, too many modern
    modems still support and operate with TIES.

            Sorry for the problem that some of you have been experiencing and
    sorry for inflicting this little off-topic history lesson on everyone.

            Back to your regularly scheduled programming... :-)

            Regards,
            Mike
            ISS Forum Moderator

    --
    Michael H. Warfield,            | Voice: (404)236-2807
    Senior Researcher - X-Force     | Main:  (404)236-2600
    Internet Security Systems, Inc. | E-Mail:  mhwiss.net  mhwwittsend.com
    6303 Barfield Road              | http://www.iss.net/
    Atlanta, Georgia 30328          | http://www.wittsend.com/mhw/
                                    | PGP Key: 0xDF1DD471