The Global State of Security in Industrial Control Systems: An Empirical Analysis of Vulnerabilities around the World

Typically, an industrial attack consists of three stages [11]. These stages are schematically depicted in Figure 2.

At first, an IT layer has to be breached. This IT layer can constitute the public-facing website of an organisation or resources reachable from the intranet. Social engineering is the most common and most successful form of breaching the IT layer, e.g. with spear-phishing [12]. Employees are tricked to open malware-infected resources by valid-looking e-mails or documents, thus enabling an attacker to infect their computer. Other, technology-based attack vectors on web-resources are collected and rated by the OWASP Foundation [13].

After an attacker has successfully breached this layer, traversal to the ICS plane is required, where control and monitoring of the OT devices and their tasks occurs. Here, the attacker can exert influence on the OT devices and tamper with the process description in acts of sabotage. Furthermore, theft of sensitive or protected information can occur at this place as well as acts of espionage and theft of intellectual property.

The third level in this taxonomy is the physical layer. As the OT devices in industrial applications are constituting Cyber-Physical System (CPS), actions in the digital domain lead to actions in the physical domain. For example, controlling an automated drill will result in holes drilled in whichever material finds itself below the drill. This has strong implications on the security and safety of OT devices, as this influence on the real world allows attackers to inflict property damage and potentially deadly injuries. Several well-known cyber attacks on ICSs, e.g. the Triton-malware [14], the power outage in the Ukraine during December of 2015 caused by the malware BlackEnergy [15], and Stuxnet [11], disrupted the physical process in order to achieve their goal. The fact that OT devices and networks were not designed with security in mind [1] motivates the requirements to place OT devices in internal networks. If access to public networks is given, the risk for cyber attacks is drastically increased.

According to the Lockheed Martin cyber kill chain [10], reconnaissance is the first stage of a cyber attack. It is performed to gain information about the intended target. The first step of reconnaissance, passive scanning, is a passive activity in the sense that no action is taken by the attacker to influence or interact with the system under investigation. Instead, public resources are employed and information is collected. Examples are methods such as GEOgraphic INTelligence (GEOINT) and OSINT, for example whois domain enumeration, analysis of Google Maps images, or mail and Pretty Good Privacy (PGP) server queries. Gathering information from social media and business networks is a means of OSINT-based passive scanning as well. In summary, every activity aimed at gathering information about the intended target without the target having any chance to learn about it is called passive scanning. Penetration testers, i.e. hackers that test the security of networks, as well as criminals commonly put much effort into passive scanning as it is possible to obtain valuable information to be used in the exploitation without alerting the target. In the course of this work, Shodan [16] is used as a passive scanning tool. Shodan is an Internet-based search engine that scans every device connected to the Internet and provides an interface to query this information. This feature explicitly extends to security- and privacy-relevant devices such as IP-cameras, IoT devices as well as ICS devices, just to name a few.

Active scanning, in contrast to passive scanning, is performed with actively engaging target systems, such as host discovery and port scanning with network scanners like nmap [17]. In active scanning, an attacker actively queries the target systems in a fashion that the interaction is traceable. Therefore, active scanning is performed less extensively than passive scanning as it can warn a potential target about malicious activities.

Assessment of vulnerabilities in ICS and OT components from an attacker’s point of view has not been performed in literature, to the best of the authors’ knowledge. However, a variety of research addresses threats and risks for ICSs. Gonzales et al. performed an empirical analysis of security weaknesses in ICSs, based on disclosed vulnerabilities [18]. This approach is somewhat similar to the approach performed in this work, however, the evaluation of how many of these vulnerabilities can actually be found in the wild is not performed by Gonzales et al.. Results of this analysis seem to correlate with the findings of this work, however, the angle of analysis is different. Thomas and Clothia categorise types of vulnerabilities based on historic SCADA vulnerability data [19]. Based on this knowledge, recommendations on how to predict and protect against future vulnerabilities are proposed. In contrast, this work underlines the danger of well-known vulnerabilities. As long as old vulnerabilities are not fixed, they remain a threat to the organisation, and our research shows plenty of old vulnerabilities. Knowles et al. evaluate known vulnerabilities, analyse the state of security in different industries and discuss methods and obstacles for introducing security measures in industrial environments [20]. Similarly, Sullivan analyses and evaluates attack vectors based on known attacks and introduces mitigation methods after elaborating differences between ICS and IT systems [21]. A discussion on potential attacks on CPSs from a theoretical control perspective is presented by Ding et al. [22]. Humayed et al. present a survey of existing research on CPS security from different points of view: the security perspective, the CPS perspective, and the perspective of the system the CPS is embedded in [23]. The cybersecurity landscape of ICSs is analysed by McLaughlin et al. [24]. They evaluate the concepts for ICS security, consider past cyber attacks on ICS, and provide an assessment for ICS security while looking at current test beds and trends in attack and defence methods. Holm at al. put a focus on test beds for analysing attacks on and vulnerabilities of CPSs [25]. Abe et al. evaluate the threats for ICSs that are reachable from the internet, based on observations in Japan [9]. They explain how Internet-reachable ICS-devices can be found and exploited, without providing a quantitative overview and limited to Japan. Successful and attempted attacks on ICSs are evaluated based on surveys by Luallen [26]. Additionally, certain aspects of ICS and IIoT infrastructure are addressed in research. Testbeds, which can be used to research vulnerabilities, their exploitation and defences, are presented by Mathur and Tippenhauer [27], Gardiner et al. [28], Gao et al. [29], and Hahn et al. [30]. Skopik et al. evaluate threats and vulnerabilities in smart metering, which brings ICS into the houses of users [31]. Plosz et al. as well as Reaves and Morris discuss vulnerabilities in wireless ICS communication by analysing the protocols for weaknesses and providing recommendations for securing the wireless communication [32, 33]. Additionally, established security security research organisations regularly publish whitepaper containing statistics about ICS vulnerabilities, such as Kaspersky [34], Positive Technologies [35], and the Control Systems Security Program of the National Cyber Security Division [36]. Such reports are based on statistical information obtained from organisations employing ICS equipment, or from studies of vulnerabilities. In contrast to this work, such studies rely on the participation of affected organisations and can only report incidents which have been disclosed.

