Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Cisco clueless about security, apparently: Meet Thrangrycat

Richi Jennings Your humble blogwatcher, dba RJA

Hundreds of Cisco products are vulnerable to a secure-enclave takeover. Dubbed Thrangrycat, it permits an attacker to hide a persistent threat inside the Trust Anchor module (TAm) of any number of Cisco networking boxes.

The kicker: The software image loaded by the TAm—the “bitstream”—is not encrypted, nor verified. I mean, seriously, what’s the point of it all?

Shouldn’t we all just give up now? It’s tempting. In this week’s Security Blogwatch, we try to ignore the researchers’ stupid, stupid use of emoji to name a vuln.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: tipping explained.

3x U+1F63E: Pissed pussies

What’s the craic? Lily Hay Newman has this breathless “exclusive”—A Cisco Router Bug Has Massive Global Implications:

Researchers are disclosing a remote attack that would potentially allow a hacker to take over any … Cisco 1001-X series router … and compromise all the data and commands that flow through it.

[There are] two vulnerabilities: The first is a bug in Cisco’s IOS … which would allow a hacker to remotely obtain root access. … This is a bad vulnerability, but not unusual. … The second vulnerability, though, is much more sinister. Once the researchers gain root access, they can bypass the router's most fundamental security protection.

Known as the Trust Anchor, this Cisco security feature has been implemented in almost all of the company’s enterprise devices since 2013. … It may be possible, with device-specific modifications, to defeat the Trust Anchor on hundreds of millions of Cisco units around the world [and] fully compromise the networks these devices are on.

The potential fallout would be enormous.

Sounds bad. Iain Thomson introduces A Cisco router secure boot flaw … to bury spyware deep inside pwned networking gear:

In order to exploit these flaws [you need] to log into the vulnerable device as an administrator, and can thus already do a lot of damage … anyway. What makes [it] interesting is that it can be used by an attacker to … go deeper, making fundamental changes to the way the equipment boots up so that spyware, once installed, is always secretly present and running, and can't be patched out or removed.

The vulnerability allows malicious code to persist on compromised systems.

CVE-2019-1862 … can be exploited by a logged-in administrator to execute commands as root. … A rogue admin can [use] that input-sanitization vulnerability to exploit the second part: … to change the firmware [via] CVE-2019-1649 [for] an on-board FPGA chip [which] is configured to implement what Cisco calls its Trust Anchor.

This technology ensures the equipment boots software that is legit and hasn't been tampered with. … Unfortunately, the Trust Anchor module (TAm) doesn't check that its own data is legit.

Who found it? Jatin Kataria, Richard Housley, James Chambers, and Ang Cui of Red Balloon Security. They dubbed the TAm vuln Thrangrycat (or three pouting-cat emoji):

While the flaws are based in hardware, [it] can be exploited remotely without any need for physical access. Since the flaws reside within the hardware design, it is unlikely that any software security patch will fully resolve the fundamental security vulnerability.

Secure Boot … ensures the integrity of the firmware … each time the device resets. Cisco developed a separate, special-purpose hardware device, known as the Trust Anchor module (TAm), as a root of trust. … Should any failure be detected, the device alerts the user and reboots the device … before the microloader is delivered to the main processor.

An attacker with root privileges on the device can modify the contents of the FPGA anchor bitstream … to disable critical functionality in the TAm. … We are unaware of any use of this exploit in the wild, but the potential danger is severe.

The vulnerability … affects more than 100 Cisco product families. … Since [it] is fundamentally a hardware design flaw, we believe it will be very difficult, if not impossible to fully resolve this vulnerability via a software patch.

So sh-run isn’t looking forward to patching it:

[I’m] a Network Engineer at an org with decent staffing and a great cyber sec program. … I'm not overly worried about this [but] we'll still patch the second we can.

Many orgs are unwilling to take a network outage for patching, especially in places like their DCs, internet or WAN edges where many of these devices would be deployed. I'm also aware of companies that are understaffed, where employees don't have the extra cycles to patch or apply workarounds.

These are the same places that don't have active cyber security departments (no red-team, no vulnerability scanning, no dot1x and no written cyber security requirements) and don't budget for redundancy (making it even harder to patch). … With how sophisticated some attackers have become and the slow rollout of network patches, this will probably be actively exploited even if it hasn't been already.

But this Anonymous Coward waxes excoriating:

Yet another secure boot exploit targeting a security chip. Can we stop with all of the "trusted" binary blobs controlled by manufacturers now?

In practice it's just another system that ultimately gets hacked, but one we can't do anything about and has full access to everything else by default. So instead of fixing the original "problem" (no bootsector viruses were not that big of a problem to deal with, a reimage would take care of it, as would have a write protect switch on the firmware chip.), they've gone and not only doubled the original issue by creating a second system running in parallel with all the same issues.

But they made it worse by making it so that end users could do nothing with that secondary system except "trust" it implicitly because they weren't given a choice in the matter. Just stop it. These companies are creating multimillion dollar secondary systems that fix none of the original issues, create new ones of their own, require hours of PR management, development, etc.

All it would take to fix the original problem is a $2.00 recovery disc and a $0.67 jumper on the motherboard.

Wait. Pause. How come the TAm bitstream is vulnerable in the first place? Shouldn’t it have been encrypted? Chris Holgate—@zynaptic—is baffled:

Valid FPGA bitstreams will be encrypted using a one-time programmable key. So you can't load any old configuration.

The FPGA vendors have put a significant amount of effort into supporting just this kind of use case. So not using that capability seems a bit weird.

So this is a deliberate backdoor? Hikikomori doubts it:

Doubt it. It's the consequence of bad security practices, incompetence at many levels, rushing to market, and in general how these platforms are designed.

But arglebargle_xiv? Not so much:

I hope the US government finally warns other governments about allowing these dangerous, obviously deliberately backdoored products into their 5G infrastructure, and instead directs them to vendors with better track records.

Like Huawei.

Meanwhile, Simarpreet Singh—@simarpreet7—is wrong, wrong, wrong:

Naming vulnerability disclosures … with emoji is the world's most progressive and disruptive idea ever.

The moral of the story?

Layered security only works if the layers are, y’know, secure.

And finally

Tipping explained (may contain lies for comedic effect)

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Emmanuel Keller (cc:by-nd)

Keep learning

Read more articles about: SecurityInformation Security