CoDeSys, a piece of software running on industrial control systems (ICS) from over 200 vendors contains a vulnerability that allows potential attackers to execute sensitive commands on the vulnerable devices without the need for authentication, according to a report from security consultancy Digital Bond.
The vulnerability was discovered by former Digital Bond researcher Reid Wightman as part of Project Basecamp, an ICS security research initiative launched by Digital Bond last year.
[ Also on InfoWorld: ICS-CERT warns of SSL security flaw in RuggedCom industrial networking devices. | Learn how to greatly reduce the threat of malicious attacks with InfoWorld's Insider Threat Deep Dive PDF special report. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
Described as a design issue, the vulnerability is located in the CoDeSys runtime, an application that runs on programmable logic controller (PLC) devices. PLCs are digital computers that control and automate electromechanical processes in power plants, oil and gas refineries, factories and other industrial or military facilities.
The CoDeSys runtime allows PLCs to load and execute so-called ladder logic files that were created using the CoDeSys development toolkit on a regular computer. These files contain instructions that affect the processes controlled by the PLCs.
According to the Digital Bond report, the CoDeSys runtime opens a TCP (Transmission Control Protocol) listening service that provides access to a command-line interface without the need for authentication.
The company has created and released two Python scripts: one that can be used to access the command line interface and one that can read or write files on a PLC running the CoDeSys runtime. There are plans to convert these scripts into modules for Metasploit, a popular penetration testing framework.
Depending on the PLC model, the command-line interface allows a potential attacker to start, stop and reset PLC programs; dump the PLC memory; get information about the tasks and programs running on the PLC; copy, rename, delete files on the PLC filesystem; set or delete online access passwords and more.
CoDeSys is developed by a company called 3S-Smart Software Solutions based in Kempten, Germany. According to the company's website, the software is used in automation hardware from over 200 vendors.
The vulnerability and scripts were tested on only a handful of products from the 261 potentially affected vendors, Digital Bond founder and CEO Dale Peterson said Thursday in a blog post. One of those PLCs was running Linux on an x86 processor while another was running Windows CE on an ARM processor.
"This attack can be used not only to control the PLC but also to turn the PLC into an 'agent' to attack other devices in the network," Ruben Santamarta, a security researcher from security firm IOActive, said Friday via email. Santamarta found vulnerabilities in industrial control systems in the past as part of Project Basecamp.
"We are aware of this security issue," Edwin Schwellinger, support manager at 3S-Smart Software, said Friday via email. "A patch is under development but not released. We are working with high pressure on these issues."
The vulnerability is only exploitable by an attacker who already has access to the network where the PLC runtime operates, Schwellinger said. Runtime systems should not be accessible from the Internet unless additional protection is in place, he said.
"Quite a few vulnerable CoDeSys systems are Internet-exposed," Reid Wightman, who now works as a security consultant for IOActive, said Thursday on Twitter. "Some found via shodan [a search engine], some found via custom scanning."
"No PLC should be accessible from the Internet ever," Santamarta said. However, many networks are compromised via advanced persistent threats -- malware that provides attackers with local network access -- and in those cases the perimeter doesn't matter anymore, he said.
"As much as possible avoid to expose PLCs and PLC networks to public networks and Internet," Schwellinger said. Customers should use additional security layers like virtual private networks (VPNs) for remote access, should install firewalls and should restrict access to sensitive networks only to authorized people, he said.
"Anything related to the SCADA [supervisory control and data acquisition] environment is a serious matter," said Luigi Auriemma, a security researcher at vulnerability research firm ReVuln who previously found and disclosed vulnerabilities in SCADA systems, via email Friday. "If you can control the PLC then you can control the infrastructure."
For example, after infecting PLCs at Iran's Natanz nuclear fuel enrichment plant, the Stuxnet malware altered their programming and destroyed around 1,000 uranium enrichment centrifuges. The attack is believed to have set back Iran's nuclear program by up to two years.
Fortunately, there are some workarounds that vendors can implement in the absence of an official patch.
"The tools do not work on at least one of the vendor's products, who chooses to remain anonymous," Peterson said. "The vendor has a security development lifecycle (SDL) that included threat modeling. They identified the threat of uploading rogue ladder logic and other malicious files, saw that this was not addressed by the CoDeSys runtime, and added a 'security envelope' around the runtime. So basically the user, or attacker, is required to authenticate before he can gain access to the port the CoDeSys runs on."
Meanwhile, users of the affected products can implement network segmentation, access control lists, firewalls and intrusion prevention systems, Santamarta said.