Shodan Search Engine Project Enumerates Internet-Facing Critical Infrastructure Devices

Never underestimate what you can do with a healthy list of advanced operator search terms and a beer budget. That’s mostly what comprises the arsenal of two critical infrastructure protection specialists who have spent close to nine months trying to paint a picture of the number of Internet-facing devices linked to critical infrastructure in the United States.

ShodanNever underestimate what you can do with a healthy list of advanced operator search terms and a beer budget. That’s mostly what comprises the arsenal of two critical infrastructure protection specialists who have spent close to nine months trying to paint a picture of the number of Internet-facing devices linked to critical infrastructure in the United States.

It’s not a pretty picture.

The duo, Bob Radvanovsky and Jacob Brodsky of consultancy InfraCritical, have with some help from the Department of Homeland Security pared down an initial list of 500,000 devices to 7,200, many of which contain online login interfaces with little more than a default password standing between an attacker and potential havoc. DHS has done outreach to the affected asset owners, yet these tides turn slowly and progress has been slow in remedying many of those weaknesses

“The biggest thing is we are trying to assign a number–a rough magnitude–to a problem plaguing the industry for some time now,” Radvanovsky said. “Until you identify the scope of a problem, no one takes steps to change things. We’re doing it on a beer budget; we hope others confirm our results.”

Those results came largely from a series of automated scripts run against the Shodan search engine. Shodan was created for the purpose of finding servers, routers, network devices and more that sit online. Users can filter searches to find specific equipment by manufacturer, function and even where they’re located geographically. A 2010 advisory on Shodan pointed out that the availability of the search engine greatly reduces the resources attackers require to find these privately owned assets.

Radvanovsky and Brodsky said they built a suite of scripts that includes 600 search terms for equipment built and managed by close to seven dozen manufacturers of SCADA equipment and support systems for SCADA. The pair found not only devices used for critical infrastructure such as energy, water and other utilities, but also SCADA devices for HVAC systems, building automation control systems, large mining trucks, traffic control systems, red-light cameras and even crematoriums. They initially approached DHS with a list of close to 500,000 devices; DHS helped pare the list down to search terms for 50 critical systems it believed were relevant. That eventually shrunk the list of devices to 7,200.

Radvanovsky and Brodsky stressed they weren’t scanning for these devices and didn’t attempt to test the logins or how accessible devices were; just that they were Internet-facing. Most of the devices, they said, appeared to be for remote administration purposes.

“A lot of these guys want to fix things at 3 a.m. without driving three hours in each direction. It’s worth a lot to them to put it up on the Net without thinking hard about the potential consequences,” Brodsky said. “They’ll presume a particular protocol is not well known. These guys think no one will figure it out, but actually, there’s a lot of residual information available where you could figure it out. They’re not as secure as they think they are. That’s why this stuff is naked out there on the Internet. A lot of people believe there is some safety in obscurity. I don’t think they’re right.”

Experts have called the state of SCADA security laughable. Terry McCorkle and Billy Rios presented similar research at the 2012 Kaspersky Lab Security Analyst Summit where they found more than 1,000 vulnerabilities in Internet-facing HMI interfaces that translate SCADA data into visualizations of critical infrastructure. More than 90 of those were exploitable flaws, including SQL injection, buffer overflows and more. They, too, said that SCADA and industrial control system operators, most of whom are privately owned, believe their systems are not connected to the Internet. Aside from Radvanovsky and Brodsky’s work and that of McCorkle and Rios, more evidence is coming out of active attacks exploiting these exposures.

ICS-CERT’s fourth quarter report on critical infrastructure security detailed a pair of malware attacks against utilities in the U.S. where USB drives were inadvertently used to spread malware that in one case delayed a plant restart by three weeks. In all, ICS-CERT said there were 198 cyber incidents reported to them in FY 2012 and 41 percent of those against the energy sector.

The biggest wake-up call for SCADA and ICS operators should have been the Shamoon attack against the Aramco oil facility in Saudi Arabia. The malware destroyed data on 30,000 workstations; oil production was not impacted.

Projects like Radvanovsky’s and Brodsky’s may help put concrete numbers to the issue, but patching vulnerabilities and systems are not as simple a proposition.

“It’s difficult to patch in timely fashion. [Ethical] hackers don’t realize that when they find a problem, the thing it controls may not be able to be pulled out for a three months,” Brodsky said. “Unlike an office, data is not the product; the product is the product. When hackers publish a Metasploit script, they do so to get vendors to fix problem. In this case, it’s not just about the vendor, it’s about the user. It’s not easy to pull things from service. Maybe I can pull something only in the fall or spring, but not in the summer because I need it to be at full capacity. That’s the problem.”

Suggested articles