xIoT XIoT Device Risk: Turning the Industry Inside-Out

A famous philosopher once asked, “if a black box is opened in a forest, and no one is around to look inside, does it have vulnerabilities?” . . . On second thought, maybe that wasn’t the exact quote, but it captures the mystique that has surrounded Extended IoT (XIoT) devices since, well, really the very beginning. Think about it: how many security solutions and technologies do we dedicate to our traditional workstations and servers? Endpoint protection, EDR, patch management tools, HIPS, DLP - the list goes on. So why aren’t our XIoT devices receiving the same treatment, especially considering more and more attacks each year target these devices as attack vectors? The primary issue is that these solutions which provide visibility and protection of traditional IT simply haven’t existed in the XIoT world.

Viewing these devices as black boxes -  knowing virtually nothing about the underlying software - has led to an attitude of acceptance when it comes to the risk they pose to the network. Sure, we do our best to follow guidelines and best practices when it comes to implementing and operating these devices, and we run vulnerability scans in an attempt to identify threats, but there’s an inherent problem with this approach; vulnerability scans only tell us half the story (really, quite a bit less than half, as we’ve come to find out) - the outside.

In order to become aware of a vulnerability for one of these devices, it has to be published specifically for that device. Take, for example, an advisory released by Siemens in April 2020 notifying customers that some of their devices were vulnerable to “SegmentSmack” and “FragmentSmack” (CVE-2018-5390 and CVE-2018-5391), two vulnerabilities in the Linux kernel that allow remote Denial of Service (DoS) attacks. There’s a glaring issue here, which astute readers may have already honed in on . . . there is a 609 day gap between when these CVEs were initially published and when the security advisory for the affected devices was published. Unfortunately, users of these devices had no way of knowing they were running vulnerable software for nearly two years.

But what if we could flip the current paradigm and start talking about what's actually inside these devices; the operating system and kernel, CPU architecture, the individual software components? Simply having visibility into this information can help organizations immensely in identifying vulnerabilities and device misconfigurations, and can lead to a much better understanding of the holistic risk associated with these devices. Just like EDR solutions allow us to ask questions of the data on our workstations and servers, we need a solution that provides similar visibility for xIoT devices on the network.

Let’s compare analyzing a device from the outside with a traditional vulnerability scanner, to the information we can garner from looking at the inside (firmware) of that same device. For this exercise we’ll use a popular consumer router, running a recent firmware version. Using a traditional (unnamed) vulnerability scanner, we can only determine the make and model of the device from HTTP header responses (redacted for responsible vulnerability disclosure) , however we don’t even have a way to determine the firmware version from this scan:

Response Code : HTTP/1.1 200 OK
Protocol version : HTTP/1.1
SSL : no
Keep-Alive : no
…
Content-Length: 534
…
Response Body :
<redacted make> Router <redacted model>

Taking a look at the vulnerability results, we can see the scanner picked up five vulnerabilities; one critical and four medium. The specific vulnerabilities identified were as follows:

In addition to these, there were 49 “informational” alerts which highlighted things such as the MAC address, SSL/TLS version(s) in use, UPnP detection, DNS version detection, and more. All of this is certainly useful information, and these types of scans are great for alerting on known vulnerabilities for specific devices, but they’re only giving us that “outside” perspective.

 What if we look up that device and firmware version directly in the National Vulnerability Database? Now we get two vulnerabilities, CVE-2021-45603 and CVE-2021-45602:

Not even the same vulnerabilities that we picked up with the vulnerability scanner! Even a simple exercise like this one starts to highlight the issues and vulnerability disparity that can arise by simply scanning these devices from the outside.

What happens when we open the elusive black box, analyze the file system, kernel, operating system, and individual components contained within the firmware, and look for vulnerabilities and configuration issues from the inside?

Analyzing the same device’s firmware with the NetRise Platform can be an eye opening experience, to say the least. Strictly from a vulnerability perspective, analyzing the individual components reveals not two, or five, or even ten, but 142 vulnerabilities in the underlying components of the firmware.

This is the exact problem that is highlighted in the Siemens example from before. There are often dozens or even hundreds of “N-Day” vulnerabilities lurking inside these black boxes, and the only way to identify them is - shockingly - opening the box. Well, there’s always the other way to identify them (waiting for the device to get popped), but we don’t have to explain why that’s a suboptimal strategy.

But wait, we’ve only talked about vulnerabilities (CVEs) up until this point, which are really just the tip of the iceberg when it comes to the valuable information you can obtain from analyzing device firmware. The NetRise Platform is equipped with a host of analysis plugins that go well beyond identifying CVEs, which is crucial in determining the true risk associated with these devices. Certificates, public/private keys, embedded authentication secrets and credentials, binary hardening mechanisms, and configuration issues (to name a few) are all vital elements in identifying and categorizing this risk. At NetRise, we take all of these factors into account when prioritizing issues and assigning a risk score to a device.

What’s arguably the most important part in all of this is the visibility we mentioned previously; simply having the ability to ask questions about the components of your devices, and get fast, accurate, actionable responses is a critical element of building a successful XIoT vulnerability management program. Imagine a world where a new N-day (or 0-day for that matter) is announced and instead of long nights and weekends of contacting vendors trying to determine if your devices are affected, you can run a few search queries and instantly scope the issue across your entire XIoT network.

NetRise is empowering organizations to rethink the way they look at XIoT risk management. A vulnerability management program is simply incomplete if these devices are treated like the black boxes they historically have been viewed as. Let’s talk about the specific pain points you feel within your business, and how NetRise can help shape the future of your XIoT vulnerability management.