Metasploit and SCADA exploits: dawn of a new era?

Courtesy Shawn Merdinger

On 18 October, 2010 a significant event occurred concerning threats to SCADA (supervisory control and data acquisition) environments.

That event is the addition of a zero-day exploit for the RealFlex RealWin SCADA software product into the Metasploit repository. Here are some striking facts about this event:

• This was a zero-day vulnerability that unfortunately was not reported publicly, to a organization like ICS-CERT or CERT/CC, or (afaik) to the RealFlex vendor.
• This exploit was not added to the public Exploit-DB site until 27 October, 2011.
• The existence of this exploit was not acknowledged with a ICS-CERT advisory until 1 November, 2010.
• This is the first SCADA exploit added to Metasploit.
• So what are the lessons learned and takeaways from this seminal event?

First, the SCADA community can expect to see an explosion of vulnerabilities and accompanying exploits against SCADA devices in the near future.

Personally, I expect we will see in the next 12 months at least a doubling of the known 16 SCADA vulnerabilities documented in NIST’s National Vulnerability Database.

Second, the diverse information sources that SCADA vulnerabilities may appear must be vigilantly monitored by numerous organizations and security researchers.

Afaik, the first widely-disseminated information on the RealFlex RealWinbuffer overflow occurred on 1 November, when I sent the information to the SCADASEC mailing list.

Third, people should recognize that the recent Stuxnet threat has cast a light on SCADA security issues. Put bluntly, there is blood in the water.

Quite a few people, companies and other organizations are currently investigating SCADA product security, buying equipment and conducting security testing for a number of differing interests and objectives.

I expect SCADA security issues will be the shiny hot topic on the 2011 security and hacker conference circuit, both in the US and abroad.

Fourth, understand that because of the current broken business model, security researchers are often frustrated by software vendors’ action, or inaction, when it comes to reporting vulnerabilities.

Often, there is no security point-of-contact at the vendor. Even worse, the technical support who are contacted by the security researcher often do not understand the technical and security implications of the issue reported.

And it is worth mentioning that a vendor acknowledging a product security issue is then“on the hook” — so there is incentive for the vendor to dismiss the vulnerability report.

Even in the case of specialty SCADA security shops reporting vulnerabilites to the vendor, we are seeing documented cases of “vendor spin” furthering the bad blood between vendors and ethical research.

All of these factors lead to frustrated security researchers, some of whom will simply expose the vulnerability and exploit to the world, rather than take a disclosure path through a CERT.

Fifth, folks should recognize that attack frameworks like Metasploit enable a never-before-seen level of integration of these kinds of targeted critical infrastructure-relate exploits into a powerful tool.

For a kinetic metaphor, Metasploit is akin to a.50 caliber sniper rifle, and a zero-day SCADA vulnerability is equivalent to a .50 caliber depleted uranium round for that rifle.

As a SCADA end user, what are you to do?

I recommend the following, at a minimum: push your vendors to have a product security POC and process, monitor resources like SCADASEC, keep current with tools like Metasploit, receive vulnerability notifications from appropriate CERT organizations like ICS-CERT.