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.
I launched Shodan nearly a year ago, and right off the bat people started finding systems that are discussed in the ICS alert. It ranged from a cyclotron at the Lawrence Berkeley National Laboratories to infrastructure-level network switches and water treatment facilities. Even now, a quick search for openly accessible Cisco switches returns almost 7,000 results.
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.
