New exploits targeting critical infrastructure added to Metasploit

Security researchers release exploits that target the programmable logic controllers at the heart of critical infrastructure.

Stuxnet is credited with being the first worm to successfully target large industrial systems, in this case, the centrifuges in Iran's uranium enrichment plants in 2010. While security researchers had been warning for years that threats to critical infrastructure, such as power grids, should be a huge concern, it wasn't until Stuxnet arrived on the scene that the message reached a wider audience. reports today that security researchers have released two different modules to Metasploit that have the potential to attack programmable logic controllers (PLCs), which are the components that control functions for some critical infrastructure such as refineries, large factories, water and waste water management plants, and other production facilities. These exploits both target Modicon Quantum PLC made by Schneider-Electric.

The exploits take advantage of the fact that the Modicon Quantum PLC doesn't require a computer that is communicating with it to authenticate itself or any commands it sends to the PLC - essentially trusting any computer that can talk to the PLC. Without such protection, an unauthorized party with network access can send the device malicious commands to seize control of it, or simply send a "stop" command to halt the system from operating.

Metasploit's own blog update for the week announces the addition of these two modules plus four others:

We've also reviewed and revised four of DigitalBond's previously released Basecamp Metasploit modules for this release:

  • d20_tftp_overflow : Triggers a Denial of Service condition due to a buffer overflow vulnerability in GE's D20ME PLC TFTP server.
  • koyo_login : Bruteforces the authentication passcode on a Koyo DirectLogic PLC
  • modicon_password_recovery : Given default FTP credentials, extracts the "write" password to the HTTP interface of the Schneider Modicon Quantum as well as the VxWorks hashes of all supervisory users.
  • multi_cip_command : Issues up to four unauthenticated stop and reset commands to a variety of PLCs which implement the Ethernet/IP Common Industrial Protocol.

From the perspective of security researchers, the point of releasing these modules is to continue to hammer home the potential for catastrophic effects on industrial systems if PLC makers do not improve their security measures and to make owners and operators of vulnerable components aware of the risks. Of course, malicious hackers can also use sites like Metasploit to learn more about where vulnerabilities exist as they design attacks of their own to exploit them.


Selena has been at TechRepublic since 2002. She is currently a Senior Editor with a background in technical writing, editing, and research. She edits Data Center, Linux and Open Source, Apple in the Enterprise, The Enterprise Cloud, Web Designer, and...


PLC still vulnerable. Many larger commercial and government buildings have Johnson controls or other brands of PLC integration. Valves, motors and vents all tied to computer monitoring. More so than the fully networked factory the building infrastructure seems to me more vulnerable. My machines that use G code are only vulnerable from the sense that their program files are on the corporate network. Factory floors may contain a dozen different PLC and machine control types so the chance that one is vulnerable is there but in most cases the "Infected laptop" scenario would be needed since they are not integrated with the LAN. If the are on the LAN then standard penetration techniques are needed before accessing the Industrial side is possible. Even then useful control requires either a specialized programming package determined by what brand and type of PLC or specially crafted malware focussed on the same (See Stuxnet vs Siemens.)


as not all automated factory floors(or other infrastructures) are quite that integrated with networking. However; many isolated PLC work centers, are accessed by technicians who repair/reprogram controllers during routine maintenance. If a carefully crafted worm or Stuxnet variant were to infect the laptops, that are typically used for such purposes; it doesn't take much imagination to dream up a scenario where a timed attack could bring a factory floor, to what amounts to, a dead stop. Physical damage can be realized by this scenario as well. I've also seen at least a certain percentage of machines actually controlled by Windows operating systems, so an even easier attack could be imagined in those instances. Fully networked factory floors were existent and growing by the year 2000; but I haven't been working in that area since. It is easy to assume this trend has continued and that we are even more vulnerable in this science by now. It would be interesting if someone could weigh into the discussion, with any knowledge or theory on how this could affect the interface to the G code popularly used in machining centers in the factory environment.

Editor's Picks