more quick actions
minimize quick actions
General
3
Posts
2
Users
0
Likes
19
Views
Topic starter
On 11th August 2023, there was a report done by Microsoft regarding the vulnerabilities present on PLCs that runs on the CoDeSys platform for programming.
The vulnerabilities include the risk of Denial of Service (DoS) and Remote Code Execution (RCE).
That means that the owner of the PLC can be locked out of the device and bad actors could program the PLC to perform hazardous tasks which might endanger people or certain operations.
While it does not affect PcVue, but at the same time, wouldn't this "vulnerability" be the same in PcVue as most of our configuration file, and even SCADA Basic files are exposed as plain text?
Posted : 15/08/2023 2:34 pm
Hi Andy,
To my knowledge, researchers found these vulns by studying the codesys protocol and doing a good bunch of reverse engineering on 2 firmware. These vulns are 'classic' buffer overflows, and have little to do with access/modification of files.
Because physical access to computers running PcVue should be limited to legitimate users, it is generally considered that potential access to files is Ok if done locally (except some that contain highly sensitive information and are already ciphered).
It is also true that an attacker could leverage other vuln(s) of the system to gain access from a remote endpoint and then access/modify such files. In practice, it means overcoming at least 2 barriers. The remote access first (overcome network segmentation, VPN, firewall...), and the authentication (to gain access to files with the identity of a legitimate user). It is the kind of attack that can only succeed in a scenario where attackers are highly motivated and full of resources.
It does not mean we are not thinking about limiting the risks of such a scenario.
Posted : 16/08/2023 8:59 pm
Hi,
To correct/extend my post from yesterday, the link Andy provided relates to a series of vulns discovered by Microsoft and they are not linked to file permissions. But he was true in that 2 other vulns were disclosed in the same timeframe by other researchers. And they are related to local access to the filesystem and user permissions considered weak.
https://cert.vde.com/en/advisories/VDE-2023-021/
https://cert.vde.com/en/advisories/VDE-2023-024/
To elaborate on what I wrote, how far the local user should be trusted ?
It is our duty to make sure it is not possible to trick the system without a clue for the user or the admin - Any weakness that can be leveraged remotely without user interaction is obviously something to fix.
It is our duty to make sure it is not possible to trick the legitimate user - Any weakness that can be leveraged locally or remotely with a user interaction is obviously something that require our attention. In particular because many human errors can fall here (the bad click from a legitimate user, with or without a bad actor).
Many other cases are not so easy to classify, and we quickly end up in a philosophical discussion. If, as part of a risk analysis or per policy, an entity operating a system does not want to consider legitimate users with local access as well trained, competent and non-hostile, then there is little you can do to protect a system. Because such legitimate users with local access can break operations in many ways that are much easier to leverage than a software vuln. Think powering off, unplugging a couple of cables, a screwdriver in-between gears or simply not reacting to alarms or downgraded process situations. If one does not train nor trust its legitimate users, no action plan works as part of risk management 😉
Posted : 17/08/2023 2:26 pm