Endpoint Security , Internet of Things Security , Open XDR
Millions of IoT Devices at Risk From TCP/IP Stack FlawsForescout Finds 33 Flaws in Open-Source TCP/IP Stacks
There’s new bad news on the IoT front. Again.
See Also: Board Members: Mitigating Their Security Risks
Millions of consumer and enterprise IoT devices have software flaws in their TCP/IP stacks that could result in remote code execution, denial of service or a complete takeover of a device. Forescout nicknamed the batch of vulnerabilities Amnesia:33. Devices from as many as 150 vendors are likely vulnerable.
The flaws impact a diverse range of embedded systems, ranging from medical devices, industrial control systems, routers and switches – virtually anything that is running a vulnerable TCP/IP stack. The largest affected categories of affected devices are enterprise and consumer IoT devices.
The research comes from Forescout Technologies, which analyzed seven open-source TCP-IP stacks as part of research called Project Memoria.
In some cases, “you can crash devices with a single [data] packet,” says Elisa Costante, vice president of research at Forescout, in an interview with ISMG. Many of the problems stem from poor software development practices, particularly an absence of basic input validation, according to Forescout’s report.
Forescout’s research will be presented at Black Hat Europe 2020.
TCP/IP Stacks: Crucial Components
The research is a continuation of Forescout’s exploration of TCP/IP stacks. In June, Forescout revealed the so-called Ripple20 flaws in a single but widely used TCP/IP stack made by an Ohio-based company, Treck (see Millions of Connected Devices Have Exploitable TCP/IP Flaws).
This time around, Forescout broadened its research into more types of TCP/IP stacks. The stacks enable basic network communication. Software developers don’t develop their own but instead use off-the-shelf open-source stacks in their products or forks of those projects.
“We discovered…33 vulnerabilities in four of seven [TCP/IP] stacks that we analyzed,” Costante says.
The flaws were found in uIP, FNET, PicoTCP and Nut/Net. Forescout also examined IwIP, CycloneTCP and uC/TCP-IP but didn’t find any of the most common coding errors. But Forescout says it doesn’t mean those TCP/IP stacks are necessarily free of problems.
Many of the issues are centered around Domain Name System functionality.
“We find that the DNS, TCP and IP sub-stacks are the most often vulnerable,” Forescout says in its report. “DNS, in particular, seems to be vulnerable because of its complexity.”
Brad Ree, who is CTO of the consultancy ioXt and board member at the ioXt Alliance, says it is concerning to see the IPv6 vulnerabilities in Forescout’s findings. Many IoT devices are starting to use 6LoWPAN (Low-Power Wireless Personal Area Networks), which is a network protocol that lets low-power or constrained devices use IPv6.
“Consumers will quickly lose patience with devices which lock up when a single malformed packet is received,” Ree says. “Consumer IoT will fail if the we have to tell our parents ‘Did you reset the refrigerator?’”
Outreach Efforts Underway
There’s a wide effort underway now by major vendors and computer security organizations to spread the message about the vulnerabilities and, if possible, implement fixes. But the problem is difficult: vulnerable products have to be identified, assessed and then fixes need to be implemented. Some devices may not be able to be patched, Costante says.
Another problem is that most IoT devices don’t come with a software bill of materials (SBOMs), which are lists of what software components are inside devices. That means determining which devices have a problem isn’t necessarily straightforward (See Keeping the Software Supply Chain Secure).
”Because of the absence of a software bill of materials, it is often very hard to determine whether a vulnerable software is in a device,” says Andrei Costin, co-founder and CEO of Binaré, which specializes in securing IoT devices pre-deployment. “Conversely, when vulnerabilities get discovered, it is very time-consuming to contact all potentially affected vendors."
Thus, Forescout’s estimate of the number of affected devices is likely “the tip of the iceberg,” Costante says.
“One of the most challenging problems arising by this study is identifying the impacted devices,” she says. “Because we are speaking of open source code and we are not speaking of a single device or a single model or a single vendor…it’s difficult to assess how many devices are actually impacted.”
Forescout began notifying the maintainers of open-source projects in August. Rather than notifying each individual vendor, Forescout has been working with ICS-CERT, the CERT Coordination Center, Germany’s Federal Office for Information Security (BSI) and JPCERT Coordination Center to distribute alerts about Amesia:33.
To uncover vulnerabilities, Forescout researchers used libFuzzer, manual analysis and code review and a pre-existing corpus of vulnerabilities.
It’s tricky to make generalizations about how exploitable the flaws are, Forescout warns in its report. As an example, an information leak of just a few bytes may not seem on the surface that serious, but it could “become part of a larger exploit chain with far more significant impact than the sum of its parts,” Forescout says.
Plus, IoT or OT devices, which are considered embedded systems, usually don’t have the hardware or software to support modern techniques for mitigating exploits, such as non-executable data memory or address space layout randomization.
“The combined lack of exploit mitigations and memory protection in embedded systems tends to render exploitation significantly easier than on modern IT devices,” Forescout writes.