A Look Back at the Top 12 IoT Exploits of 2021 (Part 1)

From Log4j to Trend Micro Home Security, here are the most important vulnerabilities we saw last year

With 2021 wrapped up, we’re taking a look back at a year that saw a 50% rise in IoT attacks in just six months. Our prediction for 2022: more of the same – and companies getting competitive about their proactive approaches to product security.

The past year’s top 12 vulnerabilities encompass everything from software supply chain issues to configuration flaws to hard-coded passwords and crypto keys. Let’s take a look at the most impactful vulnerabilities – and the ones that tell us the most about what the future holds for IoT security.

The Big One: The Apache Log4j Vulnerability 

According to the Cybersecurity and Infrastructure Security Agency (CISA), Apache’s affected software library “is very broadly used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information.”

The critical remote code execution (RCE) vulnerability, dubbed Log4Shell, affects versions 2.0 to 2.14.1 and, if exploited, would allow an unauthenticated user to control the connected system for anything from data theft to cryptomining.

According to CISA, hundreds of millions of devices are likely to be affected by Log4Shell and the agency’s director, Jen Easterly, told industry leaders the vulnerability, “is one of the most serious I’ve seen in my entire career, if not the most serious.”

Large companies like Cisco and VMware released patches for their affected products. Not addressing the vulnerability could have some dire consequences, as researchers have tied the vulnerability to two botnets.

For manufacturers that use third-party packages, it’s hard to know what’s in them unless you have a tool like the Finite State platform that can find those vulnerabilities in real-time without tedious and extensive manual testing. 

Finite State Tip: 

1. Upgrade all known instances of Log4j immediately to 2.15.0. (Don’t know which of your products contains Log4j? Talk with us; we can help.)
2. Instances that cannot be immediately upgraded should be mitigated immediately by one of the following 
3. Set the global environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true
4. Remove the JndiLookup class in versions older than 2.10.0

Hard-Coded Keys: Philips Device Vulnerabilities 

Philips had a rough month of November. Early in the month it disclosed a vulnerability in its TASY Electronic Medical Record (EMR) HTML5 system, where “a successful SQL injection attack can result in confidential patient data being exposed or extracted from the TASY database.” A few days later it found three vulnerabilities in its MRI software solutions.

The worst came later in the month, when its IoT medical device interface products and platform showed vulnerabilities, according to the company’s disclosures. The Cybersecurity & Infrastructure Security Agency (CISA) also released advisories. 

Vulnerabilities in Philips' Patient Information Center iX (PIC iX) and Efficia CM Series devices and the company's IntelliBridge EC40 and EC80 systems allow access to patient data and the ability to launch denial of service attacks if exploited. Philips released a remediation for improper input validation in PIC iX C.03.06 in the third quarter of 2021. It plans to remediate the use of a hard-coded cryptographic key and insecure cryptographic algorithm vulnerabilities by the end of 2022. 

Hard-coded passwords are notoriously easy to hack, so that vulnerability is particularly worrisome in a medical device that handles patient information. With the rise of IoT attacks within healthcare, medical facilities need to consider something that was never part of the equation before: their own attack surface.

Finite State tip: 

1. With 33 CWEs mapped to the Injection category, always be sure to validate all inputs. In 2021 alone there have been over 500 CVEs mapped to this category. Even if you know the code path isn’t reachable in any way from a user today, you more than likely won’t be alerted or perhaps even on the same project in a year or two when a new developer inadvertently opens up a new code path while implementing a new feature. 
   
   
2. Above any technology or recurring task suggestion, identify one person in your organization whose primary responsibility is securing the products you make. Without someone identified, the simple, no brainer tasks like validating products don’t have backdoors welcoming attackers fall between the cracks. “Yeah, yeah of course someone checks for back doors in our products.” 
   
   
3. If you happen to be running any of the affected Philips devices, be sure to follow CISA’s guidance from their ICS-CERT advisory as soon as possible:
   
   Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
   Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
   When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as its connected devices.
   
   

• Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
• Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
• When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as its connected devices.

Hotel Room Hacks: Vulnerabilities in Smart Rooms

The stakes are a bit lower on this one, although in the wrong hands these vulnerabilities could have been more disruptive. This story came out of one of the Black Hat sessions where Kya Supa, a security consultant at LEXFO, told everyone about the time he hacked his capsule hotel. Show of hands: Who has ever wanted to teach a noisy neighbor a lesson? Supa used the iPod touch given at check-in, meant to control his room, to start messing with the noisy neighbor that wouldn’t pipe down.

In a presentation deck, Supa outlined exactly how he did it. He used six vulnerabilities and exploited them to take advantage of controls in other capsules. Via the iPod touch, guests could control the light, change the position of the adjustable bed, and control the ventilation fan. Supa’s goal was to make his noisy neighbor, Bob, believe in ghosts for at least one night. 

According to Supa, the hotel was thankful to be made aware of the vulnerabilities it had created by making these capsules “smart” with iPod touch controls and made the necessary adjustments to fix those issues. 

