It is hard for me to write it any better than 3S, from their site:
In general, we do not offer any standard tools in CODESYS which are to protect the controller from a serious cyber attack. Should the offered password functionality suggest such a protection, this was definitely not our intention. The implementation of standard security mechanisms (firewall, VPN access) is an absolute must when operating a PLC runtime system on a controller accessible through the internet.
This statement is accurate, but a completely foolish position to take as a software vendor. So an attacker that has network access to a device with your software has the ability to get application command shell, upload and run any files they want, compromise the integrity and availability of the process, and pivot from the PLC/controller and attack the rest of the ICS.
Equally ridiculous is the fact that 200+ ICS vendors implemented the CoDeSys runtime and 3S never felt any obligation to point out that the authentication you see in the application is only client side and not passed to the server. BTW, this is common in the ICS world. Another pertinent example is Rockwell Automation’s FactoryTalk. Or that a company selling a library never felt any compunction to provide security related application guide.
The brief 3S statement also alludes to this problem affecting Version 2.3 with the unwritten implication that it does not affect Version 3. The system in our lab is Version 2.3, but we had access to a few other systems and all were vulnerable save one vendor solution that implemented their own security envelope to require authentication. Since 3S did not “offer any standard tools in CODESYS to protect the controller” we believe all versions lack authentication to access the application command shell, transfer files, change logic, … And remember that the application usually runs as a highly privileged account directly on the OS.
Reid pointed out the big endian / little endian issue with his tool. So even if the tool does not work on your particular CoDeSys implementation, it still likely is vulnerable. Every vendor may implement it slightly different, so a universal tool is unlikely to work on every product. You should assume your version is vulnerable unless the vendor has specifically implemented their own authentication or other security measure to limit access to the CoDeSys ladder logic runtime software on the PLC/controller.
It’s an ugly problem now with 200+ vendor implementations and a large and diverse deployed base. Even if 3S offers a patch, they need to go the extra mile and start tracking what vendors have implemented the fix.
Tenable Network Security put out a Nessus plugin to detect this vulnerability. Again given the large number of vendor implementations I would expect a significant number of false negatives. Still they did what they could and deserve kudos.
Oh … its nice to see on the CoDeSys page that Sandvik Mining and Construction Drill Rigs are running CoDeSys. Hit refresh and you will see a bunch of other companies using the product that does not “offer any standard tools … to protect the controller”.
And if you can take one final comment – it shows the power of threat modeling. The vendor we know that is not vulnerable (or at least significantly less vulnerable) to this threat put in security controls because they found this problem during threat modeling. I wasn’t there for the process, but just finished a detailed threat model project. This would have jumped out when the entry points were listed.