NSA able to compromise Cisco, Juniper, Huawei switches
Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven.
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On (2013-12-30 20:30 +1100), sten rulz wrote: Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx The quality of this data is too damn low. Not as bad as this though, http://cryptome.org/2013/12/Full-Disclosure.pdf I really think we're doing disservice to an issue which might be at scale of human-rights issue, by spamming media with 0 data news. Where is this backdoor? How does it work? How can I recreate on my devices? Large audience already seems to largely be in ignore mode about NSA revelations, since revelations are very noisy but little signal. -- ++ytti
The state of TACACS+
Ever since first using it I've always liked tacacs+. Having said that I've grown to dislike some things about it recently. I guess, there have always been problems but I've been willing to leave them alone. I don't have time to give the code a real deep inspection, so I'm interested in others thoughts about it. I suspect people have just left it alone because it works. Also I apologize if this is too verbose or technical, or not technical enough, or just hard to read. History: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there have been no official changes to the code. Much has happened between now and then. I specifically was interested in parsing tac_plus logs correctly. After finding idiosyncrasies I decided to look at the source and the RFC to see what was really happening. Logging, or why I got into this mess: In the accounting log, fields are sometimes logged in different order. It appears the client is logging whatever it receives without parsing it or modifying it. That means the remote system is sending them in different orders, so technically the fault lies with them. However, it seems too trusting to take in data and log it without looking at it. This can also cause issues when you send a command like (Cisco) dir /all nvram: on a box with many files. The device expands the command to include everything on the nvram (important because you might want to deny access to that command based on something it expanded), but it gets truncated somewhere (not sure if it's the device buffer that is full, tac_plus, or the logging part. I might tcpdump for a while to see if I can figure out what it looks like on the wire) I'm not sure if there are security implications there. Encryption: The existing security consists of md5 XOR content with the md5 being composed of a running series of 16 byte hashes, taking the previous hash as part of the seed of the next hash. A sequence number is used so simple replay shouldn't be a factor. Depending on how vulnerable iterative md5 is to it, and how much time you had to sniff the traffic, I would think this would be highly vulnerable to chosen plaintext if you already have a user-level login, or at least partial known plaintext (with the assumption they make backups, you can guess that at least some of the packets will have show running-config and other common commands). They also don't pad the encrypted string so you can guess the command (or password) based on the length of the encrypted data. For a better description of the encryption you can read the draft: http://tools.ietf.org/html/draft-grant-tacacs-02 I found an article from May, 2000 which shows that the encryption scheme chosen was insufficient even then. http://www.openwall.com/articles/TACACS+-Protocol-Security For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it would be easier to roll keys frequently, or if it isn't too much overhead they could use public key. Clients: As for clients, Wikipedia lists several that seem to be based on the original open-source tac_plus from Cisco. shrubbery.net has the official version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly or shrubbery.net code, but they retained the name and started doing their own versioning. All the webpages look like they're from 1995. In some cases I think it's intentional but in some ways it shows a lack of care for the code, like it's been dropped since 2000. Documentation is old: This only applies to shrubbery.net's version. I didn't look at the other ones that closely. While all of it appears valid, one QA in the FAQ was about IOS 10.3/11.0. Performance questions use the sparc 2 as a target machine. There isn't an INSTALL or README, just the FAQ/CHANGES/COPYING (and a tac_plus.conf manpage), so the learning curve for new users is probably pretty steep. Also there isn't a clear maintainer. The best email address I found was listed in the tacacs+.spec file, for packaging on rpm systems. If you hit the website they give some hints with some outdated, though still functional links. And they list the official email as tac_p...@shrubbery.net Conclusion: Did everyone already know this but me? If so have you moved to Kerberos? Can Kerberos do everything TACACS+ was doing for router authorization? I've got gear that only supports radius and tacacsplus, so in some cases I have no choice but to use one of those, neither of which I would trust over an unencrypted wire. If TACACS+ isn't a dead end then it needs a push to bring the protocol to a new version. There are big name vendors involved in making supported clients and servers. There should
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Saku Ytti s...@ytti.fi wrote: On (2013-12-30 20:30 +1100), sten rulz wrote: I really think we're doing disservice to an issue which might be at scale of human-rights issue, by spamming media with 0 data news. Where is this backdoor? How does it work? How can I recreate on my devices? I don't really want you to know how to recreate it until the companies have had a chance to fix said issue. I'd hope, if such issues were disclosed, those news outlets would go through proper channels of disclosure before going to press with it. Large audience already seems to largely be in ignore mode about NSA revelations, since revelations are very noisy but little signal. I think the NSA is hoping that to be the case. But just based on the fact that 60 Minutes did a story on the NSA and the NSA, POTUS, congress, and that half my Twitter, Facebook, and mailing lists are still talking about it (though my networks are probably biased) shows that people are still interested. Also, I think there's a fair chance SCOTUS will take this up due to differing rulings. Before this goes the way of Crypto-AG or clapper, its got quite a fair distance left in it.
Re: The state of TACACS+
I don't understand why vendors and operators keep turning to TACACS. It seems like they're often looking to Cisco as some paragon of best security practices. It's a vulnerable protocol, but some times the only thing to choose from. One approach to secure devices that can support only TACACS or RADIUS: Deploy a small embedded *nix machine (Soekris, Raspberry Pi, etc.) that runs a RADSEC (for RADIUS) or stunnel (for TACACS) proxy. Attach it to a short copper with 802.1q, take weak xor'ed requests in on one tag, wrap the requests with TLS, and forward out another tag towards your central AAA box. Kerberos or more certificate-based SSH on routers would be super. SSH with certificates is nice in that it allows authenticators out in the field to verify clients offline, without needing a central AAA server. However, the tradeoff is that you must then make sure all the clocks are correct and in-sync, and root certificates are verified. On Mon, Dec 30, 2013 at 2:06 AM, Robert Drake rdr...@direcpath.com wrote: Ever since first using it I've always liked tacacs+. Having said that I've grown to dislike some things about it recently. I guess, there have always been problems but I've been willing to leave them alone. I don't have time to give the code a real deep inspection, so I'm interested in others thoughts about it. I suspect people have just left it alone because it works. Also I apologize if this is too verbose or technical, or not technical enough, or just hard to read. History: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there have been no official changes to the code. Much has happened between now and then. I specifically was interested in parsing tac_plus logs correctly. After finding idiosyncrasies I decided to look at the source and the RFC to see what was really happening. Logging, or why I got into this mess: In the accounting log, fields are sometimes logged in different order. It appears the client is logging whatever it receives without parsing it or modifying it. That means the remote system is sending them in different orders, so technically the fault lies with them. However, it seems too trusting to take in data and log it without looking at it. This can also cause issues when you send a command like (Cisco) dir /all nvram: on a box with many files. The device expands the command to include everything on the nvram (important because you might want to deny access to that command based on something it expanded), but it gets truncated somewhere (not sure if it's the device buffer that is full, tac_plus, or the logging part. I might tcpdump for a while to see if I can figure out what it looks like on the wire) I'm not sure if there are security implications there. Encryption: The existing security consists of md5 XOR content with the md5 being composed of a running series of 16 byte hashes, taking the previous hash as part of the seed of the next hash. A sequence number is used so simple replay shouldn't be a factor. Depending on how vulnerable iterative md5 is to it, and how much time you had to sniff the traffic, I would think this would be highly vulnerable to chosen plaintext if you already have a user-level login, or at least partial known plaintext (with the assumption they make backups, you can guess that at least some of the packets will have show running-config and other common commands). They also don't pad the encrypted string so you can guess the command (or password) based on the length of the encrypted data. For a better description of the encryption you can read the draft: http://tools.ietf.org/html/draft-grant-tacacs-02 I found an article from May, 2000 which shows that the encryption scheme chosen was insufficient even then. http://www.openwall.com/articles/TACACS+-Protocol-Security For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it would be easier to roll keys frequently, or if it isn't too much overhead they could use public key. Clients: As for clients, Wikipedia lists several that seem to be based on the original open-source tac_plus from Cisco. shrubbery.net has the official version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly or shrubbery.net code, but they retained the name and started doing their own versioning. All the webpages look like they're from 1995. In some cases I think it's intentional but in some ways it shows a lack of care for the code, like it's been dropped since 2000. Documentation is old: This only applies to shrubbery.net's version. I didn't look at the other ones that closely. While all of it appears valid, one QA in the FAQ was about IOS 10.3/11.0. Performance
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On (2013-12-30 06:12 -0500), Shawn Wilson wrote: I don't really want you to know how to recreate it until the companies have had a chance to fix said issue. I'd hope, if such issues were disclosed, those news outlets would go through proper channels of disclosure before going to press with it. Until disclosed it's just speculation and conjecture. If vendors are cooperating with NSA, there is no incentive to fix, there is incentive to claim fix or non-existence of such features. I welcome the short-term havok and damage of such disclose if it would be anywhere near the magnitude implied, it would create pressure to change things. -- ++ytti
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 5:06 PM, Saku Ytti s...@ytti.fi wrote: The quality of this data is too damn low. The #1 way that Cisco routers and switches are compromised is brute-forcing against an unsecured management plane, with username 'cisco' and password 'cisco. The #1 way that Juniper and switches are compromised is brute-forcing against an unsecured management plane, with username 'cisco' and password 'cisco. ; Note that both Cisco and Juniper have many platforms, running on various hardware, and running various OSes/trains/releases/throttles --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: The state of TACACS+
On (2013-12-30 05:06 -0500), Robert Drake wrote: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there If continued existence of TACACS+ can be justified at IETF level, in parallel with radius and diameter, I have some interest in the subject and would be ready to work with draft. Encryption: For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it It seems encryption is your only/major woe? Personally I don't like how we need to keep reimplementing crypto per-application level. We're living in a world where crypto should be standard for all connection, not application issue. There are some solutions to this like BEEP framework or new L4 protocol like QUIC and MinimaLT, any of which I think would be workable as mandatory transport for TACACS. Clients: official version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly There is also commercial server 'radiator' which does radius and tacacs amongst others. Did everyone already know this but me? If so have you moved to I think I missed the key revelation. The naive encryption? The limited amount of software available? Kerberos? Can Kerberos do everything TACACS+ was doing for router I think from networker point of view, it's radiator or tacacs, if it has to work today without new software. And if it can require new software, it can be pretty much arbitrary new protocol, if sound justification can be found. -- ++ytti
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 6:18 PM, Saku Ytti s...@ytti.fi wrote: I welcome the short-term havok and damage of such disclose if it would be anywhere near the magnitude implied, it would create pressure to change things. This is the type of change we're likely to see, IMHO: http://lauren.vortex.com/archive/001074.html --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Even more outrageous than the domestic spying is the arrogance to think that they can protect the details on backdoors into critical infrastructure. They may have basically created the framework for an Internet-wide kill switch, that likely also affects every aspect of modern communication. Since they don't disclose any of this to other agencies, it's very likely that even parts of the DOD is vulnerable. I hope when [if] the truth is learned it is a lot less prevalent than it sounds, but I'm not optimistic. This is why we need all infrastructure to be implemented using open standards, open hardware designs, and open source software IMHO. I hope Cisco, Juniper, and others respond quickly with updated images for all platforms affected before the details leak. On Mon, Dec 30, 2013 at 6:29 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Dec 30, 2013, at 6:18 PM, Saku Ytti s...@ytti.fi wrote: I welcome the short-term havok and damage of such disclose if it would be anywhere near the magnitude implied, it would create pressure to change things. This is the type of change we're likely to see, IMHO: http://lauren.vortex.com/archive/001074.html --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Mon, Dec 30, 2013 at 8:07 AM, Ray Soucy r...@maine.edu wrote: I hope Cisco, Juniper, and others respond quickly with updated images for all platforms affected before the details leak. So, if this plays out nice (if true, it won't), the fix will come months before the disclosure. Think, if you're leasing a router from your ISP, you might not have the ability to update it (or might violate your contract). So, you need to wait for [manufacturer] to update, test, and release an update, then you need to work with your provider to make sure the update gets pushed correctly. Also, even open hardware isn't completely open - see the Pi - probably the most open of hardware stacks. The CPU isn't completely open. Also, see FreeBSD not using hardware PRNG for this reason.
Re: The state of TACACS+
I don't think radius nor kerberos nor ssh with certificates supports command authorization, do they? On Dec 30, 2013 6:33 AM, Saku Ytti s...@ytti.fi wrote: On (2013-12-30 05:06 -0500), Robert Drake wrote: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there If continued existence of TACACS+ can be justified at IETF level, in parallel with radius and diameter, I have some interest in the subject and would be ready to work with draft. Encryption: For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it It seems encryption is your only/major woe? Personally I don't like how we need to keep reimplementing crypto per-application level. We're living in a world where crypto should be standard for all connection, not application issue. There are some solutions to this like BEEP framework or new L4 protocol like QUIC and MinimaLT, any of which I think would be workable as mandatory transport for TACACS. Clients: official version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly There is also commercial server 'radiator' which does radius and tacacs amongst others. Did everyone already know this but me? If so have you moved to I think I missed the key revelation. The naive encryption? The limited amount of software available? Kerberos? Can Kerberos do everything TACACS+ was doing for router I think from networker point of view, it's radiator or tacacs, if it has to work today without new software. And if it can require new software, it can be pretty much arbitrary new protocol, if sound justification can be found. -- ++ytti
Re: The state of TACACS+
Nor accounting... On Dec 30, 2013 8:48 AM, Christopher Morrow christopher.mor...@gmail.com wrote: I don't think radius nor kerberos nor ssh with certificates supports command authorization, do they? On Dec 30, 2013 6:33 AM, Saku Ytti s...@ytti.fi wrote: On (2013-12-30 05:06 -0500), Robert Drake wrote: TACACS+ was proposed as a standard to the IETF. They never adopted it and let the standards draft expire in 1998. Since then there If continued existence of TACACS+ can be justified at IETF level, in parallel with radius and diameter, I have some interest in the subject and would be ready to work with draft. Encryption: For new crypto I would advise multiple cipher support with negotiation so you know what each client and server is capable of. If the client and server supported multiple keys (with a keyid) it It seems encryption is your only/major woe? Personally I don't like how we need to keep reimplementing crypto per-application level. We're living in a world where crypto should be standard for all connection, not application issue. There are some solutions to this like BEEP framework or new L4 protocol like QUIC and MinimaLT, any of which I think would be workable as mandatory transport for TACACS. Clients: official version that debian and freebsd use. I looked at some of the others and they all seemed to derive from Cisco's code directly There is also commercial server 'radiator' which does radius and tacacs amongst others. Did everyone already know this but me? If so have you moved to I think I missed the key revelation. The naive encryption? The limited amount of software available? Kerberos? Can Kerberos do everything TACACS+ was doing for router I think from networker point of view, it's radiator or tacacs, if it has to work today without new software. And if it can require new software, it can be pretty much arbitrary new protocol, if sound justification can be found. -- ++ytti
Re: The state of TACACS+
On (2013-12-30 08:49 -0500), Christopher Morrow wrote: Nor accounting... I think this is probably sufficient justification for TACACS+. I'm not sure if command authorization is sufficient, as you can deliver group via radius which maps to authorized commands. But if you must support accounting, per-command authorization comes as free gift more or less. -- ++ytti
Re: The state of TACACS+
Hi, On Mon, 30 Dec 2013, Christopher Morrow wrote: I don't think radius nor kerberos nor ssh with certificates supports command authorization, do they? it is with radius afaik ... Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
Re: The state of TACACS+
On Dec 30, 2013 9:01 AM, Saku Ytti s...@ytti.fi wrote: On (2013-12-30 08:49 -0500), Christopher Morrow wrote: Nor accounting... I think this is probably sufficient justification for TACACS+. I'm not sure if command authorization is sufficient, as you can deliver group via radius which maps to authorized commands. But if you must support accounting, per-command authorization comes as free gift more or less. Yes. Per-command auth and accounting is needed. So what we need is tacacs over TLS (sctp / ipv6) I agree tacacs is long in the tooth and needs to be revisited and invested in. Please take my money (serious) CB -- ++ytti
Re: The state of TACACS+
On Dec 30, 2013, at 9:01 AM, Christian Kratzer ck-li...@cksoft.de wrote: Hi, On Mon, 30 Dec 2013, Christopher Morrow wrote: I don't think radius nor kerberos nor ssh with certificates supports command authorization, do they? it is with radius afaik ... RADIUS does not support command authorization or accounting. -jav
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 8:07 PM, Ray Soucy r...@maine.edu wrote: I hope Cisco, Juniper, and others respond quickly with updated images for all platforms affected before the details leak. During my time at Cisco, I was involved deeply enough with various platform teams as well as PSIRT, etc., to assert with a pretty high degree of confidence that there were no deliberate secret backdoors inserted into any major Cisco router/switch code prior to 2009, when I left Cisco. And Cisco is such a large company, with so many people involved in coding, compilation, auditing, security issue remediation, et. al. that I doubt very seriously that something like that could be accomplished without leaking pretty promptly. In terms of exploits, the Cisco PSIRT team work with security researchers all the time; while I wasn't a member of PSIRT, I worked very closely with them, and if they'd run across something like that prior to 2009, I'm pretty sure I'd know about it. Every so often, they'd find a non-router/-switch product with default admin credentials, and would work with the product team in question to fix it (this is all public knowledge; you can look through PSIRT advisories on cisco.com and find advisories for default admin credentials for various products, along with links to fixed software versions). And I was also pretty well-acquainted with most of the major software/platform architects, some of whom are still there; none of them would be a party to something like a hidden backdoor, because they all know that it would only be a matter of time until it was found and exploited. The lawful intercept stuff is a partial exception to this, but Fred Baker, Chip Sharp, and Bill Foster went out of their way to proof it as much as possible against unauthorized exploitation, as long as it's implemented correctly, and they put it out there in the public domain via RFC3924. In point of fact, RFC3924 was intended to pre-empt pressure for secret backdoors from LEAs; the idea was to get something that was reasonably secure if implemented correctly out there in the public domain, and adopted as a standard, so that network infrastructure vendors could point to an RFC in order to fend off demands for all this secret-squirrel nonsense. Lawful intercept systems have been exploited in the wild by malicious insiders, but none of the incidents I know about involved Cisco gear. CVE-2008-0960 indirectly impacted lawful intercept due to its SNMP management plane, but responsible network operators should've patched this by now, and should've implemented all the generic BCPs surrounding management-plane traffic, as well. I can't speak for the various third-party lawful-intercept mediation systems, as I've no firsthand knowledge of those. My assumption is that this allegation about Cisco and Juniper is the result of non-specialists reading about lawful intercept for the first time, and failing to do their homework. I don't work for Cisco, and I can't speak for them, but I simply don't find the allegation that there are backdoors hidden in Cisco router/switch code to be credible. Maybe I'm wrong; but since folks are constantly fuzzing Cisco code and looking for ways to exploit it, my guess is that any backdoors would've been found and exploits would be in use in the wild to such a degree that it would've become apparently a long time ago. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
RE: NSA able to compromise Cisco, Juniper, Huawei switches
I'd love to know how they were getting in flight wifi. Sent from my Mobile Device. Original message From: sten rulz stenr...@gmail.com Date: 12/30/2013 12:32 AM (GMT-09:00) To: nanog@nanog.org Subject: NSA able to compromise Cisco, Juniper, Huawei switches Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven.
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Mon, 30 Dec 2013 14:34:52 +, Dobbins, Roland said: My assumption is that this allegation about Cisco and Juniper is the result of non-specialists reading about lawful intercept for the first time, and failing to do their homework. That does raise an interesting question. What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? pgp8jGvrDqnsl.pgp Description: PGP signature
Re: turning on comcast v6
From: Matthew Petach mpet...@netflight.com Date: Saturday, December 21, 2013 10:55 PM To: Lee Howard l...@asgard.org Cc: Jamie Bowden ja...@photon.com, Owen DeLong o...@delong.com, m...@kenweb.org m...@kenweb.org, nanog@nanog.org nanog@nanog.org So there's an interesting question. You suggest there's a disagreement between enterprise network operators and protocol designers. Who should change? I used to run an enterprise network. It was very different from an ISP network. I didn't say, You're wrong! I said, What's missing? default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Lee Matt
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton signature.asc Description: Message signed with OpenPGP using GPGMail
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 11:03 PM, Dobbins, Roland rdobb...@arbor.net wrote: AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. It's also possible they're talking about something along these lines: http://ids.cs.columbia.edu/sites/default/files/paper.pdf --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton signature.asc Description: Message signed with OpenPGP using GPGMail
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On 12/30/2013 08:03 AM, Dobbins, Roland wrote: On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. Also, the way that things are integrated it's usually an explicit decision to pull a piece of functionality in rather than inheriting it. Product managers don't willingly want to waste time pulling things in that a) don't make them money, and b) require support. So I doubt very seriously that CALEA functionality is accidentally included into inappropriate things. Doubly so because of the performance implications. Mike
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Mon, Dec 30, 2013 at 04:03:07PM +, Dobbins, Roland wrote: On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term private m ight be enough to perform the task remotely. have a good one Enno --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: turning on comcast v6
On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Why must the people who want it justify to _you_? This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got to where it is by letting people extend it and develop new protocols and solutions. DHCP did not exist when IPv4 was created, it was tacked on later. Now people want to tack something on to IPv6 to make it more useful to them. Why do they need to explain it to you, if it doesn't affect your deployments at all? Some of us think the model where a DHCP server knows the subnet and hands out a default gateway provides operational advantages. It's an opinion. And the current IPv6 crowds view that not having a default route and relaying on RA's is better is also an opinion. We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. Put it in their, and let the market sort it out, unless you can justify some dire harm from doing so. What is more important fast IPv6 adoption or belittling people who want to deploy it in some slightly different way than you did? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: NSA able to compromise Cisco, Juniper, Huawei switches
This might be an interesting example of it's (mis)use. http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 Sam Moats On 2013-12-30 11:16, Enno Rey wrote: On Mon, Dec 30, 2013 at 04:03:07PM +, Dobbins, Roland wrote: On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term private m ight be enough to perform the task remotely. have a good one Enno --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On 12/30/2013 9:05 AM, Warren Bailey wrote: I'd love to know how they were getting in flight wifi. Sent from my Mobile Device. Original message From: sten rulz stenr...@gmail.com Date: 12/30/2013 12:32 AM (GMT-09:00) To: nanog@nanog.org Subject: NSA able to compromise Cisco, Juniper, Huawei switches Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven. Simple. Grab it from where it hits the base stations. One of the two big in-flight Wifi carriers in the US uses Sprint towers, I believe the other used satellite. They have to get back to a ground station somewhere in order to get network access. Easy to tap it there and send it wherever you want. Grabbing an ad-hoc signal between two endpoints in the air is probably significantly more involved. Implementation of this is left as an exercise for the VERY well-funded reader. ;-) Jeremy TheBrez Bresley b...@brezworks.com
Re: NSA able to compromise Cisco, Juniper, Huawei switches
We had a hell of a time finding anything that supported the calea stuff past a 7206. This was for an in flight global wifi network, hence my original concern. Also note that when we did get it to work, it pretty much didn't. Or I should say.. It worked when it wanted to. How they are mapping pnr to user sessions is beyond me. In our case all of our aaa was being done by a German partner, which further complicated matters. I always assumed they had our traffic via listening stations but they weren't getting it from us. I no longer have a hand in that network, but I am honestly shocked this morning. Sent from my Mobile Device. Original message From: valdis.kletni...@vt.edu Date: 12/30/2013 6:48 AM (GMT-09:00) To: Dobbins, Roland rdobb...@arbor.net Cc: nanog@nanog.org list nanog@nanog.org Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches On Mon, 30 Dec 2013 14:34:52 +, Dobbins, Roland said: My assumption is that this allegation about Cisco and Juniper is the result of non-specialists reading about lawful intercept for the first time, and failing to do their homework. That does raise an interesting question. What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed?
Re: NSA able to compromise Cisco, Juniper, Huawei switches
I built the other. Sent from my Mobile Device. Original message From: Jeremy Bresley b...@brezworks.com Date: 12/30/2013 7:34 AM (GMT-09:00) To: nanog@nanog.org Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches On 12/30/2013 9:05 AM, Warren Bailey wrote: I'd love to know how they were getting in flight wifi. Sent from my Mobile Device. Original message From: sten rulz stenr...@gmail.com Date: 12/30/2013 12:32 AM (GMT-09:00) To: nanog@nanog.org Subject: NSA able to compromise Cisco, Juniper, Huawei switches Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven. Simple. Grab it from where it hits the base stations. One of the two big in-flight Wifi carriers in the US uses Sprint towers, I believe the other used satellite. They have to get back to a ground station somewhere in order to get network access. Easy to tap it there and send it wherever you want. Grabbing an ad-hoc signal between two endpoints in the air is probably significantly more involved. Implementation of this is left as an exercise for the VERY well-funded reader. ;-) Jeremy TheBrez Bresley b...@brezworks.com
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 11:16 PM, Enno Rey e...@ernw.de wrote: at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term private might be enough to perform the task remotely. SNMP RW = configuration. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 11:18 PM, Sam Moats s...@circlenet.us wrote: This might be an interesting example of it's (mis)use. http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 That's one of the cases I know about; it was utilized via Ericsson gear. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Looking more at the actual leaked information it seems that if the NSA is working with companies, it's not anything the companies are likely aware of. The common form of infection seems to be though software updates performed by administrators (through the NSA hijacking web traffic). They are implimented as firmware and BIOS infections that modify the OS image and persist through software upgrades to provide a persistant back door (PBD). The documents imply that a signiciant of systems deployed are already infected. So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Where exatcly the NSA is inserting these we can't be sure. They could be targeted or they could be at the assembly line. Quick Summary of Leaked Information: Source: http://www.spiegel.de/international/world/a-941262.html Firewalls: (1) Cisco PIX and ASA: Codename JETPLOW (2) Huawei Eudemon: Codename HALLUXWATER (3) Juniper Netscreen and ISG: Codename: FEEDTROUGH (4) Juniper SSG and Netscreen G5, 25, and 50, SSG-series: Codename: GOURMETTROUGH (5) Juniper SSG300 and SSG500: Codename SOUFFLETROUGH Routers: (1) Huawei Router: Codename HEADWATER (2) Juniper J-Series: Codename SCHOOLMONTANA (3) Juniper M-Series: Codename SIERRAMONTANA (4) Juniper T-Series: Codename STUCCOMONTANA Servers: (1) HP DL380 G5: Codename IRONCHEF (2) Dell PowerEdge: Codename DEITYBOUNCE (3) Generic PC BIOS: Codename SWAP, able to compromise Windows, Linux, FreeBSD, or Solaris using FAT32, NTFS, EXT2, EXT3, or UFS filesystems. USB Cables and VGA Cables: Codename COTTONMOUTH, this one is a hardware implmant hidden in a USB cable. The diagram shows it's small enough that you would never know its there. Codename RAGEMASTER, VGA cable, mirrors VGA over the air. Many others. I'm not sure that the list is comprehensive, so I wouldn't say that since Cisco routers are not mentioned (for example) that they're any more safe than Juniper (which is listed often). On Mon, Dec 30, 2013 at 11:50 AM, Dobbins, Roland rdobb...@arbor.netwrote: On Dec 30, 2013, at 11:18 PM, Sam Moats s...@circlenet.us wrote: This might be an interesting example of it's (mis)use. http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005 That's one of the cases I know about; it was utilized via Ericsson gear. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: turning on comcast v6
You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? this is actually a non-trivial barrier to enterprise deployment and the ietf has been in stubborn denial for years. when an it department has been using dhcp since 2000, do not tell them they have to change to the true religion. fighting with the customer, thoubgh the ipv6 way, is not generally a path to success. randy
Re: turning on comcast v6
On Tue, 24 Dec 2013, Lee Howard wrote: I used to run an enterprise network. It was very different from an ISP network. I didn't say, You're wrong! I said, What's missing? default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? DHCPv6 + RA works for that, but still, that really should have been part of the protocol from day one. I see no good reason for it not to be in there. I suspect that will eventually be fixed, but it will be a long time before the majority of DHCPv6 client and server implementations are upgraded to support it. jms
Re: turning on comcast v6
On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Lee There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there’s little interest (read: budget) in rewriting everything for IPv6. 'Rewrite all of your tools and change your long standing business practices’ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn’t fit into the “IPv6 way,” but bean counters don’t care much for that when you have to ask for developer time to rewrite everything. Disclaimer: I don’t condone said methods and trickery mentioned above, just pointing out their use. /Ryan
RE: NSA able to compromise Cisco, Juniper, Huawei switches
NANOG: Here's the really scary question for me. Would it be possible for NSA-payload traffic that originates on our private networks that is destined for the NSA to go undetected by our IDS systems? For example tcpdump-based IDS systems like Snort has been rooted to ignore or not report packets going back to the NSA? Or netflow on Cisco devices not reporting NSA traffic? Or interface traffic counters discarding NSA-packets to report that there is no usage on the interface when in fact there is? Here's another question. What traffic do we look for on our networks that would be going to the NSA? Thoughts? (And semi-self-consciously adding myself to the NSA list of targets.) Lorell Hathcock -Original Message- From: Ray Soucy [mailto:r...@maine.edu] Sent: Monday, December 30, 2013 11:01 AM To: Dobbins, Roland Cc: nanog@nanog.org list Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches Looking more at the actual leaked information it seems that if the NSA is working with companies, it's not anything the companies are likely aware of. The common form of infection seems to be though software updates performed by administrators (through the NSA hijacking web traffic). They are implimented as firmware and BIOS infections that modify the OS image and persist through software upgrades to provide a persistant back door (PBD). The documents imply that a signiciant of systems deployed are already infected. So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Where exatcly the NSA is inserting these we can't be sure. They could be targeted or they could be at the assembly line. Quick Summary of Leaked Information: Source: http://www.spiegel.de/international/world/a-941262.html Firewalls: (1) Cisco PIX and ASA: Codename JETPLOW (2) Huawei Eudemon: Codename HALLUXWATER (3) Juniper Netscreen and ISG: Codename: FEEDTROUGH (4) Juniper SSG and Netscreen G5, 25, and 50, SSG-series: Codename: GOURMETTROUGH (5) Juniper SSG300 and SSG500: Codename SOUFFLETROUGH Routers: (1) Huawei Router: Codename HEADWATER (2) Juniper J-Series: Codename SCHOOLMONTANA (3) Juniper M-Series: Codename SIERRAMONTANA (4) Juniper T-Series: Codename STUCCOMONTANA Servers: (1) HP DL380 G5: Codename IRONCHEF (2) Dell PowerEdge: Codename DEITYBOUNCE (3) Generic PC BIOS: Codename SWAP, able to compromise Windows, Linux, FreeBSD, or Solaris using FAT32, NTFS, EXT2, EXT3, or UFS filesystems. USB Cables and VGA Cables: Codename COTTONMOUTH, this one is a hardware implmant hidden in a USB cable. The diagram shows it's small enough that you would never know its there. Codename RAGEMASTER, VGA cable, mirrors VGA over the air. Many others. I'm not sure that the list is comprehensive, so I wouldn't say that since Cisco routers are not mentioned (for example) that they're any more safe than Juniper (which is listed often). On Mon, Dec 30, 2013 at 11:50 AM, Dobbins, Roland rdobb...@arbor.netwrote: On Dec 30, 2013, at 11:18 PM, Sam Moats s...@circlenet.us wrote: This might be an interesting example of it's (mis)use. http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%93200 5 That's one of the cases I know about; it was utilized via Ericsson gear. -- - Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Mon, Dec 30, 2013 at 1:17 PM, Lorell Hathcock lor...@hathcock.org wrote: NANOG: Here's the really scary question for me. Would it be possible for NSA-payload traffic that originates on our private networks that is destined for the NSA to go undetected by our IDS systems? Yup. Absolutely. Without a doubt. For example tcpdump-based IDS systems like Snort has been rooted to ignore or not report packets going back to the NSA? Or netflow on Cisco devices not reporting NSA traffic? Or interface traffic counters discarding NSA-packets to report that there is no usage on the interface when in fact there is? Do you detect 100% of malware in your IDS? Why would anyone need to do anything with your IDS? Craft a PDF, DOC, Java, Flash, or anything else that can run code that people download all the time with payload of unknown signature. This isn't really a network discussion. This is just to say - I seriously doubt there's anything wrong with your IDS - don't skin a cat with a flame thrower, it just doesn't need to be that hard. Here's another question. What traffic do we look for on our networks that would be going to the NSA? Standard https on port 443 maybe? That's how I'd send it. If you need to send something bigger than normal, maybe compromise the email server and have a few people send off some 5 - 10 meg messages? Depends on your normal user base. If you've got a big, complex user base, it's not hard to stay under the radar. Google 'Mandiant APT1' for some real good reading.
Re: turning on comcast v6
On 12/30/13 11:19 AM, Leo Bicknell bickn...@ufp.org wrote: On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Why must the people who want it justify to _you_? They don't; they have to justify it to the DHC WG at IETF, in order to generate consensus. This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got to where it is by letting people extend it and develop new protocols and solutions. DHCP did not exist when IPv4 was created, it was tacked on later. Now people want to tack something on to IPv6 to make it more useful to them. Why do they need to explain it to you, if it doesn't affect your deployments at all? You can provision your network any way you like. If you want to create a custom version of DHCP (or your own provisioning protocol), that's fine. There doesn't seem to be consensus that default gateway in DHCP is a good idea. There's running code for how to change this. Some of us think the model where a DHCP server knows the subnet and hands out a default gateway provides operational advantages. It's an opinion. And the current IPv6 crowds view that not having a default route and relaying on RA's is better is also an opinion. We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. Put it in their, and let the market sort it out, unless you can justify some dire harm from doing so. I don't like the let many flowers bloom model of protocol development. You end up with a lot of cruft in protocols. Successful protocols tend not to have that (at least, when they become successful). I don't know if it will do harm (though it's easy to imagine DHCP not aligning with default gateways in modern, more mobile networks). But if the barrier for adding fields is Eh, it probably won't cause dire harm then we would have pretty messy protocols. What is more important fast IPv6 adoption or belittling people who want to deploy it in some slightly different way than you did? Did I belittle anybody? I apologize if I did that. It certainly was not my intent. I'm trying to understand a point of view. Lee -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On a side note, I've been involved with organizing the New England regional Collegiate Cyber-Defense Competition for a while, and one our Red Team members was able to make a pretty convincing IOS rootkit using IOS TCL scripting to mask configuration from the students. I don't think any students were able to detect it until word got out after it was used a few years in a row. IIRC, Cisco threatened to sue if it was ever released, so no it's not publicly available. It is possible, however. Don't assume that your routers are any safer than your servers. :-) On Mon, Dec 30, 2013 at 1:35 PM, shawn wilson ag4ve...@gmail.com wrote: On Mon, Dec 30, 2013 at 1:17 PM, Lorell Hathcock lor...@hathcock.org wrote: NANOG: Here's the really scary question for me. Would it be possible for NSA-payload traffic that originates on our private networks that is destined for the NSA to go undetected by our IDS systems? Yup. Absolutely. Without a doubt. For example tcpdump-based IDS systems like Snort has been rooted to ignore or not report packets going back to the NSA? Or netflow on Cisco devices not reporting NSA traffic? Or interface traffic counters discarding NSA-packets to report that there is no usage on the interface when in fact there is? Do you detect 100% of malware in your IDS? Why would anyone need to do anything with your IDS? Craft a PDF, DOC, Java, Flash, or anything else that can run code that people download all the time with payload of unknown signature. This isn't really a network discussion. This is just to say - I seriously doubt there's anything wrong with your IDS - don't skin a cat with a flame thrower, it just doesn't need to be that hard. Here's another question. What traffic do we look for on our networks that would be going to the NSA? Standard https on port 443 maybe? That's how I'd send it. If you need to send something bigger than normal, maybe compromise the email server and have a few people send off some 5 - 10 meg messages? Depends on your normal user base. If you've got a big, complex user base, it's not hard to stay under the radar. Google 'Mandiant APT1' for some real good reading. -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: turning on comcast v6
On 12/30/13 1:04 PM, Ryan Harden harde...@uchicago.edu wrote: On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Lee There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there¹s little interest (read: budget) in rewriting everything for IPv6. Thank you very much for presenting an actual use case. Seems like a dot1x kind of application, where the host is in a temporary VLAN until authenticated (etc.), right? Same use case, different network solution. 'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything. Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, Make sure you call IP family agnostic libraries and increase field sizes, then let it run and Rebuild your network security. DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. As for why not add it? my answer is that if it's needed, we should add it. If it's not needed, we should not add it. I want default gateway in DHCPv6 does not answer the question of whether it's needed, which is why I asked why. Disclaimer: I don¹t condone said methods and trickery mentioned above, just pointing out their use. Will consider more. Lee /Ryan
Re: NSA able to compromise Cisco, Juniper, Huawei switches
IIRC, Cisco threatened to sue if it was ever released you gotta love it. they will roll over and piss themselves for nsa and other who are violating every principle, but threaten paying customers who would report a hole. the question is what have these companies and gov people not violated? randy
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Hi all, I've been watching this list for a couple weeks now and while risking beeing flamed, i just wanted to say that any network professional that puts any equipment into production without securing it against the kind of issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and should be fired on the spot. These are not backdoor issues, NSA related, whatever... This is noise. Trying to get this thread on track, can the original poster provide any proof of this so called ability of the so called inteligence agency beeing able to access cisco/juniper, taking into account that management access has been correctly configured ? Regards -Marco --- Cumprimentos / Best regards Marco Teixeira email/gtalk/msn: ad...@marcoteixeira.com skype: admin-marcoteixeira.com --- Did you know that Marco Teixeira is an independent, industry expert, senior consultant ? His expertise is available for hire. --- On Mon, Dec 30, 2013 at 4:16 PM, Enno Rey e...@ernw.de wrote: On Mon, Dec 30, 2013 at 04:03:07PM +, Dobbins, Roland wrote: On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/] so knowing the term private m ight be enough to perform the task remotely. have a good one Enno --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: turning on comcast v6
On Dec 30, 2013, at 12:58 PM, Lee Howard l...@asgard.org wrote: 'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything. Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, Make sure you call IP family agnostic libraries and increase field sizes, then let it run and Rebuild your network security. DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. Updating tools to add a box for IPv6 fields and tweaking the backend to generate a config file for DHCPv6 which is very similar to DHCP(for v4) is a lot different/easier than having to rewrite and/or split your backend to generate output in a completely different format. However, I'm not as familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. And you don't have to support IPv6 from top to bottom to roll out IPv6 to users. So rewriting for socket support isn't necessary day one. You can route IPv6 for users so they can reach the IPv6 world quickly, then add local services as time/money allows. The biggest driver for IPv6 will be external resources available only via IPv6, not local. (Of course this is from the point of view where your business' primary service isn't outward facing resources.) I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by fully dynamic DHCP, some who do DHCP-Reservations, and some who go static only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 needs to be flexible enough to handle the fact that not everyone builds identical architectures nor do they have the exact same needs. Being able to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. Forcing everyone down the same path will just lead to stupid proprietary solutions to a problem that shouldn't exist in the first place. /Ryan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: NSA able to compromise Cisco, Juniper, Huawei switches
There are many ways a backdoor could be used in a properly secured system. To think otherwise is a huge mistake. I can think of several ways, if tasked and given the resources of a large gov't that I would attack this problem. To assume that those tasked and focused only this type of solution aren't even more capable would be foolhardy. -jim On Mon, Dec 30, 2013 at 12:28 PM, Marco Teixeira ad...@marcoteixeira.comwrote: Hi all, I've been watching this list for a couple weeks now and while risking beeing flamed, i just wanted to say that any network professional that puts any equipment into production without securing it against the kind of issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and should be fired on the spot. These are not backdoor issues, NSA related, whatever... This is noise. Trying to get this thread on track, can the original poster provide any proof of this so called ability of the so called inteligence agency beeing able to access cisco/juniper, taking into account that management access has been correctly configured ? Regards -Marco --- Cumprimentos / Best regards Marco Teixeira email/gtalk/msn: ad...@marcoteixeira.com skype: admin-marcoteixeira.com --- Did you know that Marco Teixeira is an independent, industry expert, senior consultant ? His expertise is available for hire. --- On Mon, Dec 30, 2013 at 4:16 PM, Enno Rey e...@ernw.de wrote: On Mon, Dec 30, 2013 at 04:03:07PM +, Dobbins, Roland wrote: On Dec 30, 2013, at 10:44 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: What percentage of Cisco gear that supports a CALEA lawful intercept mode is installed in situations where CALEA doesn't apply, and thus there's a high likelyhood that said support is misconfigured and abusable without being noticed? AFAIK, it must be explicitly enabled in order to be functional. It isn't the sort of thing which is enabled by default, nor can it be enabled without making explicit configuration changes. at least back in 2007 it could be enabled/configured by SNMP RW access [see slide 43 of the presentation referenced in this post http://www.insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/ ] so knowing the term private m ight be enough to perform the task remotely. have a good one Enno --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: turning on comcast v6
The better question is are you using RIP or ICMP to set gateways in your network now? If you don't use those now, why is RA a better solution in ipv6? -Blake On Mon, Dec 30, 2013 at 1:20 PM, Ryan Harden harde...@uchicago.edu wrote: On Dec 30, 2013, at 12:58 PM, Lee Howard l...@asgard.org wrote: 'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything. Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, Make sure you call IP family agnostic libraries and increase field sizes, then let it run and Rebuild your network security. DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. Updating tools to add a box for IPv6 fields and tweaking the backend to generate a config file for DHCPv6 which is very similar to DHCP(for v4) is a lot different/easier than having to rewrite and/or split your backend to generate output in a completely different format. However, I'm not as familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. And you don't have to support IPv6 from top to bottom to roll out IPv6 to users. So rewriting for socket support isn't necessary day one. You can route IPv6 for users so they can reach the IPv6 world quickly, then add local services as time/money allows. The biggest driver for IPv6 will be external resources available only via IPv6, not local. (Of course this is from the point of view where your business' primary service isn't outward facing resources.) I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by fully dynamic DHCP, some who do DHCP-Reservations, and some who go static only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 needs to be flexible enough to handle the fact that not everyone builds identical architectures nor do they have the exact same needs. Being able to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. Forcing everyone down the same path will just lead to stupid proprietary solutions to a problem that shouldn't exist in the first place. /Ryan
Re: turning on comcast v6
On 12/30/13 2:20 PM, Ryan Harden harde...@uchicago.edu wrote: On Dec 30, 2013, at 12:58 PM, Lee Howard l...@asgard.org wrote: 'Rewrite all of your tools and change your long standing business practices¹ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn¹t fit into the ³IPv6 way,² but bean counters don¹t care much for that when you have to ask for developer time to rewrite everything. Well, the tools have to be rewritten to support IPv6 fields, sockets, and structures anyway. However, there's a difference between, Make sure you call IP family agnostic libraries and increase field sizes, then let it run and Rebuild your network security. DHCP+RA just works in most networks; this is a use case where it could be made to work, but only by changing the network. Updating tools to add a box for IPv6 fields and tweaking the backend to generate a config file for DHCPv6 which is very similar to DHCP(for v4) is a lot different/easier than having to rewrite and/or split your backend to generate output in a completely different format. However, I'm not as familiar with RADVD as I am with isc-dhcpd so that might be a bad argument. And you don't have to support IPv6 from top to bottom to roll out IPv6 to users. So rewriting for socket support isn't necessary day one. You can route IPv6 for users so they can reach the IPv6 world quickly, then add local services as time/money allows. The biggest driver for IPv6 will be external resources available only via IPv6, not local. (Of course this is from the point of view where your business' primary service isn't outward facing resources.) I agree with you on the above, I just didn't say so very well. I'm sure DHCP+RA works for most, but there are IPv4 shops who swear by fully dynamic DHCP, some who do DHCP-Reservations, and some who go static only. Just like some shops are EIGRP, some OSPF, and some ISIS. IMO IPv6 needs to be flexible enough to handle the fact that not everyone builds identical architectures nor do they have the exact same needs. Being able to use DHCPv6+RA, RA only, or DHCPv6 only should all be viable options. Forcing everyone down the same path will just lead to stupid proprietary solutions to a problem that shouldn't exist in the first place. All of those cases work just as well with DHCP+RA. Only in cases where a router on a subnet is not the correct gateway is RA a problem, AFAIK. You gave one example where that's the case. Another would be where there are two gateways for the same network segment, which don't share an IP address, and you want DHCP to tell hosts which one they should use (rather than, say, manual configuration or GPO). DHCP and RAs do different things. DHCP does host configuration. Router Advertisements advertise routers. When you have both, you can leave off a field in DHCP, and rely on the network to route the packets. Turning off RAs and putting that information into DHCP for each subnet you manage means additional work. It's not a lot of work, admittedly. Lee /Ryan
Re: turning on comcast v6
I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. From: Blake Dunlap iki...@gmail.com Date: Monday, December 30, 2013 3:19 PM To: Ryan Harden harde...@uchicago.edu Cc: Lee Howard l...@asgard.org, Jamie Bowden ja...@photon.com, nanog@nanog.org nanog@nanog.org Subject: Re: turning on comcast v6 The better question is are you using RIP or ICMP to set gateways in your network now? I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of. If you don't use those now, why is RA a better solution in ipv6? It's built into the fundamentals of IPv6, using the Neighbor Discovery Protocol. It's supported in every stack. It's the default mode of operation. To turn it off, you have to disable part, but not all, of NDP. (Do you also turn off RSs on all hosts?) There could be better solutions; I would like to understand how they are better. Again, in your network, you can do whatever you want. If you want something different standardized, then you need consensus here: https://www.ietf.org/mailman/listinfo/dhcwg Lee
Re: NSA able to compromise Cisco, Juniper, Huawei switches
These are not backdoor issues, NSA related, whatever... This is noise. Trying to get this thread on track, can the original poster provide any proof of this so called ability of the so called inteligence agency beeing able to access cisco/juniper, taking into account that management access has been correctly configured ? since you don't seem to read the articles, perhaps an info-graphic http://www.spiegel.de/international/world/a-941262.html randy
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Hi Folks - Clay Kossmeyer here from the Cisco PSIRT. We've published the following document in response to the original (Dec. 29) Der Spiegel article: http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel and are investing the claims in the Dec. 30 Der Spiegel article referencing 'persistent implants' for the PIX and ASA product lines under case number PSIRT-1384943056. Any vulnerabilities we discover will be disclosed via our standard vulnerability handling process documented here: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html I'm not currently subscribed to NANOG, so if you have a reply you'd like me to see, please copy me directly. Regards, Clay - Found some interesting news on one of the Australia news websites. http://www.scmagazine.com.au/News/368527,nsa-able-to-compromise-cisco-juniper-huawei-switches.aspx Regards, Steven. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 30, 2013, at 8:19 AM, Leo Bicknell bickn...@ufp.org wrote: On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Why must the people who want it justify to _you_? In a consensus process, it is not unusual or uncommon for the group to expect a justification for a topic seeking consensus. This is fundamental part I've not gotten about the IPv6 crowd. IPv4 got to where it is by letting people extend it and develop new protocols and solutions. DHCP did not exist when IPv4 was created, it was tacked on later. Now people want to tack something on to IPv6 to make it more useful to them. Why do they need to explain it to you, if it doesn't affect your deployments at all? To the best of my knowledge, those same questions have been asked about all of the IPv4 protocols in the IETF development process, too. If he wants to just go mod his DHCP daemons, he’s welcome to do that. If he wants IETF consensus around a change to the DHCP protocol, then it’s not at all unreasonable for him to have to justify that position to the IETF. Some of us think the model where a DHCP server knows the subnet and hands out a default gateway provides operational advantages. It's an opinion. And the current IPv6 crowds view that not having a default route and relaying on RA's is better is also an opinion. Sure, but here’s where you break down… The current situation isn’t attributable to “the current IPv6 crowd” (whoever that is), it’s the current IETF consensus position. Changing that IETF consensus position is a matter of going through the IETF process and getting a new consensus. That requires justifying your position and convincing enough people willing to actively participate in the working group process of that position. I like to think that I would be part of almost any valid definition of “the current IPv6 crowd”. While I do think that RAs are a better mechanism for most situations, I also support the inclusion of information equivalent to RIOs in DHCP options. We've spent years of wasted bits and oxygen on ONE STUPID FIELD IN DHCP. Put it in their, and let the market sort it out, unless you can justify some dire harm from doing so. It shouldn’t be one stupid field, even if we do put it in. It should be an additional option for providing zero or more RIOs. What is more important fast IPv6 adoption or belittling people who want to deploy it in some slightly different way than you did? I do not think it is legitimate to say that asking for justification for a position is belittling. Owen
Re: turning on comcast v6
On Dec 30, 2013, at 10:04 AM, Ryan Harden harde...@uchicago.edu wrote: On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Lee There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there’s little interest (read: budget) in rewriting everything for IPv6. While I do not oppose the inclusion of Routing Information into DHCPv6, I have to say that this seems to be one of the weaker arguments. Please permit me to repeat your statement from an IPv6 perspective… Because many places have poorly thought out cruft that deals with deficiencies in IPv4 by doing stunts that won’t work in the current IPv6 implementation and because we don’t want to rewrite our cruft to take advantage of the cleaner solutions available for these problems in IPv6, we demand that you include the cruft from IPv4 into IPv6 in order to support this hackery. 'Rewrite all of your tools and change your long standing business practices’ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn’t fit into the “IPv6 way,” but bean counters don’t care much for that when you have to ask for developer time to rewrite everything. You have to rewrite all your tools to handle the bigger addresses anyway. While you’re at it, why not rewrite them to take advantage of cleaner solutions? Disclaimer: I don’t condone said methods and trickery mentioned above, just pointing out their use. So you’re defending a position you don’t share? Interesting tactic. Owen
Re: turning on comcast v6
On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard l...@asgard.org wrote: I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. From: Blake Dunlap iki...@gmail.com Date: Monday, December 30, 2013 3:19 PM To: Ryan Harden harde...@uchicago.edu Cc: Lee Howard l...@asgard.org, Jamie Bowden ja...@photon.com, nanog@nanog.org nanog@nanog.org Subject: Re: turning on comcast v6 The better question is are you using RIP or ICMP to set gateways in your network now? I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of. [VK] The RIP comparison is somewhat confusing to me. I don't see how RIP is comparable in this context (I guess technically you can pass a default route in RIP, but as Lee mentions, the protocol is designed for a different purpose and requires configuration). I guess the ICMP reference fair as Neighbor Discovery is built on ICMP (which is a good thing in my opinion). Perhaps the reference here was to people not using RFC1256 in their networks? If you don't use those now, why is RA a better solution in ipv6? It's built into the fundamentals of IPv6, using the Neighbor Discovery Protocol. It's supported in every stack. It's the default mode of operation. To turn it off, you have to disable part, but not all, of NDP. (Do you also turn off RSs on all hosts?) [VK] Although I think there may be a valid case presented for an Option, I agree with Lee with the point that Neighbor Discovery is already built-in so it has operational benefits in that respect. There are many IPv6 deployments out there today in both ISPs and Enterprises, where ND/RAs are being used - this may or may not make RAs better then a potential DHCPv6 router option, but we know it (RA method) works in real networks using IPv6. As for a DHCPv6 router option case being made, if there a good reason and technical merit, that should be made to the DHC WG, or perhaps even made at a v6ops ops meeting and the advocate should make note of points made in draft-ietf-dhc-option-guidelineshttp://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/. Changes/updates to DHCPv6 have been made (as with RFC7083) when the problem can be stated with technical merit and people are willing to work on it. regards, Victor K
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Clay Kossmeyer here from the Cisco PSIRT. shoveling kitty litter as fast as you can, eh? http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel The article does not discuss or disclose any Cisco product vulnerabilities. this is disengenuous at best. from the nsa document copied in der spiegel and now many other places: JETPLOW is a firmware persistence implant for Cisco PIX series and ASA firewalls ... so in cisco kitty litter lingo, what would be discuss[ing] or disclos[ing] any Cisco product vulnerabilities? the exploit code itself? randy
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Hi, you gotta love it. they will roll over and piss themselves for nsa and other who are violating every principle, but threaten paying customers who would report a hole. Don't forget that for C and J, the U.S. government is a large customer as well. Thanks, Sabri
Re: turning on comcast v6
On Dec 30, 2013, at 3:43 PM, Owen DeLong o...@delong.com wrote: The current situation isn’t attributable to “the current IPv6 crowd” (whoever that is), it’s the current IETF consensus position. Changing that IETF consensus position is a matter of going through the IETF process and getting a new consensus. That requires justifying your position and convincing enough people willing to actively participate in the working group process of that position. Some of us tried to engage the IETF on this topic in multiple working groups. If you search the archives you'll find this topic has come up before. I would charitably describe the environment there as hostile to anyone who has not been inside the IEFT machine for the last 15 years. And that's assuming the working group is working, there are plenty inside the IEFT that are extremely dysfunctional even when the people on them agree. It's not enough to tell a bunch of enterprise people who have never dealt with the IETF before that they should go there are plead their case. Most do not know how, and the few who try find themselves berated by that community for being ignorant of the way things should be. What the enterprise folks need is IPv6 champions, like yourself, like Lee, to user stand their use case that even if you don't end up deploying it on your own network you will show up at the IETF, or at least participate on the IETF mailing lists and help them get what they need, so IPv6 deployment can proceed apace. If you really don't think there is harm, help them go get what they (think they?) need. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 30, 2013, at 2:49 PM, Lee Howard l...@asgard.org wrote: I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration. Configure up a simple network topology of three boxes representing a hub and spoke network: DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan Number it up as expected for both protocols: wan links: IPv4 /30, IPv6 /64 lan links: IPv4 /24, IPv6 /64 Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests to it. Verify a machine plugged into either of the LANs gets a fully functional network for both protocols. Now, take r1 turn it off, and stick it in a closet. You see, that office closed. Normal every day thing. Plug up two PC's to the remaining LAN off r2. This represents your desktop, and your neighbors desktop. Think Bob from accounting perhaps. Open two windows on each, one with an IPv4 ping, one with an IPv6 ping running. Now, boss man comes in and has a new office opening up. Go grab the r1 box out of the closet, you need to upgrade the code and reconfigure it. Cable it up to your PC with a serial port, open some some sort of terminal program so you can catch the boot and password recover it. Plug it's ethernet into your lan, as you're going to need to tftp down new config, and turn it on. Here's what you will soon find: 1) The IPv6 pings on both machines cease to work. 2) The IPv4 network continues to work just fine. Now, for even more fun, turn on another PC, say Sally from HR just rebooted her machine. It will come up in the same state, IPv6 not working, while IPv4 works just fine. Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are now complaining to him that their network is down, again. Make sure you not only understand the technical nuances of why the problem above happened, but also how to explain them to a totally non-technical CEO. (Oh yeah, go ahead and unplug r1 to fix the problem, and observe how long until the pings start working again. I think it's 15 minutes, IIRC. For super-extra credit tell me how to make that time shorter for everyone on the LAN with Cisco or Juniper commands on r2.) I'll give you a hint on understanding this issue. The IETF's grand solution is to replace every ethernet switch in your entire network with new hardware that supports RA Guard, and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6. Now do you understand why people just want to put the route in DHCPv6 and move on? It's not a feature that's different between the two, it's that operationally they have entirely different attack surfaces and failure modes. And yes, it involves people doing stupid things. However if the IETF is going to rely on smart people deploying networking devices we might as well give up and go home now. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh vic...@jvknet.com wrote: On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard l...@asgard.org wrote: The better question is are you using RIP or ICMP to set gateways in your network now? I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of. [VK] The RIP comparison is somewhat confusing to me. I don't see how RIP is comparable in this context (I guess technically you can pass a default route in RIP, but as Lee mentions, the protocol is designed for a different purpose and requires configuration). There was a time, I'm going to roughly guess approximately 1987-1992, although I may be off by a year or two, that you needed to have lived through for this to make sense. You see, in that time the available IGP was, well, RIP. RIPv1. Routers, at least ones you could buy, did not have OSPF, EIGRP, or even in many cases EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP. So almost every campus network ran RIPv1. This is also pre-CIDR, so remember every subnet had to have the same mask. For instance the University I went to had a /16, divided into entirely /22 networks for each LAN. The RIP config enabled it for the entire /16. Certain vendors, like Sun (who was popular at the time) shipped SunOS boxes with routed enabled by default, where they received a default route (if the admins filtered) or a full (local) table via RIPv1. In short, there was a time when getting a default route via RIP was in fact common. It was also the time of telnet, and rsh, decidedly pre SSL, ssh, or IPSEC. It was also a time when the Internet came under heavy, well, attack, by people who realized how soft and squishy it was. Injecting a route into RIP allowed you to hijack rsh sessions, for example. Lots of people who were admins at that time learned through personal pain and late night hacking that sending a dynamic route to a box via an unauthenticated protocol was a recipe for disaster. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: The state of TACACS+
On Mon, Dec 30, 2013 at 8:11 AM, Javier Henderson jav...@kjsl.org wrote: Given the problem of remote auth; the restriction of choice of protocols is dictated by what protocols the relying party device supports. This is the problem: You are at the mercy of your router vendor, to support the authentication protocol functionality. Things are workable, but in a sad state. Obviously, providing highly robust, highly secure remote authentication, is not a high priority among the router vendors. They pay lip service to the whole thing. In many cases you might be better off with local auth. How do you feel about having to wait 30 seconds between every command you enter to troubleshoot, to fail to the second server, if the TACACS or RADIUS system is nonresponsive, because the dumb router can't remember which TACACS servers are up and which ones are down, and always tries the first one in the list first? At least RADIUS has the concept of a dead timer :) By all rights; routers should be implementing authorization using LDAP over TLS, with a locally cached persistent copy of the directory and credentials (so users can still log in, and their command exec rights cached, in case of network outages).. and authentication with either user SSH public key published in LDAP, Kerberos/GSSAPI with Smartcard and other 2factor auth/OTP support, or LDAP BIND using SASL. RADIUS and TACACS+ are what you get, because they've been there forever, and frequently enough deemed good enough. Some routers have limited Kerberos support; although, usually, not support for Kerberos ticket forwarding SPNEGO / Negotiate authentication using GSSAPI over SSH. (Over encrypted Telnet, Yes) RADIUS and TACACS+, without IPSEC or TLS encapsulation of all the traffic are both highly insecure by today's standards, and in theory should not be used. Unfortunately; on many network devices, these are your only native central authentication options! Fallback plan: The network should be designed so such connections are not allowed to cross an untrusted Layer 2 domain. If an attacker can sniff auth traffic --- TACACS+ is particularly susceptible to decryption of the entire session including user credentials, whereas RADIUS is particularly susceptible to the possibility of authentication replay. Depending on the router vendor; the available functionality with each protocol, varies. Cisco is most noted for providing rich functionality over TACACS+ for shell authorization and accounting, and providing very limited RADIUS support. It is not that RADIUS is limited --- its that your device vendor's RADIUS featureset is limited -- which, for all intents and purposes, means, the features available to you are more limited, if you use such gear. On Dec 30, 2013, at 9:01 AM, Christian Kratzer ck-li...@cksoft.de wrote: Hi, it is with radius afaik ... RADIUS does not support command authorization or accounting. RADIUS protocol supports accounting; and there is no reason RADIUS start-stop accounting events cannot be sent for every shell command --- this is not a protocol limitation, this is a device implementation limitation. Some devices can provide per-command authorization by embedding the command being run in an Access-Request. RADIUS protocol response messages can encapsulate any attribute-value pair that can be sent in a TACACS response. using Vendor-specific attributes. There is a restriction on IOS devices, that arbitrarily forbids certain vendor-specific Attribute-value pairs from being encapsulated in the RADIUS reply message; per-command authorization is among prevented software capabilities of the router, not a limitation of the RADIUS protocol. http://wiki.freeradius.org/vendor/Cisco#Command-Authorization ' cisco-avpair = shell:cmd=show would do the trick to authorize the show command. except that there is a tiny note for the commands cmd and cmd-arg saying that they cannot be used for encapsulation in the Vendor-Specific space. These two are the ONLY ones.' -jav -- -JH
Re: The state of TACACS+
On Dec 30, 2013, at 6:42 PM, Jimmy Hess mysi...@gmail.com wrote: How do you feel about having to wait 30 seconds between every command you enter to troubleshoot, to fail to the second server, if the TACACS or RADIUS system is nonresponsive, because the dumb router can't remember which TACACS servers are up and which ones are down, and always tries the first one in the list first? At least RADIUS has the concept of a dead timer :) Are you talking about Cisco routers? The default timeout value for TACACS+ is five seconds, so I’m not sure where you’re coming up with thirty seconds, unless you have seven servers listed on the router and the first six are dead/unreachable. -jav
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On 12/30/2013 3:51 PM, Randy Bush wrote: Clay Kossmeyer here from the Cisco PSIRT. shoveling kitty litter as fast as you can, eh? http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20131229-der-spiegel The article does not discuss or disclose any Cisco product vulnerabilities. this is disengenuous at best. from the nsa document copied in der spiegel and now many other places: JETPLOW is a firmware persistence implant for Cisco PIX series and ASA firewalls ... so in cisco kitty litter lingo, what would be discuss[ing] or disclos[ing] any Cisco product vulnerabilities? the exploit code itself? randy What is the vulnerability in Cisco product Randy? That a 3rd party can replace the firmware in your firewall? There isn't enough information to determine if this is a software vulnerability triggered with exploit code or wholesale firmware replacement. The document refers to an implant but not how it gets there. -- The first rule of any game is to know that you're in one. -Sandy Lerner, co-founder, Cisco Systems
Re: The state of TACACS+
On Mon, Dec 30, 2013 at 6:05 PM, Javier Henderson jav...@kjsl.org wrote: Are you talking about Cisco routers? The default timeout value for TACACS+ is five seconds, so I’m not sure where you’re coming up with thirty seconds, unless you have seven servers listed on the router and the first six are dead/unreachable. Even 5 seconds extra for each command may hinder operators, to the extent it would be intolerable; shell commands should run almost instantaneously this is not a GUI, with an hourglass. Real-time responsiveness in a shell is crucial --- which remote auth should not change. Sometimes operators paste a buffer with a fair number of commands, not expecting a second delay between each command --- a repeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to be unreachable, in case of a network break, but that isn't necessary. The response timeout might be 5 seconds, but in reality, there are cases where you would wait longer, and that is tragic, since there are some obvious alternative approaches that would have had results that would be more 'friendly' to the interactive user. (Like remembering which server is working for a while, or remembering that all servers are down -- for a while, and having a 50ms timeout, with all servers queried in parallel, instead of a 5 seconds timeout) -jav -- -JH
Re: turning on comcast v6
What the enterprise folks need is IPv6 champions, like yourself, like Lee, to user stand their use case that even if you don't end up deploying it on your own network you will show up at the IETF, or at least participate on the IETF mailing lists and help them get what they need, so IPv6 deployment can proceed apace. If you really don't think there is harm, help them go get what they (think they?) need. I don’t think there’s harm to including the option for RIO in DHCPv6. I think there is great harm in continuing the use case presented earlier. I have yet to see a use case from enterprise that actually requires RIO or default route in DHCPv6, and I have seen many many use cases. Most of them are, actually, better solved through education, so I tend to focus my efforts in that area. If you can find someone who wants to pay me to plead the enterprise cases to the IETF, I suppose I might be interested in that job if it came with the right offer, but for now, that’s not what I get paid to do. Owen
Re: turning on comcast v6
You can accomplish the same thing in IPv4…. Plug in Sally’s PC with Internet Connection Sharing turned on and watch as her DHCP server takes over your network. Yes, you have to pay attention when you plug in a router just like you’d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. Incompetence in execution really isn’t the protocol’s fault. Owen On Dec 30, 2013, at 3:24 PM, Leo Bicknell bickn...@ufp.org wrote: On Dec 30, 2013, at 2:49 PM, Lee Howard l...@asgard.org wrote: I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration. Configure up a simple network topology of three boxes representing a hub and spoke network: DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan Number it up as expected for both protocols: wan links: IPv4 /30, IPv6 /64 lan links: IPv4 /24, IPv6 /64 Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests to it. Verify a machine plugged into either of the LANs gets a fully functional network for both protocols. Now, take r1 turn it off, and stick it in a closet. You see, that office closed. Normal every day thing. Plug up two PC's to the remaining LAN off r2. This represents your desktop, and your neighbors desktop. Think Bob from accounting perhaps. Open two windows on each, one with an IPv4 ping, one with an IPv6 ping running. Now, boss man comes in and has a new office opening up. Go grab the r1 box out of the closet, you need to upgrade the code and reconfigure it. Cable it up to your PC with a serial port, open some some sort of terminal program so you can catch the boot and password recover it. Plug it's ethernet into your lan, as you're going to need to tftp down new config, and turn it on. Here's what you will soon find: 1) The IPv6 pings on both machines cease to work. 2) The IPv4 network continues to work just fine. Now, for even more fun, turn on another PC, say Sally from HR just rebooted her machine. It will come up in the same state, IPv6 not working, while IPv4 works just fine. Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are now complaining to him that their network is down, again. Make sure you not only understand the technical nuances of why the problem above happened, but also how to explain them to a totally non-technical CEO. (Oh yeah, go ahead and unplug r1 to fix the problem, and observe how long until the pings start working again. I think it's 15 minutes, IIRC. For super-extra credit tell me how to make that time shorter for everyone on the LAN with Cisco or Juniper commands on r2.) I'll give you a hint on understanding this issue. The IETF's grand solution is to replace every ethernet switch in your entire network with new hardware that supports RA Guard, and then deploy new configuration on every single port of every single device in your network. Please develop a capital justification plan for Mr MoneyBagsCEO for replacing every switch in your network so you can safely deploy IPv6. Now do you understand why people just want to put the route in DHCPv6 and move on? It's not a feature that's different between the two, it's that operationally they have entirely different attack surfaces and failure modes. And yes, it involves people doing stupid things. However if the IETF is going to rely on smart people deploying networking devices we might as well give up and go home now. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: turning on comcast v6
On Dec 30, 2013, at 7:51 PM, Owen DeLong o...@delong.com wrote: I have yet to see a use case from enterprise that actually requires RIO or default route in DHCPv6, and I have seen many many use cases. Most of them are, actually, better solved through education, so I tend to focus my efforts in that area. If you can find someone who wants to pay me to plead the enterprise cases to the IETF, I suppose I might be interested in that job if it came with the right offer, but for now, that’s not what I get paid to do. The kinky layer-2 stuff I've seen some places do tells me they won't be able to deploy IPv6 without it. I think the key here is feature parity and the whole 96 more bits no magic aspect. The option is low hanging fruit to solve a problem. Perhaps it's just a conceptual problem (eg: DHCPv4 gives me option #4. I should have a comparable option# in IPv6!). While I may not need option #37 (or folks may not use it), sending a RS in addition to DHCPv6 request is two steps in host configuration, whereas one should be able to suffice (perhaps). It's also about authorization though, I could get a RA back from the RS from an unexpected (rogue) device in the same way I could see a rogue DHCP response as well. I have logging on my DHCP server, but I don't have that capability from a RA/RS stance. One is central (but perhaps relayed), the other is local (and never relayed). Seems a lot of emails over something simple that's not much creep and just parity. (enjoy other great options here: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options .. I need my quotes server for IPv6 via DHCPv6 too). - Jared
Re: turning on comcast v6
On Dec 30, 2013, at 6:56 PM, Owen DeLong o...@delong.com wrote: You can accomplish the same thing in IPv4…. Plug in Sally’s PC with Internet Connection Sharing turned on and watch as her DHCP server takes over your network. No, the failure mode is still different. With IPv6 RA's, the rouge router breaks all hosts on the LAN with a single broadcast. With a rogue DHCP server no currently working clients will stop working. In fact many will do directed renews, and never notice said rogue server. It is only a freshly booted host that might be captured by a rogue DHCP server. In a corporate environment the difference between one user getting a rogue DHCP server, being down, and asking for troubleshooting, and taking out an entire department/floor/office is enormous. Yes, you have to pay attention when you plug in a router just like you’d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. Incompetence in execution really isn’t the protocol’s fault. We can't work around incompetent admins. Even the best humans goof from time to time. What we can do is design protocols that are robust, or not in the face of stupidity and accident. I should tell you about the time rogue RA's took down a data center network because in the middle of the night the tech I was talking to couldn't tell if I said port fifteen or port fifty over the phone, and thus plugged the router into the wrong network taking down several hundred hosts. The IPv4 side was fine for the 30 seconds or so until we straightened it out. There's a reason why there's huge efforts to put RA guard in switches, and do cryptographic RA's. These are two admissions that the status quo does not work for many folks, but for some reason these two solutions get pushed over a simple DHCP router assignment option. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 30, 2013, at 11:28 PM, Marco Teixeira ad...@marcoteixeira.com wrote: i just wanted to say that any network professional that puts any equipment into production without securing it against the kind of issues mentioned so far (cisco/cisco, snmp private, etc) is negligent and should be fired on the spot. Yes, but keep in mind that with near-infinite resources, one can go after internal machines used by network operations personnel, etc. There are multiple things that network operators can and should do to prevent direct unauthorized configuration, to prevent tampering with configuration-management systems, to securing jump-off boxes, to implementing AAA with per-command auth and logging, to monitoring for config changes, etc. Unfortunately, many network operators don't do all these various things, and so it's quite possible for an organization with time and resources to attack via a side-channel. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 31, 2013, at 12:00 AM, Ray Soucy r...@maine.edu wrote: So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Yes, I see this now, thanks. AFAICT, the Cisco boxes listed are ASAs and PIXes, which are essentially Linux PCs running a bunch of userland firewall stuff and which have BIOSes and so forth; they aren't routers/switches. I don't know much about Juniper gear, but it appears that the Juniper boxes listed are similar in nature, albeit running FreeBSD underneath (correction welcome). I know nothing at all about Huawei gear. Compromising PCs with persistent malware/rootkits is pretty routine, so this isn't really surprising, IMHO. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: turning on comcast v6
On 12/30/2013 8:16 PM, Leo Bicknell wrote: There's a reason why there's huge efforts to put RA guard in switches, and do cryptographic RA's. These are two admissions that the status quo does not work for many folks, but for some reason these two solutions get pushed over a simple DHCP router assignment option. The more disturbing feature for those that have been there, done that, debugged the meltdown, and tried to avoid repeating the issue is the growing proliferation of automatic discovery/configuration... whether RA / SLAAC / mDNS / Bonjour / uPnP / (the list goes on...). There are too many opportunities for spoofing / MITM / self-propagating issues. Yes, DHCP is prone to similar issues, but better to focus on one service and one authoritative source to try to lock down than to try to protect the plethora of growing options to introduce issues from arbitrary sources. But as the market focus appears to continue to try to address the home / SOHO environment of naive users, the self-configuration nastiness continues to propagate. It may fit at home / SOHO, but not in the Enterprise, and certainly not in a university environment where you can't be as restrictive on a universal basis as you might like to be :( Jeff signature.asc Description: OpenPGP digital signature
Re: NSA able to compromise Cisco, Juniper, Huawei switches
So this isn't an issue of the NSA working with Cisco and Juniper to include back doors, it's an issue of the NSA modifying those releases after the fact though BIOS implants. Yes, I see this now, thanks. AFAICT, the Cisco boxes listed are ASAs and PIXes, which are essentially Linux PCs running a bunch of userland firewall stuff and which have BIOSes and so forth; they aren't routers/switches. you may want to read the more complete, well let's say extensive http://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 31, 2013, at 9:41 AM, Randy Bush ra...@psg.com wrote: you may want to read the more complete, well let's say extensive Thanks, Randy - now I see the JunOS stuff in there for J-series and M-series. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
The cynic in me says that cisco switch/router gear isn't part of that report on clandestine backdoors, because they don't need said clandestine backdoors to access them... -Blake On Mon, Dec 30, 2013 at 8:54 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Dec 31, 2013, at 9:41 AM, Randy Bush ra...@psg.com wrote: you may want to read the more complete, well let's say extensive Thanks, Randy - now I see the JunOS stuff in there for J-series and M-series. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 31, 2013, at 10:16 AM, Blake Dunlap iki...@gmail.com wrote: The cynic in me says that cisco switch/router gear isn't part of that report on clandestine backdoors, because they don't need said clandestine backdoors to access them... T-series is in there, too. It's also important to keep in mind that all these purported documents refer to technologies which were supposedly available 5 years ago, based on the dates in the slides. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Hi Roland. I don't know much about Juniper gear, but it appears that the Juniper boxes listed are similar in nature, albeit running FreeBSD underneath (correction welcome). With most Juniper gear, it is actually quite difficult to achieve wire-tapping on a large scale using something as simple as a backdoor in the BIOS. Assuming M/MX/T series, you are correct that the foundation of the control-plane is a FreeBSD-based kernel. However, that control-plane talks to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which differ per platform and sometimes per line-card). In general, transit-traffic (traffic that enters the PFE and is not destined to the router itself), will not be forwarded via the control-plane. This means that whatever the backdoor is designed to do, simply can not touch the traffic. There are a few exceptions, such as a carefully crafted backdoor capable of altering the next-hop database (the PFEs forwarding table) and mirroring traffic. This however, would mean that the network would already have to be compromised. Another option would be to duplicate target traffic into a tunnel (GRE or IPIP based for example), but that would certainly have a noticeable affect on the performance, if it is possible to perform those operations at all on the target chipset. However, attempting any of the limited attacks that I can think of would require expert-level knowledge of not just the overall architecture, but also of the microcode that runs on the specific PFE that the attacker would target, as well as the ability to partially rewrite that. Furthermore, to embed such a sophisticated attack in a BIOS would seem impossible to me with the first reason being the limited amount of storage available on the EEPROM to store all that binary code. An attack based on corrupted firmware loaded post-manufacturing would also be difficult due to the signed binaries and microcode. If someone were to embed a backdoor it is extremely difficult without Juniper's cooperation. And the last time I looked at the code (I left Juniper a few months ago), I saw nothing that would indicate a backdoor of any kind. -- Thanks, Sabri
Re: NSA able to compromise Cisco, Juniper, Huawei switches
- Original Message - From: Ray Soucy r...@maine.edu I hope when [if] the truth is learned it is a lot less prevalent than it sounds, but I'm not optimistic. This is why we need all infrastructure to be implemented using open standards, open hardware designs, and open source software IMHO. I hope Cisco, Juniper, and others respond quickly with updated images for all platforms affected before the details leak. I hate to be Even More Paranoid Than That (and if I go off-air for more than about a week, assume those Black Eyeshades types whose mention got me kicked off the list after Katrina came for me :-), but contemplate this: === If you were the NSA, and you had a spandy new image with lots of great backdooring and kill-switching all ready to do, and you'd plunked it in Cisco's TAC download site (with or without their knowledge)... ...what do you suppose you'd do? Wouldn't you want some way to motivate everyone to grab that new image and plonk it on all their devices as fast as possible? Wouldn't it be the definition of irony if the way you got everyone to install your bug on their router ... was because they were afraid you already had? Is Ken Thompson turning over in his grave yet? === Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Is Ken Thompson turning over in his grave yet? I certainly hope not...
Re: NSA able to compromise Cisco, Juniper, Huawei switches
It's also important to keep in mind that all these purported documents refer to technologies which were supposedly available 5 years ago, based on the dates in the slides. assumptions that the TAO folk have been taking a long much-deserved sabbatical are probably naive the shocking revelation will come tomorrow when it is announced that there is some piece of equipment or technology which has not been violated randy
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Sabri, As I was going through reading all these replies, the one thing that continued to poke at me was the requirement of the signed binaries and microcode. The same goes for many of the Cisco binaries, without direct assistance, which is unclear at this point through the cloud of smoke so to speak, it would be difficult to load this code post implementation or manufacturing. Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign virtually anything they wish. This is similar to what happened to Red Hat a number a years ago when they had their repos owned and the packages were compromised but passed just fine because the signing server was owned as well. Not say this is or isn't the case, but I know from my experience were I worked in an ISP running Juniper routers (M J Series) coast to coast, that with the number of eyes watching these devices, it would have to be done at the firmware level not to be seen by the analysts. This is not out of reach either, it was roughly 5-7 years ago when Ethernet cards were owned with a firmware hack and all the traffic crossing that interface was seen then reported back. I know that all the conversations surrounding this topic were shut down quickly and the conference talks surrounding it dried up as well, everyone I talked to was curious why the conversations of such an attack all of a sudden went silent and have yet to resurface... I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. Keep in mind the best way to cover up a covert mission is not to cover it up to start with. Put it out there, then flood the channels with false or miss information, until the real mission is so clouded with miss information you can no longer see the real mission resulting in the perfect execution of the op. Just a few thoughts, sorry no answers... -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel On 12/30/13, 10:38 PM, Sabri Berisha wrote: Hi Roland. I don't know much about Juniper gear, but it appears that the Juniper boxes listed are similar in nature, albeit running FreeBSD underneath (correction welcome). With most Juniper gear, it is actually quite difficult to achieve wire-tapping on a large scale using something as simple as a backdoor in the BIOS. Assuming M/MX/T series, you are correct that the foundation of the control-plane is a FreeBSD-based kernel. However, that control-plane talks to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which differ per platform and sometimes per line-card). In general, transit-traffic (traffic that enters the PFE and is not destined to the router itself), will not be forwarded via the control-plane. This means that whatever the backdoor is designed to do, simply can not touch the traffic. There are a few exceptions, such as a carefully crafted backdoor capable of altering the next-hop database (the PFEs forwarding table) and mirroring traffic. This however, would mean that the network would already have to be compromised. Another option would be to duplicate target traffic into a tunnel (GRE or IPIP based for example), but that would certainly have a noticeable affect on the performance, if it is possible to perform those operations at all on the target chipset. However, attempting any of the limited attacks that I can think of would require expert-level knowledge of not just the overall architecture, but also of the microcode that runs on the specific PFE that the attacker would target, as well as the ability to partially rewrite that. Furthermore, to embed such a sophisticated attack in a BIOS would seem impossible to me with the first reason being the limited amount of storage available on the EEPROM to store all that binary code. An attack based on corrupted firmware loaded post-manufacturing would also be difficult due to the signed binaries and microcode. If someone were to embed a backdoor it is extremely difficult without Juniper's cooperation. And the last time I looked at the code (I left Juniper a few months ago), I saw nothing that would indicate a backdoor of any kind.
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 31, 2013, at 10:59 AM, Randy Bush ra...@psg.com wrote: assumptions that the TAO folk have been taking a long much-deserved sabbatical are probably naive Indeed; that is my point. These documents allege that the capabilities in question were present five years ago, which is an eternity in tech-time. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 31, 2013, at 10:38 AM, Sabri Berisha sa...@cluecentral.net wrote: Assuming M/MX/T series, you are correct that the foundation of the control-plane is a FreeBSD-based kernel. And the management plane, too? However, that control-plane talks to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which differ per platform and sometimes per line-card). In general, transit-traffic (traffic that enters the PFE and is not destined to the router itself), will not be forwarded via the control-plane. These same concepts apply to most Cisco gear, as well. Another option would be to duplicate target traffic into a tunnel (GRE or IPIP based for example), but that would certainly have a noticeable affect on the performance, if it is possible to perform those operations at all on the target chipset. Something along these lines would be a good guess, along with the ability to alter the config of the device and to mask said alteration. Other purported documents speak of tunneling duplicated traffic, and in fact we've seen tunnels on compromised routers + NAT used by spammers in conjunction with BGP hijacking in order to send out spam-bursts from allocated space (i.e., the precise opposite use-case, heh). Assuming these alleged documents describe actual capabilities, there is some reason for having developed them in the first place. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Dec 31, 2013, at 11:06 AM, [AP] NANOG na...@armoredpackets.com wrote: Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign virtually anything they wish. Or if they owned *people* with the right level of access to do so, or if there were implementation bugs which could be utilized to bypass or obviate the signing . . . None of the alleged capabilities described in the purported documents is really standalone; they all rely upon other methods/mechanisms in order to provide the required foundation to accomplish their stated goals. I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. This is the most pertinent and insightful comment made in this thread. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: turning on comcast v6
On Mon, Dec 30, 2013 at 6:31 PM, Leo Bicknell bickn...@ufp.org wrote: On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh vic...@jvknet.com wrote: On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard l...@asgard.org wrote: The better question is are you using RIP or ICMP to set gateways in your network now? I disagree that that's a better question. I'm not using RIP because my hosts don't support it (at least, not without additional configuration), and it would be a very unusual configuration, adding weight and complexity for no benefit. RAs are the opposite. Not even sure how you would use ICMP to set a default gateway. Maybe there's a field I'm unaware of. [VK] The RIP comparison is somewhat confusing to me. I don't see how RIP is comparable in this context (I guess technically you can pass a default route in RIP, but as Lee mentions, the protocol is designed for a different purpose and requires configuration). There was a time, I'm going to roughly guess approximately 1987-1992, although I may be off by a year or two, that you needed to have lived through for this to make sense. You see, in that time the available IGP was, well, RIP. RIPv1. Routers, at least ones you could buy, did not have OSPF, EIGRP, or even in many cases EGP/BGP. They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP. So almost every campus network ran RIPv1 [VK] Leo, I understand the case you mention, but I am not sure if this is a parallel to what the subject is on this thread. I would think we are talking - not about routers and servers here - but end hosts (PCs, tablets, home gateways, smart phones, media devices etc.) which would be the beneficiaries of the [DHCPv6] route option information. I still don't think that RIP's prevalence in 20+ year old network environments, and it's lack of use today, draws a comparison to the validity of using RAs. I get that it [RIP] may have been default on may historic boxes, so had similar effect on providing a default route, but the protocol's purpose was not intended to do that for all the hosts on a network (also a world where not all networks were IP as well). RA on the other had was specifically purposed to be used to provide this kind of information to all IPv6 stacks. So I still think we are talking about very different environments in protocol types, purpose and mixture of participating hosts/routers etc. regards, Victor K
Re: NSA able to compromise Cisco, Juniper, Huawei switches
Roland, I did fail to mention the HUMINT (Human Intelligence) side of things, thank you for bringing that up! -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel On 12/30/13, 11:33 PM, Dobbins, Roland wrote: On Dec 31, 2013, at 11:06 AM, [AP] NANOG na...@armoredpackets.com wrote: Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign virtually anything they wish. Or if they owned *people* with the right level of access to do so, or if there were implementation bugs which could be utilized to bypass or obviate the signing . . . None of the alleged capabilities described in the purported documents is really standalone; they all rely upon other methods/mechanisms in order to provide the required foundation to accomplish their stated goals. I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. This is the most pertinent and insightful comment made in this thread. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
I'm torn on this. On one hand, it seems sinister. On the other, it's not only what the NSA is tasked with doing, but it's what you'd EXPECT them to be doing in the role as the NSA. I'm not saying it's right or wrong...it creeps me out a little, though...but these are the kinds of things we have demanded that they do (via our elected representatives). More to the point, I really doubt the NSA has any interest whatsoever in my Facebook or Twitter account. It's probable a means to and end...a transitory stop on their way to propagating more widely. They need regular folks to propagate, but in reality, they likely have zero interest in our actual accounts at the end of the day. I think of it a bit like a virus with a slightly less hysterical outcome/plan. On Mon, Dec 30, 2013 at 10:33 PM, Dobbins, Roland rdobb...@arbor.netwrote: On Dec 31, 2013, at 11:06 AM, [AP] NANOG na...@armoredpackets.com wrote: Then looking at things from the evil side though, if they owned the system which provides the signing then they could sign virtually anything they wish. Or if they owned *people* with the right level of access to do so, or if there were implementation bugs which could be utilized to bypass or obviate the signing . . . None of the alleged capabilities described in the purported documents is really standalone; they all rely upon other methods/mechanisms in order to provide the required foundation to accomplish their stated goals. I think we need to watch and listen/read over the coming weeks and months before we go assuming we have it figured out. This is the most pertinent and insightful comment made in this thread. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On 12/30/2013 11:06 PM, [AP] NANOG wrote: As I was going through reading all these replies, the one thing that continued to poke at me was the requirement of the signed binaries and microcode. The same goes for many of the Cisco binaries, without direct assistance, which is unclear at this point through the cloud of smoke so to speak, it would be difficult to load this code post implementation or manufacturing. Signed binaries?? Surely you jest... Try download *anything* from Cisco TAC these days with a new browser and latest Java and see how many exceptions you have to make to get an allegedly legitimate copy of anything. If you don't like it, open a TAC case, and count the number of exceptions you have to make to get to THAT point as well. And of course they'll want you to upload a show tech first thing, and see how many MORE exceptions you have to make to get that to work. Geez, just open ASDM today I have to honor Java exceptions. We're all getting far too conditioned for the click OK to proceed overload, and the sources aren't helping. Jeff
Re: NSA able to compromise Cisco, Juniper, Huawei switches
On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper blair.tros...@gmail.comwrote: I'm torn on this. On one hand, it seems sinister. On the other, it's not only what the NSA is tasked with doing, but it's what you'd EXPECT them to be doing in the role as the NSA. [snip] The NSA's role is not supposed to include subterfuge and undermining the integrity or security of domestic enterprise infrastructure With any luck, we'll hopefully find absolutely nothing, or that it was targetted backdooring against specific targets only. And people have a need to know that the security agencies haven't left a trail of artificially inserted bugs and backdoors in common IT equipment providing critical infrastructures services, and that the agencies haven't prepared a collection of instant-root 0days, that are no more protected then the agencies' other poorly guarded secrets. There would be a risk that any 'backdoors' are ready to be exploited by other unintended nefarious actors! Because the NSA are apparently great at prepping the flammables and setting fires,but totally incapable of keeping the fires contained, once they (or someone else) lights it. It is not the least bit necessary for the NSA itself to be a nefarious actor exploiting things or even complicit; for the mere presence of any backdoor or surreptitious code to eventually have the potential for serious damage. It could well be a rogue ex-employee of the NSA, such as Snowden, or others, that happened to be aware of technical details, hackers, or members of a foreign nation state, who will just happen to have the time and energy to track down open doors waiting for the taking, AND figure out how to abuse them for evil purposes. There are enough potential 0day risks, without intentional ones, waiting for bad guys to co-opt! -- -JH
RE: NSA able to compromise Cisco, Juniper, Huawei switches
We're all getting far too conditioned for the click OK to proceed overload, and the sources aren't helping. If one embarks with deliberation upon a course of action which may entertain certain results then the intent to cause the result so obtained is, by implication, proved.
Re: NSA able to compromise Cisco, Juniper, Huawei switches
To supplement and amend what I said: These are the KINDS of things we want the NSA to do; however, the institutional oversight necessary to make sure it's Constitutional, warranted, and kept in bounds is woefully lacking (if any exists at all). Even FISA is unsatisfactory. At any rate, I agree that the current disposition of the NSA (or, at least, what's been leaking the last few months) is simply unacceptable and cannot be allowed. I say that last part from the perspective of a US citizen, though I'd imagine most people of other nationalities would agree with me, but probably for different reasons. On Mon, Dec 30, 2013 at 11:08 PM, Jimmy Hess mysi...@gmail.com wrote: On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper blair.tros...@gmail.comwrote: I'm torn on this. On one hand, it seems sinister. On the other, it's not only what the NSA is tasked with doing, but it's what you'd EXPECT them to be doing in the role as the NSA. [snip] The NSA's role is not supposed to include subterfuge and undermining the integrity or security of domestic enterprise infrastructure With any luck, we'll hopefully find absolutely nothing, or that it was targetted backdooring against specific targets only. And people have a need to know that the security agencies haven't left a trail of artificially inserted bugs and backdoors in common IT equipment providing critical infrastructures services, and that the agencies haven't prepared a collection of instant-root 0days, that are no more protected then the agencies' other poorly guarded secrets. There would be a risk that any 'backdoors' are ready to be exploited by other unintended nefarious actors! Because the NSA are apparently great at prepping the flammables and setting fires,but totally incapable of keeping the fires contained, once they (or someone else) lights it. It is not the least bit necessary for the NSA itself to be a nefarious actor exploiting things or even complicit; for the mere presence of any backdoor or surreptitious code to eventually have the potential for serious damage. It could well be a rogue ex-employee of the NSA, such as Snowden, or others, that happened to be aware of technical details, hackers, or members of a foreign nation state, who will just happen to have the time and energy to track down open doors waiting for the taking, AND figure out how to abuse them for evil purposes. There are enough potential 0day risks, without intentional ones, waiting for bad guys to co-opt! -- -JH
Re: turning on comcast v6
Leo, On Mon, Dec 30, 2013 at 6:24 PM, Leo Bicknell bickn...@ufp.org wrote: On Dec 30, 2013, at 2:49 PM, Lee Howard l...@asgard.org wrote: I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing. I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration. Configure up a simple network topology of three boxes representing a hub and spoke network: DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan . Here's what you will soon find: 1) The IPv6 pings on both machines cease to work. 2) The IPv4 network continues to work just fine. Yes, in this very specific case, you may get this result. However, this is a very specific case with very specific parameters and conditions. There are also many cases (again specific in nature) which would cause the IPv4 connection to have problems and not the IPv6 connection. As an example, say the failure is now over and we have running state with r1 and r2 as two potential routers out of the LAN to a common WAN for IPv4 and IPv6 connectivity. The DHCPv4 server provides only the address of the r2 router (original on that LAN). Both r1 and r2 provide RAs and the client works over r2 for IPv6 for now. r1 fails, the machines will lose IPv4 connectivity but IPv6 will keep working (as the hosts will detect r1 as unreachable and then use r2). There are a number of assumptions in this use case - but that's the point. One may say that without IPv4, perhaps we have a problem anyway (since I am sure many networks will have some level of dependance on IPv4 for a while) - but the designers of IPv6 will then say that the IPv6 protocol needs to be free from IPv4 baggage to truly succeed IPv4. I am not fighting against the case of the DHCPv6 option, but I am not sure if use cases like the one you mentioned will convince the right audiences that the option is needed. For reference, this concept has died on the vine before - draft-droms-dhc-dhcpv6-default-router-00 as an example. (where technical comments were made to diminish the technical value of using DHCPv6 as an option to provide default gateway information). We can also reference draft-ietf-mif-dhcpv6-route-option from the MIF working group. I think a new initiative to revive this concept will need to address the [negative] points from those previous experiences and contrast them to the operational benefits of having it available. I am willing to help out here, but we need some folks willing to put the use cases together which make a strong case (oh and they will need email stamina). regards, Victor K -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: turning on comcast v6
On Dec 30, 2013, at 9:29 PM, Victor Kuarsingh vic...@jvknet.com wrote: I think a new initiative to revive this concept will need to address the [negative] points from those previous experiences and contrast them to the operational benefits of having it available. I am willing to help out here, but we need some folks willing to put the use cases together which make a strong case (oh and they will need email stamina). Or, alternatively, operators who care about this and vendors who are interested in accepting money to implement what the operators want could get together and form, oh I dunno, the Internet DHCP Task Force, which could specify/implement the standard way of solving this particular problem... Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: turning on comcast v6
I've been in the process of rolling out IPv6 (again this night) across a very large, highly conservative, and very bureaucratic enterprise. (Roughly 100K employees. More than 600 distinct site. Yada. Yada.) I've had no issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4 model. In fact, the IPv6 model has generally been much more straightforward and easy to implement. So I'm a large enterprise operator, not an ISP. Convince me. Because I don't see any need. And if I don't, I'm hard-pressed to see why the IETF would. Scott On Mon, Dec 30, 2013 at 3:49 PM, Owen DeLong o...@delong.com wrote: On Dec 30, 2013, at 10:04 AM, Ryan Harden harde...@uchicago.edu wrote: On Dec 24, 2013, at 8:15 AM, Lee Howard l...@asgard.org wrote: default route information via DHCPv6. That's what I'm still waiting for. Why? You say, The protocol suite doesn't meet my needs; I need default gateway in DHCPv6. So the IETF WG must change for you to deploy IPv6. Why? Lee There are many places that wish to severely restrict or even block RA. Implementations of Captive Portal/NetReg/Bump in the wire auth/etc like to do redirection based on MAC. Many are doing this with very short DHCP leases that hand out different name servers and/or gateways until you properly auth via $method. You might be able to do this with something like RADVD, but when you have systems that have been doing this for IPv4 for years, there’s little interest (read: budget) in rewriting everything for IPv6. While I do not oppose the inclusion of Routing Information into DHCPv6, I have to say that this seems to be one of the weaker arguments. Please permit me to repeat your statement from an IPv6 perspective… Because many places have poorly thought out cruft that deals with deficiencies in IPv4 by doing stunts that won’t work in the current IPv6 implementation and because we don’t want to rewrite our cruft to take advantage of the cleaner solutions available for these problems in IPv6, we demand that you include the cruft from IPv4 into IPv6 in order to support this hackery. 'Rewrite all of your tools and change your long standing business practices’ is a very large barrier to entry to IPv6. If adding gateway as an optional field will help people get over that barrier, why not add it? Sure it doesn’t fit into the “IPv6 way,” but bean counters don’t care much for that when you have to ask for developer time to rewrite everything. You have to rewrite all your tools to handle the bigger addresses anyway. While you’re at it, why not rewrite them to take advantage of cleaner solutions? Disclaimer: I don’t condone said methods and trickery mentioned above, just pointing out their use. So you’re defending a position you don’t share? Interesting tactic. Owen
