ICS-CERT Updates HeartBleed Alert

This afternoon the DHS ICS-CERT updated their ‘Situational Awareness Alert for OpenSSL Vulnerability’, commonly referred to as the HeartBleed bug. The information added to date is the most extensive to date and includes:

• An advance notice about an ICS-CERT Advisory for HeartBleed in Atvise;

• An extensive (but probably not exhaustive) list of ICS related applications and devices that have been determined not to be affected by HeartBleed;

• A reminder that while older versions of OpenSSL may not be affected by HeartBleed, they do have their own known vulnerabilities; and

• A reminder that the use of SHODAN and other search engines may make it relatively easy to find ICS components that are susceptible to HeartBleed.

Atvise

ICS-CERT took the unusual step of announcing that an “ICS-CERT advisory [was] coming soon” for the Certec atvise scada products. It provides a link to the atvise notice about the vulnerability. That stilted notice (okay I lived in Berlin for 7 years and my German syntax was way worse at its best than this English language notice) claims that while some versions of their products have the HeartBleed bug “but wasn't affected by known attacks”. Now they “face new kinds of attacks found nearly daily”. I certainly look forward to hearing more about the ‘new kinds of attacks’ on a SCADA system.

Atvise does have a patch available for the vulnerable OpenSSL components.

Systems Not Affected

There is a fairly long list of systems here that are not affected by the HeartBleed bug because either they ‘don’t use OpenSSL’ or ‘don’t use an affected version of OpenSSL’. Unfortunately there is not an actual control system or component on the list. They are all either communications tools or security tools. This list will be invaluable to a security manager or integrator. It does let them concentrate of other parts of their systems, but it is strangely unhelpful for control systems.

The lack of any control system applications or devices on the list is more than a little disconcerting. Two weeks into the public discussion of HeartBleed and we have two vendors (Siemens and atvise) self-identifying their infection with this bug, but no one saying that they are infection free. At this point I think that any ICS system that has not identified itself as being free of HeartBleed should, for the sake of safety and security, must be considered to be infected until proven otherwise.

Other OpenSSL Vulnerabilities

There have been any number of system vendors that have bragged that their system uses an older version of OpenSSL that is not affected by HeartBleed. Today’s update reminds people that earlier versions of the software have their own problems that should not be ignored. The Update provides a link to the OpenSSL web page that lists a large number of reported vulnerabilities in the system. If all of the patches and upgrades have not been applied to earlier versions, there may be more serious problems than HeartBleed.

SHODAN and Others

Any time you have a widespread vulnerability like HeartBleed it is valuable to be reminded that search engines like SHODAN make it relative easy for people to find vulnerable systems. That combined with the wide spread availability of automated attack and exploit tools makes it easier for both the opportunistic and targeted attackers to gain access to improperly secured systems.

ICS-CERT notes in the Alert that: “As tools and adversary capabilities advance, ICS-CERT expects that exposed systems will be more effectively discovered, and targeted.” They also remind owner/operators that they can use many of the same tools to discover if their systems are vulnerable. Knowing that their systems are accessible and vulnerable should allow owners to better protect their systems.

Reader Comment – 11-02-13 – Project Shine

On Saturday Jake Brodsky (a frequent commenter, an ICS manager, and a person with his fingers in lots of ICS security projects) left a comment on my blog post on the ICS-CERT Nordex Alert. Jake used my mention of the missed SHODAN angle for the vulnerability discovery as a spring board to mention Project Shine that he and Bob Radvanovsky have been working on. I’m glad he did because I have only mentioned this project in passing.

Project Shine (SHodan INtelligence Extraction) is an ongoing project that uses the SHODAN search engine to identify industrial control systems that are facing the internet. To date they have found well over 1,000,000 systems (that number was bandied about back in the middle of September and they are adding a couple of thousand new systems every week) that look like control systems.

Now this includes building environmental control system, security systems and the like, but there are enough industrial control systems involved to kill the idea that these systems are not connected to the internet. This point is emphatically made by Eric Byres in his blog post.

Now I am not going to get involved in a technical discussion of how these two are using SHODAN to discover potential ICS systems facing the internet. Dale Peterson’s podcast conversation with Bob does that well enough. But I do want to talk about some interesting implications that Bob and Jake have not talked about.

First off, you have to understand that Project Shine is not a professional job (though both Bob and Jake are certainly professionals). As I understand it it is being run out of the basement laboratory in Bob’s home. I don’t suspect that Bob’s basement is really very normal, but this is a project running on a private system with limited resources. Think of a super geeks version of Gibb’s basement boat building; professionally, even painstakingly, done in the spare time of a very busy team.

