Your IoT devices are under attack!
If you have IoT devices in your home, the truly frightening thing is that your devices might have already been attacked and compromised. And you might not even know. Why? Because most IoT devices have built-in vulnerabilities (as I’ll explain), and there are LOTS of them connected to the Internet.
How many? More than three years ago, experts predicted that by 2020 there would be over 20 billion IoT devices in use. But according to this (more recent) McAfee study that number is projected to be 25 billion by 2020.
It seems that our predictions of the number of IoT devices are always low, as IoT device adoption is driven by many factors like price and ever-increasing network communication speeds. And according to Nokia, 5G communication is likely to speed IoT device adoption.
Now do I have your attention? Good.
So what kinds of vulnerabilities are we talking about? According to the OWASP IoT project all IoT devices have potential security vulnerabilities like weak passwords and other poor default security settings, lack of encryption when devices communicate over the network, and poor (or non-existent) user-serviceable device management.
Due to these vulnerabilities, many IoT devices are surprisingly easy to attack.
Is it any wonder, then, why IoT devices are such frequent targets of hackers and bot-herders, like the ones who launched Distributed Denial of Service (DDoS) attacks in 2016 against security blogger Brian Krebs and Silex in June of 2019?
If you’re like I was before I really dug into this topic, you have questions:
- What does an IoT device look like under the hood?
- What does an IoT malware attack look like?
- What do you do to protect your IoT devices from attack?
In this article, I’ll answer these questions.
Anatomy of an IoT device
To understand what makes IoT devices vulnerable to attack, it’s worth a detailed look at what’s going on under the hood.
You probably have a good idea of what the term “IoT device” means, but just so we’re on the same page, let me define the term as I’ll use it in this article.
An IoT device is a special-purpose device, that connects wirelessly to a network and transmits and receives data over that wireless connection in order to monitor or control a “thing” (which I’ll call a Thing from now on).
IoT device hardware
At the heart of an IoT device are the key characteristics of the underlying hardware that make IoT devices work:
- Data acquisition and control
- Data processing and storage
Essentially, IoT devices contain sensors, actuators, or both. Sensors acquire data, and actuators control the data or act on the data.
- Sensors monitor Things and provide data about the Thing, whether it be the temperature, light intensity, or battery level. Popular IoT sensor devices include hub devices like Amazon’s Echo Dot, Apple’s HomeKit, and your smartphone.
- Actuators control the Thing through hardware in the device, like the controls in a smart thermostat, the dimmer switch in a smart light bulb, or the gear motors in a robotic vacuum cleaner. The actuators represent the physical interface to the Thing that make it “go,” whether it be to turn on the heat, dim the lights, or send the robotic vacuum cleaner to its charging station. Popular IoT actuator devices include the Ring(TM) Doorbell camera, Smart outlets, and the Nest(TM) thermostat.
All IoT devices have a way to process sensor data, store that data locally (if necessary), and provide the computing power that makes the device operate.
If data from multiple sensors needs to be coordinated, or if data needs to be stored in flash memory (for whatever reason), it is the data processing component of the IoT device that does it.
IoT device firmware
The firmware that runs an IoT device is the onboard software that sits between the hardware and the outside world, and generally falls into one of two categories: embedded firmware or operating system-based (OS-based) firmware.
IoT devices are resource-constrained, so they often use custom-built, embedded firmware, which is another term for the software that runs on the device. In many cases, the only cost-effective solution for device manufacturers is to engage programmers with a deep understanding of the hardware to write embedded software (firmware) to interact with the hardware.
Embedded software engineers have to perform double-duty. In addition to the embedded firmware, they also write the software to interact with the hardware (think: device driver), along with the application software to interface with the device’s user, such as the interface to configure the device, for example.
As IoT devices have grown “smarter” (read: more complex) — more sensors, greater data processing and storage capabilities, and so on — the demand for more complicated software to manage and exploit the new capabilities has also grown.
Just as the first computers evolved from firmware loaded from ROM to run the computer’s basic functions to an operating system like MS-DOS instead, IoT devices are maturing in a similar fashion. An IoT device now probably runs an operating system (OS) that provides an abstraction layer between the hardware and other software that runs on the device.
By providing an abstraction of the underlying hardware from the device’s application software, the IoT operating system enables a familiar division of labor. Embedded software engineers (who understand the hardware) can now spend their time writing device drivers, and application programmers (who do not need to understand the hardware intimately) spend their time writing the software that makes the device “smart”.
A popular OS choice for many device manufacturers is Busybox, a stripped down version of the Unix operating system that contains many of the most common utilities, has a very small footprint, and provides many capabilities of Unix in a single executable.
IoT device wireless communication
IoT devices most often communicate wirelessly, which means they can be anywhere in your home or enterprise. The communication needs of the device change depending on how the device is designed to work.
Some devices are designed to work by making a direct 802.11 Wifi connection to your router. From there, the device can access the internet. A motion-activated security camera is a popular example of this type of device, which uses wifi to send its data to a cloud server, for example, which you can access via an app on your smartphone.
Some devices are meant to work as part of a group of IoT devices. For example, a window open/closed sensor that is connected to a smart home gateway device (sometimes called a hub) uses a wireless protocol like Z-Wave, Zigbee, or any of a half-dozen others so it can report that the window has been opened.
IoT device management
You manage your IoT devices in two main ways: you have to connect the device to the network (a process called provisioning), and once it’s connected, you monitor and control it. I’ll explain these more below.
Provision the device
Many IoT devices (especially small ones like a temperature sensor) do not have built-in user interaction hardware, such as a touch screen, and are called “headless” devices. One way to configure headless devices is to use Wifi Protected Setup (WPS), which requires a WPS-enabled device and a WPS-enabled router. In the simplest scenario, you press the WPS button on your IoT device, then press the WPS button on the router, and the two devices are eventually connected.
Other devices create a Wifi access point you connect to using an app on your smart phone where you to enter your wifi network credentials, which will be used later by the IoT device to connect to your wifi network.
Still other devices, like hubs and gateways, scan and add devices that it detects are in your home or business. You simply configure the gateway so it has internet access, tell it to sniff out other devices, and follow the device-specific instructions to put the devices in pairing mode so that they can connect to the gateway.
Monitor and control the device
Once your device is connected to the network, you can monitor and control it. One way to control it is through a smartphone, either connected to the gateway directly (inside your home, for example) or through an interface to a cloud service.
Some devices like CCTV security cameras connect directly to the internet and have dedicated IP addresses. You access these devices directly over the internet, bypassing the need for the device to connect to a hub or gateway.
Many IoT devices are installed in homes and businesses, but are exposed directly to the internet by modifying your firewall to enable port-forwarding. This allows the device to be conveniently accessed from anywhere on the internet to monitor and control it.
IoT device security
Lastly, there’s security. That’s right. Last. Unfortunately, that’s the single biggest problem with IoT devices: security is most often last. It’s an afterthought.
I get it. It’s difficult to create a reliable, resource-constrained device that can connect to a wireless network, use very little power, and is most importantly (to the consumer) inexpensive. Because there is so much to do to just produce a working device, is it any wonder security is the last thing to be considered in the development lifecycle?
It’s worth noting that lots of manufacturers do take security very seriously, but their devices tend to be pricey. That’s the tradeoff.
So, now we have all these cheap, er, I mean inexpensive or cost-effective, devices on the network with very little security. This, my friends, is an IoT malware attack waiting to happen.
Anatomy of IoT malware attacks
So we hear about “IoT malware” a lot, but what does that mean, really? Let me break it down, starting with the attacker.
Who are these people? The short (and unsatisfying or even terrifying) answer is: nobody knows for sure.
According to Schneier, the attacks are designed to test the defenses of the target by employing multiple attack vectors, causing the target of the attack to put up all of its defenses in the process. Schneier says such carefully executed attacks are characteristic of state actors (government body). Now, that’s a scary thought, and hopefully Schneier is overreacting a little.
At any rate, it’s not crystal clear who the attackers are, but one thing is clear: they’re clever, resourceful hackers. Do not underestimate them.
The attack vector
For any type of attack (malware or otherwise), the attacker needs to hit an attack surface, which is defined as the sum total of all of the device’s vulnerabilities. When the attacker identifies and becomes familiar with the attack surface, they create an attack vector, the path the attacker uses to discover and exploit vulnerable IoT devices on your network, and cause the device do something other than what it was intended to do. Common attack vectors include: a link in an email (“click here if you want to get rich quick”), downloaded software (“your Flash player is out of date”), or even hovering your mouse over an infected ad can give a would-be attacker a way in.
Once the attacker has exploited an attack vector, they identify and attack your IoT devices using a number of known vulnerabilities. Let’s look at some common IoT device vulnerabilities exploited by attack vectors.
Aside from security’s low priority in the device development lifecycle, manufacturers want their devices to be easy to setup and use, well-aware that many IoT device end-users are not often technically savvy. In order to make the device easy to setup and use, the manufacturer usually provides some simple way to login to the device, like a single userid/password combination.
This simplicity creates three problems:
- After the device is set up, the vast majority of users then go about their merry way and leave the device’s login credentials unchanged from the default
- Often the same userid/password is the same for all the same devices (and printed in the user manual, or on the side of the packaging), allowing attackers to simply add the default userid/password to a list of known exploits for that particular device.
- Manufacturers use easy userid/password combinations (for example, admin/admin, user/user, and so forth), or make up new, equally simple ones, which then quickly join the ranks of known vectors.
Lack of encryption
Because security is unfortunately often an afterthought in the IoT device development lifecycle, security features like encryption are often overlooked or not even considered. The industry is requesting embedded cryptography, such as cryptographic co-processors that can handle encryption and authentication in IoT devices. Suppose you are designing and building an IoT apps. Securing your data over the network (a la data encryption techniques) must be part of your design.
Unfortunately, many IoT devices do not support encryption, which means you need to really do your homework when investigating the devices you intend to use as part of your overall solution to make sure they provide encryption.
Some IoT device manufacturers put “hidden” access mechanisms in their devices called backdoors. Ostensibly, this makes the devices easier for them to support. But in reality, it might as well open the front door for hackers. While most users don’t have the technical know-how to crack a backdoor, for a hacker, it’s child’s play.
No worries though, once a backdoor becomes known, the manufacturer apologizes profusely and immediately releases a firmware update closing the backdoor. Right? You would think so. Unfortunately, there are numerous stories like this one, where a manufacturer has a known backdoor in their device, but rather than remove the backdoor, the manufacturer just made it more difficult to access (or so they think).
In most cases, the backdoor is either a userid/password or an open port on the device (that you can’t close). To call these “backdoors” is a mistake. To a hacker, these are wide-open front doors. Plain and simple.
Anytime a device is exposed to the internet — meaning that it will accept incoming traffic — it will come under attack. I guarantee it.
Consider this example from my work. In the past I have leases a number of virtual servers for running websites, and leave port 22 open so I can SSH into them. With just default firewall rules, these hosts are under constant attack. As in hundreds of login attempts per hour! Of course, I run
iptables to set rules on every server I manage to block IP addresses of failed logins for long enough to weaken scripted attacks. So now I see “only” 5-10 failed logins from around the globe per hour.
My point is this: expose anything to the internet, and it will be attacked. And, unlike a hardened server where you can control the firewall and how the host is accessed, most IoT devices have little or no security and are particularly susceptible to attack.
But wait, there’s more
As you can see, IoT devices are rife with vulnerabilities. Weak passwords, coupled with direct device exposure and backdoors, make IoT devices easy pickings for even the least sophisticated hackers (sometimes called “script kiddies”).
Think only state actors and the most sophisticated hackers have the skill to hack your IoT devices? Think again.
The Open Web Application Security Project (OWASP) has a sub-project called the IoT Attack Surface Area Project, where they have a list of potential vulnerabilities in the IoT attack surface.
You’ve seen how an attacker gets into the IoT device, so now let’s talk about the attack itself.
To set the stage, the point of an IoT device attack is to take over the device and bend it to the hacker’s will. So the attack comes in two phases: the scan and takeover phase and the attack launch phase. Both phases are normally executed by a Command and Control (CNC) program.
Scan and takeover
The CNC program scans IP addresses on the internet looking for hosts with open ports, and if it finds one, it attempts to log in using a set of known default userid/password combinations (for example, admin/admin, root/admin, user/user, and so forth).
If the login succeeds, a script runs that reports the device’s IP address, along with the login credentials to use. The CNC program then pushes the malware to the device that it needs to run the attack. The device is now pwned, and awaits further instructions from CNC to begin the attack.
The attack scanning program continues this process, taking over as many new devices as it can. Each device that has been taken over is referred to as a bot.
Nobody knows for sure how much time passes from the moment an IoT device becomes a bot until the time it is used in an attack. It could be hours, days, weeks, or months before a bot is called to action. Until that time, since the infected device appears to function normally, the device’s owner is almost certainly unaware of what is going on.
A single IoT device is not typically very powerful, and so a single bot is not much of a threat. But create a horde of bots networked together to achieve a common purpose, and, look out! This type of botnet attack is made up of hundreds, thousands, and even hundreds of thousands of bots, all under the control of the hacker. Scary.
The attacker typically uses their botnet army for one of two purposes: DoS attacks or spam bots.
- A Denial of Service (DoS) attack is designed to cripple a target host by sending it so much HTTP (and other) traffic it cannot handle the volume. Eventually the targeted host fails to respond, effectively taking down the host. Rather than originating from a single powerful computer (or cluster of computers), a Distributed Denial of Service (DDoS) attack originates from many host computers (thousands or hundreds of thousands). In the case of an IoT botnet attack, the host computers are the legion of IoT devices. The target doesn’t stand a chance.
- Spam bots are fueling the spam industry. There is big money in the spam industry. System administrators spend vast amounts of time and energy to blocklist known spam relays, hoping that just a fraction of a spammer’s emails make it to your inbox. But what if the spam could appear to have been sent from a non-blocklisted IP address? An IoT device running on grandma’s network through grandma’s router? Perfect! It’s not likely that grandma’s IP address will pop up on a blocklist. Besides, if grandma’s smart TV is just one of a hundred thousand bots sending spam, imagine the administrative nightmare trying to figure out which of all those IP addresses to blocklist!
- Brickers are destructive malware, bent on rendering the IoT device unusable (that is, “bricking it”). The Silex malware specifically targets IoT devices by exploiting notoriously weak default credentials, deleting the device’s system software, then rebooting the device, which will not be able to successfully reboot. Like its cousin Brickerbot, Silex appears to be purely destructive, with no apparent agenda or profit motive, unlike ransomware viruses like the Wanna Cry worm.
- Cryptomining bots are a type of botnet where the infected IoT devices are used to mine cryptocurrency like Monero. Such malware makes up about half of the most active malware around, including the half of this December 2018 list from Checkpoint. Once the malware is on your IoT device (cryptomining occurs most often on smart phones, but theoretically can exploit any device with sufficient computing power) it sits in the background mining cryptocurrency around the clock. These little daemons are nasty.
Once an attacker has a botnet army at their disposal, they have a sea of small devices they can use to create a terrifying flood of internet traffic, spam the world, or sit quietly in the background and mine cryptocurrency.
Recent examples of IoT malware
Here are some recent IoT malware exploits that you may have heard of.
This malware specifically attacks Android devices and makes its way onto the device via a bogus voice mail app. This McAfee report describes how unsuspecting victims are sent an SMS message telling them they have voice mails, along with a link to install the TimpDoor app’s APK file (Android’s app distribution format). APKs are normally (and should only be) installed from Google’s PlayStore, so the victim is given detailed instructions for installing applications from “unknown sources” (a red flag, right?).
Once the voice mail app is installed, it turns the mobile device into a proxy server for encrypted traffic, the goal being to invade private corporate and home networks to which the device’s owner has access.
However, according to McAfee, TimpDoor can also be used to send spam – including phishing emails – and even participate in a bot army of infected devices to launch a distributed denial-of-service (DDoS) attack, similar to Mirai (see below).
This type of malware was developed by IBM Research as a proof-of-concept, and presented at Blackhat USA’s August 2019 conference to demonstrate the type of malware that is possible through the use of AI.
Like a trojan, the malware hides inside of other, legitimate-looking software while waiting to launch its attack. In the case of the IBM Research prototype, the malware was wrapped inside of a video conferencing application. The similarities to the classic Trojan end here.
The DeepLocker prototype used a Deep Neural Network (DNN) to target the attack at a specific individual, for example, using facial recognition (a forte of DNNs) to launch the attack only on that individual. All other infected devices would simply go on about their day, their users blissfully unaware of the dangerous malware they carry.
Scary, that’s true, but a better understanding the types of malware that are possible using sophisticated AI allows security researchers to get ahead of this new type of malware before it becomes a security nightmare.
Email is the lifeblood of spammers, whose real goal is to drive traffic to their customers’ websites through emails with catchy subjects, lewd content, and so forth (known as click bait. The tactics employed to bait you into clicking on a link vary (“Lose 100 pounds overnight! CLICK HERE NOW!” or “Get a free iPhone. CLICK HERE NOW!”).
The entire strategy hinges on their email arriving in your inbox. The main problem spammers have is sending their emails so they won’t be caught in spam filters, many of which use “blocklists” of Simple Mail Transport Protocol (SMTP) server IP addresses known to be used by spammers (like open relays).
However, if a spammer could use a legitimate-looking proxy to their SMTP server — such as a SOCKS proxy, for example — whose IP address isn’t blocklisted (remember grandma’s smart TV?), their spam emails have a greater chance of finding their target (but you’re still not getting a free iPhone, sorry).
The Linux.ProxyM virus is such a secondary payload Trojan, which goes to work once the initial Trojan has infected your computer. How? Something like this: you’re baited into clicking on that “get your free iPhone now!” link, and you agree to install the “Simple free iPhone plugin” (the initial Trojan), which infects your computer. At that point a script goes to work, which scans for vulnerable IoT devices. If it finds one, it uses the now familiar weak credential exploit to gain access.
Once the malware has access to the device, the device is infected with the secondary payload containing the actual malware that drives the attack. This malware connects to a CNC server that provides a list of email addresses, and an SMTP server. At that point, now acting as a SOCKS proxy, your device sends spam emails at the behest of the CNC server. Unless you’re in the habit of monitoring and analyzing the traffic on your home network, for example, you have no idea this is going on.
Classic IoT Malware attacks
Ah, the classics. Oldies but goodies. This section contains attacks that aren’t really recent, but revolutionized in some major way the way we think about IoT Malware attacks (and how seriously we should take them). Today’s newest malware threats stand on the shoulders of these evil giants.
This is a Busybox attack. It works by scanning the internet for hosts with an open port 23 (telnet), and using a weak password vector to gain access to devices that are running Busybox. Once inside, the malware is installed and contacts the CNC server where it awaits further instructions. When attacking, the Mirai CNC server instructs all the bots under its command to launch a flood of various kinds of traffic, overwhelming the target host.
Mirai is possibly the most well-known attack, and (as it turns out) mostly used infected CCTV camera devices to carry it out. Several things make Mirai different:
- Mirai contains a “do not mess with” list of servers that include General Electric, Hewlett Packard, and the US Department of Defense.
- The author of Mirai, known only as “Anna-senpai” on Hack Forums released the source code on September 30, 2016.
Mirai hit in several major waves. The first attack was on security blogger Brian Kreb’s site on September 20, 2016. Another attack occurred on October 21, 2016 against US DNS provider Dyn that disrupted the popular streaming service Netflix, along with Twitter, Airbnb, and others.
Security researcher Robert Graham of Errata Security blog presented an analysis of the attack at the 2016 RSA Security Conference in San Francisco, CA, USA.
The authors of the Mirai attack – Paras Jha, Josiah White, and Dalton Norman – have since been caught and pled guilty to leasing out their botnet army to cybercriminals. The authors managed to avoid jail time for their part in Mirai (although Jha has since been sentenced to 6 months in jail and over 8 million USD in fines for a separate attack on Rutgers University).
Security firm Radware first warned about a potential attack they dubbed “Brickerbot”) on April 4, 2017. Another Busybox-based attack, this malware bricks the device (makes it unusable), hence the name.
In this type of attack, known as a Permanent Denial of Service (PDoS) attack, Brickerbot does this through a series of Busybox commands that wipe everything from the device’s internal storage through the Unix
rm command, along with commands that reconfigure the kernel, and finally reboot the (now useless) device.
Later in April a “gray-hat” hacker whose Hack Forums userid is “Janit0r” claimed to be the malware’s author, saying in a HackForums post that the virus was targeted at “careless manufacturers” of devices that are so easily hacked. You can read more about it here.
How to protect your IoT devices
So, how do you protect your IoT devices from being infected? You don’t allow them to become infected to begin with. I know, really helpful advice.
If you already have devices deployed, I have good news and bad news. The bad news is that if your devices are directly exposed to the internet (as I described earlier), they have at best been probed, and at worst, have been turned into bots.
The good news is that most IoT malware resides in memory, so as long as the device is powered on, the malware is alive. Reboot the device and the malware is gone.
All kidding aside, it’s still best to prevent your devices from becoming infected to begin with. Here are a few tips, courtesy of Captain Obvious.
Always change default passwords
When you provision a new device, always change the default password. This seems so simple, yet in the hustle and bustle of setting up a new device so you can play around with it — er, I mean, put it to useful work — it’s easy to skip this vital step. Don’t skip this step!
Go into the management interface and change the password. And, if there is not a way to do this, and you plan to expose the device to the internet, send the device back. You can be optimistic, of course, and hope the device doesn’t get turned into a bot, but malware writers love optimists.
Remove devices with telnet backdoors
Vendors may think themselves clever by putting these backdoors in, but they’re not. It may make support easier for the manufacturer, but at what cost to you?
A device with an open telnet backdoor should be removed from the network, but how do you know? There are IoT device scanners like this one from BullGuard, which scan an IoT search engine called Shodan to reveal if your devices are vulnerable based on the IP address of the computer where you originate the scan. Please note: as a rule of thumb, only scan IP addresses that are yours or that you have the owner’s permission to scan!
Here is a scan I ran from my computer.
Figure 2. BullGuard scan of my raw public IP address
If the scan looks like this, you may have a problem:
Figure 3. BullGuard scan showing potential issues
Never expose a device directly to the internet
When you are faced with the question of whether or not to expose a device to the internet by opening up your firewall, the right answer is almost always no.
BullGuard provides a way to do a “deep scan” to check for any open ports on your publicly exposed IP address assigned by your ISP. This allowed me to see if I had any open ports on my router. I was relieved to see that I did not.
Figure 4. BullGuard deep scan of my raw public IP address
Run port scans on all your machines
Okay, so scanners like BullGuard can give you a level of comfort that your IP address is locked down, but if you’re like me, you want to run the tools yourself.
I used the Mac Network Utility to do a scan of one of the virtual hosts I lease to see which ports were open.
Figure 5. Mac Network Utility scan
These results were not really a surprise to me. This virtual server hosts a website, running Apache, with a Tomcat AJP backend, and SSH access for admin purposes.
As malware attacks on IoT devices have proliferated, off-the-shelf products have begun to enter the marketplace to prevent attacks and protect IoT devices. I’m constantly amazed at both the innovative ways new technolgies are exploited, and the market’s inevitable and equally innovative ways to address those exploits.
From consumer products like Bitdefender BOX, which plugs into your home wifi network and acts as a front-line of defense for all of the devices in your home that use your wifi network, to business solutions like Zingbox Guardian, which uses AI machine learning algorithms to help protect thousands of devices on corporate networks simulatneously, the industry is listening and working to address the IoT security issues across the board.
In this article I showed you a detailed look at the anatomy of an IoT device and then the anatomy of an IoT malware attack. If you understand how IoT malware attacks happen, you can be better prepared to secure your IoT solutions right from the start.