Ars: Advanced CIA firmware can turn home routers into recon slaves

[Dan Goodin]

​

Home routers from 10 manufacturers, including Linksys, DLink, and Belkin, can be turned into covert listening posts that allow the Central Intelligence Agency to monitor and manipulate incoming and outgoing traffic and infect connected devices. That's according to secret documents posted Thursday by WikiLeaks.

CherryBlossom, as the implant is code-named, can be especially effective against targets using some D-Link-made DIR-130 and Linksys-manufactured WRT300N models because they can be remotely infected even when they use a strong administrative password. An exploit code-named Tomato can extract their passwords as long as a default feature known as universal plug and play remains on. Routers that are protected by a default or easily-guessed administrative password are, of course, trivial to infect. In all, documents say CherryBlossom runs on 25 router models, although it's likely modifications would allow the implant to run on at least 100 more.

Continue reading on Ars Technica

 

[eak]

The CherryBlossom user's manual, as released by WikiLeaks, indicates that the CIA software can be built for Asus hardware. Is anything known about what techniques were used to compromise Asus routers, and whether those vulnerabilities have been closed in the latest software?

 

[sfx2000]

Took a fast look at a couple of things - it's dependent on vulnerable versions on the uPNP daemon - I think Asus (or may rmerlin) has updated that service.

Many other vendors have as well... sounds exciting, but might not be these days - it's not exactly a zero-day exploit there.

Risk is for older gear that hasn't been updated for a while.

(BTW - Apple's Airports - not impacted - as they don't run linux, and they don't run the upnp daemon)

 

[pege63]

http://www.zdnet.com/article/cia-ha...i-fi-routers-for-years-leaked-documents-show/

 

[Malcolm_Thawne]

https://www.theverge.com/2017/6/15/...router-hack-surveillance-dlink-linksys-belkin

I guess this is not suprising, but is still a bit depressing.

 

[Threska49]

Whew! Thank goodness I'm a nobody. Anyone listening would die of boredom.

 

[RMerlin]

(BTW - Apple's Airports - not impacted - as they don't run linux, and they don't run the upnp daemon)

I did see one Airport being listed in their documents.

 

[RMerlin]

Well-written article BTW Ars. Unlike ZDNet who claims that the CIA has invented time travel...

According to one 2010-dated document, the CIA had by mid-2012 developed implants...

 

[sfx2000]

I did see one Airport being listed in their documents.

As being unsuccessful - that was the Harpy Eagle tool... 3 letter agencies have not had a lot of luck with Airports - there's not much inside them (e.g. no WebGUI, no shell, minimal services, and Apple is fairly clued in on security as part of the design, not added in later)

It probably helps that Apple uses NetBSD rather than linux in their 11n/11ac gear

I'll concede Apple has had issues with upstream code in the past - good case here was the HeartBleed SSL on the 11n/11ac Airports, and for Heartbleed, they pushed out an update almost immediately - current firmware for Airport 11n (7.6.8) and Airport AC (7.7.8), and upgrading firmware on Airports is fairly painless -- so there's a fair amount of herd immunity when fixes are deployed. That, and it's a small threat surface/target compared to other consumer Router/AP's numbers wise...

Keep in mind that many of the affected vendors... pretty much use the vendor SDK's as the base of their firmware, as such, when vulns like this pop up, it can impact a large group...

I think the only consumer oriented vendor that comes close to Apple for device security would be Asus on the RT-AC product lines - mostly due to mandated code audits and long term support on certain models.

 

[RMerlin]

It probably helps that Apple uses NetBSD rather than linux in their 11n/11ac gear

Linux has nothing to do with it. The almost entire list of security issues found in these routers in recent years had to do with either third party code (miniupnpd, OpenSSL, Samba, etc...), or the manufacturer's code (httpd, rc, etc...). A small portion came from the SDK (BCM's acsd).

Apple escaped most of these not because of BSD, but because:

1) they wrote the large majority of the code, with better quality standards than a lot of third party/open source components (for example, fairly sure their TLS stack is much better written than OpenSSL pre-Heartblead was)

2) That code being closed source, it's harder to track potential issues beside hands-on testing, so issues are harder to find

3) Much reduced attack surface, by having a reduced feature set: no Samba, FTP or VPN services


Not denying the end result, just saying the cause isn't BSD vs Linux - it's all the userspace content.

 

[mokodi]

How about the Google Wifi/OnHub devices which implement secure boot? That should prevent these types of exploits unless they have the ability to sign firmware or have the cooperation of Google right?

 

