Updating software: NAME:WRECK shows it’s not always quick and easy

“Keep your software up to date,” is a constant mantra from cybersecurity experts.

For good reason. Failing to patch vulnerabilities in your software — especially when those vulnerabilities are known and there are patches available to fix them — is a bit like leaving the vault open at night. It’s an open invitation to cyber criminals.

But keeping software up-to-date is not always as simple as getting a notification from a vendor, clicking the “update-now” button, and then watching the little circle fill in, or the progress bar tell you how many minutes or seconds left before it’s installed.

The NAME:WRECK cluster of bugs, featured in a report released a few weeks ago by researchers from Forescout and JSOF, is the most recent high-profile example that patching can be complicated and difficult.

More detail on that shortly. But that report is one reason NAME:WRECK is now famous. Over the last few weeks, the tech press has been all over it. Another reason could be that its reach illustrates the scale (and therefore the risks) of the Internet of Things (IoT). The researchers estimated that at least 100 million devices worldwide were impacted by what they called a “cluster” of nine related bugs.

Which is a lot — a number close to a third of the population of the U.S. But compared to the entire IoT, now estimated at 31 billion devices and growing, it’s in the category of a rounding error — just 3/10 of 1 percent.

In other words, the IoT is an indescribably large attack surface. You can be sure that an army of hackers is out there looking for more collections of bugs to exploit in other “tiny” 100-million-device corners of the IoT. Some of those devices may be owned or used by you. Because we’re all connected to the IoT. We can’t avoid it.

Patch or perish

Which is why the main message of the report—patching vulnerabilities in the software of your IoT devices—is important. Really important.

And on the face of it, there’s no good reason why the NAME:WRECK bugs should have put any organization, or devices, at risk. The vulnerabilities are all known. They have all been assigned Common Vulnerabilities and Exposures(CVE) numbers and are therefore on a list maintained by the MITRE Corp. And there are patches available for all of them — at least one has had an update available for nearly a year.

Of course, as should be obvious, a patch is only effective if it’s installed. There’s a long parade of horror stories about what can happen when they are not installed, perhaps the most notorious of which is the 2017 breach of credit reporting giant Equifax that compromised crucial personal information of more than 147 million people because the company failed to install a patch for a vulnerability in Apache Struts, a popular open source web software. That patch had been available for months.

In the case of NAME:WRECK, the group of nine bugs are connected to “underlying problems related to Domain Name System (DNS) implementation,” according to the Forescout/JSOF report.

DNS converts web addresses like www.yourbusiness.com that are easy for humans to read into internet protocol (IP) numbers like 168.212.226.204, which are much easier for computers to read.

But as Paul Ducklin wrote on the Naked Security blog, systems that function just fine when they receive normal packets of input can “misbehave when faced with deliberately malformed packets that would never occur in regular use.”

Which is why such things are a favorite tactic of hackers.

The researchers reported that the vulnerabilities appear in “four popular TCP/IP (transmission communication protocol/internet protocol) stacks and in popular IoT/OT firmware, such as Siemens’ Nucleus NET.

One of the most popular TCP/IP stacks, FreeBSD, “is widely known to be used for high-performance servers in millions of IT networks, including major websites such as Netflix and Yahoo,” the report said. Another, Nucleus NET, “has been used for decades in several critical OT and IoT devices.”

Those vulnerabilities, if not patched, could allow for denial of service (DoS) or remote code execution (RCE) attacks.

DoS attacks are what the name implies. They flood a website with so much junk traffic that it blocks legitimate traffic, denying its ability to service its customers. An RCE vulnerability allows an attacker to execute code on a remote machine and install malware on it, which can lead to the takeover of an entire system.

It’s very complicated

So the solution would seem to be obvious: Install patches. It’s just that in this case it’s more complicated. The researchers said “patching devices is not always possible, and the required effort changes drastically depending upon whether the device is a standard IT server or an IoT device.”

So, what’s an organization trying to keep its systems secure to do? Forescout and JSOF offer a list of “mitigation” strategies. But none of them is simple or quick.

• Find and create an inventory of devices running the vulnerable stacks. The researchers provide an open source script to help with that, which is regularly updated “with new signatures to follow the latest development of our research.” Forescout customers using eyeSight can also automatically identify devices using FreeBSD, Nucleus RTOS, ThreadX or VxWorks.
• Enforce segmentation controls (as in, don’t allow things to be connected if they don’t have to be) and use “proper network hygiene” to mitigate risk from vulnerable devices. Restrict external communication paths, and isolate or contain vulnerable devices if they can’t be patched or until they can be patched.
• Keep track of progressive patches released by affected device vendors and create a remediation plan for your vulnerable asset inventory.
• Configure devices to rely on internal DNS servers as much as possible and closely monitor external DNS traffic since exploitation requires a malicious DNS server to reply with malicious packets.
• Monitor all network traffic for malicious packets that try to exploit known vulnerabilities or possible zero days (previously unknown vulnerabilities for which there is no patch yet available). Block any anomalous and malformed traffic, or at least alert your network operators about it.

The first item on that list — create an inventory or Bill of Materials (BoM) — is the most important. Without it, everything else is irrelevant. That’s why there’s a security cliché (which is a cliché because it’s true) that says you can’t protect what you don’t know you have.

As Quinn Wilton, research and development technician with the Synopsys Software Integrity Group, puts it, “Organizations often don’t have a thorough inventory of what software or hardware they’re running in the first place, so they’re unaware that they need to patch,” she said.

But even a BoM for all your software won’t always get you all the way there. “Even if the organization knows what software it’s running, tracking vulnerability disclosures can sometimes be a full-time job,” Wilton said, “so it’s easy for vulnerabilities to slip through the cracks.”

Then there’s the varying complexity of patching. John Tapp, senior consultant with the Synopsys Software Integrity Group, said sometimes it is “a simple implementation flaw like with Apple’s infamous “goto fail” bug that didn’t do its job because of an oversight in implementation. Other times you may have a fundamental flaw in how the system is designed that requires redesigning an individual flow or even the entire architecture of the affected software.”

“Then you have things in between where a team needs to understand an issue better to figure out what the root of a problem is and how it can be best addressed. This could lead to a complex vulnerability being temporarily fixed with a mitigating control while the team develops a solution that completely remediates it,” he said.

The priority, Wilton said, “should always be to understand the threat surface you’re dealing with. That’s only possible if you’re able to inventory all the software you’re running and determine who’s responsible for responding to incidents relating to that software.”

Which, she said, makes it more “an organizational problem than a technical one, although software can help mitigate some of the work required to survey your threat surface.”