So what would a Project Shine executed by a professional organization with extensive time, resources and expertise (say the NSA? Or its Russian or Chinese or Israeli counterparts)  look like? Well it wouldn’t use a limited search engine like SHODAN. It would custom design a program using high-speed computational assets that geeks like Bob and Jake can only dream about. They would have a team of engineers and analysts working the project around the clock. And they would not be afraid to reach out and gently touch the systems so that they could determine exactly where and what they were.

Why would they do that? Let’s face it; if you want to be able to conduct cyber-war (and you have to because the other guy is) then you have to understand the battlefield and you have to have a target list. Remember, since WWII modern warfare has not been about destroying the other guy’s military (those are hard targets), it has been about destroying his will and ability to conduct war. You do that by targeting his critical infrastructure. And if you are really smart, you might consider weakening his CI well before you go to war.

If you don’t think that this is happening right now, then you haven’t been paying attention to the news. Now does this put cybersecurity for control systems into a different perspective? For most people (and certainly for politicians) probably not; if nothing has happened, then nothing will happen.

Except when it does happen, the Washington political establishment will make Chicken Little look like an over-sedated octogenarian. Just look at what happened when two buildings were destroyed and a couple of thousand people killed. What happens when we are really attacked?

ICS-CERT Publishes Nordex Alert

Earlier this week DHS ICS-CERT published a control system alert for the wind turbine generator SCADA/HMI produced by Nordex. The cross-site scripting vulnerability was publicly disclosed by Darius Freamon on his blog (The Darius Freamon Blog, he is more creative in his cyber-vulnerability research than in his blog naming).

ICS-CERT does identify Darius as the source of this vulnerability report but only provides a link to his disclosure through OSVDB not his blog. To be fair though, you have to be something of a control system geek to see the actual vulnerability from the Darius blog post whereas the OSVDB listing makes it much clearer:

“Nordex NC2 Wind Farm Portal contains a flaw that allows a reflected cross-site scripting (XSS) attack. This flaw exists because the application does not validate the 'userName' parameter upon submission to the /login script. This may allow an attacker to create a specially crafted request that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.”

An interesting thing that neither ICS-CERT or OSVDB noted in their write-ups about this vulnerability is that it was discovered via SHODAN. It appears that Darius is a prolific user of SHODAN to search for vulnerabilities. Most commentators have focused on the use of this search engine for finding internet facing control systems, Darius has been using it to find system vulnerabilities, particularly default credentials.

Darius has been looking mostly at servers and communications devices, but I expect that we will be hearing more from him about control systems.

ICS-CERT Alert on SCADA Accessibility

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an alert about control systems that are accessible from the Internet. This is a follow-up alert to one that they published last year in October when news of the SHODAN search engine became widely available.

SCARY News

Since that earlier alert was published a number of security researchers have contacted ICS-CERT with detailed information about real-life control systems that they have found using tools like SHODAN. The summary data provided in this alert is scary. They include:

• February 2011; a number of electrical utilities remote access links were discovered on-line, many still using default usernames and passwords;

• April 2011; 75 Internet facing control systems from the water sector; again many using default logon credentials; and

• September 2011; several thousand Internet facing control systems in 63 different countries;

In these cases ICS-CERT coordinated with vendors and system owners to reduce the threat from these readily found vulnerabilities. But, like just about any other security system vulnerability, they only know how many systems that they have found, not the actual number of vulnerable systems. And someone could be locating those systems right now and planning their unwanted penetration testing of the identified systems.

Use of Search Engine Tools

Shortly after the original alert came out last year I did a blog posting on how these search engine tools could be used in protecting industrial control systems from potential attacks. According to this alert, while ICS-CERT hasn’t actually been using these tools themselves to search for vulnerable systems, they certainly seem to have been proactive in using data provided by researchers who used these tools to actively search for internet facing systems.

With the known proliferation of SCADA systems and devices that have design components that include potential Internet connectivity, I think that any cybersecurity manager worthy of the title should periodically conduct (or have conducted by appropriate security vendors) searches for internet facing devices in their control systems.

Regulated SCADA systems (which currently only include NERC and CFATS programs) should be required to periodically conduct such searches. Any agency reviews of the security of such systems should routinely include an agency conducted search for Internet facing systems and an evaluation of the security measures in place to protect the detected devices.

Last year’s ICS-CERT alert notified the control system industry of the problem. This report clearly identifies the extent of the problem. The ICS security community now has no excuse for not proactively using these tools to detect, correct and protect their systems from potential attack via open access of their systems and devices to the Internet.