In this section, several decisions made for the evaluation are introduced. These decisions influence the results of the analysis, while being necessary due to imperfections of the real world.

Exposing PLC devices to the Internet is not recommended, it is expected that a significant number of ICS devices is not connected to the Internet. Thus, large amounts of false negative results are expected, i.e. devices that are operating in ICSs environments, but are not found by Shodan. This is expected as the given survey aims specifically at those ICS devices that are connected to the Internet. On the other hand, false positives are expected as well, for two reasons. First, some devices might be configured in a way that they do not use a TCP or UDP port in the standardised way. Every query, as discussed later on, relies on the port number in order to identify communication protocols. Non-standardised usage of said ports can introduce false positive as well as false negative results. However, each query has additional aspects and the results are further analysed. Ports are used as an initial indicator for potentially vulnerable devices. After they are discovered, additional information, such as server banners with descriptions of the running services and versions, are employed to ensure the correct analysis of the device. Also, further insight from other ports on the same device are taken into account, for example web services with an HTTP banner. Thus, false positives due to non-standardised usage of ports are expected to not have a significant influence on the result. Second, some organisations employ honeypots, e.g. Conpot, that are capable of mimicking ICS protocols. A discussion of honeypots in ICS devices is presented in Section V.

Furthermore, many vulnerabilities correspond to specific firmware versions, while later versions patch the given vulnerability. Some vendors might patch old firmwares as well without changing the version number, making these vulnerabilities obsolete. This might lead to false positive results. However, we have found no evidence of such practice during this research. Additionally, there are cases where web services are vulnerable and the security advisory of the vendor advises network segmentation, firewalling and deactivation of services. These services are considered vulnerable in the course of this work. Furthermore, the results are presented in tables which contain the CVEs as well as the conditions required to be vulnerable and an indicator of how well the vulnerability to a CVE can be derived. The indicator is a circle with the following meaning:

• •

  ●: yes - The susceptibility to a vulnerability can be derived with certainty on measurable features

• •

  ◐: partially - The susceptibility to a vulnerability can be guessed based on sound assumptions

• •

  ○: no - The susceptibility to a vulnerability cannot be derived with certainty based on the available information

The selected devices, which were presented in Section III, were queried with the Search Engine Shodan [16] in an iterative fashion. A schematic overview of the process is shown in Figure 3.

First, the query to search for was designed by manual inspection and interaction. In this work, five PLC series from different vendors were analysed. The corresponding queries were meant to catch any device that fits the respective series under investigation, based on banner and open ports. For each resulting host found with a query, this host was scanned with Shodan via the Python-API in order to obtain an overview of open ports and provided services and banners. The results were stored in a JSON-formatted file, for which the json library of Python was used. In a second step, the conditions for each CVE were manually derived from several sources, mainly the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) [37], but also security advisories of the vendors. These conditions often include firmware versions which could be derived from the banner, open ports or services or certain modules present on the host, also derived from banner information. In a final step, the prerequisites for each CVE that is potentially applicable to a given device are obtained from the JSON-formatted information by an automated Python-script. The results are then used to calculate metrics, such as the amount of devices and vulnerabilities per country. For this, a custom made Python script was employed. In order to make the process clear, it is described in the following toy example for the PerfectToast-series of the fictional vendor KitchenAppliances. Research showed that the PerfectToast-series always runs a service at port 4567 and also displays a banner that says ”perfect toast”, so the query “port:4567 perfect toast” would be used. This would detect all potential devices of the PerfectToast-series. The hosts are stored in a csv-type file and in a next step queried for any information that can be obtained of the given host, e.g. additional open ports and provided services. This would obtain the information for every PerfectToast-device, such as open ports and services banners. Let’s assume PerfectToast-device have an open HTTP-port with number 80 and an open SSH-port with number 22 and return a web server version, as well as an SSH-version upon query. All of these devices are then stored with the given host information in a JSON-file. After that, all CVEs for which PerfectToast-devices are potentially vulnerable, are collected manually, together with conditions related to the vulnerability. For example, the PerfectToast-devices are vulnerable to a CVE if the Apache server version on HTTP port 80 is less than 2.9. Unfortunately, CVEs are structured in a way that it is difficult to automatically discover any conditions that are explained in non-structured text. In a final step, the devices stored in the JSON-file are queried to evaluate if they match the conditions for the CVEs. So each of the PerfectToast-devices which was found by Shodan is queried for having an open HTTP port and an Apache server version of less than 2.9. If this condition is met, the device is considered to be vulnerable. In this fashion, each device is queried for every potential CVE. Subsequently the results from those queries undergo statistical analysis, thus providing a valuable insight into the factual state of vulnerability of ICSs. Furthermore, a categorisation of the results into six classes was performed, based on the aim of a successful attack. For this, the well-established STRIDE-model [38] has been applied. STRIDE is an anagram describing the different types of computer security threats:

• •

  Spoofing, indicated in tables by S

• •

  Tampering, indicated in tables by T

