Locating SCADA and ICS systems on .EDU networks using Shodan

[Shawn Merdinger <shawnmer () GMAIL COM>]

Hi List Folks,

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 is 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.

This 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 .
edu's 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 doing searches on your own see the scada
ports list here:
https://www.digitalbond.com/tools/the-rack/control-system-port-list/

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 http://www.shodanhq.com/help/filters

Also of use, though as they are user-submitted and not 'clean' or vetted,
the “Popular Searches' locate at http://www.shodanhq.com/browse may help to
provide some insights into not only what Shodan users are searching for,
but also what are the more popular search terms.

To begin, you would enter in the Shodan search box the following: hostname:
limiter as youruniversityname.edu <http://cornell.edu/> and then the
SCADA/ICS port limiter as port: xxx

A key point here is the above search only located systems in the Shodan
database that have assigned DNS names with
youruniversityname.edu<http://cornell.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 <http://cornell.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, and on occasion 161 (snmp).

Another strategy is to conduct Shodan searches using your youruniversityname
.edu <http://cornell.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:
https://www.digitalbond.com/tools/the-rack/control-system-port-list/

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've 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 a .edu's 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
Extracttion) managed by Bob Radvanovsky of http://www.infracritical.com

See the following medial stories to get an idea of Project SHINE's findings
and outcomes:

http://krebsonsecurity.com/2012/10/dhs-warns-of-hacktivist-threat-against-industrial-control-systems/

http://www.networkworld.com/news/2013/011513-dire-warnings-dont-yield-better-265830.html

http://www.belden.com/blog/industrialsecurity/Project-SHINE-Are-Control-Systems-REALLY-Connected-to-the-Internet.cfm

On a side note, and this will perhaps later evolve into a Educause security
mailinglist post, 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 SPC presentation from
last week (
http://www.educause.edu/events/security-professionals-conference/2014/using-shodan-edu
) I outline a threat vector that includes sending child pornography 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. I wrestled with a myself a long time
about whether or not to post this, but the time has come that education and
action regarding exposed SCADA/ICS in the .edu sector is no longer an
option.

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.  If you're interested in someone who "tell it like it is" -- for
the right role at the right .edu, I would consider interviewing for a
position.

Cheers,

--scm