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.

Errata

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.