• •

  Repudiation, indicated in tables by R

• •

  Informatin disclosure, indicated in tables by I

• •

  Denial of service, indicated in tables by D

• •

  Elevation of privilege, indicated in tables by E

In general, an attacker can tamper, i.e. break the integrity of data to influence the process, disclose, i.e. steal information, disrupt the service, or elevate privileges to increase the radius and impact of operation. Of course, there might be an overlap, e.g. Denial of Service (DoS) by changing process parameters fits D as well as T, however, since the intended result is of interest in this context, this instance would be labelled as D. Spoofing at this point is of little interest, as many applications do not have identity management at all. Furthermore, Repudiation is seldomly the goal of an attack, but rather a means to an end. All results obtained in the course of this work are presented in Section IV.

The market for ICS devices is mostly covered by five vendors. For the year 2017, the distribution is shown in Figure 4 which was created by Dawson [39].

The market shares of PLC vendors based on information from statista is shown in Table I [40].

This matches the distribution shown in Figure 4. Furthermore, commercial market analysis, such as Mordor Intelligence and PR Newswire name ABB Ltd., Mitsubishi Electric, Schneider Electric, Rockwell Automation, and Siemens [41], or Schneider Electric, Rockwell Automaton, Siemens, Mitsubishi Electric, and Omron [42] respectively as the most prominent vendors of PLCs. Thus, we chose to analyse products or product groups from the following five vendors, as they represent a large share of the PLC market:

• •

  Siemens

• •

  Rockwell Automation

• •

  Rockwell Automation

• •

  Mitsubishi

• •

  Schneider Electric

• •

  Omron

This aims at addressing devices with a high distribution and application in industry. Since each group or type of devices from a specific vendor contains different potential vulnerabilities, exemplary devices or groups of devices have been selected for the study. These devices should be easily identifiably with Shodan, have vulnerabilities that can be checked against, and be available in a number large enough to be expressive. Pre-emptive analysis of device types by the individual vendors led to the devices that are analysed below.

One of the devices evaluated was the Schneider Electric BMX P34 series [43]. Schneider Electric, who, under the name Modicon developed the Modbus-protocol [3], is the fourth largest manufacturer of ICS technology, as indicated by Figure 4. It was founded in 1836 and has its main seat in Paris. Schneider Electric is active in about 150 countries and thus has a significant influence on the industrial landscape. The Schneider Electric BMX P34 series is part of the Modicon M340 series, containing seven PLC devices with CPUs and different connectivity options.

The devices were fingerprinted by Shodan by looking for two conditions: First, the device had to provide Modbus-functionality. This was analysed by the open ports, standard port for Modbus/TCP is 502. If a service is active on that port, it is assumed to communicate with the Modbus-protocol. Furthermore, each device should have the string “Schneider Electric BMX” in their banner. The “Schneider Electric BMX” are part of the Modicon M340-series by Schneider Electric. If these two conditions were met, the device was employed for the analysis. The resulting search term was: port:502 “Schneider Electric BMX”. Since all banners were expressive, it is safe to assume that every device found was actually communicating via Modbus on port 502.

In general, devices of this series can contain a total of 59 different vulnerabilities, listed as CVEs according to the NIST NVD [37]. These vulnerabilities are listed, with Common Vulnerability Scoring System Calculator (CVSS) score version 3.1 and 2 taken from the respective vulnerability description [37] in Table II. If a CVE did not have a CVSS score version 3.1, it was calculated manually and indicated with a star.

Since several of the 59 CVEs share the same conditions, they are clustered into 15 Clusters in a fashion that they are applicable to the same devices, including configuration and firmware version. Meaning if a device is susceptible to one CVE in a cluster, it is also susceptible to all the others. This is indicated by the leftmost column Cl.. It is noteworthy that all vulnerabilities of Cluster 7 solely require access on the Modbus/TCP port in order to be exploitable. Since the port was used to discover the devices, all devices that are part of the data set are vulnerable.

The table shows that DoS attacks are the most common, followed by a similar number of information disclosure, elevation of privilege and tampering attacks. The experiments for the Schneider Electric BMX P34 series were performed with data queried on April 14th, 2020. A total of 758 was identified matching the criteria presented in Section IV-A. The summary of these results is provided in Table III, containing the ten countries hosting the most Schneider Electric BMX P34 series devices.

In this table, $\sum_{Top10}$ is the column sum of the devices used in the ten countries employing most devices, while $\sum_{Total}$ is the sum over all devices. It can be seen that about 85% of each sum are found in the top ten countries. Most devices were found in France, which is the country of origin of Schneider Electric, followed by Spain and the United States. It can be seen that the relative number of devices per country and the relative number of CVEs per country is within a deviation of .5. However, the CVEs weighted by the CVSS starts with almost half the relative value, compared to the relative value of numbers of CVEs and decreases slower than the number of CVEs. That is an indication that, although France, Spain, the United States, and Italy operate most devices containing most vulnerabilities, these vulnerabilities are not as severe as vulnerabilities of other countries. Israel has a slightly higher percentage of the weighted score than of the number of CVEs. That means the CVEs the devices operated there are more susceptible to attacks with severe effects. It is noteworthy that, since all of the CVEs in Cluster 7, as described in Table II, solely rely on Modbus/TCP communication, all evaluated devices are vulnerable. However, there are also vulnerabilities no monitored devices is susceptible to, namely CVE-2019-6851 that relies on a running TFTP server and CVE-2014-0754 that requires an active HTTP server as well as a specific device version. In general, each device is at least susceptible to one CVE, at most, a device is vulnerable to all clusters except the above-mentioned. The mean number of vulnerabilities per device is 5.85. Each of the evaluated devices has at least one open port, TCP 502, which is the default port for Modbus/TCP. Apart from that, 237 devices listen on TCP port 80, indicating a web server. A running web server is required for exploiting CVEs in Clusters 9, 10, 11 and 12. 58 devices listened on TCP port 21, commonly used for FTP and required for exploiting CVEs in Clusters 5, 13, and 15. 54 devices listened on TCP port 23, commonly used for the Telnet-protocol. It is a remote control protocol that does not provide encryption and is thus only suited for private networks, if at all. Telnet is required for exploiting CVEs in Clusters 15, only containing CVE-2011-4859 which is nine years old. In total, 76 devices are vulnerable to CVE-2011-4859, which is a bad sign since the disclosed vulnerability is available for a sufficiently long time. Shodans built-in CVE matcher found a total of 1412 CVEs. However, the distribution is skewed, with a mean of 1.8 CVEs per device, a minimum of 0, a maximum of 169 and a variance of 124.41. That means few devices contain most of the vulnerabilities Shodan matched automatically. This is unexpected behaviour, indicating either devices with several old services, invalid CVE detection of Shodan, or honeypots.

