From: Jim Devane (jim@powerpulse.cc)
Date: Wed Apr 21 2004 - 16:05:47 GMT-3
After having successfully spoofed the source IP and source port and the
destination port ( not a given since who knows which side of the routers
initiated the session ) and then adjusted for the TTL difference.
The hacker must pass the MD5 hash BEFORE the sequence number is even
checked.
If the MD5 hash fails the packet is discarded and the asteroid misses Earth.
They key ( pardon the pun ) is that the sequence number is checked after the
MD5.
So here is the question... checking MD5 hashes takes CPU cycles. If you
enable it and the hashes start to fly as you throw out packet after packet
of bogus info ( again after aforementioned req's have been satisfied ) the
CPU util will climb. IT won't take long of a router checking hashes of
packets destined to itself before the whole things goes face down in the
dirt. Then you have lost all your BGP sessions. That is a bummer.
Rock - A single BGP session is reset
Hard Place - The whole router goes belly up.
Scylla - Admin of having all these passwords for various sessions ( and
rotating them occasionally )
Charybdis - Seeming like you don't take security seriously ( even though you
do )
Again, eval of you own network will likely make clear the lesser of two
evils.
HTH,
Jim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Paul
Borghese
Sent: Wednesday, April 21, 2004 11:43 AM
To: 'Armand D'; ccielab@groupstudy.com
Subject: RE: Transmission Control Protocol (TCP) vulnerability ???
I have been studying the vulnerability with relation to how it effects
BGP sessions. In a nutshell, the hacker sends a TCP RST message thus
terminating the BGP neighbor relationship. This causes the routes to be
removed from the BGP table. Do this a few times and (assuming you have
route dampening enabled) the routes are placed in a dampened state. The
hacker must guess the TCP Sequence number (or be close based upon the
windowing size).
Cisco's workaround is to simply use BGP authentication. While I do not
doubt Cisco has tested this and it works, I do not understand why it
will work. BGP is transported as data that rides over TCP/IP (port
179). Why would authenticating application layer data prevent the TCP
session from being reset? The authentication is taking place at a
higher layer then layer 4.
Any opinions? Howard?
Take care,
Paul Borghese
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Armand D
Sent: Wednesday, April 21, 2004 1:51 PM
To: ccielab@groupstudy.com
Subject: Transmission Control Protocol (TCP) vulnerability ???
Hi,
I'm wondering what anyone thinks about the latest
vulnerability (TCP) specification ? What precautions
are people taking if any at this point ?
Thanks,
Armand
http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:52 GMT-3