If you keep tabs on major vulnerability discovery reports or stay tuned for security researchers’ new findings unearthed at popular conferences such as Black Hat or Defcon, it may seem that everything is online and easily hackable these days. Moreover, analysts often emphasize that it doesn’t take advanced skills or special high-end gear to execute such a compromise. Let’s try to figure out if this is true.
If you keep tabs on major vulnerability discovery reports or stay tuned for security researchers’ new findings unearthed at popular conferences such as Black Hat or Defcon, it may seem that everything is online and easily hackable these days. Moreover, analysts often emphasize that it doesn’t take advanced skills or special high-end gear to execute such a compromise. Let’s try to figure out if this is true.
A plethora of potential targets
According to Statista, the size of the IoT market reached $330 billion in 2019. The total number of internet-facing
smart devices is expected to exceed 38 billion in 2020 and will double by 2025. Furthermore, researchers claim the number is going to jump to about 125 billion by 2030.
It appears that the global production volume is likely to live up to the predictions. The current jaw-dropping
IoT growth is mostly attributed to the releases of inexpensive Chinese smart devices. Unfortunately, security is hardly ever the first priority of their manufacturers.
Numerous mainstream components of connected homes and even
smart security systems are notoriously unsafe to use due to gaping loopholes in their firmware and feature implementation. Some of these flaws apply to entire ranges of such IoT appliances rather than a single series of devices made by a vendor that doesn’t take security seriously. The imperfections often stem from the following flagrant, large-scale violations of secure development fundamentals.
- The use of hard-coded and obfuscated default admin credentials.
- Massive reuse of easy-to-guess access keys and PINs.
- Lack of access control techniques for verifying users as they query a common settings page (for instance, accessing /settings.asp while bypassing /index/html) or directly request images and video stream from a video surveillance camera (such as /axis-cgi/jpg.image.cgi).
- Crude data processing implementation that leads to a buffer overflow. This can be a launchpad for arbitrary code execution after receiving a malicious TCP packet.
- The option of configuring a server to use old protocol versions based on a request from the client device (“I’m an obsolete chunk of metal, so let’s play simple”).
- A slew of other common flaws and instances of deliberately loosening the security measures for the sake of user experience and easy customization, including remote tweaks of the settings without proper authentication.
Ways of searching for vulnerable connected devices
Security experts have masterminded plenty of algorithms to pinpoint easy-to-compromise devices. The opportunistic creators of botnets, in their turn, have already weaponized the most effective ones. On a side note, if botnet authors heavily use a specific vulnerability, it means that this flaw is perfectly “suitable” for massive real-world exploitation.
When scouring the Internet of Things for weak links, some black hats focus on vulnerabilities in firmware, including bugs discovered through reverse-engineering of its code. The other tactic is to narrow the search down to the vendor name – a simple MAC address lookup can reveal this information (specifically, its first three octets say it all). Some attackers use the OS build criterion – most devices broadcast it in regular network response to search engine crawlers.
In any of the above scenarios, a white hat or black hat needs some distinctive characteristic of a vulnerable device. A few of these hallmarks will make the search yet more effective and accurate. Here is a “classic” process of spotting unsecured IoT devices.
1. The starting point is to query a vulnerability database, such as MITRE or Rapid7, for known loopholes in specific IoT objects. The following types of vulnerabilities tend to yield the best results in terms of exploitation:
- Flaws discovered after the manufacturer ended support of the device and stopped releasing patches.
- Recent imperfections that haven’t been patched yet. Even if a bug fix is already available, it takes some users quite a while to install the update.
- Loopholes in software architecture that cannot be fully addressed through patches and hardly ever vanish from the radar completely. For instance, this is the case with the multi-pronged Meltdown and Spectre vulnerabilities that are still making themselves felt in the security ecosystem.
- Overarching bugs that affect a number of different models or types of devices due to a shared web interface component or communication protocol flaw.
2. The next step is to do your homework and examine the details about the vulnerabilities you found and the devices they apply to. Peruse all the documentation in search of unique features and fragments of shoddy code. At this point, your goal is to single out the characteristics that make the target device stand out from the crowd of similar ones. An example is a specific OS version string in the network response from the device or an uncommon open port it may be using.
3. Now you need to create advanced search queries for Google (what’s called Google Dorks) and popular IoT search engines, including
To keep wannabe hackers at bay, I will omit IP addresses of vulnerable systems as well as some details and queries that allow finding low-hanging fruit in a single click of a mouse. With that said, though, the clues are in plain sight. All it takes to find them is scrutinizing a vulnerability description and adding a couple of search filters.
By the way, Shodan and Censys have some mechanisms in place to fend off ill-minded researchers. They prevent unregistered users from viewing more than a few top search results, restrict the number of daily queries, and don’t allow potential black hats to refine their searches. These are effective countermeasures because the most verbose results typically go after the top hundred entries or further.
Some analysts leverage scripts to facilitate their search for IoT devices that meet certain criteria. It’s worth mentioning that both readily available and custom scripts can only be executed by registered users of Shodan and Censys.
4. Verify the targets listed in the search results and filter the search via extra queries where necessary. The need for additional filtering is almost always the case and therefore scripts come in handy to parse the results.
5.
It’s usually no big deal to come up with the toolkit for connecting to the discovered IoT devices. The ordinary web browser will do the trick in most cases. To maintain remote control of
video surveillance cameras and DVRs, you may need to install a legacy version of Java Runtime Environment (JRE) along with a specific video codec. In some scenarios, you will need Telnet and SSH clients to interact with the device. Tools such as Cisco Smart Install Client may sometimes be required, too.
6. Depending on how far you plan on going with the exploitation, the next stage is to amass statistics or try to establish a test connection and modify some settings. The latter is a slippery slope – one of the reasons is that you run the risk of being ambushed in a honeypot. Furthermore, law enforcement agencies are getting better at investigating cybercrime and chasing down malicious actors, so you don’t want your research to end up in their spotlight.
The bottom line
Although the internet of things is full of vulnerabilities, exploiting many of them is easier said than done. To harness some of these flaws, you need to be physically close to the target local network. Timely firmware updates with critical security patches onboard may prevent attackers from piggybacking on the other known flaws. Nevertheless, most vendors take their time releasing such fixes and they often admit this sluggishness.
It takes a good deal of effort to compile a list of IoT devices that are susceptible to specific vectors of compromise. The vast majority of search results generated by the likes of Shodan have nothing to do with easily hackable devices. The reason why a bevy of entries is returned is that the network response of many connected things partially matches the queries of analysts or enthusiasts searching for targets that meet their criteria.
To get the big picture regarding the prevalence of potential targets for botnets, you need to go through an in-depth analysis of the search results and quite a bit of trial and error with the checks whose importance is usually underestimated.
About the author
David Balaban is a computer security researcher with over 17 years of experience in malware analysis and antivirus software evaluation. David runs
MacSecurity.net, which presents expert opinions on contemporary information security matters related to Apple devices, including malware, social engineering, and privacy. David has a strong malware troubleshooting background, with the recent focus on ransomware countermeasures.