Saturday, December 12, 2020

Amnesia:33


Forescout Technologies made a huge announcement this week about a set of 33 vulnerabilities in four open source IP stacks (libraries) implemented in probably millions of devices around the world. Wired points out that Forescout has identified “33 flaws in an open source internet protocol bundles that potentially expose millions of embedded devices to attacks like information interception, denial of service, and total takeover. The affected devices run the gamut: smart home sensors and lights, barcode readers, enterprise network equipment, building automation systems, and even industrial control equipment. They're difficult if not impossible to patch—and introduce real risk that attackers could exploit these flaws as a first step into a vast array of networks.” Note that the vulnerabilities only apply to embedded devices, not personal computers, smartphones, servers or similar devices.

The article continues “The seven stacks[i] are all open source and have been modified and republished in many forms. Five of the seven have been around for nearly 20 years, and two have circulated since 2013. That longevity means that there are many versions and variations of each stack out there with no central authority to issue patches. And even if there were, manufacturers who have incorporated the code into their products would need to proactively adopt the correct patch for their version and implementation, then distribute it to users.”

‘What scares me the most is that it’s very difficult to understand how big the impact is and how many more vulnerable devices are out there,’ says Elisa Costante, vice president of research at Forescout. ‘These vulnerable stacks are open source, so everybody can take them and use them and you can document it or not. The 150 we have so far are the ones we could find that were documented. But I'm sure there are tons and tons of other vulnerable devices that we just don't know about yet."

But it gets worse. Later, the article says “…in many cases it wouldn't actually be feasible for device makers themselves to push patches even if they wanted to or could. Many vendors get basic functionality like the TCP/IP stack from the ‘systems on a chip’ provided by third-party silicon makers, who would need to be involved in a fix as well. And it's far from a given that many of these parties would even have a way to deliver a patch. In some instances, for example, Forescout researchers found that vulnerabilities in a diverse array of devices could all be traced to one systems-on-a-chip maker that went bankrupt and is no longer in business.”

This means it won’t do a lot of good to wait for patches; they may never come. The article gives this advice on other means to mitigate the risks caused by these vulnerabilities: “IT administrators should patch as many devices as possible as often as possible, knowing the scope of devices connected to a given network, monitoring traffic patterns to spot suspicious activity, and segmenting networks so one compromised device can't give attackers keys to the whole kingdom.”

There are two main culprits in this story. The first is the open source communities that developed these flawed IP stacks. While I haven’t seen anything directly addressing this issue, it seems clear that these vulnerabilities show that some communities (perhaps a lot) aren’t following good software development practices (see this post for a further statement of the open source problem, although not a solution).

The manufacturers of devices that include this flawed software are culprits, but also victims in this case. A white paper from Forescout includes this statement: “It is rare to have a complete list of all hardware and software components, known as a Bill of Materials (BOM), for IoT and OT devices. These components come from a device vendor’s supply chain, and may run embedded software such as TCP/IP stacks. The numbers and types of embedded components in devices often come as a surprise to the end user, and the same can often be said for device vendors. Thus, there is no way to know precisely how many devices are affected by AMNESIA:33, and actual device numbers may far exceed current estimates of millions of vulnerable devices in enterprise networks.”

An article in SC Magazine elaborates on this statement: “For asset vendors, the risk is to inadvertently produce and ship large numbers of devices that contain the faulty stacks. This can happen because open source TCP/IP stacks are so deep into the supply chain that it is not unthinkable that the producer of an end device is unaware of their presence.” 

Of course, the risk here is that both the users and the manufacturers don’t know what’s embedded in what they’re buying: the “software within the software”. What is the ultimate solution to this problem? Multilevel software bills of materials (SBoMs), which tell both end-product manufacturers and user organizations not only what are the immediate components of the software they buy, but what are the components of those components, the components of the components of those components…yea verily, unto the tenth or twentieth level. That way, a simple search will let the consumer or manufacturer identify every instance of a particular component – like the four IP stacks affected by the Amnesia:33 vulnerabilities – in a final product.

When will it be possible to do these simple yet very powerful searches, thus eliminating what might be thousands of hours of work to identify instances of a component, without any guarantee of success? Probably never, although possibly a little before that. If even first-level SBoMs are available – and updated whenever the software changes – for most software products within say 2-3 years, that would be welcome but surprising.

But here’s the thing about SBoMs: They’re not an all-or-nothing proposition like vaccines, where there has to be widespread use before there is any real benefit from them. Even though you won’t have probably even five-level SBoMs for most of your software products within five years, even if you could have two-level SBoMs for most of your software within five years, that would be a huge improvement from now, when you most likely have 0 SBoMs of any level. Any amount of software transparency at all is an improvement from what you have now, and will enable you to make your organization more secure.

If you’d like to be part of the solution to this problem and you’re in any way involved with the electric power industry (or just curious, no matter what you do), you’re welcome to attend one of the webinars next Thursday. In both webinars, we will provide an SBoM 101 overview and a description of the upcoming proof of concept for the industry, which you might want to participate in.   

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.


[i] Forescout just names four IP stacks in their press release. It is possible that Wired misread Forescout’s press release, which said the vulnerabilities affect seven components of the stacks: DNS, IPv6, IPv4, TCP, ICMP, LLMNR and mDNS. So as long as you aren’t using IPv4 or v6, DNS or TCP, you have nothing to worry about! 😊

No comments:

Post a Comment