Additionally, the overall distribution of the CVEs found is listed in Table IV.

Each device of the Schneider Electric BMX P34 series is susceptible to the CVEs in Cluster 7. The CVEs in Cluster 7 have a CVSS 3.1 score of 7.5, except for CVE-2019-6808, which as a CVSS 3.1 score of 9.8 and is thus critical. This CVE allows Remote Code Execution (RCE) via Modbus. The other CVEs have CVSS scores that are considered to be high. All of them are exploitable via the Modbus protocol, consequently finding them in the public network is a critical security issue. The remaining CVEs in Cluster 7 either allow a DoS or the leakage of sensitive information from the device. CVE-2017-6017 has a CVSS 3.1 score of 7.5, which is considered high. It is only applicable to a certain list of devices and to certain firmware versions. However, a total of 757 devices, or 96.43% of analysed devices, are vulnerable. This CVE allows a DoS condition that has to be reset by manually pressing a button on the device by an operator. 732 devices are susceptible to the CVEs in Cluster 2. This cluster contains three CVEs, CVE-2018-7842, CVE-2018-7846, and CVE-2018-7847, with a CVSS 3.1 score of 9.8, which is considered critical. These CVEs allow code exection resulting in unauthorised access and elevation of privileges, which enables an attacker to directly impact the system. CVE-2018-7850 has a CVSS 3.1 score of 3.5, which is considered medium. This CVE allows for the displaying of incorrect information in the associated Unity Pro software. All other CVEs in this cluster have a CVSS 3.1 score of 7.5, which is considered high. These CVEs, except for CVE-2018-7848 Detail, create DoS conditions. CVE-2018-7848 Detail enables the extraction of information. The types of attacks that are evaluated in this scenario describe RCE attacks, data leakage and DoS attacks. RCE on industrial devices allows an attacker to influence the CPS connected to the PLC. That means an attacker potentially has the option to misuse CPSs that influence the physical world. Causing physical damage to materials and products as well as injuring operators is consequently possible. Information leakage can provide business secrets to an attacker, which could be stolen due to monetary gain. DoS can be used to disrupt often highly dependant, sequential production environments, causing a halt in production which often leads to drastic monetary loss.

The Siemens Simatic S7-300 is part of the Siemens Simatic product series. This series is the most popular product for process control, of which the Simatic S7-300 is the low-end device with limited computational capabilities. It was fingerprinted by searching the Shodan database for devices satisfying the following two conditions: First, the S7 communication port (TCP/102) was exposed to the internet at Shodan scan time. Second, the received data from that scan contained the string PLC name: SIMATIC 300, which indicates that a correct header of the Simatic S7 product family was received as well as that the field containing the product family is indicating a S7-300 device. The resulting Shodan query was port:102 ”PLC name: SIMATIC 300”. There are known honeypots supporting the S7 protocol, e.g. Conpot. In parallel to the fingerprinting process, 16 relevant CVEs have been identified for the Simatic S7-300 series. The set of CVE was obtained by searching the NVD provided by the NIST for the key word SIMATIC S7-300. The set of CVEs was then used to compile a set of fingerprints to identify the subset of vulnerabilities that are applicable to a particular system. An overview of the result is given in Table V.

As it can be seen, most CVEs are fingerprintable from the data received from the Shodan database. CVE-2016-8672 is an exception, as it is not possible to determine if a Simatic S7-300 is Profinet-enabled or Profinet-disabled, as Profinet communications and banners might not be exposed to the Internet.

The table shows that most CVEs result in DoS conditions, two allow information disclosure, one allows the elevation of privileges. A total of 439 devices were fingerprinted by the signature presented previously. Each device has a unique IP address. Comparing the geo-spatial distribution of Simatic S7-300 devices found, Germany and Italy amount to approximately 16$\%$ each. The third ranked country is Spain with around 7$\%$ of the identified devices. Interestingly, the vulnerabilities are distributed rather different. There are only three frequencies with which vulnerabilities occur: Six out of 17 occur at >99 $\%$, three at 80 $\%$ probability and seven occur not at all. Out of 439 devices, 436 were identified to have at least one Siemens Simatic S7-300-specific vulnerability. In total 3660 vulnerabilities were found, the median of vulnerabilities per device was determined to be 9. In Table VI, a comparative overview of the results is presented.

