IoT Security: How to Search for Vulnerable Connected Devices

IoT Security: How to Search for Vulnerable Connected Devices

by Dominique René

When you read news about recently discovered vulnerabilities or watch video presentations from conferences like Defcon, you may get the impression that these days everything is connected to the Internet and can be easily hacked. Security media outlets often stress that today IoT hacking does not require either high qualifications or specialized equipment. Let's find out whether this is really true.

Billions of potential targets

According to Statista.com, the market for the Internet of Things in 2017 exceeded one billion dollars. The total number of devices connected to the Internet is currently estimated at more than 26 billion. This number may increase to 75 billion in 2025, and 125 billion devices in 2030.

The current shocking pace of the release of new IoT devices is achieved mainly thanks to the cheap Chinese products. It is sad, but security considerations are rarely taken into account by plenty of current IoT manufacturers.

A significant part of smart home solutions and even security systems have security problems. Moreover, these problems are typical for a whole galaxy of devices, and not just a product lineup of several not the most reliable vendors. We are talking about massive violations of secure development principles:

The use of hardcoded user credentials.
The use of the same or easily predictable keys and PIN codes.
The lack of access control mechanisms for accessing the settings sections (for example, /settings.asp bypassing /index.htm) or accessing images and video streams of IP cameras (/axis-cgi/jpg/image.cgi.)
Incorrect processing of the received data, causing a buffer overflow. As a result, it is possible to execute arbitrary code upon receipt of a malicious TCP packet.
Forced switching to the use of old versions of protocols at the request of the client device (I am an old stupid piece of iron, let’s talk the old and simple way.)
Dozens of other typical errors and intentional security issues left for the sake of the convenience of configuration by non-technical specialists (including easy remote access without proper authorization.)

How black hats and white hats search for vulnerable IoT devices

Researchers offer many tools and ways to search for hacker-friendly IoT devices. The most effective methods have already been tested by botnet creators. In general, the use of certain vulnerabilities by botnets is the most reliable criterion for assessing the level of security of IoT devices and the possibilities of their mass exploitation.

Searching for vulnerabilities, some attackers rely on the firmware (in particular, those errors that were discovered during firmware analysis using reverse engineering methods). Other attackers start looking for vulnerabilities searching for the manufacturer’s name (it can be determined by the first three octets of the MAC address) or the OS version (most devices report it in a network response.)

In any case, for a successful search, some kind of a distinctive feature of a vulnerable device is needed, and it would be nice to find several such features.

Let’s take a look at the standard process of finding vulnerable devices:

First of all, you need a database of vulnerabilities. There are several good sites, for example, Rapid7 or MITRE. These sites help to find vulnerabilities related to certain types of IoT devices.

The most promising in terms of successful exploitation are the following types of vulnerabilities:

Vulnerabilities found after the manufacturer stopped supporting the device and releasing patches.
Recently discovered vulnerabilities that do not have patches yet, or if most users have not had time to install such patches.
Architectural bugs and hardware vulnerabilities that cannot be fully fixed by software patches like Spectre/Meltdown.
Vulnerabilities affecting several models or even types of devices at once, for example, those that have to do with an imperfect component of the web interface or with the communication protocol.

Next, it is necessary to study all the minor technical details associated with selected vulnerabilities as well as the devices affected by them. You need to read all the available documentation in search of unique markers or details of the mistakes made by the manufacturer. It is necessary to determine the features that distinguish the selected devices from the mass of other similar ones. For example, the response from the vulnerable device contains a line with the number of a specific OS version, or maybe a non-standard port is used.
The next step is to prepare advanced search queries for Google (Google Dorks) and specialized search engines for the Internet of Things:

To prevent script kiddies, we will not cite IPs of vulnerable systems, and detailed queries that make it possible to find low hanging fruits in one click. However, the treasure lies on the surface. It is enough to carefully read the description of the vulnerability and add one or two search filters.

The Shodan and Censys services perform additional screening of evil researchers. Without registration, they show only a short list of search results, limit the number of queries per day, and do not allow them to be refined effectively. All the fun usually begins after the first hundred results, or even further.

Many researchers use scripts to speed up their search for vulnerable IoT devices. To use them (as well as to use your own custom scripts), researchers need to register with Shodan and Censys.

Now, you have to check the search results and (if necessary) sift them using additional queries. Such a need arises almost always; therefore, scripts are also often used to parse results.

It is not a problem to prepare a set of tools for connecting to vulnerable IoT devices. In most cases, a browser will be enough. To control cameras and DVRs, it is sometimes needed to install an old version of Java Runtime Environment (JRE) and a specific video codec. You will also need Telnet and SSH clients. Sometimes you will need specific software like Cisco Smart Install Client.

So, finally, it is time to perform a test connection and try to change the settings. The latter is not recommended, because you can easily run into a trap - honeypot. Interpol also needs to improve its crime detection stats in the field of information security, and not too cautious security researchers may get caught.

Conclusion

There are really many vulnerabilities in IoT devices, but not all of them are easy to exploit. Some vulnerabilities require a physical connection, being near or on the same local network. The use of others is complicated by quick security patches. On the other hand, manufacturers are in no hurry to patch firmware and often admit it.

Getting an accurate list of vulnerable IoT devices will require significant efforts, it is not just a one-time query. The biggest part of search results from Shodan, Censys, and ZoomEye is not related to easily hacked devices. Numerous search results come up because the network response of many nodes partially coincides with the request of researchers looking for suitable targets.

The real extent of the prevalence of potential targets can be evaluated only after an in-depth analysis of search results and direct\manual one-by-one tests.

About the Author

Dominique René is a young content writer who is currently working for MacSecurity.net. She is inspired by the present-day groundbreaking technological progress. Dominique’s overwhelming enthusiasm for tech matters stems from her current research in college and innate aspiration to expand her academic outlook. She’s committed to staying on top of innovative trends in computer security, online privacy, threat intelligence, cryptocurrencies, and cloud solutions.

Cover photo by Louis Reed on Unsplash

February 14, 2020