[scg-sec] Telnet Vulnerability
Battles, Timothy A (Tim), ALABS
tmbattles at att.com
Fri Aug 27 10:20:30 EDT 2004
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
>
More information about the scg-sec
mailing list