- NANOG - lists.nanog.org

RE: tcp bgp vulnerability looking glass and route server issues.
by Smith, Donald 22 Apr '04

22 Apr '04

By providing the 4tuple ip/port dst/src it makes guessing easier. As for production vs non-production I suspect we have a mix I did not even begin to audit them. I few spot checks is all I had time for. I would welcome any assistence in auditing vulnerable looking glass/route servers and would personally urge any LG/RS owners that were too verbose to lock them down a little. Something I wasn't looking for but found was a full open connect proxy. With that you can connect to any ip on any port nice way to scan someelses network and hide your source. I also found a few that allowed show flash:. Personally the exact image we run on a router isn't something I would want to publish:-) Will locking down looking glass/route servers stop the tcp vulnerablity? NO. Does providing information assist in trouble shooting a bgp issue? NO. I tend to error on the side of caution. Donald.Smith(a)qwest.com GCIA http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC I reserve the right to be wrong and exercise as required. -----Original Message----- From: Lane Patterson [mailto:lpatterson@equinix.com] Sent: Wednesday, April 21, 2004 5:22 PM To: Smith, Donald; nanog(a)merit.edu Subject: RE: tcp bgp vulnerability looking glass and route server issues. Sensitivity: Private While I agree that publicly open route-views routers should not allow display of "sho ip bgp nei" information, this is only giving away 4-tuple info regarding non-production BGP sessions, right? So folks could potentially flap the route-views sessions, but this will not affect any production routing in the data path. If any folks are allowing "sho ip bgp nei" via looking glass interface to a production router, then yes, that is a problem. I haven't seen any. > -----Original Message----- > From: Smith, Donald [mailto:Donald.Smith@qwest.com] > Sent: Tuesday, April 20, 2004 1:38 PM > To: nanog(a)merit.edu > Subject: tcp bgp vulnerability looking glass and route server issues. > Sensitivity: Private > > > > John Fraizer author of MRLG one of the looking glass implementations > has updated his code to fix a flaw that provided too much information. > > MRLG-4.3.0 is available at: > Available here: ftp://ftp.enterzone.net/looking-glass/CURRENT/ > > Some route servers also provide too much info. > This audit was performed yesterday so if you have already > fixed this issue please ignore:-) > Part of this issue is the fact that some router servers > provide too much information. > Without knowing the source/destination ports and IP's this is > still a difficult vulnerability to exploit. > > From this URL I did a quick audit. > http://www.traceroute.org/#Route%20Servers > I did NOT look at the looking glass URLs just the route servers. > > This is the list of open route servers I did a quick audit on. No > connection means I was unable to connect to it. Not misconfigured > meant sho ip bgp nei did NOT work. Sho ip bgp nei gives full ports/ips > means what you think it means. You have may want to see if any of them > are yours of if you peer / are the upstream for any of them. > > "Route Servers" > > "telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor > No connection > > "telnet://route-server.belwue.de" BelWue (AS553) > Sho ip bgp nei gives full ports/ips. > > "telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852) Sho > ip bgp nei gives full ports/ips. > > telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852) Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.cerf.net">CerfNet Route Server > (AS1838)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.ip.tiscali.net">Tiscali (AS3257)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.gblx.net">Global Crossing (AS3549)</A></LI> Not > misconfigured:-) > > "telnet://route-server.savvis.net/">SAVVIS Communications > (AS3561)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://public-route-server.is.co.za" TARGET=NEW>Internet > Solutions (AS3741)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server-ap.exodus.net">Exodus Communications > Asia (AS4197)</A></LI> > No connection > > "telnet://route-server.as5388.net">Planet Online (AS5388)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.opentransit.net">Opentransit (AS5511)</A></LI> > Not misconfigured:-) > > "telnet://tpr-route-server.saix.net">South African Internet > eXchange SAIX (AS5713)</A></LI> > Not misconfigure:-) > > "telnet://route-server.gt.ca">GT Group Telecom (AS6539)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.as6667.net">EUNet Finland (AS6667)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server.he.net">Hurricane Electric (AS6939)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.ip.att.net">AT&T (AS7018)</A></LI> > No connection > > "telnet://route-views.optus.net.au">Optus Route Server > Australia (AS7474)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.wcg.net">Wiltel (AS7911)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.colt.net">Colt Internet (AS8220)</A></LI> Sho > ip bgp nei gives full ports/ips. > > "telnet://route-server-eu.exodus.net">Exodus Communications > Europe (AS8709)</A></LI> > No connection > > "telnet://route-views.bmcag.net">Broadnet mediascape > communications AG (AS9132)</A></LI> > Not misconfigured:-) > > "telnet://route-server-au.exodus.net">Exodus Communications > Australia (AS9328)</A></LI> > No connection > > "telnet://route-server.manilaix.net.ph">Manila Internet > Exchange, Philippines (AS9670)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.east.attcanada.com">ATT Canada - East > (AS15290)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.west.attcanada.com">ATT Canada - West > (AS15290)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.ip.ndsoftware.net">NDSoftware > (AS25358)</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://route-server.loudpacket.net">Loud Packet (AS27276)</A></LI> > No connection. > > "telnet://route-server.as28747.net/">RealROOT (AS28747)</A></LI> No > connection > > "telnet://route-views.oregon-ix.net">Oregon-ix.net Route > Server</A></LI> > Sho ip bgp nei appears it WOULD provide full ports/ips if > they had any? The command executed but came back empty!!?? > This one can be used as a proxy bounce (connect ip port) too:-( > > "telnet://route-server.utah.rep.net">Utah Regional Exchange > Point Route Server</A></LI> > Sho ip bgp nei gives full ports/ips. > > "telnet://www.netlantis.org">The NetLantis Project Route > Server</A></LI> > Not misconfigured. > > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC > pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC > Increased trust is received by not violating the trust you have > received. >

