It started with Bryan Owen’s reply to a tweet.
Why after all these years of CODESYS security fails, although one could contend they are no worse than their peers, do so many asset owners have no idea that the core functionality of their PLC is CODESYS? SBOMs would address this, and we shouldn’t wait for SBOMs for asset owners to know if they are in some sense using a private labeled CODESYS PLC.
In 2012/2013, when Reid Wightman first found CODESYS security issues and put out Metasploit modules, I had hoped that ICS-CERT would take on the mission of identifying the 261 PLCs with the CODESYS runtime. This may not have been fair. The manpower required to identify and map software component vulnerabilities to products is a large effort as the SBOM projects and products are demonstrating.
There is a Pareto Principle in play with software components. Tracking a small number of components could have an outsized impact in understanding and mitigating risk. CODESYS runtime, Triangle MicroWorks DNP3 stack and SISCO’s ICCP stack are three examples.
CISA and the newly formed JCDC decided that Log4j was one of those small number of high and widespread impact vulnerabilities that warranted special effort. CISA put up a Log4j web page and more importantly a community sourced GitHub repository of affected devices and services. Many ICS vendors added their products into this repository, see Rockwell Automation here. This was a clear information sharing win.
Reid responded quickly to my request and put up a few products on his ReidMeFirst GitHub. And there were no further contributions for 8 days.
Perhaps this is a good chance for CISA to step in and give a task to the newly formed JCDC ICS. Use the Log4j GitHub as a model. Encourage the JCDC ICS members to lead the way with what they have (ICS vendors) and what they know (ICS security vendors). Put up the automated tools, with permission, to detect and identify versions of CODESYS. Show us that meaningful information sharing is possible in the ICS community.
———-
This would also be a good counterpoint to the limited information sharing on INCONTROLLER / PIPEDREAM. It is unclear why we are not seeing Yara rules. Why samples aren’t being made available to proven reliable researchers and companies. Why there is so much confidence it has not been “employed”, and some have said not deployed, even though these effective detection tools are not widely available.
I remember when Sean McGurk testified to Congress in 2010 about Stuxnet after Ralph Langner and Symantec had put out details on Stuxnet’s fingerprinting and then modifying a specific process. What he said made no sense. Of course it didn’t because he couldn’t let on that this was US created malware aimed at Iran. I’m not claiming INCONTROLLER / PIPEDREAM is another US or US/Israel creation, just that it raises the same feeling that what we are being told and actions that are being taken seem odd and possibly big parts of the story are not yet known. The opposite of information sharing.