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
Dale, it isn’t “hating” to disapprove of your methods.
From what I read, you seem to feel that disclosure is everything. We will agree to disagree on this regard. Several protocols do what CIP does. They were never intended to see the outside of a real-time network. The very nature of such protocols is to presume that the network is secured from ALL extraneous traffic.
You can’t run a real time network using protocols such as CIP with other uncoordinated traffic. At that point it is not a real time network any more.
What you have basically done is to show everyone that yes, such protocols are a sharp knife –and here is where you can stab someone if you want to kill them.
In this instance you haven’t done anyone any good by publishing these metasploit scripts. In fact, I think Digital Bond has probably done a fair amount of harm by showing poor sensitivity on behalf of researchers to the needs of the ICS community.
I know it is fashionable in the IT world to act as if information is frictionless. I disagree. The movement of data may be nearly frictionless, but education, experience, and the context to use it don’t actually move around so quickly. Your act of publishing that script does accelerate the process; but it does not convey the risks or the potential damage. As I have pointed out before, you have just handed a Molotov Cocktail to the hordes of script kiddies. And now you’re going to bemoan the fact that there are so many old buildings that don’t meet today’s fire codes.
Honestly, I thought you understood the situation better than that.
Hi Jake,
That was Reid’s blog and discussion of “haters”, but I thought it was an accurate response to a lot of the disclosure complaints. In fact Project Basecamp isn’t at all about disclosure as we have repeatedly stated, everyone supposedly knows these devices and protocols are vulnerable. How this continues to be viewed as acceptable, even today, even by people who know how easy it is for a motivated attacker to cause serious damage, I cannot begin to understand.
A point on protocols. The DNP3 Committee, which I know you are quite active on, deserves a lot of credit for starting the effort to integrate security in that protocol years ago. Compare this to ODVA, the EtherNet/IP and CIP group, which has not even started this effort.
Dale
Secure authentication is helpful, but it is not a panacea. It was only last month that we finally approved a new specification that allows for remote key-changes and can use PKI.
We can get away with this because an event oriented SCADA protocol does not operate in real time. If it takes an extra half second to challenge a supervisory command to a remote station, life goes on. It is a SCADA system, not a DCS or a PLC network.
Other SCADA protocols such as IEC 60870 are working toward this goal but I have yet to see that any have been formally adopted. As far as I know, only DNP3 (IEEE-1815) has anything available today.
Other Industrial protocols such as Modbus, CIP, and ProfiNet will need a major update and modifications to enable this to work. Protocols such as DNP3 have an object orientation which makes addition of a new authentication object easy. The latter may not be so easily updated.
Look at how “smoothly” people have been migrating to IPv6. That’s what moving to a secured protocol will be like. It involves major new infrastructure, and fundamentally new designs. There is no way it can happen overnight.
It will take time, education, and lots of investment. Problems with existing real-time protocols are going to be here for a long time to come, even if it receives all the attention and concern that it is deserves.
Jake, you know I respect you as an ICS expert – so please excuse my “provoking” comment:
>Several protocols do what CIP does. They were never intended to see the outside of a real-time network.
>What you have basically done is to show everyone that yes, such protocols are a sharp knife –and here is where you can stab someone if you want to kill them.
If those protocols are only used on isolated networks, releasing an exploit shouldn’t do any harm, should it?
“Other Industrial protocols such as Modbus, CIP, and ProfiNet will need a major update and modifications to enable this to work. Protocols such as DNP3 have an object orientation which makes addition of a new authentication object easy. The latter may not be so easily updated.”
Just as a reminder, nobody forces anyone to use Ethernet to talk to field devices, especially not in realtime. If you think you have problems with authentication and stuff, it might be better to use a conventional fieldbus rather than to rant on researchers who point out that the emporer is naked.
I think this discussion is important because with realtime Ethernet, the industry is just starting to install it on a large scale, so we don’t face the problem of a huge installed legacy base. Bottom line: You install insecure technology in a new project –> you are the one who is responsible, not the whistleblower who points out how insecure it is.
We use CIP. We use ProfiBus. We use Modbus. We use DNP3. I’ve got real skin in this game. I have to live with the limitations and threats every day.
Yes, anyone who installs this stuff on an unsecured network, well, they don’t deserve to get hacked; but they shouldn’t be surprised either. Publishing tools like this to teach kiddies how to hack things they find with Shodan is bad. However, over the longer term, it is also possible to write malware Trojans designed to attack even private networks.
Yes, we use malware detection wherever it is practical. However, the update process, like all update processes, is offline and reviewed. There is an inherent delay before we post any updates to our system. This is the window of opportunity for someone to write malware, and get it in to a utility system. But even if there weren’t a delay, someone still has to discover this malware and write a signature file for it. That takes time too.
I seem to remember that Stuxnet had apparently rattled around various networks for over a year before it was discovered…
I’ll have more to discuss about this on SCADASEC.
Hello all,
I have been speaking with my vendors about this issue…and one of the vendors, HIMA Paul Hildebrandt GmbH + Co KG,
that focuses on Safety Information Systems (SIS) has stated that he sees no problems with their implementation of the ethernet/ip protocol. It is “safe” and this exploit as it is publically explained would only affect in their plc build the communications processor and not the processor that controls any other safety processes. They use 3 processors in the PLC 1 to control communications, the EtherNet/IP protocol, and two for redundancy for the safety relevant processes. He stated that the product that uses this protocol is TÜV tested, but I have spoken with Exida about some of these issues and a lot of their personnel come from TÜV which means that they kind of know the testing strategy. There is no CC testing on the product; rather, they use IEC 61508 as the main standard.
I will post more…later.
for now here is the german explanation of how the Hima HImax PLC is built.
Insgesamt sind 3 Prozessoren verbaut. 2 Prozessoren die den sicheren Steuerungsprozess übernehmen und ein einzelner Prozessor, der die Kommunikation ausführt und damit auch die Schnittstellen verwaltet. Diese „Subsysteme“ sind mittels eine Dual ported RAM rückwirkungsfrei miteinander verbunden. Diese Rückwikungsfreiheit ist eine Anforderung an die IEC 61508 und ein TÜV zertifizierter Mechanismus. Die „Außenwelt“ kann das Doppelprozessorsystem nicht in seiner Abarbeitung beeinflussen. Da ich die Attacke nicht wirklich beurteilen kann (sie ist nicht genauer beschrieben) muss ich unterstellen, dass der Kommunikationsprozessor, so wie es im Artikel beschrieben wird, zum Crash bzw. Reboot gezwungen werden kann. Das bedeutet in diesem Fall, dass die Kommunikation unterbrochen wird, ähnlich wie wenn ein Kabel unterbrochen wird. Aus Sicht der Anlage kann sich daraus ergeben, dass die Steuerung in den sicheren Zustand geht und dadurch z.B. der Prozess gestoppt wird. Ein fehlerhaftes Verhalten im Sinne der Safety ist nicht zu erwarten.
Excellent job!
Without these revelations many manufacturers had continued with their dreams that nothing has to be fixed – ever.
Securing automation network and isolating it from all other networks is nr.1 issue in todays industrial design. The problem is that there is more and more connections between the automation and corporation networks. Even so that corporate Microsoft network is extended to manage operating stations on automation network.
This kind of revelations remind everyone that unhomogenous infrastructure and total isolation are the easiest keys for security.