Forescout security researchers found that millions of smart devices were affected by internet protocol vulnerabilities, existing in open-source libraries used in their firmware.
The 33 vulnerabilities codenamed Amnesia:33, affected information technology (IT), operational technology (OT), and internet of things (IoT) devices manufactured by more than 150 vendors.
Forescout researchers discovered the vulnerabilities during a research project named Project Memoria inspired by the previous discoveries of Urgent/11 and Ripple20 vulnerabilities in the IPnet and Treck TCP/IP stacks. The researchers analyzed seven additional TCP/IP libraries in search of similar vulnerabilities.
Smart devices affected by vulnerabilities in the open-source networking libraries
The 33 vulnerabilities in open-source libraries affected both consumer and industrial-grade smart devices across enterprise verticals.
The bugs affect various smart devices, including badge readers, HVAC systems, gaming consoles, IP cameras, printers, RFID asset trackers, routers, self-checkout kiosks, smart plugs, smartphones, switches, system-on-a-chip (SOC) boards, uninterruptible power supplies, among others.
However, the number of affected devices could be higher, considering that most smart devices do not provide the software bill of materials.
Some of the vulnerabilities were directly or indirectly introduced through the installation of other products such as the Contiki and NutOS operating systems installed on the affected hardware. Examples of products include the MediaTek MT7681 WiFi module used on many smart devices.
Based on Forescout’s data, IoT devices had the highest prevalence (46%) of Amnesia:33 bugs, followed by OT devices (BAS and ICS) at 19%. IT devices were the least affected at 16%.
Four open-source TCP/IP stacks affected by Amnesia:33 bugs
Unlike previous vulnerabilities such as Ripple20 and Urgent/11, Amnesia:33 vulnerability primarily affects DNS, TCP, and IPv4/IPv6 stacks. They also exist in the ICMP, LLMNR, and mDNS stacks. However, like Ripple20, the bugs originate from Out-of-Bounds Read, followed by an Integer Overflow fault.
The vulnerabilities exist in four open-source libraries namely, uIP, FNET, picoTCP, and Nut/Net. uIP had the largest number of vulnerabilities (13), followed by picoTCP (10). FNET and Nut/Net had five (5) vulnerabilities each.
Researchers at Forescout applied automated fuzzing based on libFuzzer’s white-box code instrumentation, manual analysis using Joern code querying engine, and manual code review. They found that lwIP, uC/TCP-IP, and CycloneTCP stacks did not contain any vulnerabilities found in the previously mentioned open-source libraries.
They also found that the three open-source libraries had “consistent bounds checking” and did not depend on shotgun parsing, a method consistent with the vulnerable open-source libraries.
However, they warned that the libraries could still contain undetected vulnerabilities.
Risks posed by Amnesia:33 vulnerabilities
The risks posed by the vulnerable open-source libraries depend on the role played by the affected smart devices.
For example, networking devices such as routers pose higher risks because they are accessible from the Internet and act as gateways to local networks.
Contrarily, others such as industrial controllers require an initial compromise of the internal network before the attackers could exploit them, thus posing reduced risks.
Device vendors frequently use these open-source TCP/IP libraries to support networking communications between smart devices and the Internet.
Consequently, the open-source libraries play a critical role in the firmware networking stack and could, thus, be exploited to execute various forms of cyberattacks such as:
- Remote code execution (RCE), allowing remote attackers to take control of a target device.
- Denial of service (DoS) attacks to interrupt computer systems and shut down business operations.
- Information leak, where unauthorized criminals could access sensitive information by hijacking smart devices.
- DNS cache poisoning where the attackers point the victim’s servers to rouge destinations.
The researchers noted that while discovering and patching Amnesia:33 vulnerabilities were easy tasks, some smart devices may not support over-the-air software updates.
To prevent attackers from exploiting such vulnerabilities, device manufacturers must integrate the updates into their products’ firmware.
However, some connected devices do not support firmware updates and would, therefore, remain vulnerable for their entire shelf life. Thus, vendors must invent countermeasures to prevent the exploitation of such devices by attackers.
The worst scenario was when vendors were unaware that their products used the vulnerable open-source libraries for the lack of the software bill of materials.
Boris Cipot, Senior Security Engineer at Synopsys Software Integrity Group, is skeptical about the possibility of patching vulnerable consumer devices.
“One thing that IoT users need to be aware of is that many of the devices on the market and used in their homes will or have already passed the maintenance guarantee period offered by the manufacturer,” Cipot says. “In other words, the difficulty is in ensuring that devices are patched, particularly for any low cost/high volume product. This same concern also applies to license conflict issues that may surface in the software.”
He notes that the only solution to address such issues is by addressing them before releasing the products into the market. Otherwise, users and organizations “will have to proactively adopt preventative measures themselves.”
According to Cipot, such measures include “treating devices as untrustworthy, monitoring their behavior, creating subnets in which they work and abiding by the principle of least privilege.”
Jonathan Knudsen, Senior Security Strategist at Synopsys Software Integrity Group, says that most vendors prioritize release while ignoring support.
“For many IoT devices, getting a functioning product to market quickly takes precedence over, which means manufacturers might not have an automatic mechanism for updates, or indeed, might not even be devoting resources to maintaining released products.”
“After you release a product, you need to respond if new weaknesses are discovered in software components that you already used. In an ideal scenario, devices would be able to update themselves with a newer version of the component that does not have the same weaknesses,” Knudsen concludes.
