Do you know what your router is doing? We have two stories of the embedded devices misbehaving. First, Linksys “Smart” routers keep track of every device that connects to its network. Right, so does every other router. These routers, however, also helpfully expose that stored data over JNAP/HNAP.
Some background is needed here. First, HNAP is the Home Network Administration Protocol, designed to manage routers and network devices. Originally designed by Pure Networks, HNAP is a SOAP based protocol, and has been part of security problems in the past. You may also see the term JNAP. It seems that JNAP is the JSON Network Administration Protocol, identical to HNAP except for using JSON instead of SOAP.
The odd part is that this is an old problem. CVE-2014-8244 was disclosed and fixed in 2014. According to the writeup at Badpackets.net, the problem was re-discovered as a result of observing active network attacks targeting JNAP. When Linksys was informed of the rediscovered problem, they responded that the problem was fixed in 2014, and devices with updated firmware and default settings are not accessible from the public internet. The presence of over 20,000 devices leaking data casts doubt on their response.
Malicious Routers and Cloud Storage
Researchers at Eset have been studying a backdoor called “Plead”, mainly targeted at Asian companies. In a recent blog post, they describe an uptick in infections, stemming from an executable named “AsusWSPanel.exe”. Yes, Asus features in our weekly column again. Eset considered the possibility of another supply chain attack, and while they don’t completely rule it out, they strongly suspect that this is actually a man-in-the-middle attack. When the Asus WebStorage application checks for updates, it doesn’t use encrypted connections or any verification. The server has a higher version number? Great, download and run it. The group behind Plead have been known to use router vulnerabilities in the past, so it’s not a stretch to assume that the Asus update is hijacked by a compromised router. Unfortunately the Eset writer doesn’t disclose what routers they suspect to be vulnerable.
Let’s have a talk about routers. They’re embedded computers. Many of them are running ancient, unpatched versions of Linux. They’re tiny computers on your network that you don’t control, and that should worry you. Many of them open their control interface to outside connections by default, sometimes without even an option to disable that mis-feature. When considering your network security, don’t forget the router. OpenWRT, PFSense, and others are excellent options.
Zombieload, or Meltdown By Any Other Name
You’ve probably already heard of Zombieload, the next iteration of the Meltdown weakness. This class of vulnerabilities targets speculative execution, the ability of modern processors to run code out of order in order to speed up the overall execution process. With the discovery of Meltdown and Spectre in 2017, a new avenue of research was opened, leading to Spectre-NG, Foreshadow, Spoiler, Fallout, RIDL, and now Zombieload. All the attacks are similar in that they abuse speculative execution to extract the contents of memory to a non-privledged process.
Zombieload specifically targets processes running on the same physical core as the attacking process. The post containing their demo shows off the ability to extract information even when the attacker is running inside a Virtual Machine.
The central concept of Zombieload is that as data is loaded from memory into the on-processor cache, that data persists in buffers between RAM and cache. An attacker can abuse speculative execution in order to determine the contents of those buffers. In essence, this gives an attacker a window into the stream of data flowing into the physical processor it is running on, even if that data is from another process or even another VM.
So far, only Intel processors are vulnerable to Zombieload, and updated microcode has been released for processors as old as second generation Core processors. This microcode doesn’t actually fix the issue, but instead repurposes a obsolete command, “VERW”. This command allows the OS to forcibly flush the vulnerable buffers when switching between processes or VMs. The Linux code is the most available for further study. Windows and MacOS have also pushed updates to do partial mitigations by default, on processors that have received the required microcode updates.
The last wrinkle of Zombieload is SMT, or Hyperthreading. The mitigation above happens whenever the kernel does a “context switch”, when it unloads one thread of execution and switches to another. Hyperthreading is essentially the processor hardware performing the context switch, instead of the kernel. It makes some tasks execute much faster, but in this case it prevents the kernel from ensuring the Zombieload mitigation happens. For use cases where Zombieload absolutely must be fully mitigated, the only possible solution is to fully disable SMT/Hyperthreading on Intel chips.
The RDP vulnerability we covered last week has a name: Bluekeep. It’s better than “Thrangrycat”, at least. There is also proof of concept code, as well as a scanning utility.
8 thoughts on “This Week In Security: Zombieload, And Is Your Router Leaking?”
I demoted my router to simply being an access point a long time ago and now use a Raspberry Pi as my router(easy to set up with the exception of getting the IPV6 side of things working.) The reasons include the darn thing crashing every so often, there haven’t been any patches released for it in ages, and I have much more greater control of things with a Raspberry Pi. A strane thing that I’ve noticed with my router (now just as an AP) is for some reason it likes to do ARP requests for every address in the subnet every so often.
Oh, Intel, Intel, Intel… Does nobody at that company understand security at the hardware level? And the solution is always to kill the processor’s performance by like 50%. Meanwhile AMD chips can continue to run at 100% without leaking important data all over the place.
Come to think of it, I can’t remember a single instance of a security bug that affected AMD and not Intel. Anyone?
Going to be pessimistic here. I almost wonder if no AMD exploits have been found (that we know of) simply because the targets that malicious hackers have in mind more than likely use Intel CPUs.
All of the shortcuts that Intel used to make their processors faster than the competition came back to bite them in the butt.
Yes, and who kept demanding those improvements? Single-thread performance is what everyone kept hammering about (reviewers too), holding it over AMDs head in the inevitable “ours better than yours” E-penis that’s fanboyishness. People got what they wanted, and now they’re complaining about the price that decision entailed. If they wanted security, they knew what they could have bought.
It’s ironic, and I don’t understand how none of this affects AMD because….
AMD licenses the x64 tech to Intel. Intel sold (sells?) x86 rights to AMD, but AMD beat Intel to the 64-bit game (minus IA-64) and Intel essentially paid AMD for the x64/x86-64. So given the similarities with what Intel are using as well as AMD, how can they (AMD) not be affected at all?
AMD doesn’t speculate
I don’t think that’s true. They just use different approaches and techniques. The IPC improvements they brag about with each new processor is a direct result of speculation improvements.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)