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

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 <rdobbins@arbor.net> wrote:

On Dec 30, 2013, at 6:18 PM, Saku Ytti <saku@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 <rdobbins@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

On Dec 30, 2013, at 8:07 PM, Ray Soucy <rps@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Dec 30, 2013, at 10:44 PM, <Valdis.Kletnieks@vt.edu> <Valdis.Kletnieks@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On 12/30/2013 08:03 AM, Dobbins, Roland wrote:

On Dec 30, 2013, at 10:44 PM, <Valdis.Kletnieks@vt.edu> <Valdis.Kletnieks@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

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 +0000, Dobbins, Roland wrote:

...

On Dec 30, 2013, at 10:44 PM, <Valdis.Kletnieks@vt.edu> <Valdis.Kletnieks@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

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 <rdobbins@arbor.net>wrote:

On Dec 30, 2013, at 11:18 PM, Sam Moats <sam@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 <rdobbins@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

On Mon, Dec 30, 2013 at 1:17 PM, Lorell Hathcock <lorell@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.

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

On Dec 31, 2013, at 12:00 AM, Ray Soucy <rps@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Dec 31, 2013, at 9:41 AM, Randy Bush <randy@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Dec 31, 2013, at 10:16 AM, Blake Dunlap <ikiris@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

On Dec 31, 2013, at 10:59 AM, Randy Bush <randy@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

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.

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 <nanog@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper <blair.trosper@gmail.com>wrote:

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

I think there needs to be some clarification on how these tools get used, how often they're used, and if they're ever cleaned up when no longer part of an active operation. Of course we'll never get that. The amount of apologists with the attitude "this isn't a big deal, nothing to see here, the NSA does this kind of thing" is kind of shocking for this community; especially with the information that's been released over the past few months. This whole backdoor business is a very, very, dangerous game. On Tue, Dec 31, 2013 at 12:19 AM, Blair Trosper <blair.trosper@gmail.com>wrote:

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 <mysidia@gmail.com> wrote:

...

On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper <blair.trosper@gmail.com wrote:

...

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

-- 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

I think there needs to be some clarification on how these tools get used, how often they're used, and if they're ever cleaned up when no longer part of an active operation. Of course we'll never get that.

Highly unlikely, I'd say.

The amount of apologists with the attitude "this isn't a big deal, nothing to see here, the NSA does this kind of thing" is kind of shocking for this community; especially with the information that's been released over the past few months.

This whole backdoor business is a very, very, dangerous game.

It *is* a big deal. And if you want to get even more scared, listen to Jacob Appelbaum's talk at the CCC here: http://www.youtube.com/watch?v=b0w36GAyZIA Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Dec 31, 2013, at 8:32 AM, Saku Ytti <saku@ytti.fi> wrote:

I'm going to wait calmly for some of the examples being recovered from the field, documented and analysed.

If I were Cisco/Juniper/et all I would have a team working on this right now. It should be trivial for them to insert code into the routers that say, hashes all sorts of things (code image, BIOS, any PROMS and EERPOMS and such on the linecards) and submits all of those signatures back. Any APT that has been snuck into those things should be able to be detected. For most of them the signatures should be known, as the code shipped from the factory and was never intended to be modified (e.g. BIOS). A transparent public report about how many devices are running signatures they do not know would be very interesting. Plus, it's an opportunity to sell new equipment to those people, so they can rid themselves of the infection. I also wonder how this will change engineering going forward. Maybe the BIOS should be a ROM chip, not an EEPROM again. Maybe the write line needs to be run through a physical jumper on the motherboard that is normally not present. Why do we accept our devices, be it a PC or a router, can be "persistently" infected. The hardware industry needs to do better. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On (2013-12-31 16:22 +0100), nanog@mitteilung.com wrote:

Since some weeks all my cisco / juniper equipment was replaced with open source solutions (sometimes with embedded devices) and that works fine. Google as search engine and Facebook accounts are deleted and some more things. Cloud solutions outside europe now are forbidden for me. Thank you NSA & Co. for your "great" work :-(

Back in 2008 when Sweden publicly stated that their SIGINT police, 'FRA', starts to spy all traffic coming and going to Swedish borders. Finnish pirate party had two suggestions to this revelation 1) Finland needs own direct fibre connection to Germany, to by-pass Swedish spying -- sounds good, since only those who tell about spying, spy -- germany has flawless recent history record about spying 2) Finland needs goverment operated mandator VPN box in border -- Just like other civilized states, like China and Saudi Arabia. Point I'm making, it's naive to think landscape has changed or that non-implied instances are safer. The most local cloud providers I know personally, and conversely they know me personally, so there is quite high degree of likelyhood for them to come up with reason to access my data. If I'm worried about the data, I should store it myself. If the data is non-encrypted email, there are so many points to intercept it at, make sure it is something that survives being published. If it's encrypted, it does not much matter where you store it, as long as you don't decrypt it there. -- ++ytti

On Dec 31, 2013, at 11:50 AM, Saku Ytti <saku@ytti.fi> wrote:

I asked earlier today JTAC (#2013-1231-0033) and JTAC asked SIRT for tool to read BIOS and output SHA2 or SHA3 hash, and such tool does not exist yet. I'm dubious, it might be possible even with existing tools. At least it's possible to reflash the BIOS with stock JunOS, as lot of us had to do due to misformatted SSD disks. But fully agreed some of these sanity checks should be added, it's not cure all, maybe the attack changes the answers before showing them, maybe BIOS comes infected from Juniper or from Kontron. But it would create additional barrier.

I also emailed Kontrol and told it would be prudent for them to do press release also. Just to know what their public/official statement is.

Most of the vendors (I think Cisco/Juniper) have many of their staff out on vacation this week. I believe both are doing the "mandatory shutdown" or similar that I've seen other folks do around this season. Arbor networks did something similar as well this year. If you are looking at your hardware, you can get inexpensive flash readers/writers out there. I have one I use when doing low level hardware work. There's also tools for your servers (eg: Flashrom) which are available in your favorite repos/ports/elsewhere and work on Linux/FreeBSD/others. You can use this to typically read/checksum your bios quickly on supported hardware. I'm sure they would love to have the efforts that have gone into this e-mail thread followed-up with hardware/research/contributions to improve the software. It shouldn't be too hard for you to read your bios and load it into ida pro or similar to perform checks. - Jared

On Dec 31, 2013, at 12:49 PM, Enno Rey <erey@ernw.de> wrote:

Hi,

some approaches were discussed in 2010, by Graeme Neilson from NZ here:

https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS10_Netscreen_of_t...

a later year, at the same conference, he gave a private session demonstrating basically the same stuff for JunOS, as ongoing (and, at the time, non-public) research.

happy NYE to everybody

What I found mildly amusing this summer was most of the outlines of the summer "Snowden" stuff was covered in this book: http://www.amazon.com/dp/B00DNL1AXE/ref=nosim?tag=pucknethernet-20&linkCode=sb1&camp=212353&creative=380549 If you have no plans for tomorrow and like this type of stuff, go ahead and take a quick read :) Much of this stuff isn't new. There have been industry groups working on these supply chain assurance and risk models for years. If you are truly paranoid you will be working with these groups already. Pointers available in private if you want them. - Jared

Any one heard of a host checker issue with Juniper VPN today ? Thanks Kapeel

This is it thanks. Kapeel From: Jamie Gwatkin [mailto:jgwatkin@magmic.com] Sent: Tuesday, December 31, 2013 7:43 AM To: Sharma, Kapeel Cc: nanog@nanog.org Subject: Re: Juniper SSL VPN Could be related to this? http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290 On Tue, Dec 31, 2013 at 10:31 AM, Sharma, Kapeel <Kapeel.Sharma@mckesson.com<mailto:Kapeel.Sharma@mckesson.com>> wrote: Any one heard of a host checker issue with Juniper VPN today ? Thanks Kapeel

On Tue, 31 Dec 2013 10:43:02 -0500, Jamie Gwatkin said:

Could be related to this? http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290

Do I want to ask why *THIS*? "Estimated Fix Date: Juniper engineering has root caused this issue is working to build and release a ESAP fix as soon as possible. The initial estimated release date for the fix is between 12/31/2013 (PST) and 1/3/2014 (PST). We will update this message regularly with the current status until we resolve this issue." We need an emergency fix because a piece of software unexpectedly hit an end-of-life date? Didn't we learn anything 14 years ago??!?

On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said:

...

We need an emergency fix because a piece of software unexpectedly hit an end-of-life date? Didn't we learn anything 14 years ago??!?

Juniper just posted a technical note saying the issue is fixed and a new ESAP package is out.

Right. The question is why it's coming out on the last day of December, rather than the last day of November, or even October...

On Tue, Dec 31, 2013 at 11:19 PM, <Valdis.Kletnieks@vt.edu> wrote:

On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said:

...

...

We need an emergency fix because a piece of software unexpectedly hit an end-of-life date? Didn't we learn anything 14 years ago??!?

Juniper just posted a technical note saying the issue is fixed and a new ESAP package is out.

Right. The question is why it's coming out on the last day of December, rather than the last day of November, or even October...

From what I understood from the tech note, they had no clue this would happen on the 31st of December :)

