Dangerous IoT: How to Find Vulnerable Devices and What Makes Them Hard to Hack

When you read news about newly discovered vulnerabilities or watch talks at hacker conferences, it can seem like everything is connected to the internet and easily hackable. Often, hacking doesn’t require high-level skills or specialized equipment. But is it really that simple? Let’s find out in practice!

Billions of Potential Targets

According to Statista.com, the Internet of Things (IoT) market exceeded $1 billion in 2017. The total number of internet-connected devices is currently estimated at over 23 billion, with projections to reach 30 billion by 2020. After that, IHS Markit forecasts nonlinear growth to 125 billion devices by 2030. This production volume is possible, but the rapid growth is mainly due to cheap “Chinese” devices, where security is often an afterthought.

Many smart home components and even security systems have significant security issues, often affecting entire product lines rather than just a single unreliable vendor. Common problems include:

• Use of hardcoded and hidden service credentials
• Identical or easily predictable keys and PIN codes
• Lack of access control checks when accessing known settings pages (like /settings.asp instead of /index.htm) or direct access to images and video streams from IP cameras (such as /axis-cgi/jpg/image.cgi)
• Improper data handling leading to buffer overflows, allowing arbitrary code execution via malicious TCP packets
• Forcing servers to use outdated protocol versions at the client’s request
• Dozens of other typical mistakes and intentional security trade-offs for easier configuration, including remote setup without proper authorization

How to Search for Vulnerable IoT Devices

Researchers have developed many methods for finding hacker-friendly devices, and the most effective have already been used by botnet creators. In fact, the use of vulnerabilities in botnets is a reliable indicator of how easy it is to exploit them on a large scale.

Some start by analyzing firmware for wild bugs using reverse engineering. Others use manufacturer names (which can be identified by the first three octets of the MAC address) or OS versions (most devices report this in their network responses, including to search engine crawlers). In any case, you need a unique marker to identify vulnerable devices, and ideally, several such markers. Here’s a practical approach:

1. Check vulnerability databases like MITRE or Rapid7 to find vulnerabilities in specific IoT devices. The most exploitable vulnerabilities are:
   • Discovered after the manufacturer stopped supporting the device
   • Recently discovered (no patches yet or most users haven’t updated)
   • Architectural bugs that are hard to fix with software patches, like the Spectre vulnerability
   • Vulnerabilities affecting multiple models or device types (e.g., due to a shared web interface component or protocol flaw)
2. Study the details of the vulnerabilities and affected devices. Look for unique markers and developer mistakes. For example, a vulnerable device’s response might include a specific OS version string, protocol revision, or an open non-standard port.
3. Create advanced search queries for Google and specialized IoT search engines: Shodan, Censys, and ZoomEye. For more on advanced search, see our articles linked above.

   Note: We won’t provide IPs of vulnerable systems or detailed queries to prevent misuse, but the information is easy to find by reading vulnerability descriptions and adding a filter or two.

   Shodan and Censys themselves filter out bad actors by limiting search results and queries for unregistered users. The most interesting results usually appear after the first hundred entries.

   Searches can be automated with scripts like RussianOtter Mult-API Network Scanner or GasMasK. Registration with Shodan and Censys is required.

4. Check the search results and filter them further if needed, often using scripts (e.g., this one by thesubtlety).
5. Choose tools to connect to found IoT devices. Usually, a browser is enough. For cameras and DVRs, you might need an old Java RE version and a specific video codec. Telnet and SSH clients are often needed. Sometimes, you’ll need vendor software, like Cisco Smart Install Client.
6. Decide how far to go: collect statistics or attempt a test connection and try changing settings. The latter is not recommended, as you might hit a honeypot. Law enforcement is also watching, and careless researchers are ideal targets.

Priority Targets

We asked Egor “Xarlan” Litvinov, an information security specialist at GS-Labs, for his opinion on the most frequently targeted IoT devices.

Q: Which IoT devices have the most vulnerable firmware?
A: It depends—do you mean the most bugs, or a single bug with fatal consequences? The OWASP Top 10 IoT Vulnerabilities list is a good reference, even though it’s from 2014. Recent talks, like at PHDays 2018, show it’s still relevant.

Q: Any recent examples?
A: DNS rebinding is a fresh example—an attacker binds a network device to a malicious DNS server, turning it into an entry point into the victim’s infrastructure. For instance, Google Home speakers could be manipulated, Wi-Fi networks scanned, apps launched, and media played. Another recent case: attackers exploiting a critical vulnerability in D-Link routers to add them to the Satori botnet.

Q: Which IoT devices are hacked most often?
A: The most common targets are the most widespread devices. The Mirai botnet, for example, targeted IP cameras and DVRs. There’s also a serious vulnerability in Axis IP cameras that can give attackers full control.

Q: Besides cameras?
A: The Z-Shave attack is worth mentioning. Researchers downgraded the S2 encryption protocol to the vulnerable S0 version (which used a key of sixteen zeros) and exploited bugs to unlock a Yale smart lock. This is a non-trivial attack, though. Generally, devices using standard data transfer protocols—Ethernet, Wi-Fi, Bluetooth—are targeted first. Devices using RF protocols like ZigBee, LoRa, and Z-Wave are less common targets.

Q: Any other criteria for choosing targets?
A: Another factor is the use of similar operating systems. Many embedded devices use lightweight Linux variants, followed by other embedded OSes like FreeRTOS, ChibiOS, embOS, and others. Botnets like Mirai, Satori, and Persirai first attack devices running Linux over Ethernet/Wi-Fi, then move on to less common systems.

Analyzing Recent Vulnerabilities