It can be seen that there is no significant difference between the values with and without the CVSS weighting. This is expected behaviour as the corresponding CVSS values presented in Table V are often exactly $7.5$ or similar. A second observation is that the top 10 accounts for roughly 70 $\%$ of the total vulnerabilities found, thus following a power distribution. This is a common distribution in information security-related statistics [44, 45]. As there are more factors, e.g. insecure configuration, that can lead to system vulnerabilities, two more parameters are considered to gather a more complete picture of the overall state of security. First, the number of ports exposed to the internet is enumerated for each identified device. Port 102 was found open on each device, as it was part of the query. The subsequent ports in terms of frequency are 80 (26$\%$) and 443 (22$\%$), both are standardised for HTTP and HTTPS web services respectively by IANA. Web-based applications are often used to administrate a system or monitor the current state. An exposition may result in a compromise or information leakage. Followed by the ports 5900 (13$\%$), 161 (9$\%$) and 5800 (7$\%$). Ports 5800 and 5900 are standardised by IANA for the VNC protocol, which provides remote access to a device. This remote access may be susceptible to credential guessing-attacks, which can result a full system compromise. Another potential vulnerability is the exposition of port 21 (6$\%$), which is typically used for FTP. FTP can be used to upload files, e.g. web shells or other backdoors, or download potentially sensitive information if the configuration allows this type of access. FTP, as well as HTTP, are inherently susceptible to man-in-the-middle attacks, as they to not provide encryption or integrity. To further get a picture of the vulnerabilities, Shodan’s vulnerability fingerprinting is used. The first interesting observation is that there is no overlap between the CVEs identified by Shodan and the CVEs identified by the signatures presented in Table V. Therefore, both vulnerabilities sets can be combined to assess the overall security. Comparing the absolute numbers, reveals that Shodan is able to identify 34 devices that are susceptible to at least one vulnerability. In total, 779 CVEs of which 305 are unique are identified. Curiously, there is one single device which is identified to expose 152 vulnerabilities by Shodan. On average, there are 1.8 vulnerabilities per device.

Additionally, the overall distribution of the CVEs found is listed in Table VII.

The table shows that seven CVEs can be exploited on all vulnerable devices that were found. Furthermore, seven CVEs could not be exploited on any device and are thus not listed. From the seven CVEs, all except for CVE-2016-9159 create DoS situations. CVE-2016-9159 in contrast allows an attacker to extract credentials from the device. It is assigned a CVSS 3.1 score of 5.9, which is considered medium. Every other CVE is assigned a CVSS 3.1 score of 7.5, which is considered high; except for CVE-2015-2177, which is not assigned a CVSS 3.1 score due to its age, but has the same CVSS 2.0 score as the other CVEs. The DoS attacks can be exploited by an attacker with access to the network the PLCs are located in. As they can be found by an Internet-based search engine, Shodan, they are obviously reachable from the Internet. Similarly, the credentials can be extracted if an attacker has access to the network. In general, the most frequent vulnerabilities have a strong impact on the network environment. Disrupting process environments can cause a significant loss of money, can render materials useless and thus harm an organisation. The fact that CVEs that can be exploited just with network access can be discovered is concerning, especially since the oldest is from 2015. As discussed, honeypots could distort the results, however, it is sufficiently unlikely that all results are honeypots, due to their heterogeneity in spatial distribution, services running and other characteristics.

The Omron CJ and CS PLC series are part of the Omron PLC product family for process control. Other Omron PLC product groups are the CV-series, the C200-series, the CVM1 and the CQM1H. The Omron CJ series was chosen as initial scan results indicated a high prevalence (>30$\%$) compared to the other Omron products in the Shodan database. As the identified vulnerabilities are mostly found in both, CJ and CS series, the CS series was included as well. The series were fingerprinted by searching the Shodan database for devices satisfying the following three conditions: First, the proprietary Factory Interface Network Service (FINS) protocol port (TCP/9600) was exposed to the internet at Shodan scan time. Second, the received data from that scan contained the string response code. As Shodan does not support partial matching of strings separated by space, the Shodan query used to identify Omron PLC devices was port:9600 ”response code”. The third condition was then locally applied to filter for the CJ and CS series by matching the controller model field against the strings CJ and CS. By this process the set of relevant devices was extracted from the Shodan database. In addition to the fingerprinting process, 30 CVEs for Omron products have been identified. As with the Simatic devices, the set of CVEs was obtained by searching the NVD of the NIST for the key word Omron. Most CVEs are for the Omron CX product line, which includes the devices used to program Omron PLCs. Even though a compromised programming device is a suitable attack vector, only CVEs directly affecting the PLC devices are considered in this study. The final set consists of seven CVE from between 2015 and 2020. The set of CVEs was then used to compile a set of fingerprints to identify the subset of vulnerabilities that are applicable to a particular system. An overview of the result is given in Table VIII.

As it can be seen, each CVE is fingerprintable from the data received from the Shodan database. This enables a broad insight into the vulnerabilities that are prevalent in the Omron CJ and CS series PLCs exposed to the Internet.

A total of 1579 devices was fingerprinted according to the previously presented signature. Each device has a unique IP address. Comparing the geo-spatial distribution of Omron CJ and CS PLC found, Spain is the origin of approximately 25$\%$ of them. The second and third ranked countries are France and Canada each with around 10$\%$ of the identified devices. Comparing this distribution the country distribution of the devices with an identified vulnerability, it can be observed that both are similar for the top 3 countries. However, the percentage of devices in Spain is reduced to 19$\%$ when only devices with CVEs are considered. This indicates that devices in Spain have a slightly better security compared to the average. Five out of seven vulnerabilities occur at about 63$\%$ of all devices identified as Omron product. The remaining two vulnerabilities occur at a significantly lower rate of about 15$\%$ of the devices. Out of 1579 devices, 1018 were identified to have at least one Omron-specific vulnerability. In total, 5219 vulnerabilities were found, the median of vulnerabilities per device was determined to be 5. In Table IX, a comparative overview of the results is presented.

