Radware delivers advice on protecting against IoT search engines targeting vulnerable devices

Cyber security and application delivery solutions vendor Radware has issued five tips that help organisations to protect against search engines targeting vulnerable devices.

Radware’s Director, Threat Intelligence, Pascal Geenens, says Internet of Things (IoT) search engines present both good solutions and serious risks of weaponised exploits: two VMware vCenter Server vulnerabilitiesidentified earlier this year illustrate this.

vCenter allows organisations to automate and deliver virtual infrastructures across the hybrid cloud, and a hack of vCenter enables threat actors to control the virtualisation layer.  This is a serious vulnerability for thousands of the largest organisations around the globe.

The first vulnerability identified was a remote code execution (RCE) in the vSphere HTML5 client vCenter plug-in. A day after VMware published this vulnerability on February 23, there were already two published exploits. By May 11, we saw a great deal of scanning by Necro Python Botnet, a cryptojacking malware.

The second vulnerability was disclosed by VMware on May 25 and relates to an RCE in the vSAN Health Check Plugin, which is enabled by default in all vCenter deployments. As such, unless organisations disabled the plug-in, they were vulnerable. By June 1, we saw a rapid uptick in scans following the online disclosure of the vulnerability details that could lead to weaponisation of the exploit.

Not all scans are nefarious. There are good actors that continuously scan the Internet randomly to catalogue vulnerabilities and assess the danger. Some turned those scanning activities into paying services, allowing businesses to easily assess their exposed services and threat surface. But in laying wide open all the vulnerabilities on the Internet, nefarious individuals can profit from them as well, easily and without investing in infrastructure or having in-depth technical knowledge.

Perhaps the three best known of these search engines are Censys, Shodan and ZoomEye. Among the capabilities they offer are the ability for organisations to discover all their Internet-connected devices and view exposed devices so that they can be protected or disconnected.

But they’ve made it so easy to search for unprotected IoT devices (by geolocation, port/operating system, services/host, IP address, keyword search, etc.) that anyone — white hat, grey hat, or black hat — can uncover vulnerable devices.

Consider the Deep Web, which is not indexed by search engines. Even if your IP address doesn’t have a DNS entry, it will be registered somewhere. You might think that if you put a service out there and notify only select people of the IP address, it would be safe. But now, these IoT search engines scan the world not just on HTTP ports, but also SSH, SMTP, and RDP. In the case of HTTP and HTTPS, they also grab the response of the webpage.

So with vCenter, anyone looking for a server running a vCenter HTML5 client, can look for a response that contains ID_VC_Welcome. Choose Censys for that query, and you’ll find about 30,000 HTTP hosts revealed. That doesn’t mean that all of those IP addresses are vulnerable because you haven’t searched for a specific version yet.

However, a version is encoded, and if by searching for all devices running a specific Web interface and firmware version, the database will provide the results. The exact answer isn’t always that simple, since information may be a few days or weeks old. And sometimes it’s on a dynamic IP address, though most vCenter addresses are static.

Doing a search of the same string on Shodan gives about 5,800 results. A sample result shows the vCenter server number and build number, which gives you enough information to know if it’s vulnerable. And the SSL certificate will tell you which category of company it is.

Basically, threat actors can purchase access to APIs for a few dollars, write a script that goes to the API, search for ID_VC_Welcome, check the version number of VMware, take the IP, and perform an exploit to see if it’s vulnerable. If so, they can drop a reverse shell or just flag it as being open for future use or sale.

ZoomEye provides similar capabilities to the other two IoT search engines. In my experiment, I was able to search for vulnerabilities using an unregistered account for Censys and ZoomEye and a free-tier account on Shodan. In the latter case, you need to register, but don’t need a subscription, and minimal personal information is required. In fact, I have provided more information just to download cybersecurity reports!

It should be clear now that providing access to this information requires acceptance of  the bad with the good. Anyone out there with a fully functioning Python script can abuse it almost immediately, regardless of their expertise or infrastructure.

Enough examples out there show how to use the APIs of IoT search engines to take the IP address, feed it into a proof of concept script downloaded from GitHub, and they’re off to the races hacking.

What can organisations do to protect themselves from the hacking risks created by legitimate IoT search engines? Here are five tips:


Tip 1: Much like red teaming, leverage the tools that attackers use to find out if you’re vulnerable. Check the best known IoT search engines for your IP subnet ranges and learn from this information.

Tip 2: Try to minimise your attack surface by only exposing the services you need. Don’t think a service or application you are exposing is not valuable to attackers; if it’s valuable enough for you to expose, it’s valuable enough for attackers to target.

Tip 3: Minimise the information you’re sharing through unauthenticated requests. Many services have the ability to configure the headers used in responses to requests, remove the software name, and release version details from the headers and replace them with fake information. Don’t be afraid to consult the manual; it might save you from a breach in the future!

Tip 4: When possible, don’t allow unauthenticated requests on exposed services. If you need to, and can’t change information shared by the service, consider using reverse proxies, where you have more control of which information is leaking.

Tip 5: Leverage bot management solutions, IP feeds and network signatures to detect and block scans from robots upstream from your services. Become a ‘’ghost’ on the Internet.