I wrestled with a myself for a long time about whether or not to publish this article, but the time has come for education and action regarding exposed SCADA/ICS in the .edu sector.
The goal of this post is to encourage security teams at .edus to proactively discover, enumerate, inventory and classify SCADA/ICS devices on their networks in order to mitigate risk. I assume no responsibility for misuse or impact arising from this sharing of information.
The following Information is derived from public resources. While the strategy was developed by me, it is important to understand that any motivated individual with Internet access could leverage these resources to target SCADA/ICS not only on .edu networks, but also against any public Internet facing devices.
Further, SHODAN is simply a database of scanned devices and indexed banners, and is one of several scan repositories available to anyone, for example Internet-wide Scan Repository hosted at the University of Michigan and located at https://scans.io – put simply, SHODAN is a tool, and should not be disparaged, but rather used for the public good.
The following strategy is neither exhaustive nor comprehensive for several reasons, including:
- SHODAN does not scan all ports
- Some SHODAN results may be purged or incomplete
- SHODAN does not scan all networks
- SHODAN does not scan IPv6, etc.
It is important to realize that SHODAN is one man’s project, and as such should be viewed as merely the beginning of your .edus quest to identify SCADA/ICS devices on your network.
To wit, this is your responsibility, and you should develop, with proper authority and top management support, a holistic strategy that includes policy, technical measures like targeted and tactical scanning, security assurance contracts (i.e. 2nd and 3rd party implementers like Siemens and Johnson Controls), hardening, remediation, collaboration with and a push-back against vendors’ product insecurities and (if push comes to shove) authority for .edu IP takedown.
The first step is to register for a free account at http://www.shodanhq.com – I strongly suggest that you also purchase the SHODAN extras that include Telnet and HTTPS and also allow you to export results in CSV format so you can incorporate findings into reports and other tools.
I receive zero compensation or ‘kickback’ for any purchases of SHODAN extras, therefore, this is recommendation is of benefit only to .edus. For a few ports to get started in doing searches on your own see the SCADA ports list here:
If you have utilized Google search limiters such as site: this search strategy should be intuitive. As a reference of available SHODAN search limiters, see:
Also of use, though they are user-submitted and not ‘clean’ or vetted, the “Popular Searches’ located here:
They may help to provide some insights into not only what SHODAN users are searching for, but also what the more popular search terms are.
To begin, you would enter into the SHODAN search box the following: hostname: limiter as youruniversityname.edu, and then the SCADA/ICS port limiter as port: xxx.
A key point here is that the above search only located systems in the SHODAN database that have assigned DNS names with youruniversityname.edu, and it’s likely that other systems on your network just have an IP address and no DNS entry, so I strongly recommend you conduct net: limiter searches with all of youruniversityname.edu networks – you probably have a class B, so an example search would look like net:xxx.xxx.0.0/16 and stack the port: in the same search.
Also key is to search for the DNS and class Bs for open Telnet, as well as HTTP, HTTPS, SSH, etc. since some devices will not have SCADA/ICS ports open, but are systems that are gateways from TCP to Modbus, etc. These usually have a port like 80, 443 or 23 open, port 21 for FTP, and on occasion 161 (snmp).
Another strategy is to conduct SHODAN searches using your youruniversityname.edu and CIDR block and also add in common vendor names such as Siemens, Niagara, Lenel, etc. And yet approach is to search for SCADA/ICS device functionality, such as PLC or BMC. Again, visit the DigitalBond reference which has common vendor names:
SCADA/ICS systems on public IP in .edus pose a serious and oft-overlooked safety threat to the university community as most .edu security teams are burdened with compliance-oriented tasks and often lack the skillset and knowledge that comes from this kind of specialized enumeration.
Bear in mind that not only are the systems often tied to critical institution infrastructure devices like power, water, lab equipment, refrigeration, building controls, door control systems and the like, but also are quite often embedded devices with poor security measures like clear-text protocols, well-known hard-coded passwords, extraneous services, backdoors, leftovers from developers like open debug ports and the like.
It’s important to recognize that the robustness of these devices when subjected to aggressive probes and scans makes them susceptible to severe impact from the very simplest of attacks. One must exercise restraint and utmost caution when enumerating or accessing these devices.
For example, I have seen firsthand SCADA/ICS devices reboot from mere Nmap scans. If you subject an embedded SCADA/ICS device to a full Nessus scan, it will most certainly be impacted. Therefore, this kind of device enumeration should take place outside of your normal scanning practices, if they exist.
Put simply, if you approach this task with the ignorant, cavalier attitude of “anything should be able to handle a Nessus scan” (and I have been told this directly by former ‘security’ colleagues who should have known better), I have little doubt you will severely impact that device, with your best hope that the device reboot and mostly recovers… mostly.
Bear in mind that this strategy applies only to Internet-facing devices and does not even begin to address what a malicious attacker can do once gaining a foothold into an .edus internal network via pivot or other means. Addressing those risks requires an entirely different level of scope, policy, tactics and skillsets.
What I’ve outlined above are, quite frankly at this stage of the game, baby-steps. In case you’re wondering, my expertise in this analysis stems from personal research as well as a multi-year volunteer effort as lead contributor to Project SHINE (SHODAN Intelligence Extraction) managed by Bob Radvanovsky of http://www.infracritical.com.
See the following media stories to get an idea of Project SHINE’s findings and outcomes:
On a side note, MFP (multi-function printers) exposure on .edus networks is abhorrently rampant and poses significant risk via simple and advanced attacks that includes loss of PII/PHI and allowing anyone on the Internet to print whatever they want to your printers.
In my recent SPC presentation (http://www.educause.edu/events/security-professionals-conference/2014/using-shodan-edu) I outlined a threat vector that includes sending child pxxnography to .edu printers, and the potential ramifications including lost productivity, extraordinary investigative costs, negative press, hostile work environment, employee lawsuits and the potential cost of security and IT leadership jobs for due diligence failures (just ask Target’s former CISO, CIO and CEO) .
There is a slide that if you bring to top management I am sure you will gain support to remove these from public IP, or at least it will motivate you to mitigate the risk to your job by notification of the risks and assigning responsibility via contract to the responsible department choosing to host MFPs on public IP.
I wish you the best of luck in tackling this task. Be vigilant and be careful… there’s a lot at stake here. Finally, I am available for Shodan consulting and training for security and network teams and provide this service only to .edus, law enforcement and InfraGard.
About the Author: Shawn Merdinger is a healthcare security researcher with 13 years’ of experience in information security. He is founder of MedSec, a LinkedIn group with a technical focus on medical device security risks with more than 500 members and worked with Cisco Systems, TippingPoint, a university academic medical center and independent security consultant. A proponent of responsible disclosure practices, he collaborates frequently with organizations like ICS-CERT and CERT/CC and has served as a technical editor for 12 titles from publishers Cisco Press, Pearson, Wiley and Syngress. Shawn has presented original security research at security conferences such as DEFCON, DerbyCon, Educause, ShmooCon, CONfidence, NoConName, O’Reilly, IT Underground, CarolinaCon and SecurityOpus and earned a graduate degree from the University of Texas at Austin and undergraduate degrees from the University of Connecticut.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
- Fred Cohen on Simplifying Security Assessments for Critical Infrastructure
- CyberLens: The New Tool Suite for Critical Infrastructure Security
- Where Do You Stand with NERC CIP v5?
- Building Trust Among Cyber Tribes
Check out Tripwire SecureScan™, a free, cloud-based vulnerability management service for up to 100 Internet Protocol (IP) addresses on internal networks. This new tool makes vulnerability management easily accessible to small and medium-sized businesses that may not have the resources for enterprise-grade security technology – and it detects the Heartbleed vulnerability.
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Title image courtesy of ShutterStock