[167854] in North American Network Operators' Group
Re: NSA able to compromise Cisco, Juniper, Huawei switches
daemon@ATHENA.MIT.EDU ([AP] NANOG)
Mon Dec 30 23:06:27 2013
Date: Mon, 30 Dec 2013 23:06:29 -0500
From: "[AP] NANOG" <nanog@armoredpackets.com>
To: nanog@nanog.org
In-Reply-To: <1536002173.5096.1388461092319.JavaMail.zimbra@cluecentral.net>
Reply-To: nanog@armoredpackets.com
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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...
--=20
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 natu=
re,
>> 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 B=
IOS.
>
> Assuming M/MX/T series, you are correct that the foundation of the cont=
rol-plane is a FreeBSD-based kernel. However, that control-plane talks to=
a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which dif=
fer per platform and sometimes per line-card). In general, transit-traffi=
c (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 th=
e backdoor is designed to do, simply can not touch the traffic. There are=
a few exceptions, such as a carefully crafted backdoor capable of alteri=
ng the next-hop database (the PFEs forwarding table) and mirroring traffi=
c. This however, would mean that the network would already have to be com=
promised. Another option would be to duplicate target traffic into a tunn=
el (GRE or IPIP based for example), but that would certainly have a notic=
eable affect on the performance, if it is possible to perform those opera=
tions at all on the target chipset.=20
>
> However, attempting any of the limited attacks that I can think of woul=
d require expert-level knowledge of not just the overall architecture, bu=
t also of the microcode that runs on the specific PFE that the attacker w=
ould target, as well as the ability to partially rewrite that. Furthermor=
e, to embed such a sophisticated attack in a BIOS would seem impossible t=
o me with the first reason being the limited amount of storage available =
on the EEPROM to store all that binary code.=20
>
> An attack based on corrupted firmware loaded post-manufacturing would a=
lso be difficult due to the signed binaries and microcode. If someone wer=
e to embed a backdoor it is extremely difficult without Juniper's coopera=
tion. 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.=20
>
