[scg-sec] Telnet Vulnerability

Fri Aug 27 11:07:57 EDT 2004

Oh no, not ATT marketing!  I heard they just inked a deal to deliver 100
million pounds of ice to some scientists in Antarctica for $100 a pound.

Ryan McDowell
NTAC Internet (SprintLink)
Sprint Network Operations
Office: +1 703 689 7527
Mobile: +1 703 862 2570
EED9 192F 9F45 FAE4 F6A3  8764 FEE1 299D 1B62 A361

On Fri, 27 Aug 2004, Battles, Timothy A (Tim), ALABS wrote:

> Well we suck just as much as you guys suck. Don't make me get Marketing
> involved to prove how much more we suck.
>
> >-----Original Message-----
> >From: scg-sec-bounces at puck.nether.net
> >[mailto:scg-sec-bounces at puck.nether.net]On Behalf Of Ryan McDowell
> >Sent: Friday, August 27, 2004 8:45 AM
> >To: Christopher L. Morrow
> >Cc: scg-sec at puck.nether.net
> >Subject: Re: [scg-sec] Telnet Vulnerability
> >
> >
> >
> >
> >Ryan McDowell
> >NTAC Internet (SprintLink)
> >Sprint Network Operations
> >Office: +1 703 689 7527
> >Mobile: +1 703 862 2570
> >EED9 192F 9F45 FAE4 F6A3  8764 FEE1 299D 1B62 A361
> >
> >On Fri, 27 Aug 2004, Christopher L. Morrow wrote:
> >
> >>
> >>
> >> On Thu, 26 Aug 2004, Ryan McDowell wrote:
> >>
> >> > I'd say its a non-issue, everybody should be running at
> >least vty acl's
> >> > and that is what console is for.
> >> >
> >>
> >> yes, everyone SHOULD be using vty acls... at
> >> sprint/att/mci|uu/verio/C&W|Savvis/blah-large-nsp probably
> >the use of vty
> >> acls is 'standard' (not on our managed networks, because we
> >suck, what
> >> about yours?)
> >
> >Point taken.  Maybe this is a good oppertunity to get folks running vty
> >ACL's then.  It is an alternative to convincing people that
> >"cisco" is a
> >bad password to use.  Actually, our MNS folks run vty ACL's.
> >So I guess
> >we suck less :)
> >
> >>
> >> Many, many, many folks do NOT use vty acls :( reference Rob
> >Thomas for
> >> evidence of same :(
> >>
> >> That being said, however, this doesn't affect 'me', and I'm
> >not sure that
> >> there is any great call for fire and brimstone (aside from
> >cisco should
> >> have not let a little coding error get them like this, oh
> >well!) and Ryan
> >> points out that Console (remote console) is quite effective
> >at clearing
> >> stuck lines, which is nice :)
> >>
> >> > Although its interesting to see this as an explanation to
> >why vty sessions lock
> >> >  up.  We've opened up several cases on this and could
> >never quite figure it
> >> > out.  Any idea if other protocols are impacted?  We've had
> >some problems with
> >> > TCP/49 sessions getting stuck in CLOSEWAIT, maybe this is
> >related somehow?
> >> >
> >> > Ryan McDowell
> >> > NTAC Internet (SprintLink)
> >> > Sprint Network Operations
> >> > Office: +1 703 689 7527
> >> > Mobile: +1 703 862 2570
> >> > EED9 192F 9F45 FAE4 F6A3  8764 FEE1 299D 1B62 A361
> >> >
> >> > On Thu, 26 Aug 2004, Wendy Garvin wrote:
> >> >
> >> > >
> >> > > Folks,
> >> > >
> >> > > The detail about the window size will be withheld from
> >the initial advisory
> >> > > in order to give customers time to implement the vty
> >acl. Since we can't
> >> > > write ACL's to block a connection based on the window
> >size, there doesn't
> >> > > seem to be any value in releasing this detail at first.
> >At some point, we'll
> >> > > want IDS vendors to be able to detect this and we'll
> >release the details
> >> > > then. The idea is to buy time. We may release this
> >detail to the nsp-sec
> >> > > list before we put it in the advisory.
> >> > >
> >> > > Thanks, and let me know if you think you see attempted
> >exploitation. I wish
> >> > > we could detect this with netflow. If any of you employ
> >IDS systems and can
> >> > > write custom signatures, we'd sure like to know if you
> >get attacked.
> >> > >
> >> > > Paul - Can Junipers do ACLs based on window size?
> >> > >
> >> > > By the way, we're considering this an annoyance attack
> >rather than a
> >> > > production affecting attack, as it doesn't affect other
> >TCP based protocols
> >> > > like BGP or LDP. The worst we can see happening is that
> >people are locked
> >> > > out of managing their routers until they can get someone
> >on site. While this
> >> > > is not a good situation, at least the device is still
> >routing and switching
> >> > > traffic. We're also interested in knowing if that risk
> >assessment misses
> >> > > anything from your deployment point of view.
> >> > >
> >> > > Thanks,
> >> > >
> >> > > -Wendy
> >> > >
> >> > > > Battles, Timothy A (Tim), ALABS <tmbattles at att.com>
> >[2004-08-26 11:51] wrote:
> >> > > >
> >> > > > Ohh, and clear line vty x
> >> > > >
> >> > > > Will not work.
> >> > > >
> >> > > > must be a clear tcp
> >> > > >
> >> > > > >-----Original Message-----
> >> > > > >From: Jared Mauch [mailto:jared at puck.nether.net]
> >> > > > >Sent: Thursday, August 26, 2004 1:43 PM
> >> > > > >To: Battles, Timothy A (Tim), ALABS
> >> > > > >Cc: scg-sec at puck.nether.net
> >> > > > >Subject: Re: [scg-sec] Telnet Vulnerability
> >> > > > >
> >> > > > >
> >> > > > >	so if there is a vty acl, we're safe, or semi-safe (ie:
> >> > > > >hosts in the
> >> > > > >acl only that can do 3-way).
> >> > > > >
> >> > > > >	- jared
> >> > > > >
> >> > > > >On Thu, Aug 26, 2004 at 02:39:19PM -0400, Battles, Timothy A
> >> > > > >(Tim), ALABS wrote:
> >> > > > >>
> >> > > > >> Cisco Day1 VTY Vulnerability
> >> > > > >>
> >> > > > >> We have recently by accident discovered the following.
> >> > > > >>
> >> > > > >> After completing a 3-Way handshake with IOS and sending a
> >> > > > >Window size of 0, the VTY handler becomes confused
> >> > > > >> and will not allow other session to become established,
> >> > > > >SYN-ACKS will be received from the router.
> >> > > > >>
> >> > > > >> In order to clear the session a
> >> > > > >>
> >> > > > >> clear tcp tcb xxxxxxxx
> >> > > > >> clear tcp line x
> >> > > > >> clear tcp line vty x
> >> > > > >>
> >> > > > >>
> >> > > > >> needs to be issued.
> >> > > > >>
> >> > > > >>
> >> > > > >> Some clarifiers
> >> > > > >> This effects both telnet and ssh.
> >> > > > >> The packet cannot be spoofed.
> >> > > > >> This is IOS only. Day 1
> >> > > > >>
> >> > > > >>
> >> > > > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> > > > >> Timothy A Battles
> >> > > > >> AT&T IP Network Security Group
> >> > > > >> Work: (314)770-3326
> >> > > > >> Cell: (314)280-4578
> >> > > > >> Fax:  (314)770-9568
> >> > > > >> Email: tmbattles at att.com
> >> > > > >> 12976 Hollenberg Drive
> >> > > > >> Bridgeton, MO 63044-2407
> >> > > > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >> _______________________________________________
> >> > > > >> scg-sec mailing list
> >> > > > >> scg-sec at puck.nether.net
> >> > > > >> https://puck.nether.net/mailman/listinfo/scg-sec
> >> > > > >
> >> > > > >--
> >> > > > >Jared Mauch  | pgp key available via finger from
> >jared at puck.nether.net
> >> > > > >clue++;      | http://puck.nether.net/~jared/  My statements
> >> > > > >are only mine.
> >> > > > >
> >> > > >
> >> > > > _______________________________________________
> >> > > > scg-sec mailing list
> >> > > > scg-sec at puck.nether.net
> >> > > > https://puck.nether.net/mailman/listinfo/scg-sec
> >> > > >
> >> > > > [    ----- End of Included Message -----    ]
> >> > >
> >> > > --
> >> > > Wendy Garvin - Cisco PSIRT - 408 525-1888 CCIE# 6526
> >> > > ----------------------------------------------------
> >> > >            http://www.cisco.com/go/psirt
> >> > > _______________________________________________
> >> > > scg-sec mailing list
> >> > > scg-sec at puck.nether.net
> >> > > https://puck.nether.net/mailman/listinfo/scg-sec
> >> > >
> >> >
> >> > _______________________________________________
> >> > scg-sec mailing list
> >> > scg-sec at puck.nether.net
> >> > https://puck.nether.net/mailman/listinfo/scg-sec
> >> >
> >>
> >
> >_______________________________________________
> >scg-sec mailing list
> >scg-sec at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/scg-sec
> >
>