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