1 0

RE: Microsoft XP SP2 (was Re: Lazy network operators - NOT)
by Drew Weaver 22 Apr '04

22 Apr '04

-- Jeff said -- Patches either need to be of a size that a dialup user doesn't have to be dialed in for 24 hours to download and install them. Or .iso's should be available for ISP's to download, turn into CD's and distribute as appropriate. Wouldn't that be nice for a dialup user - getting Windows Update on a CD-ROM from their ISP? To which I reply: It is somewhat unreasonable to think that ISPs should be responsible for the security of its users' systems on a systematic basis. Another reason the idea of a 'CD with updates' most likely wouldn't be effective is because by the time the ISP produced the CD, the user got the CD, and installed it, the patches would most likely not be the most recent available. Also, do you realize how much the 'average technical school graduate type' makes just from acquaintances who complain that their computers are slow, by simply removing whatever "flavor of the month backdoor spam proxy virus" I bet a good number of 'tech service calls' that companies such as PC On Call and people who service residences get could've been avoided by patching in a reasonable time period. However, awhile ago we tried an idea of sending out E-Mail alerts to our customers whenever a critical update of "Remote execution" or worse was released. We found that most of our users were annoyed by this, a different time we used a network sniffing tool to find a few dozen handfuls of your average home Dial-Up users who were infected with various malicious agents (I.e. Nimda, et cetera) and we actually contacted those users, to let them know and again we were met with more hostility. From this interesting pattern I would surmise that users want their ISPs to be hands-off unless the problem that they're causing is effecting them directly. End users on the Internet see their connectivity as a right, and not a privilege. I remember when I was 13 (that was only 11 years ago) and I signed up for my Freenet account at the Columbus Public Library (I believe it was, ? still is? Through OSU), they really made me feel like it was a privilege to be using the Internet, and I honored that. Its just difficult to explain from a professional level what the effects these peoples' behavior (or lack there of) is having on the rest of the community. Think of it like people who drive monster SUV's, they can afford the gas, and the insurance so they don't believe that the harm that these beasts do to our environment matter, because again its their god given right to drive them. -Drew

9 12

Re: Ordering Windows Security Update CD (was Re: Microsoft XP SP2)
by Alexei Roudnev 22 Apr '04

22 Apr '04

It depends... if you use FreeBSD with port system, for example - it is safe enough (esp. if make a pause between 'make' and 'make install' in a few days or a week. and read mail lists about possible problems). > dowloading opensource software is safe? -CP

1 0

RE: TCP/BGP vulnerability - easier than you think
by Michel Py 22 Apr '04

22 Apr '04

> Aditya wrote > I sure hope there are no asymmetric paths on the Internet > that will bite you when you turn on strict RPF on your > peering interfaces </sarcasm> > Seriously, if you do turn RPF on on peering interfaces, > please let your peers know (plea from circa 1999) Ah, I was waiting for someone to say something like this and make my point, thank you. In the topic I was arguing earlier (about prefix filtering peers, underlining the fact that imperfect filtering would not cause traffic loss) it does indeed create asymmetry and prohibits the use of RPF. Michel.

2 1

Re: tcp bgp vulnerability looking glass and route server issues.
by Troy Davis 22 Apr '04

22 Apr '04

On Wed, Apr 21, 2004 at 04:21:51PM -0700, Lane Patterson <lpatterson(a)equinix.com> wrote: > While I agree that publicly open route-views routers should not allow > display of "sho ip bgp nei" information, this is only giving away 4-tuple > info regarding non-production BGP sessions, right? So folks could A few cases where a non-production session source port suggests same for production sessions, assuming the production router opened the connections: - Reachability for a non-production session can depend on the same interface(s) as production session(s), so they may use sequential ports after an interface flap. - When the source port is near the start of the range (ie, 11020), other sessions with that router may have last reset when it reloaded. Troy

1 0

Re: TCP/BGP vulnerability - easier than you think
by John Kristoff 22 Apr '04

22 Apr '04

On Wed, 21 Apr 2004 21:00:55 +0100 (IST) Paul Jakma <paul(a)clubi.ie> wrote: > risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The > risk is due to MD5, not IPSec :). I would say the risk is due to implementation. If the vendor's gear vomits quicker due to a resource consumption issue in handling MD5, is this really a problem with MD5? These issues can usually be fixed by simply improving the scaling properties of the implementation that may be required during adverse conditions. John

