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.