Vulnerability Inheritance in PLCs – CoDeSys V3 Edition

At last week’s S4xJapan conference, I gave a talk about insecure-by-design vulnerabilities inherited in PLCs, and provide two vulnerable Japanese PLC vendors as examples of those inheriting security issues.

During the talk, I am speaking purposefully slowly — the conference was being simultaneously translated into Japanese and it was important to allow the translators time to catch up.

Inheriting insecure-by-design vulnerability problems is particularly troublesome.  In the talk, I look at two Japanese vendors who have inherited vulnerabilities from third-party software.  In both cases, it appears that the vendors affected are either unwilling (Sanyo Denki) or unable (Hitachi) to fix their systems.  Even if they would or could produce patches for their PLCs, external software dependencies mean it is unlikely that anyone will actually apply those patches.

Sanyo Denki is actually the more interesting case to me, because the same hardware and firmware is in use by many vendors. Their SanMotion C controller is used primarily for servo-actuated robotic arms.  While that isn’t likely to be critical infrastructure to the general public, it is likely a critical system to a manufacturer that relies upon a robot arm in its manufacturing process.

I’ve said this before — 3S Software is in a unique position in the industry.  Hundreds of vendors run their PLC ladder logic runtime.  I wish that 3S Software would introduce some security into the runtime, for example integrating authentication against a RADIUS server or other network management server, and add proper protocol integrity (encryption or at least message signing). They could revolutionize the industry and become the secure logic runtime of choice for security-concious vendors. But…in the words of Ellie Arroway…that continues to be my wish.

There were some fun challenges in making a tool to speak the newer CoDeSys V3 protocol. Continue reading for a little bit of reverse engineering and code-gawking that didn’t end up in my talk.

One of the items that I did not delve into in the talk is an interesting bit of faux-object-orientedness in the CoDeSys V3 protocol.  I mention in my talk that the CRC algorithm took a bit of time to figure out.  There were several CRC algorithms defined in the CoDeSys V3 Gateway Service including CRC32 (which is what is used), but no cross-references to those functions in the binary.  It turns out that CRC selection is performed using the protocol itself:

 

The 4th byte of the protocol packet (which is always 0×40 in the protocol samples we observed) is used as an index into a data structure in memory.  The data structure element loaded is a function pointer, which ends up being call’ed.  I only point this out because the 3S-Software people are a bit crazy for implementing their protocol parser this way.  Sending a value other than 0×40 (but less than 0×41, since there is a check for that) can cause an application crash here, as several of the ints stored in the data structure are non-memory-mapped values (some of them are also non-null, which thankfully is checked).  The result is that the application may end up call’ing 0×01 or some other non-memory-mapped value, which would cause a crash on Windows.  It may end up exploitable in the RCE sense, as well.

The CRC selector is not unique in this regard — there are other portions of code that I would expect to see disassembly xrefs to, and don’t.  I suspect that other portions of the protocol rely on this data structure message-passing.  I never got the sense that the V2 protocol worked this way, although it might be interesting to go back and re-explore some of the functionality of that protocol armed with new knowledge.

Given the way that ICS protocol fixing works, my guess is that 3S Software will quickly fix the crash bug outlined above (the bug exists in their PC software’s “Gateway Service” executable).  I imagine that they will take forever to fix the insecure-by-design portions of the protocol for the PLC, though.  Not that I can blame them — 3S-Software (eventually) produced a patch for the V2 PLC runtime to enforce password protection, but to date, 0 vendors have released updated firmware to incorporate even plaintext password protection on the V2 runtime.