Vulnerability

    aux

Affected

    CISCO, other routers?

Description

    HD Moore found following.  The tcp access / configuration ports on
    most routers can be disabled remotely.  These sit on port  numbers
    like 23,2001,4001,6001, and 9001.   The attack simply consists  of
    shoving a few thousand bytes of any character down the connection,
    a couple times may be needed for some routers, with the length  of
    time of the DoS related to  the amount of bytes you send  down the
    initial connection.  Some routers has to be reseted after  attack.
    The impact of  this is that  an administrator would  need physical
    access to reconfigure  a router after  an attack like  this.  This
    is merely annoying for those who have a rack in the closet, and  a
    huge pain in the ass for those 'remote' admins who may or may  not
    be able to have someone reset them for them.  The exploit is  just
    pathetic,  and  may  need  3-6  runs  of  varying  lengths  to any
    substantial damage.  Shorter  attacks result in shorter  downtimes
    for those  ports, longer  attacks do  everything from  locking the
    port out until it is reset to crashing the router itself.  The one
    line bash$ exploit is:

        perl -e'print 0xFF x 10000' | telnet router.example.org 2001

    After disconnecting try to connect  to that port again, it  should
    say connection refused.  While some routers will recover within 30
    seconds to 5 minutes,  older models tend to  take days to ???   to
    fix  themsleves.   Since  the  TCP  connection  isn't deleted, the
    virtual TTY (VTY) is  not being released.   If you run a  bunch of
    attacks,  you  eventually  end  up  with  all your VTYs hung up on
    nonexistent connections.  If you can reach the router at all,  you
    can reclaim them with the "clear line" command, but if they're all
    hung up, you may not have a way to get in and do that.

    Although  the  router's  getting  into  this  state  under   these
    circumstances  is  very  probably  caused  by  a  bug, and we will
    address that  bug, it's  very important  that everybody understand
    that it would be possible  to create the same condition  *without*
    any  bug.   The  easiest  way  would  be  to keep opening (and not
    closing) TELNET sessions to the router, until it refused to accept
    any more, then simply turn off the power on the initiating system,
    so that the sessions were never closed properly.  That's just  the
    way  TCP  works.   It  affects  any  system  that  accepts  TELNET
    connections and doesn't use TCP keepalives.  It may be  aggravated
    by a  bug in  this case,  but you  can definitely  make it  happen
    without having a bug.

Solution

    Some Cisco's would have to  be reset manually to fix  this, others
    will recover by  themselves given a  few minutes, hours,  or days.
    ComOS  seems  to  be  in  the  manual-reset category, as HD hasn't
    found one  yet that  recovers from  a 1  minute attack  onto thier
    access ports.   Normal operation  continues, only  in a  few freak
    cases did the router drop  the entire network / reset  connections
    as  a   result.   There   are  several   ways  to   mitigate  this
    vulnerability in your Cisco configuration:

    1. Don't accept TELNET connections  from just any old host  on the
       network.  Do something like this:

        access-list 1 permit host <trusted-host-1>
        access-list 1 permit host <trusted-host-2>
        ...
        access-list 1 deny any

        line vty 0 4                    ! Select all 5 VTYs
        transport input telnet          ! Don't accept non-TELNET connections
        access-class 1 in               ! ... and only from listed machines

       This is known to work, and should be the primary defense.

    2. Configure  "service  tcp-keepalives-in".   This  will make  the
       router detect dropped  TCP connections.   By default, it  won't
       detect a dropped session unless  it has output to send  to that
       session...   which it  usually won't  have for  a long time, if
       ever.

    3. Configure timeouts  on the VTY  lines, so that  an idle session
       can't permanently occupy a line.  You might do:

        line vty 0 4
        exec-timeout 10              ! Disconnect if no commands for 10 minutes
        session-timeout 10           ! Disconnect if outgoing session and no input