Let’s look at a real-world IoT hack. The MITRE database lists a set of related vulnerabilities: CVE-2018-11681, CVE-2018-11682, and CVE-2018-11629. These affect dozens of IoT devices using the RadioRA2 or Homeworks QS protocols in Lutron Electronics smart home systems. These devices have port 23 (Telnet) open and hardcoded service accounts for remote support: lutron/integration or nwk/nwk2, depending on device type and protocol revision.

Vulnerable hosts include dimmers, light switches, and HVAC elements. In theory, they could be used as entry points to more critical systems like alarms, electronic locks, gates, and video surveillance. Telnet commands can be sent to control them remotely.

Censys supports geo-filters, and press releases often reveal physical locations of these devices. Lutron devices are installed at Wimbledon Stadium, the Guggenheim Museum, Taipei 101, and even the Kennedy Space Center near Cape Canaveral.

The catch: users can’t disable these service accounts or change their default passwords—they’re hardcoded in the firmware. By default, Telnet allows three login attempts, and you have two valid credential pairs, so it seems like an easy hack.

But in reality, it’s not so simple. Researcher David “SadFud75” Castro shared a Censys query: (metadata.product:Homeworks Processor) AND protocols.raw: "23/telnet". This finds over 2,000 Lutron devices with open port 23 (down from over 7,000 recently). But when you try to log in, most devices reject the credentials. Why?

The key detail: only devices connected via the integration protocol with revisions M to Y are vulnerable—and not all of them. When the vulnerability became public, it couldn’t be patched quickly, but owners were advised to log in with the service accounts and keep the connection open. Support staff did this for most clients. Now, when you try to log in via Telnet, you usually get “login incorrect,” even though the credentials are valid.

Tip: Linux usually has a Telnet client, or you can install it with sudo apt-get install telnet. On Windows, use a portable client like PuTTY.

IoT Mythology

Such omissions are an ethical standard among “white hats.” On one hand, it protects against script kiddies. On the other, demo queries create the illusion of countless vulnerable targets and widespread manufacturer failures. Remember: a Shodan or Censys search gives you a large but raw list of potential targets, each of which must be checked for the actual vulnerability. Many researchers skip this step for the sake of impressive numbers in presentations.

This leads to claims of “hundreds of millions of vulnerable devices” and “thousands of negligent vendors” at DEF CON and Black Hat, which are then picked up by journalists and security vendors. Scaring people and offering a solution at a discount is a classic sales tactic.

The same goes for other vulnerabilities hyped recently. For example, the Z-Shave attack “potentially affects 2,400+ manufacturers and over 100 million IoT devices—from smart bulbs to door locks.” It sounds terrifying, but in reality, nothing like this has happened. Why?

The devil is in the details. To exploit this vulnerability, you need to be physically near the device to intercept its radio signal and force it to switch to the old, insecure protocol. Are you going to fly to San Diego with a Z-Wave sniffer just to turn off someone’s bathroom light? Or risk opening a lock and getting caught?

For most, it’s just not worth it. This is a cautionary tale about the dangers of using third-party components. Silicon Labs doesn’t even consider it a vulnerability, calling it a side effect of backward compatibility.

Disabling Alarms

Due to limited computing resources, IoT devices are extremely vulnerable to DoS attacks. A simple ICMP flood can paralyze them, which is especially dangerous for security systems. For example, the iSmartAlarm Cube has several vulnerabilities (CVE-2017-7728, CVE-2017-7729, CVE-2017-7730) that allow remote disabling with a single command. Here’s how:

$ hping3 --flood -S -p <port> <IP>

Here, --flood sends packets without waiting for a response, -S sets the SYN flag, and -p specifies the port (default is 12345). Once you hit Enter, ICMP packets flood the iSmartAlarm Cube, overwhelming it so it can’t respond to motion sensors. The alarm won’t recover without a reboot and disconnecting from the internet.

Additionally, CVE-2017-7728 allows full remote control due to poor authentication. A ready Python PoC is available here. Plus, CVE-2017-7729 lets you intercept the authorization key over the local network, as it’s sent unencrypted. At the time of writing, iSmartAlarm had not provided comments or patches.

More on Cameras

We’ve already analyzed IP camera vulnerabilities in detail, so here’s a recent example. In April 2018, Locklin Networks audited the firmware of the popular Momentum Axel 720P network camera and found numerous security holes:

• All processes run as root
• Physical UART access gives root console without authentication, allowing you to read the key file at /devinfo/Ozvision/key/<deviceid>.key
• Passwords are stored in /devinfo as unencrypted SQLite, readable with the showKey command
• Logins and password hashes can be read from the console without authentication using cat /etc/passwd
• Firmware can be replaced locally from an SD card without checks
• Remote firmware overwrite is possible via DNS hijacking by editing /etc/resolv.conf and redirecting firmware.momentum-cam.com to a malicious server
• Video is available on the local network via RTSP on port 554, no authentication required (rtsp://<camera_ip>:554), viewable in VLC Media Player
• Hardcoded service accounts: root/EHLGVG and admin/EHLGVG

Good luck hunting for Axel cameras!

Conclusions

There are indeed many vulnerabilities in IoT devices, but not all are as easy to exploit as the examples above. Some require physical access or being on the same local network. Others become harder to exploit after details are published and before official patches are released.

On the other hand, manufacturers are slow to patch firmware or even acknowledge their mistakes, so easy targets are always available. Compiling an accurate list of them takes much more effort than a quick search on Shodan or Censys. Most search results from Shodan, Censys, and ZoomEye are not easily hackable devices—many network responses just partially match researchers’ queries.

The real scale of potential botnet targets can only be determined after in-depth analysis and direct testing, which is often skipped.