Hacking PLC SCADA Systems: Easy as Pushing a Button

Friday, January 20, 2012

Dan Dieterle


Interesting news yesterday from Digital Bond and Rapid 7, PLC exploits have been added to the Metasploit security testing platform.

According to the Rapid 7 Blog the following exploits that target General Electric’s D20 PLCs have been added to Metasploit:

  • d20pass : This module leverages a pretty major information disclosure for the device — turns out, anyone who connects to the TFTP server on the D20 can snag the complete configuration for the device, which includes plaintext usernames and passwords. This module does just that — downloads the configuration file, parses out the credentials, and stores them in Metasploit’s database for reuse.
  • d20tftpdb : This module demonstrates an asynchronous backdoor functionality in the D20 via the TFTP interface. Again, in an unauthenticated way, anyone can connect to the TFTP server, and issue command by writing to a special location on the filesystem. Also again, this is a pretty big deal. Note that this module is currently still in the unstable Metasploit branch pending a little more QA work on getting this (pretty unique) command and channel all nice and automated. As is, though, it works just fine for demonstration purposes, and if you have some of these PLCs in your environment, you are encouraged to investigate this more (and send patches!).

HD Moore developer of the Metasploit project had this to say on Twitter:

With the media hype of “CyberWar” and the news of hacker attacks against critical infrastructure systems, this is a shocking move by the Metasploit team. But maybe that is what they intended.

Metasploit is used for network security and penetration testing and it is very good. There are automated options that you can use with Metasploit that will try numerous exploits against a system, and give you a remote shell if one of them works. Taking this technology  and adding in PLC exploits is truly scary, or should I say, push button easy.

Just last month the FBI released the news that infrastructure systems of three US cities were hacked:

“We just had a circumstance where we had three cities, one of them a major city within the US, where you had several hackers that had made their way into Scada systems within the city.” And, “Essentially it was an ego trip for the hacker because he had control of that city’s system and he could dump raw sewage into the lake, he could shut down the power plant at the mall – a wide array of things.”

The problem is, even though people who run PLC devices in a SCADA environment have had years of warnings, many systems are still woefully unprotected, some even using default passwords. And many of these systems can be found using simple online search tools.

Most likely the thinking behind publicly releasing a tool to automate PLC exploits is that it will force companies to lock down their SCADA systems, as Dale Peterson, founder of Digital Bond states:

We felt it was important to provide tools that showed critical infrastructure owners how easy it is for an attacker to take control of their system with potentially catastrophic results. These attacks have existed in theory for a while, but were difficult to demonstrate to a Plant Manager. By creating exploit modules for the most widely used exploit framework – Metasploit – we hope that security professionals in critical infrastructure companies, consultants, and penetration testers will prod vendors to add basic security measures to PLCs after decades of neglect.”

Hopefully this tactic works and the good guys are the ones using the tools.

Cross-posted from Cyber Arms

Possibly Related Articles:
Information Security
SCADA Hacking Metasploit Exploits Infrastructure National Security Programmable Logic Controllers ICS Industrial Control Systems Dan Dieterle plc HD Moore Rapid 7 Dale Peterson
Post Rating I Like this!
nathan ouellette While the research of these system flaws for various SCADA systems is valuable (for several reasons), I think we're losing site of a few other important issues. It's true, that these systems are drawing attention and that vendors (and customers) are being put to task for helping up the ante on the technical weaknesses of some of these systems. It's also worth noting that are (and have been) compliance mandates that these networks are isolated and segmented properly and that these organizations are supposed to be adhering to. We all know that compliance does not equal security, but I would have to assume that many critical infrastructure organizations are enforcing additional layers of prevention beyond patching systems. I have to believe the 'exposed' SCADA system is not the norm. Like any vertical, I'm sure there will continue to be the occasional and horrible case of having control systems exposed and accessed easily. I'm sure we will continue to see these in the news. But for the most part, these networks have to be defined, identified, segmented and access to these systems should be properly controlled, documented and reviewed. In a nutshell...a SCADA system that is not patched, still has to be accessed from a remote (or local) perspective. Now...a system vulnerability is a system vulnerability. But let's recognize that when coupled with other layers of prevention, an alleged 'point and click' exploit and compromise is not as cookie cutter and as much of a 'done deal' as many of these articles are making them out to be. Let's patch these holes and help vendors step up security. But let's not pretend that 'security' of critical infrastructure is relegated just to host level vulnerabilities. There MUST be other layers of defense involved. It's mandatory and imperative. In fact, I would argue that the OTHER layers of defense, including simply 'best practices' are equally (if not more) important than patching the systems. Reducing the attack surface and mitigating the threat's ability to reach the system is being over-looked in the SCADA software vulnerability conversation.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.