It can be seen that there is no significant difference between the values with and without the CVSS weighting. This can be an indication that the vulnerabilities are equally distributed among the vulnerable devices and countries. A second observation is that the top 10 accounts for more than 80 $\%$ of the total of vulnerabilities found, thus following a power distribution. This is a common distribution in information security-related statistics [44, 45]. To complement the overview of the state of security, two further factors are considered. First, the number of ports exposed to the internet is enumerated for each identified device. Port 9600 was found open on each device. This was expected as one of the two conditions to fingerprint a device as Omron CJ and CS PLC series was the exposition of port 9600. The subsequent ports in terms of frequency are 80 (26$\%$) and 443 (18$\%$), both are standardised for web services, namely HTTP and HTTPS, by IANA. Web-based applications are often used to administrate a system or monitor the current state. An exposition may result in a full compromise or information leakage scenario. Next in rank is the port 21 (11$\%$), which is used for FTP-based file transfer. Exposing this port to the internet is a security risk as it has no encryption and integrity protection. A compromised FTP service can lead to full system compromise or information disclosure. Additionally, port 5900 (11$\%$) and 22 (10$\%$) are found open. These ports are used for VNC and SSH, both of which being remote administration services. Having publicly available administration services may be a risk as in many cases no or default credentials are used to secure them. Furthermore, they are often susceptible to credential-guessing attacks. Port 23 (6$\%$) is also a major security risk. Port 23 is standardised for Telnet by IANA. Telnet, as well as FTP, does not have any encryption or integrity protection, thus being susceptible to man-in-the-middle scenarios. A compromised Telnet service grants full access to the system. To further analyse the state of security of the Omron CJ and CS PLC series, Shodans vulnerability fingerprinting is used. The first interesting observation is that there is no overlap between the CVEs identified by Shodan and the CVEs identified by the signatures presented in Table VIII. Therefore, both vulnerabilities sets can be combined to assess the overall security. Comparing the absolute numbers, reveals that Shodan is able to identify 128 devices that are susceptible to at least one vulnerability. In total, 2213 CVEs of which 426 are unique are identified. Curiously, there is one single device which is identified to expose 121 vulnerabilities by Shodan. In average, there are 1.4 vulnerabilities per device.

Additionally, the overall distribution of the CVEs found is listed in Table X.

Several noteworthy features of the Omron CJ and CS PLC series can be observed. First, no CVE can be attributed to the whole set of devices found. Second, compared to the Schneider Electric BMX P34 series and the Siemens S7-300 series, the Omron CJ and CS PLC series is less susceptible to DoS attacks. Instead, the CVEs allow for tampering, elevation of privilege and information disclosure. Especially tampering can have catastrophic consequences in an OT environment jand ultimately cause bodily harm. CVE-2019-18261 allows for brute force attacks to gain access to the device, which extends the attackers circle of influence. CVE-2019-18259 allows for an attacker to spoof messages or execute arbitrary commands, meaning an attacker with access to the network can actively influence the device and all connected actuators. CVE-2019-13533 allows for replay attacks, which enable an attacker to tamper with the physical environment, again potentially causing catastrophic results. CVE-2020-6986 can lead to a DoS condition, disrupting a process, and CVE-2019-18269 enables attackers to tamper with locks in the software flow.

The Rockwell Automation/Allen-Bradley MicroLogix 1400 series encompasses six different controllers and one memory module. In fingerprinting the series, the Shodan functionalities were used to make sure that the scanned device is a product of Rockwell Automation and shows a version starting with 1766, which is used for the MicroLogix 1400 series. The main limitation of this fingerprinting method is its reliance on the correct product name and version number being available. However, circumventing this limitation by instead introducing expected services to the search parameters would yield far too many false positives. The resulting search query was ’product:Rockwell Automation’ ’version:1766-’. In order to find relevant CVEs, the NVD of the NIST was queried for cpe:2.3:h:rockwellautomation:ab_micrologix_controller:1400: *:*:*:*:*:*:*, which uses the most recent edition of the Official Common Platform Enumeration Dictionary [46]. Missing from the query is the firmware version, which was not searchable by Shodan. Therefore, a higher rate of false positives is to be expected, since many of the vulnerabilities are mitigated by firmware upgrades. The relevant CVEs can be seen in Table XI.

The queries for the Rockwell Automation/Allen-Bradley MicroLogix 1400 series were launched on April 22nd, 2020. A total number of 1832 devices was fingerprinted, each with its own unique IP address. With $65\%$, the majority of devices were located in the USA, the second and third place being Canada and Portugal with $5-6\%$ each. This result is congruent with the calculation of exposed devices by factoring in the vendor-specific CVEs per country. Since not all vulnerabilities are of equal severity, Table XII additionally shows a weighted score that is the product of the number of CVEs and their CVSS. The weighted ranking is almost identical to the unweighted ranking by number of devices, with the exceptions of Australia and Norway, both of whom have a slightly higher percentage in the weighted ranking.