2 1

Ad blocking with squid
by Paul Khavkine 21 Apr '04

21 Apr '04

Hi Folks. Anyone doing ad blocking with Squid cache engine out there ? Is there a comprehensive URL list out there on the net ? Thanx Paul ************************************************ Paul Khavkine Network Administrator DISTRIBUTEL Communications. 740 Notre Dame West, Suite 1135 Montreal, Quebec, Canada, H3C 3X6 1-514-877-5505 x 263 http://www.distributel.net ************************************************

6 7

RE: TCP RST attack (the cause of all that MD5-o-rama)
by Michel Py 21 Apr '04

21 Apr '04

>> James wrote: >> now the question is... would this also affect single-hop >> bgp sessions? my understanding would be no, as single-hops >> require ttl set to 1. > Simon Lockhart wrote: > All it requires is for the TTL to be 1 (or 0, I can't > remember which) when it's received. Just launch your > packets with a TTL of the number of hops between you > and the victim, and that's that bit sorted... That's not the way I read it at all. The way I read it is that the TTL of the packet has to be equal or _greater_ than 254 (or 255). Since you can't set the TTL to a value greater than 255 when sending the forged packet, it means that the spoofer sending a packet from 10 hops away will have a TTL of 245 at most, and will be discarded. As nobody has figured out how to prevent the TTL to be decremented by each of the hops on the way, it works. Michel.

1 0

Re: The Uneducated Enduser (Re: Microsoft XP SP2 (was Re: Lazy network operators - NOT))
by Dr. Jeffrey Race 21 Apr '04

21 Apr '04

On Tue, 20 Apr 2004 09:21:02 -0500 (CDT), Adi Linden wrote: >> Since many gateway service providers will not prevent insufficiently >> skilled users from connecting to the internet and injuring others, the >> only remaining solution, as far as I can see, is cutting connectivity >> with those enablers. That is the proposal I advanced in >> <http://www.camblab.com/misc/univ_std.txt>. >And once again the you're punishing the victim. Let's not forget that the >uneducated end user is tricked into doing things that are not good for >them or the rest of the internet connected world. >Unfortunately the only feasible and readily available computer solution >for the uneducated end user is a single available operating system. >Everyone is at the mercy of this product with all its flaws and downfalls. >Instead of continually blaming the uneducated end user how about providing >tools to the uneducated end user that can be used to connect to the >internet without becoming a liability. A toaster with keyboard an monitor... I beg to clarify that I am not "blaming" anyone; I am describing a system with known input-output properties and internal structures. We know how this system behaves in terms of technology and human behavior, and we know what to do to the inputs to change the outputs. If you choose to smoke, you get cancer. Same with spam. If you don't want to have spam, you have to change some behaviors. Some people will be inconvenienced. Life is full of such choices. As for the specifics of your comments, I could not disagree more, but it is a philosophy of life that distinguishes our views, not the analysis of the problem. I believe (like a lot of other New Englanders and even some from California) that people must assume responsibility for their actions. If responsibility is not enforced, society collapses (into e.g. the kind of chaos we see on the internet.) In 2004 no one is "tricked" into using rubbish software; there are plenty of alternatives, and the rubbishy nature of the leading OS is in almost every day's newspaper. It's a choice people make, like overeating and gaining weight. No one is there with a gun forcing people to gain weight. As for "uneducated", the solution is the same as for bad drivers: training. If you are a threat to the rest of the internet because of your ignorance (or irresponsibility) then you do not qualify for connectivity, just as bad drivers don't get licenses, bad credit risks don't get credit, and drunk airline pilots stop flying. To repeat: the solution to spam is to apply rigorously the same rules to the internet as are used everywhere else in society. It is simple, it pays for itself, it works, and it works immediately. Some people will be upset, like the smokers who have to go outside for a puff or even give up their habit. However the result is better for EVERYONE including "the uneducated". Jeffrey Race

5 4

RE: TCP/BGP vulnerability - easier than you think
by Michel Py 21 Apr '04

21 Apr '04

> Adam Rothschild wrote: > Which begs the question, what is one to do, shy of > moving (private) peering/transit/customer /31's and > /30's into non-routable IP space, which opens up an > entirely new can of worms? Insist that the peer uses "ip verify unicast reverse-path" on all interfaces, or similar command for other vendors. > Fact of the matter is, MD5 computation/verification > is not cheap, and many Cisco and Juniper platforms > aren't designed to handle a barrage of MD5-hashed > TCP packets. All things considered, I think MD5 > authentication will lower the bar for attackers, not > raise it. I'm sure code optimizations could fix > things to some degree, but that's just not the case > today. Certainly the best reason not to MD5 I have heard so far. > Mikael Abrahamsson wrote: > http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml > This one seems much worse than the TCP RST problem. Relatively easy to filter though. Michel.

3 2