[sfx2000]

How about the Google Wifi/OnHub devices which implement secure boot? That should prevent these types of exploits unless they have the ability to sign firmware or have the cooperation of Google right?

That's an excellent point - the OnHubs/Google WiFi devices run a variant of ChromeOS - everything is signed code, and clear separation of user code and system code, and even then, it's checked each time the code runs - so it would be extremely difficult to hack in remotely without physical access to the device.

google WiFi has the TPM module - don't recall if TP-Link and Asus on-hubs have it, but even then, they're robust on the security side.

 

[RMerlin]

How about the Google Wifi/OnHub devices which implement secure boot? That should prevent these types of exploits unless they have the ability to sign firmware or have the cooperation of Google right?

RSA signed kernels are definitely a very good security measure (but with its own set of drawbacks, especially for people like me). But I wouldn't assume it to be 100% tamper-proof. Signing keys could be compromised, a collision might exist in the signing cipher, bootloader might possibly be overwritable, etc...

And there's always the possibility that one could simply inject its own daemon in the existing firmware, and start hijacking DNS requests, add additional routes, etc...

Best example here: the whole jailbreak community in the Apple ecosystem. Security never prevented people from finding holes to slip within iOS.

 

[RMerlin]

(although the cynical might claim that Apple is deliberately leaving entry points to the jailbreak community, since it's a fairly interesting chunk of their userbase that might jump ship if they suddenly were no jailbreak methods anymore... But I doubt it.)

 

[sfx2000]

(although the cynical might claim that Apple is deliberately leaving entry points to the jailbreak community, since it's a fairly interesting chunk of their userbase that might jump ship if they suddenly were no jailbreak methods anymore... But I doubt it.)

Phones/Tablets do have more opportunities for executable code to do odd things - esp. something with a web browser and a decent javascript engine that can execute code there...

Router/AP's - smaller surface than a smartphone...

 

[dieter]

Does anyone know if ALL Asus routers with stock firmware validate the digital signature when updating firmware?

For further reading about this CherryBlossom treat:
http://searchsecurity.techtarget.co...ues-highlighted-by-CIAs-CherryBlossom-project

Thanks.

 

[RMerlin]

Does anyone know if ALL Asus routers with stock firmware validate the digital signature when updating firmware?

For further reading about this CherryBlossom treat:
http://searchsecurity.techtarget.co...ues-highlighted-by-CIAs-CherryBlossom-project

Thanks.

What digital signature? Router firmware are not signed... And if there were, then it would mean there would be NO third party firmware possible.

Careful what you wish for...

 

[wouterv]

The goal is to be very careful in selecting the source of what ever software, firmware or media you download. Be sure to download from genuine websites and preferably the website of the manufacturer or original author. E.g. download Asus firmware only from the Asus website and Merlin firmware only from Merlin's website.
Many download sites offer about anything for download (e.g. anti virus software, firmware files for various equipment, music and any data you think of). The real source of what is offered by those generic download sites can never be proved, the download files can easily be manipulated and extended with malware.

 

[RMerlin]

The issue here however is the fact that they can use an exploit to gain root access to your router, and flash a modified version of the firmware. Or so they claim.

There are quite a few things however that sound odd with this whole Cherry Blossom report. For instance, flashing a modified firmware would imply that anyone accessing the webui would see a different version. It's unlikely that they have modified images for every single version available, both stock and third party.

It's much more likely that what they could do is inject new routes within a running firmware rather than flat out replace the existing firmware. Unlike a Cisco router, a webui makes it VERY easy to notice that you're not running the original firmware.

If I didn't know better, I'd start wondering whether this Cherry Blossom is actually real or not. Too many of their claims simply make no sense to me. Another example, their document claim that it's easy to inject into a compromised device even if the firmware has been updated. That would imply that whatever security hole they use to inject themselves couldn't be patched by a firmware update - a claim I strongly disbelief.

Let's also not forget the fact that this is based on a 5 years old document...

 

[dieter]

As I understand the article, this has nothing to do with getting the firmware from a reliable source. "The wireless device itself is compromised by implanting a customized CherryBlossom firmware on it; some devices allow upgrading their firmware over a wireless link, so no physical access to the device is necessary for a successful infection."

I'm non-technical, so I don't know how the router firmware got "implanted" in the first place.

Here is another article on vulnerable routers/access points:
https://qz.com/1008273/complete-lis...ase-possibly-vulnerable-to-cia-hacking-tools/