Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Exposing SCADA Systems With Shodan

“The sad truth is that Shodan is just scratching the surface of unprotected or misconfigured SCADA devices… And, of course, the search engine merely finds systems. It doesn’t expose
the myriad of bad security practices that seem to be rampant amongst vendors and operators.“

Editor’s Note: The U.S.’s Industrial Control System Computer Emergency Response Team (ICS-CERT) recently issued a warning to its members about the ability of attackers to discover ICS systems using a simple search on Shodan, a public search engine that is used to locate systems accessible from the public Internet. In this column, Shodan’s creator, John Matherly, writes that the ICS-CERT warning just scratches the surface of SCADA and ICS System insecurity, and provides suggestions for shielding these systems from the attentions of search engines, curious netizens or would-be attackers.

The recent ICS-CERT alert on the ability to find Supervisory Control and Data Acquisition (SCADA) systems using Shodan has received a lot of attention, mostly by people who were surprised to hear about the apparent lack of security on systems that run much of our nation’s critical infrastructure. For many security experts, though, these security issues were well known and long-standing – the proverbial elephant in the living room. Now it seems Shodan, a search engine that I created, has brought the security issues plaguing SCADA and ICS systems into the daylight by making it possible to discover Internet facing ICS systems with a simple Web search.

For people unfamiliar with Shodan (http://www.shodanhq.com), it’s a web service that scans the entire Internet for specific services (HTTP, HTTPS, Telnet, SMTP, SSH and FTP). If it finds an IP that responds to an initial search, it proceeds to grab a banner that contains information about the service. Finally, the IP gets correlated with other sources of data, such as geographic location, to complete the picture.

To cloak a computer from Shodan, systems should simply refrain from responding to either the first crawl or subsequent connection attempts by configuring their firewall to block unknown sources from connecting. I should note that this is not the same as trying to hide the computer from search engine crawling by configuring a robots.txt file to tell Google, Yahoo, Bing, etc. to leave you alone. That might be an instinctual first step for IT staff, but would only mask and delay the real problem. The truth is that SCADA and industrial control systems should not have a public IP address. If the security of a service depends on that service remaining hidden (a.k.a. “security through obscurity,”), then that’s a problem.

The sad truth is that Shodan is just scratching the surface of unprotected or misconfigured SCADA devices. Since it mostly looks for computers running a web server, it misses any device that relies on a custom daemon operating on a different port. That doesn’t mean that such systems are undiscoverable. It just means that Shodan isn’t looking for them. And, of course, the search engine merely finds systems. It doesn’t expose the myriad of bad security practices that seem to be rampant amongst vendors and operators.

The good news is that a few, simple security precautions would prevent the problems mentioned in the ICS alert: multiple layers of defense are important and expected of an organization containing sensitive equipment or information. Such measures include the use of strong passwords, removing default user accounts, setting up a VPN for remote access, properly configuring the firewall and having emergency response procedures in place, constantly testing network security and monitoring for file system changes. Operators should use Shodan to check whether their systems have been indexed.

Finally, there’s an API for Shodan that lets system administrators periodically check whether any of their machines are publicly accessible. The bad news is that getting ICS vendors and their customers to understand and implement these common-sense measures is an uphill battle. A few weeks ago at the Toorcon conference, security researcher Jeremy Brown gave a talk on exploiting SCADA systems that showed just how little some vendors care about security.

Brown related his experience trying to convey information about a serious, remotely exploitable hole in a common SCADA platform to the vendor responsible for the software. Brown told the audience about how he struggled to explain the concept and implications of remotely exploitable vulnerabilities to the vendor’s security contact, only to be told to “stop wasting their time.”

It wasn’t until Brown went public with his findings and aroused the interest of the Industrial Control Systems Computer Emergency Response Team (ICS-CERT) that a vendor patch was issued.

Hopefully the Stuxnet incident as well as recent ICS alerts will convince vendors and operators alike to allocate more resources to security and make it a central component of their infrastructure.

Discussion

Great article John, and it highlights some important aspects of Shodan.

I'd like to add something regarding scanning. In some circles there's concerns about Shodan, but the reality is that Shodan should be considered an example of attacker capability, and not a threat in and of itself.

Specifically, I refer to HDM's awesome VxWorks research earlier this year, where he employed some virtual hosts and scanned the Internet...yes, that's correct, the entire 0/0 range...for VxWorks port UDP/17185 (see slide #27 of his preso below).

So, the first takeaway should be that a scanning a huge IP range for specific ports is totally doable for those with a few bucks for a VPS. The second takeaway is that people and organizations are creating their own, private, personal databases of scanned IPs (and likely wider ranges of TCP/UDP ports) and that Shodan is merely highlighting the threat posed.

I agree with Shawn that the problem is not that Shodan exists. The problem is that Shodan finds stuff that shouldn't be there.

While I was looking at Shodan it seemed that much of what Shodan knows is a result of meta-data that these systems freely offer up when queried. If those systems would simply suppress that meta-data then there would be little known about the system other than that there is an open port. Suppressing that data certainly wouldn't be the equivalent of securing the system but it would seem to reduce the effectiveness of Shodan.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.