As shown in Table XI, CVE-2012-4690 does not distinguish between versions, which is why all of the 1831 scanned devices are flagged as susceptible to the corresponding attack. The other six CVEs were found to fit over half of the scanned devices, with percentages ranging from $53.09\%$ to $68.00\%$. In total, 9028 vulnerabilities were found. The most CVEs per device found were 7, which means that all vendor-specific CVEs were present. On average, every device showed 4.4 vulnerabilities. In addition to the vendor-specific CVEs there was also a distinct set of Shodan CVEs, with 81 devices being susceptible to at least one of them. In total, 2151 of Shodan vulnerabilities were found, with an average of 1.17 vulnerabilities per device. The scan showed a total number of 5664 open ports and therefore services. Naturally, not every open port is necessarily a vulnerability, though in general, opening up a device to the Internet always increases the attack surface and therefore the risk of damage.

Table XIII shows the ten most frequent open ports. By far the most common service found is EtherNet/IP which is both very common for PLCs and a key feature of the MicroLogix 1400 PLC, and was found in every scanned device. Over half of the scanned devices showed HTTP or HTTPS ports. Interestingly, $11.47\%$ of the scanned devices had an open Point-to-Point Tunnelling Protocol (PPTP) port, which could mean serious security issues since PPTP is fundamentally flawed with respect to encryption and authentication.

Table XIV provides an overview of the prevalence of the vendor-specific CVEs by showing the absolute and relative numbers of devices that were flagged as susceptible to each CVE.

CVE-2012-4690 occurs when static status is not enabled, which opens the system up to a DoS attack, since remote attackers can modify the status bits. The severity of CVE-2012-4690 is high, with a CVSSv3 of 7.5.

The next five vulnerabilities were all equally common, affecting 68% of devices. CVE-2017-7898 allows for remote brute force attacks, since the system does not set a limit on repeated authentication attempts. This is made even more precarious by the system’s use of numeric passwords of short length, which is described in CVE-2017-7903. Both vulnerabilities are critical.

CVE-2017-7899 allows a local attacker to obtain authentication credentials by reading the server logs, since the system accepts them being sent by GET requests. With a CVSSv3 of 9.8, this too is a critical vulnerability.

CVE-2017-7901 is of high severity. It allows remote attackers to spoof TCP connections or launch DoS attacks, made possible by insufficiently random initial sequence numbers in the server’s TCP communication.

CVE-2017-7902 opens the system up to replay attacks, and scores as critical. Nonces, which usually mitigate this kind of attack, are reused by the system, which defeats their purpose when faced with an attacker that can monitor the network.

Lastly, attackers can send malformed packets over Ethernet or Serial Line Internet Protocol (SLIP) to execute a DoS attack. This vulnerability, described in CVE-2014-5410, has a high severity.

According to Figure 4, Mitsubishi has a significant share on the PLC market. The PLC series of Mitsubishi is called Melsec series. A product line of this series, the Melsec-Q Series, uses a proprietary service protocol operating by default on TCP port 5006 and 5007. Shodan only lists relatively few of theses devices, between 200 and 300, by the time this paper is written, that are exposed to the Internet. The devices can be easily identified by the TCP port and banner stating the device model with a string like CPU: Q03UDECPU for the respective model. Querying the CVE database of NIST for the Melsec service protocol results in eight CVEs. Of these results, only four devices affected by the CVEs can be queried with Shodan. As the firmware versions of the respective devices are not listed on Shodan, it is impossible to say whether the devices are patched, so a high false positive rate for the survey of Mitsubishi devices should be expected. The CVEs that have been considered are from the years 2019 and 2020. The vulnerabilities CVE-2019-10977 and CVE-2016-8370 affect the Melsec-Q Ethernet interface module which could not be detected by Shodan and was therefore not taken into account for this work. The CVE-2019-13555 affects the FTP server of the PLC by default running on port 21 and returning the banner ”220 iQ-R FTP server ready.”. Searching Shodan for the banner reveals 44 devices, but it is likely that these are honeypots, which will be discussed in detail in Section V.

The Shodan query for Mitsubishi Melsec devices produced 259 results, of which 187 were unique IP addresses. The duplicates are listed once for the open UDP port 5006 and once for the open TCP port 5007. In this evaluation only unique IP addresses were considered as one device. The Melsec Q devices were found most often in Japan, the country of origin of Mitsubishi, with 119 devices or 63.3$\%$. Second is USA with 15 devices and Poland with 8. Of the CVEs considered in Table XV, 173 vulnerabilities were found in 119 devices of Japan and 30 in the devices of the USA. It is not clear whether the vulnerabilities are actually present for the firmware of the devices, as only the model was fingerprinted. For this evaluation it is assumed no device is patched, which is the most conservative assumption. The distribution of devices and of CVEs over the countries is nearly even. The mean of CVEs per device was found to be 1.56 with a median of CVEs per device of 2.0. In Table XVI, an overview of the results is provided.

Weighting the CVEs with the CVSS 3 score does not change the relative distribution of impact per country as the CVSS 3 score for the most common vulnerabilities are equal. Since only in the top five countries more than five devices were found, the top ten countries account for 90,44$\%$ of all devices. Either TCP port 5007 or UDP port 5006 have to be open on each device, as these were part of the search query. These ports are used for the custom networking protocol on the Melsec devices. 86 devices has port 80 open for which is assigned the HTTP protocol by the IANA. Also frequently open were port 23 (32.45$\%$) for Telnet, a remote terminal, and port 21 (28.72$\%$) for FTP, a protocol used for file transfer. Both Telnet and FTP pose a security risk as they do not encrypt communication and no integrity checks and therefore allow man-in-the-middle attacks. Less frequently the ports 8080, 9191, 590, 2332 and 5009 are found to be open. The Shodan vulnerability analysis found 10 CVEs of which none overlap with the CVEs identified in Table XV. Shodan only found CVEs matching 9 devices which are mostly located in Poland, the UK and France. Combining the Shodan results with the vendor specific vulnerabilities increases the vulnerabilities found on devices in Poland from 15 to 62. In total, Shodan identified 114 CVEs, of which 57 are unique. Note that many of the Melsec Q devices located in Japan have an IP address assigned to ”Research Organization of Information and Systems” and may be exposed to the internet intentionally to study potential attacks, as described in Section V.