Supa’s story is amusing—well, maybe not to Bob—but also serves as a cautionary tale about how IoT devices can easily be weaponized. Manufacturers are creating new IoT and connected devices and embedded systems faster than security measures that protect these devices. At Finite State, we have the solution to keep your company safe because not all hackers are as kind as Kya Supa.

Finite State tip: 

1. Where to start? This seems like it goes without saying, but processing commands received over the network without any authentication is just plain bad. Don’t do this. Ever. In fact, audit all inputs and code paths interacting with network calls to make sure proper authentication is in place. And for the embedded developers out there, don’t forget to check each of your board support packages (BSP) too. As you’ll find throughout this series, the SDKs supplied by chip vendors or suppliers are commonly becoming the weakest link in software supply chains. If you’re including their binaries in your firmware, you are accepting the risk of any vulnerabilities within them. Don’t let your security news feed be the first you hear about these kind of zero-day vulnerabilities and scan those binaries yourself with some form of *AST solution.
   
   
2. This example tells it all, and we should make it a point to learn from it. Far too often we rationalize not addressing lower severity vulnerabilities. Whether concluding the vulnerable condition is not reachable or justifying based on the assumption it would never be exploitable because an attacker would first have to have access to another part of the system that they normally wouldn’t. Let this example remind us all that attackers are just as crafty as we are and usually find a way when they’ve identified a target system to attack or fundamental to the overall attack.

Security System Slip-Up: Trend Micro Home Security Vulnerability

In May, we learned that Trend Micro's Home Network Security Station had bugs that left the device vulnerable. Ironically, the product that gets plugged into home routers is meant to prevent internet-connected devices from being hacked. 

Researchers at Cisco Talos found three vulnerabilities in the device, two of which are elevations of privilege. The third is a hard-coded password vulnerability that exists in the SFTP Log Collection Server function. If exploited, attackers could carry out denial of service (DoS) attacks, escalate privileges, and execute code. Trend Micro remediated the issue through an update.

While the researchers didn’t observe any exploits in the wild, it’s still unnerving for consumers that were hoping to protect their devices to find a vulnerability in the security system. This is one of the reasons we at Finite State are in full support of requiring manufacturers to create a Software Bill of Materials (SBOM). This is the best way to know what is in a connected device before it is deployed.

Finite State tip:

1. Always check your input destination variable sizes before attempting to write data. Buffer overflows can easily be avoided with little extra effort.
2. Hard-coded passwords come in all shapes and sizes. Don’t let supporting service accounts be the foothold a bad actor uses to get just enough access to discover their next move in an attack.

Unprotected Information: Zoll Defibrillator Software Vulnerabilities

An advisory from the Cybersecurity and Infrastructure Agency (CISA) found in June that defibrillator management software by Zoll was littered with vulnerabilities. According to the advisory, “Successful exploitation of these vulnerabilities could allow remote code execution, allow an attacker to gain access to credentials, or impact confidentiality, integrity, and availability of the application.”

The actual defibrillators weren’t at risk of being compromised, but the software had six vulnerabilities that put data in the crosshairs for attackers. One of the vulnerabilities showed that credentials were stored in plaintext, allowing attackers to gain access to sensitive information. The highest scoring vulnerability was a CVSS v3 base score of 9.9 for the bug in the web application that allows virtually any user to upload a malicious file.

As healthcare organizations make a digital transformation, they have more to consider than just ease of use or cost. According to a report by Medigate and CrowdStrike, 82% of surveyed healthcare organizations reported at least one form of IoT cyberattack since May 2020. Attack surface and exposure to critical systems are now part of the calculation as healthcare systems modernize their tools.

Finite State tip: 

1. Always assume your code will at some point be able to access cyber-physical systems. While it may seem low risk to ship with one or two vulnerabilities because they will get fixed in a release soon to follow or they affect a walled off part of the application, attackers always find a way to take that one inch and turn it into a mile’s worth of leverage for their next move.

Stack Attack: Nucleus TCP/IP Stack Vulnerabilities

Analysis from Forescout Research Labs informed a report called NUCLEUS:13, which identifies a baker’s dozen vulnerabilities within the Nucleus TCP/IP stack, which is a real-time operating system used in systems for aerospace, industrial, and medical applications. 

Risks range from enabling remote code execution, denial of service (DoS), and information leaks. The highest scoring vulnerabilities in the bunch were improper null terminations in which the FTP server does not properly validate the length of the “MKD/XMKD, PWD/XPWD, and USER” commands, leading to stack-based buffer overflows. According to a CISA advisory, “This may result in denial-of-service conditions and remote code execution.”

Siemens, which owns Nucleus, acknowledged the vulnerabilities, has already fixed the majority of them through software updates, and recommends countermeasures for products where updates are not available. Researchers “found close to 5,500 devices from 16 vendors in place at 127 customers. Thirteen of these customers had more than 100 vulnerable devices, with healthcare being the most impacted sector.”

Finite State tip: 

1. While we usually have trusted partners, vendors, and suppliers we rely on to deliver our products, always operate on a zero-trust policy and scan all 3rd party binaries for vulnerabilities. The extra due diligence may not only save the day but potentially the lives of many.