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.
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.
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.
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.
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
This is the type of change we're likely to see, IMHO:
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.
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.
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.
I'd love to know how they were getting in flight wifi.
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?
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:
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
> 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
This might be an interesting example of it's (mis)use.
http://en.wikipedia.org/wiki/Greek_wiretapping_case_2004–2005
Sam Moats
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
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
brez@brezworks.com
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.
I built the other.