The Rockwell Automation vulnerabilities that Rubén Santamarta uncovered for Basecamp were in my opinion the most challenging and interesting in the entire project (the very close second-place device being the Koyo). I say that because the protocol is something that a normal security researcher has never seen before. I threw my hands up in surrender at learning GE’s LogicLinx protocol, for example, but Rubén and our anonymous researcher didn’t back down from their device’s control protocols. Rubén reverse engineered Rockwell’s firmware, software, and read up on the configuration protocol to discover some fascinating design issues. I highly recommend checking out his official report here.
These issues have the potential to affect every product that implements the EtherNet/IP (CIP) protocol, not just Rockwell. Schneider, Wago, and a number of other vendors will be affected by most of these problems. ICS-CERT is probably going to need to issue a new advisory. For a complete list of affected vendors, check out the member list at ODVA, the organization which is responsible for defining the protocol.
Rubén even went so far as to write C code covering the design issues, which we hope to build into a Metasploit module for our mid-February release.
These requests can all be performed without authentication:
1) The PLC CPU can be placed into STOP mode, meaning that it won’t execute ladder logic any longer.
2) The PLC CPU can be crashed using a malformed request.
3) The Ethernet card can have a new firmware uploaded.
4) The Ethernet card can be crashed using a malformed request.
5) The IP address of the Ethernet card can be changed.
Combining these attacks can cause an interesting conundrum for operators: Place the CPU into STOP mode and then crash the Ethernet card (or just change its IP address), and an operator is going to have to walk up the system to even determine what the problem is — an attacker can easily cause a loss of control and loss of view scenario. Uploading a new Ethernet firmware may even allow an attacker to bypass the password protection system completely (assuming that authentication is checked in the Ethernet module…we’re not sure at this point).
Issues 2 and 4 are less of a concern than 1, 3, and 5. Issues 2 and 4 are just implementation mistakes that can be patched. Issues 1, 3, and 5 are actually defined by the CIP specification as not requiring a password to perform. Fixing them is going to require a sit-down between at least a half-dozen companies to decide on how to fix the protocol. Fortunately the change should be easy: simply require that a CIP session is authenticated before these requests are allowed. A future challenge is going to be that EtherNet/IP is not encrypted: I can sniff a session and, if that session is authenticated, spoof a CPU STOP message using the session identifier.
The decisions made when designing this protocol truly show the cost of “insecure by design.” Fixing it is going to be expensive at many levels: numerous vendors will have to spend time and money just to agree on a new standard. Those companies are then going to have to implement the new standard, and to backport the new standard to existing devices — or make the decision to leave existing systems vulnerable to attack. Application software will have to be modified to require authentication for those operations, and the software will have to deal with legacy systems that aren’t patched. Finally, end users are going to have to upgrade their application software. This cost is placed on the OVDA members, the firmware and software development teams, and the end users.
A number of LogicLinx devices can be found using Shodan, making this a pressing issue for quite a few users, whether they know it or not.
So you’re expecting the asset owner to configure a password in each of the thousands of devices he has in his application?
And you think he’s really going to do that?
And you further think that encrypting real-time, low-latency communications is going to meet his application needs?
Anon -
Question: Google has millions of computers. Did they give up on managing the passwords in all of the millions of devices that they own?
Answer: No. They use a password management system (LDAP/Active Directory, probably, but IANAGE I Am Not A Google Employee).
PLCs are just servers. They speak IP and don’t have a screen and keyboard. We need to get over the fact that they’re somehow special.
As for encryption, there are already low-latency, relatively low-cost solutions for encrypting communication. It may not work for everyone, but it will help for some. Also: ladder-logic is real-time and doesn’t have to worry about the crypto. Input from an HMI is definitely not real-time, unless someone has replaced your operators with robots (and if so, why not just program whatever the robots are doing with some 61131?).
Reid
go spend some time working on an actual industrial application in a real end user setting, in more than one different industry, and then report back. until then your credibility is quite low.
foobar|anon,
Digital Bond has over a decade experience with actual industrial applications in different industries. Reid has worked several years for a vendor.
Hiding in anonymity is not a sign of outstanding credibility, either..
Perhaps the ‘credibility’ comment is a bit unfair. But it should be clear that there are significant differences between Google’s server farm and a pharmaceutical manufacturing plant. In the latter case you can expect to have someone with a HS degree who has to fix something when it breaks, not a skilled IT staff. What do you think happens when the process stops and the next widget can’t be made? Does the plant manager care more about security or that his boss is screaming because things aren’t working?
And where you also have equipment that is perhaps a decade old. Or more. That the asset owner is not willing to rip out and replace. What is this “low latency encryption” that would work in such equipment? And obviously applications are more than just PLCs and robots, right?
… and since when is anonymity an issue? (if it is then you’ve got a problem with an entire community. I mean … you’ve heard of “Anonymous”, right?)
The simpler solution is to not expose your control networks to the outside world. Keep them isolated.
Have you guys taken a look at devices such as Omni Flow Computers, TotalFlow flow computers, or Fisher ROC’s. All of these devices are used for custody transfer of natural gas and/or crude oil (and I’m sure other gases and liquids).
Wouldn’t you have to be inside the company firewall to implement any of these hacks?
Michael – we have not looked at those devices as part of Project Basecamp. They are popular in the gas and liquids as you mention and are worth a look.
Logical access is required for any of these insecure by design issues or vulnerabilities to be compromised. For most SCADA and DCS this does mean access to a system on the corporate network that is allowed through the SCADA/DCS security perimeter or direct access to the SCADA/DCS.
Of course there are few in percentage but still large in number ICS that are Internet connected. Eireann is working on a Shodan post on the number of accessible Basecamp systems.
Dale
KF is correct! Automation control systems should not be Internet connected. Many, if not most are not. Eñterprise historians and other information systems generally gather data on a different/isolated networks, and publish that data via webservers over protected networks.
The immediate solution is simple. Isolation.
In an ideal world, KF is right, keep them away from the rest of the world.
In reality you have to put them on the external network as someone wants to remotely monitor the process or gather statistics.
It was ok in the olden days when you could only program them locally via a specialised cable, but in these days of interconnectivity, its not so simple.