On Dec 31, 2013, at 7:05 AM, Ray Soucy wrote:

I think there needs to be some clarification on how these tools get used, how often they're used, and if they're ever cleaned up when no longer part of an active operation. Of course we'll never get that.

But that's exactly what we need. Look at CALEA. It has its warts and issues, but the rules are published so everyone knows how the game is played. Even with NSLs, there's apparently some oversight, and you can challenge certain aspects (though it's a long and expensive process). But backdooring gear, servers, BIOS, etc. has no rules. It's just chaos. You don't know if a customer has been targeted, so you can't take appropriate steps. You have no way of knowing if your gear is backdoored or who is using the backdoor. And simply knowing that there is a backdoor will increase the chances that it will be found and used by others. The known threat landscape has been increased by orders of magnitude. --Chris

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.

On Tue, Dec 31, 2013 at 5:38 AM, Sabri Berisha <sabri@cluecentral.net>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.

From my experience with Juniper, you can actually tell the PFEs to do quite a lot to the packets that flow through the router, I would imagine that

You would just need an entry-point into the system, nothing fancy at first. programmatically you can tell the router to mirror packets which match a certain criteria (source, destination, ports, protocol) to a chosen destination and it would not get noticed by the NOC monitoring systems (it may not even blip on the throughput graphs)

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.

All you need is a hook into the system and load your code, the main payload can be easily downloaded from the internet.

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.

Who checks the binaries when they are loaded when the OS boots up ? :)

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: admin@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 <erey@ernw.de> wrote:

On Mon, Dec 30, 2013 at 04:03:07PM +0000, Dobbins, Roland wrote:

...

On Dec 30, 2013, at 10:44 PM, <Valdis.Kletnieks@vt.edu> <

Valdis.Kletnieks@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 <rdobbins@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 =======================================================

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

On Dec 30, 2013, at 11:28 PM, Marco Teixeira <admin@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 <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton

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.Kletnieks@vt.edu Date: 12/30/2013 6:48 AM (GMT-09:00) To: "Dobbins, Roland" <rdobbins@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 +0000, "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?

Is Ken Thompson turning over in his grave yet?

I certainly hope not...

I built the other. Sent from my Mobile Device. -------- Original message -------- From: Jeremy Bresley <brez@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 <stenrulz@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-junipe...

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 brez@brezworks.com