20 April 2022
Vulnerability in ICS: assessing the severity
On the last day of March 2022, Claroty (Team82) published an article on two vulnerabilities they had identified in Rockwell Automation products:
- CVE-2022-1159 – a vulnerability in Studio 5000 Logix Designer software that could allow an attacker to inject code into a PLC project during its compilation;
- CVE-2022-1161 – a vulnerability in ControlLogix controllers that could allow attackers to modify compiled code on a PLC without modifying the source code.
Both vulnerabilities have sufficiently high CVSS 3.1 scores, 7.7 (High) and 10.0 (Critical), respectively. Information about them is being actively discussed by mass media and experts. However, we believe that the severity of these vulnerabilities has been significantly exaggerated. At the same time, the most dangerous vulnerability in the same Rockwell Automation products has remained unnoticed by the public and owners of vulnerable products for years.
What’s wrong with information on these vulnerabilities
Let’s have a closer look at these vulnerabilities.
As mentioned above, the vulnerability could allow an attacker to modify compiled code of a user application downloaded to a PLC. According to the researchers, an attacker needs administrator access to exploit this vulnerability.
- An attacker requires local access with elevated privileges to a computer with Studio 5000 Logix Designer;
- User interaction is required since the modification takes place while the application is being compiled by an engineer;
- The attack results in a complete compromise of the confidentiality, integrity, and availability of the PLC to which the compiled application is downloaded.
However, according to CVSS v3.1: Specification Document:
Since administrative access to an engineering computer enables an attacker to completely compromise the confidentiality, integrity and availability of a PLC anyway, e.g., by modifying network traffic, all impact metrics for this vulnerability should be set to None.
In other words, we disagree with the high severity score assigned to this vulnerability, assess the vulnerability as insignificant and suggest that the value 0.0 (None) should be used as the severity score for CVE-2022-1159.
The second vulnerability, which the researchers treat as a “Stuxnet level” flaw, affects ControlLogix PLCs.
A PLC stores both the source code and the compiled code of an application. Both are changed when loading an application using standard tools in such a way as to ensure that the two copies of the code match. The vulnerability could allow an attacker to replace compiled code without changing the source code. This offers the attacker additional capabilities related to preventing engineers from identifying unauthorized modifications of an application on a PLC. That’s really an unpleasant vulnerability!
Rockwell Automation has assigned this vulnerability a CVSS 3.1 base score of 10. The vendor provides the following CVSS vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. It means that, according to Rockwell Automation, an attacker could completely disrupt the operation of a vulnerable PLC remotely and without authentication.
Let’s have a closer look at this severity assessment.
First of all, to ensure successful exploitation, an attacker must have rights related to downloading an application to the PLC. However, given such rights, the attacker could do very serious damage without exploiting any vulnerabilities.
This requirement can be bypassed by exploiting another vulnerability, such as CVE-2021-22681 (see below). However, this in itself shouldn’t be used to artificially exaggerate the severity of CVE-2022-1161: CVSS v3.1: User Guide specifically mentions that CVSS is designed to classify and rate individual vulnerabilities.
Secondly, the vulnerability could allow compiled code of an application to be replaced without changing the source code, which means that it affects the integrity of information used by engineering software. At the same time, it does not affect the confidentiality or availability of the engineering software itself.
We believe that, in all fairness, the severity score for this vulnerability should be decreased from 10.0 (Critical) to 6.8 (Medium) and the CVSS vector string should be as follows: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N.
As mentioned above, the publication of information about these vulnerabilities was widely discussed. Both flaws are definitely interesting from the technical viewpoint and they were bound to draw the attention of researchers. However, when evaluating the severity of a vulnerability, a careful analysis of the necessary conditions for its exploitation is a must – otherwise owners of vulnerable systems will not be able to assess the risk associated with the vulnerability correctly.
For the two vulnerabilities discussed above, the danger has been exaggerated.
We would like to draw the attention back to another vulnerability affecting the same Rockwell Automation products. We believe it has been seriously underestimated by owners of vulnerable systems – in fact, we believe it to be the most dangerous of all known vulnerabilities affecting these products.
Most dangerous vulnerability
On September 20, 2017 Kaspersky ICS CERT notified the Rockwell Automation product security team of a vulnerability in the authorization mechanism used in several lines of Rockwell Automation controllers, including safety PLCs. The vulnerability could allow a remote unauthenticated user to perform any operations with Rockwell Automation PLCs and safety controllers. The vulnerability was assigned the CVE-2021-22681 ID number.
Unlike the vulnerabilities discussed above, CVE-2021-22681 requires no privileges to exploit and leads to a complete compromise of the device. It has the severity score of 9.8 (Critical) and its CVSS vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Why we believe this vulnerability is so important
First of all, 4.5 years after being notified of this vulnerability, Rockwell Automation has not come up with a way to fix it. This is why the Mitigations section lists only mitigation measures but not security updates fixing the vulnerability.
That’s because this is an architectural issue related to the way in which the network communication protocol used by the entire controller family is designed. Such flaws are usually very hard to correct, because any changes to the protocol can lead to compatibility issues that are often impossible to resolve. It should also be noted that the problem faced by Rockwell Automation is far from being unique. For example, a similar situation occurred with Schneider Electric’s Modicon family of devices (CVE-2021-22779).
Second, the vulnerability is very easy to identify. Two more independent teams, including Claroty, have identified it after us. This increases the chances of it being exploited by threat actors.
Compared to the two vulnerabilities recently reported by Claroty, CVE-2021-22681 has a much more serious impact. If a system is affected by this vulnerability, it makes no difference whether it’s also affected by CVE-2022-1159 or CVE-2022-1161, because CVE-2021-22681 enables an attacker to achieve the same or even more adverse effects as the other two vulnerabilities, but much more easily.
However, for some reason, CVE-2021-22681 has not been as widely discussed as the vulnerabilities reported by Claroty. Vulnerable system owners underestimated the danger, as well. Although they should have taken mitigation measures to neutralize the vulnerability, we can see that they haven’t done this.
At the time of writing, Censys and Shodan search engines listed 515 and 6793 available devices, respectively, that have port 44818/TCP (the port on which CVE-2021-22681 is exploited) open and have the word Rockwell in the descriptions of headers or other fields. Of course, some of the devices found are almost certainly honeypots (designed to attract or lure attackers). However, a large proportion of these devices are controllers.
In other words, some of the vulnerable Rockwell Automation devices can probably be attacked directly over the internet, without any long or complicated chains of compromise – because these devices are available online.
System owners should spend their time and energy on measures designed to reduce the threat of CVE-2021-22681 exploitation, at the very least on making vulnerable devices unavailable online, rather than on fixing CVE-2022-1159 and CVE-2022-1161.
We chose CVE-2022-1159, CVE-2022-1161, and CVE-2021-22681 to demonstrate the importance of the quality of information on vulnerabilities in OT products and technologies. The issues that we have described using these vulnerabilities as examples are typical of information on vulnerabilities in many vendors’ products.
When assessing any vulnerability, it is essential to carefully analyze the conditions required to exploit it and properly assess its severity.
This information should be useful from the practical viewpoint – it should help owners of vulnerable systems to make accurate assessments of the threat level and to take measures to reduce it for their facilities (we all know that fixing all vulnerabilities in the systems in a timely manner is a challenging task and only a few ICS owners are able to do it).