Re: NSA able to compromise Cisco, Juniper, Huawei switches

["[AP] NANOG" <nanog () armoredpackets com>]

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.