Additionally, the overall distribution of the CVEs found is listed in Table XVII.

All three CVEs create DoS conditions which can be used to disrupt often highly dependant, sequential production environments, causing a halt in production, as previously described. CVE-2020-5527 was assumed to apply to all 188 devices, CVE-2019-6535 applies to 52.13$\%$ of the devices with 98 occurrences and CVE-2019-13555 to 7 devices. CVE-2019-13555 requires the FTP port 21 to be open and certain CPU-types, resulting in the low distribution. Table XVIII shows a comparison of all devices on a set of important metrics.

The number of devices, in absolute and relative terms throughout the set evaluated in this work, shows the Rockwell Automation/Allen-Bradley MicroLogix 1400 being the most common device in the analysis. Remarkably, the Omron CJ and CS PLC Series have a significantly lower relative amount of CVEs and of the weighted CVSS than of overall devices. That indicates a higher state of security compared to other devices. At the same time, the mean CVSS value per device is highest for the Omron CJ and CS PLC Series, indicating few but impactful vulnerabilities. In contrast, Schneider Electric BMX P34 and Siemens S7-300 series have a significant higher distribution in CVEs and CVSS than of overall devices, indicating more and more severe vulnerabilities on these devices. Regarding the security objectives, a majority of almost every device is vulnerable to DoS attacks. Apart from that, information disclosure is a frequent threat, followed by escalations of privilege. No device is susceptible to repudiation attacks, spoofing only occurs in Rockwell Automation/Allen-Bradley MicroLogix 1400 devices.

Honeypots are computer resources in a network that are solely intended to mimic real behaviour and thus attract attackers [47]. They can be used in any environment. Consequently, honeypots tailored for ICSs were designed, e.g. Conpot [48]. ICS honeypots present an attacker the interface of an alleged industrial system, e.g. a water processing facility or a power plant [49]. The intention is twofold: First, insights about the attacker are gathered. The credentials and commands used by the attacker as well as indications of tools and goals can provide insight about the motives and aims of an attacker. Second, it binds resources of an attacker that consequently cannot be used to attack real systems, thus serving as a distraction. Shodan provides a heuristic to detect honeypots, however, this was not applicable in this work. It is likely that some of the results are honeypots. The devices presented in Section IV of the Mitsubishi devices which belong to a Japanese research institution are most likely research honeypots. Since these devices presented a valid fingerprint, they could have been real in the sense that it was hardware also used in productive environments, however, not connected to a process environment. These types of honeypots are solely distinguishable by analysing the correlation of actuator input and sensor output. However, this was the only instance of an obvious allocation of IP addresses by an individual institute that was encountered in the course of this work.

The previous chapter showed that, first, there is a substantial number of OT devices connected to the Internet and second, the majority of devices is susceptible to at least one known vulnerability. The implications are that either operators connecting their devices to the Internet against best practices do not employ best practices for security in general, or patching and updating OT devices is too difficult to be feasible in praxis. Characteristics of OT devices include spatial distribution over a large area, continuous operation with little to no time for maintenance and operating times of up to several decades, resulting in legacy systems. Due to these characteristics it is plausible that update- and patch-management is difficult in OT environments. The absolute numbers, as well as consideration of past incidents show the threat to OT environments. Furthermore, the effects range from low due to limited influence and knowledge of an attacker to significant damage to machines and products as well as threats to human life. All relevant attacker objectives of the STRIDE methodology can be achieved by CVEs. The CVSS severity rating indicates how much impact on the network environment is to be expected in case of a successful attack. The power outage in the Ukraine or the destruction of nuclear processing plants in Iran demonstrate the destructive abilities. As mentioned in Section I, effects of cyber attacks on the OT domain are not limited to the digital domain but can affect the physical domain as well. This property in combination with the large attack surface present a grave danger. For ethical and legal reasons it was not possible to try to exploit the vulnerabilities, so whether the identified vulnerabilities were exploitable or not was not evaluated. In general, there is no silver bullet for cyber security. Best practices need to be applied and even then, vulnerabilities can be found and exploited. A set of recommendations for OT operators is, similar to home and office operators, to:

• •

  Use network segmentation. In case of OT networks, they should be separated from IT networks and, especially, the public internet with firewalls and De-Militarised Zones. Those are well-established, easy-to-implement solutions that go a long way.

• •

  Deactivate services that are not used. This leads to a decreased attack surface.

• •

  Activate security properties that are available in ICSs to make spoofing more difficult once an attacker has gained access to a network.

• •

  Implement Identity and Access Management (IAM) schemes, to restrict the attacker’s capabilities.

Taking those recommendations into account will drastically reduce the threat. Additionally, vendors of OT devices should adhere to security practices established in IT development. Patch management, security-by-design, and security features as a core concept should be implemented in devices by default.

The geo-spatial analysis is intended to reveal insights about the importance of cyber security for OT in certain regions. E.g. it could have been expected that richer countries like European or Northern American would put a higher focus on security. However, most vulnerabilities of all devices were discovered in Europe and the USA, indicating that there are still challenges regarding OT security. Furthermore, a correlation between legislation and the security state can be derived in a later work.