From Log4j to Trend Micro Home Security, here are the most important vulnerabilities we saw last year
We’re back with a second round of IoT vulnerabilities and exploits from 2021.
Product manufacturers often discover that the most critical vulnerabilities impacting their systems were created by third-party vendors and complex hardware and software supply chains. Many of the vulnerabilities we’ll be talking about today cut across a wide swath of industries and products precisely because they come from third-party components.
Audio Processor Problems: MediaTek Vulnerabilities
Tawianese microchip company MediaTek, the global leader since the third quarter of 2020, posted a security bulletin in October that confirmed multiple vulnerabilities in a disclosure by Check Point Research.
The researcher reverse engineered the Android API that connects with MediaTek’s audio digital signal processing (DSP) and the firmware that runs on the audio DSP to show how an unprivileged Android application could abuse the AudioManager API and conduct an eavesdropping campaign.
In order for the vulnerabilities to be exploited, users would have had to download a malicious app to carry out the attack. Check Point disclosed the vulnerabilities to MediaTek before publishing its findings, so the issue was remediated before 37% of all smartphones and IoT devices in the world could be attacked.
When device manufacturers use microchips from third parties, they often don’t know what’s inside and plug them into their products without knowing the effect it has on their product’s security. By enlisting the help of Finite State, you can gain visibility into those black boxes that are important components of your products.
Finite State tip: System on Chip (SoC) manufacturers almost always provide libraries, making it easy for developers to interface with their hardware in the form of an SDK or a board support package (BSP). More often than not, those packages make it into the end product … and so do all of the security flaws in that code. Because these are usually proprietary software packages, they often slip under the radar–evading detection from security tools and the programs companies build around them.
Protect against supply chain vulnerabilities by examining your BSPs, using some form of binary analysis. Using traditional SAST solutions based on source code simply cannot analyze compiled binaries. If you’re only analyzing your code pre-compile time, you should look to add in binary analysis to uncover vulnerabilities introduced by the compiler or somewhere downstream in the CI/CD pipeline.
Ripple Effect: Ripple20 Vulnerabilities
There’s a growing range of uses for IoT devices, from consumer gadgets to utility controls to healthcare devices, but the software that connects these products to the internet is typically quite common. When Israeli security firm JSOF disclosed 19 vulnerabilities in software from Treck, the supposed ramifications spawned the nickname “Ripple20.” (The number signified the year of the findings, 2020, not the amount of vulnerabilities.)
According to JSOF’s disclosure, “Affected vendors range from one-person boutique shops to Fortune 500 multinational corporations, including HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors suspected of being of vulnerable in medical, transportation, industrial control, enterprise, energy (oil/gas), telecom, retail and commerce, and other industries.”
The disclosure made jaws drop because of its sheer magnitude and, considering the Treck TCP/IP stack was first released in the late 1990s, how vulnerable so many devices had been for so long.
What Finite State found in our attempts to verify the effects of these vulnerabilities is that the effects and impacts initially reported by JSOF are greatly exaggerated. Check out our whitepaper for a breakdown of our results, methods, and to understand why these discrepancies matter and how they affect your organization and your network.
Finite State tip: It’s far too common for TCP/IP stacks like these to be statically compiled into another software or firmware package. Most SCA solutions based their detection on file hashes, which will certainly miss software statically compiled in another package. Furthermore, most SCA solutions only work on mainstream server and workstation CPU architectures. Many device manufacturers we talk to come to us because their current solution doesn’t cover the specialized processors and/or microcontrollers used in their embedded devices.
Before completing impact assessments for vulnerabilities like Ripple20, be sure you’re working with a solution that can detect statically compiled software across all CPU architectures and instruction sets in your portfolio. Without this, you will have an incomplete impact assessment that leads to leaving valued customers vulnerable.
SDKs in Security Cameras: ThroughTek Vulnerability
ThroughTek’s point-to-point (P2P) software development kit (SDK) had a vulnerability allowing encryption to be compromised. Nozomi Networks research disclosed it to the company. ThroughTek’s software is reportedly in millions of connected devices throughout the supply chain, including many consumer-grade security cameras.
The vulnerability was so grave that the Cybersecurity and Infrastructure Security Agency (CISA) also issued an advisory, in which it stated “The affected ThroughTek P2P products do not sufficiently protect data transferred between the local device and ThroughTek servers. This can allow an attacker to access sensitive information, such as camera feeds.” CISA said the vulnerability was exploitable remotely with a low attack complexity and scored the vuln 9.1 out of 10.
In a statement, ThroughTek directed customers to “follow the instructions below to avoid any potential problems,” but also acknowledged there were SDK versions with a “nossl” tag, which meant it wasn’t encrypted to begin with.
Device manufacturers often count on firmware developers for security, but cases like this show why those developers can’t be trusted. The spotlight is especially bright when the products are consumer video cameras. That kind of potential privacy breach is enough to make any end user think twice about bringing that product into their home.
But device manufacturers don’t have to be left in the dark. Finite State’s advanced binary analysis enhances automated zero-day vulnerability detection to eliminate blind spots in developer libraries.
Finite State tip: Illuminate and remove hidden vulnerabilities in your supply chain by analyzing software coming from all sources: open source, third-party proprietary, and (of course) first-party code written in house. To make it easier on your team, find a tool that can analyze all three in a single pane of glass.
Stack Attack, Part II: AMNESIA:33 Vulnerabilities
As we saw with Treck, TCP/IP stacks are widely used and often not very secure. Forescout Research Labs published a study called AMNESIA:33, which detailed vulnerabilities in four of the seven open-source TCP/IP stacks it analyzed.
According to the report, “Exploiting these vulnerabilities could allow an attacker to take control of a device, thus using it as an entry point on a network for internet-connected devices, as a pivot point for lateral movement, as a persistence point on the target network or as the final target of an attack.”
The common thread among these vulnerabilities was memory corruption, hence the report’s name, which could lead to denial of service (DoS), information leaks or remote code execution (RCE). The report estimated more than 150 vendors and millions of devices were vulnerable to AMNESIA:33 and CISA issued an advisory “to provide early notice of the reported vulnerabilities and identify baseline mitigations for reducing risks to these and other cybersecurity attacks.”
Many responsible disclosures name the developers that left the door open in their software. Forescout didn’t identify the vendors but highlighted their mistakes, saying the vulnerabilities stemmed from “bad software development practices, such as an absence of basic input validation.”
At this point we may sound like a broken record, but Forescout’s commentary underscores one of our main themes at Finite State: You can’t trust a third-party software developer to prioritize security. Trusting them leaves your own products vulnerable.
Finite State tip: Upgrade your security tool chain. Most SAST technologies date back to the early 2000s and simply were not made for the new connected world. Welcome your team to 2022 with the latest in advanced security technology: binary analysis. Best-of-breed solutions cover the full software stack, starting from the lowest level with machine code delivered in firmware binaries all the way up to the top of the software supply chain.
Dangerous DNS: NAME:WRECK Vulnerabilities
Forescout teamed up with JSOF to create another study in April. This one, titled NAME:WRECK, highlighted issues with Domain Name System (DNS) implementations and identified nine vulnerabilities within four popular TCP/IP stacks that are often used with IoT devices. All of the vulnerabilities allow for either RCE or DoS.
The report cited recent DNS vulnerabilities like DNSpooq as an example of why NAME:WRECK is important, stating, “This kind of research shows that DNS is a complex protocol that tends to yield vulnerable implementations, and these vulnerabilities can often be leveraged by external attackers to take control of millions of devices simultaneously.”
The four stacks that were observed to have vulnerabilities—FreeBSD, IPnet, NetX, and Nucleus NET—are commonly used in healthcare and industrial control systems (ICS) devices, so there is an extra urgency factor to remediation.
When a common vulnerabilities and exposures (CVE) identifier is assigned and manufacturers are trying to figure out if their devices are affected, it doesn’t have to be a month-long wild goose chase that involves all of your product teams manually searching. We have an advanced search function in the Finite State platform that can automate that search within seconds across product families and business units.
Finite State tip: Get ahead of vulnerable third-party software by integrating your CI/CD with a full-stack solution that can help identify zero-days like these before they ship. Integrating early in the development cycle is the key to reducing the time and cost to fix vulnerabilities.
Remote Takeover: Realtek Vulnerabilities
The JFrog security research team unearthed six major vulnerabilities in Realtek’s RTL8195A Wi-Fi module, which is used in embedded devices for industries like agriculture, automotive, energy, gaming, industrial, and security. JFrog found that the device’s WPA2 handshake mechanism had stack overflow and out-of-bounds read vulnerabilities.
Most severe in the group is “a remote stack overflow that allows an attacker in the proximity of an RTL8195 module to completely take over the module, without knowing the Wi-Fi network password (PSK) and regardless of whether the module is acting as a Wi-Fi access point or client.”
Realtek has its own API, “Ameba,” that allows developers to communicate with WiFi, and that’s where it issued its patches, after JFrog’s responsible disclosure. While the company says that any devices created after April 2020 are patched for the vulnerabilities JFrog uncovered, this tale points to the importance of these security researchers and their responsible disclosures.
As the 12 days of exploits have shown, third-party chip manufacturers have a history of not taking security seriously enough. Device manufacturers that implant these chips into their products often don’t know exactly what is inside and how that may make their products unsecure.
A study we recently conducted with the Ponemon Institute shows that nearly 60% of connected device manufacturers say security concerns have cost them sales. Our platform can give manufacturers more visibility into their devices and alleviate that business risk while having a provable security solution to show their customers.
Finite State tip: At the risk of repeating ourselves: please please please analyze the full binaries of the SDKs and BSPs that come from your suppliers. Blindly including them in products is like not wearing a seatbelt: while someone might be able to get away with not wearing one for a while, by the time they realize it would have saved a life, the damage is already done. Don’t let your supply chain be the accident we all wish never happened.
Ready to take the next step toward product security that helps you and your customers sleep better in 2022? Talk to the Finite State team today to discover how scalable, automated product security is now within reach for connected and embedded product manufacturers.
