Written By Reid Wightman
Vendors are red
SCADA is blue
Now everybody
can demonstrate vulnerabilities in controllers
As promised, we have more PLC exploits ready to roll in time for Valentine’s Day.
First, I can’t stress enough how much the other Basecamp researchers have done as volunteers. I was lucky enough to be paid to do this work, but I feel a bit outgunned by the accomplishments of the other researchers. I especially wish that our anonymous researchers could take credit for their hard work.
The tools may be downloaded from our site’s newly created Basecamp section, which includes individual pages for the Basecamp devices. Note that the Metasploit modules provided today are ‘proof-of-concept,’ and have not yet been blessed by Rapid7. They go through a QA process and typically make the modules a bit more elegant. These proof-of-concept modules may be buggy. Please pester Reid for support until they are officially released by Rapid7.
All three devices tested against today’s releases can be found online using Shodan or other methods. The exploit modules will do nasty things such as stop the CPU or provide the credentials to control the device. Please be responsible and don’t attack any systems that you find.
Allen-Bradley/Rockwell Automation (plus Schneider, WAGO, Omron, and many, many, many, many others)
Rubén went so far as to write C code demonstrating issues with the EtherNet/IP protocol. I ported a small part of the tool to be a Metasploit module. Note two of the payloads in this module (ethernetip_multi) should work against any PLC which speaks the EtherNet/IP protocol. The ‘vulnerability’ is in the protocol specification: no authentication is required per the standard for many commands. About 300 vendors belong to the organization responsible for the EtherNet/IP CIP specification, so the list of affected devices is going to be…large. This vulnerability should include some systems by Schneider Electric, WAGO, Omron, Opto 22, Phoenix Contact, and ABB, just as examples.
There are multiple payloads for this module. Currently you can issue a STOP command (should affect all manufacturers), crash the PLC CPU (probably Allen-Bradley specific, unless other vendors purchased their stack), crash the Ethernet controller (probably Allen-Bradley specific), and reboot the Ethernet controller (should affect all manufacturers). Note that Quickdraw already includes EtherNet/IP IDS signatures for a remote STOP (and many other attacks), and you can have those snort rules for free.
If you have EtherNet/IP devices from different manufacturers to test, I would appreciate reports on what works and what doesn’t. This could help us characterize vendors, and could possibly tell us which vendors implement CIP themselves, and which buy the stack from Rockwell.
Go to the Basecamp ControlLogix Page
Schneider Password Retrieval
In addition to hard-coded accounts in the Modicon Quantum series, the device also stores user-definable login names and passwords in plaintext files (a third user-definable password is stored using vxWorks’ terrible loginDefaultEncrypt() hashing algorithm). These files can be retrieved via FTP, and the accounts let an attacker log into the web interface and make changes to the device that would be difficult to make via FTP alone. This module (modiconpass) simply grabs plaintext files and stores the passwords in Metasploit’s database. It’s a trivial ‘hack’ but can be useful for pen-testers who don’t want to be bogged down remembering details of every system under the sun. Two accounts are currently retrieved: one is a username and password for the Modicon webserver login, and a second is just a password, which allows control operations to be performed via the web interface (called the ‘Write password’). The third password, a user-definable FTP account, will be added to an update to the module.
Go to the Basecamp Modicon Page
Koyo Password Bruteforcer
The Koyo DirectLogic uses a funky UDP protocol that has an authentication option. There is no lockout or timeout for incorrect passcode guesses, though, so a bruteforce is fairly easy. Running through the entire password space is a bit slow for now, until we learn how to properly thread the requests to maximize throughput.
Go to the Basecamp Koyo ECOM Page
GE D20 Additional Tools
Two Metasploit modules were previously released through Rapid7 in January. Today there are additional tools available to demonstrate the fragility of this device.
- d20tftpbo – This module crashes the D20 tftp service. The operating system catches the exception, but the damage is done — all processes are stopped and the D20’s network stack is disabled.
- telnet-fp.py – A D20 fingerprinting tool.
- d20cmd.py – A stand alone program that provides the asynchronous command line similar to the Metasploit module.
Go to the Basecamp GE D20 Page
A Note to all the Haters
For some reason, all of the criticism for Basecamp has so far been directed at us for disclosing vulnerabilities and tools, and not providing the vendors time to respond. Let me categorically show that this is not the case, and that vendors have had forever-and-a-half in the world of computer security to respond. ‘Haters gonna hate,’ according to a fun internet meme, but I thought it worthwhile to dive into the history of vulnerability handling with these devices a bit.
EtherNet/IP as a protocol has been known to have a lot of issues. Major issues were documented in the protocol in 2009 (that’s the earliest that I can find, anyway), when Daniel Peck uploaded firmware to a ControlLogix controller without signature or authentication using the protocol. The Quickdraw signatures linked to above were created in 2010, and the results were shared with DOE and DHS. DHS has had a copy of Dale’s presentation outlining some of the issues in EtherNet/IP for quite a while. Dale’s presentation at ICSJWG is even hosted by US-CERT. This series of issues have been known about for the least amount of time — and even then it’s been at least 2 years by all measures.
Schneider first became aware of backdoor accounts and Telnet access in their Modicon Quantum series of devices in 2006. Digital Bond worked with Tenable Security to produce a Nessus plugin for the sysdiag/factorycast@schneider backdoor account at that time. That hard-coded backdoor account can still be used with our password retrieval module today. Six years is a long time to go without designing a new way of doing things — it looks like Schneider just doesn’t care about security, at least in this product line.
Serious issues with the Koyo ECOM firmwares were also demonstrated back in 2009. We had a phone call with DHS last week in which they politely asked us to hold off on the release of this tool so that Koyo could have time to work on the issues we presented with Basecamp. Koyo has had three years to deal with existing problems, and have apparently done nothing to mitigate the oldest issue (unauthenticated/unsigned firmware upload), so I’m not sure that waiting is the Right Thing To Do. It certainly hasn’t worked so far.
Digging into the history of vulnerability handling was kind of an eye-opener for me. Given the past serious issues in these controllers, I’m feeling a bit better with myself for doing a tools release now. Hopefully the disclosure dates above serve to direct pressure in the right direction. Whether we want to use the word ‘blame,’ when talking about vendors here is still open for debate. One thing is for sure, though: vendors are the only ones with the power to fix the problems, and they have had years to fix them. So far, no fixes have come.
Image by dm-set