ProConOS/ProConOS eCLR insufficiently verifies uploaded data.
An unauthenticated, remote attacker could upload malicious logic to the devices based on ProConOS/ProConOS eCLR in order to gain full control over the device.
The identified vulnerability allows attackers uploading logic with arbitrary malicious code once
having access to the communication to products that are utilizing ProConOS/ProConOS eCLR.
Attackers must have network or physical controller access to exploit this vulnerability. This
vulnerability affects all versions of ProConOS/ProConOS eCLR and MULTIPROG from Phoenix
Contact Software (formerly KW-Software).
Manufacturers using ProConOS/ProConOS eCLR in their automation devices are advised to
check their implementation and may publish an advisory according to their product.
Users of automation devices utilizing ProConOS/ProConOS eCLR in their automation systems
may check if their application requires additional security measures like an adequate defense–
in-depth networking architecture, the use of virtual private networks (VPNs) for remote access,
as well as the use of firewalls for network segmentation or controller isolation.
Users should check their manufacturers security advisories for more adequate information
according to their dedicated device.
Users should ensure that the logic is always transferred or stored in protected environments.
This is valid for data in transmission as well as data in rest. Connections between the
Engineering Tools and the controller must always be in a locally protected environment or
protected by VPN for remote access. Project data shouldn’t send as a file via e-mail or other
transfer mechanisms without additional integrity and authenticity checks.
Project data should save in protected environments only.
Generic information and recommendations for security measures to protect network-capable
devices can be found in the application note.
This vulnerability was reported by Forescout.
We kindly appreciate the coordinated disclosure of this vulnerability by the finder.
PHOENIX CONTACT thanks CERT@VDE for the coordination and support with this publication.