Abstract

Industrial and critical infrastructure automation systems, integrated with the Industrial Internet of things (IIoT) are becoming lucrative targets for cyber-attackers. Typically these are cyber-physical systems, with cyber components such as sensors, actuators, micro-controllers, programmable logic controllers, or distributed control systems, field-area networks, wide-area networks, etc., overseen by supervisory control and data acquisition systems (SCADA). After the discovery of the Stuxnet in 2009, and multiple other instances of cyber-attacks such as on a German steel plant, Ukraine power distribution system, chemical plant, etc., research on securing these systems from cyber-attacks has become very important. However, it is often not permissible to attack the real operational critical systems for vulnerability assessment or testing mitigation techniques. Therefore, virtual or real test beds are required. In this paper, we focus on a lab-scale test bed for a 3 phase power distribution system under industrial PLC control, instrumented with relay, power meters, various field protocol switches, supervised by an industrial SCADA system. The main contributions of the paper are (i) case studies of vulnerability assessment of the industrial components of this test bed – components that are being widely deployed in real critical systems throughout the world. (ii) the exploits and their security implications, especially their effect on the physical functioning of the systems; and (iii) mitigation techniques we have deployed to defend against such attacks. We are working with the original equipment manufacturers to disclose these vulnerabilities and in deploying mitigation techniques. A library of exploits and payloads which can be used in similar industrial control systems is under preparation.

Type of attacks on CI Through our VAPT methodology, we discovered different classes of attacks, and made a rough classification of attack types as follows: • Firmware reverse engineering The File Transfer Protocol (FTP) is the standard network protocol used for the transfer of computer files onto various field devices such as PLCs. Most of the devices implemented them through the web interface as JAVA applets which run on the operators’ browsers. The applets can be disassembled using a JAVA Decompiler. This vulnerability was already reported in the year 2015 and was demonstrated in Black Hat talk [26]. However, the decompiled bytecode reveals very important and hardcoded credentials as we describe later, leading to easy attacks. • DOS Denial of service attacks. • Man-in-the-middle (MITM): MITM attack targets the confidentiality and integrity of data flowing between two entities and results in gaining control over devices if control commands are subject to MITM. • MITM: ARP spoofing: Attacker takes advantage of plain text communication between the devices and runs unidirectional ARP (Address Resolution Protocol) which misdirects IP traffic by ARP poisoning. • Protocol Weakness based: Though there is a lot of research done for Modbus authentication, we did a detailed analysis and malware attack on the Modbus. Modbus is a commonly used field protocol in CI and is subject to various easy attacks. • Web-based attacks Cross-site request forgery, Remote file inclusion, cross-site scripting, etc., are abundant in the poorly implemented web interfaces designed for configuration of the devices via HTTP protocol VAPT of PLC

1. Vulnerabilities in Firmware: The firmware of the PLC was found to have high privileged hard-coded FTP credentials. These credentials were retrieved from the firmware of RTU and the same credentials were working in the PLC. The vulnerability pertaining to hardcoded credentials has been identified by the community and publicly disclosed earlier also. Using the discovered hardcoded password, we are able to access FTP. After the FTP login, we can access the hashed password file of the webserver installed inside the PLC. Because of the vulnerable hashing algorithm of Vxworks under the VxEncrypt library, we could generate password collisions and be able to login to the webserver without any knowledge of the existing credentials.
2. Vulnerabilities in Operating System: As mentioned before, the PLC is using Vxworks, an RTOS. TCP/IP protocol implemented in the PLC is prone to various DoS attacks like Ping of death etc.
3. Vulnerabilities in the embedded web server: The PLC has an embedded web server, a small piece of code that resides with the firmware – and it is used to view device information and configure the device settings. Here are some of the vulnerabilities identified in the web server inside the PLC. a) Remote File Inclusion (RFI): RFI vulnerability lies in the PLC web interface which was already reported in the year 2015 and has remained unfixed till date. Using this vulnerability the attacker can use a specially crafted link and send it as a phishing email which can then be used to perform network scan and other attacks. b) Cross-Site Scripting (XSS): During the VAPT, we found that the PLC has an XSS vulnerability. Using a URL after an RFI, such as http://IP/html/english/home/index.html?MalLink in which the IP address part uses the IP address of the PLC and a malicious link is a path to a malicious file uploaded using RFI, an attacker can load a malicious script into the victim’s web browser and perform undesired activities. c) Cross-Site Request Forgery (CSRF): During the VAPT, We found that the PLC has a http_config_passwd.htm file which is used to update/modify the HTTP credential of the users. Using a crafted payload, an attacker can modify the existing credentials and terminate the authenticated session. Once the unwanted action happens, there is no way around for a user to configure the hardware. d) Weak password Management: During the VAPT, we found that the PLC is using a vulnerable hashing algorithm for storing plaintext username and password hash in userlist_encrypt.dat at /SDCA/WEB/userlist_encrypt.dat. e) Insecure communication: The Web server inside the PLC is configured to communicate using HTTP by default and we did not find any option of configuring SSL certificates to avoid eavesdropping or MITM attacks. f) DoS: An attacker can flood the webserver with specially crafted HTTP requests to prevent the web page from loading. This leads to DoS against any attempt to configure the PLC.
4. Vulnerabilities in Modbus-TCP: The vulnerabilities of the Modbus-TCP application layer protocol were found in the PLC as expected. a) DoS: An attacker can flood the server with specially crafted Modbus-TCP packets which leads to a DoS attack and will prevent legitimate users from accessing the device. If an attacker overloads the server with requests, the server cannot process requests from a legitimate end-user. b) Insecure Communication: The Modbus TCP plaintext communication reveals all information about the addresses of the input/output of the PLC, which makes it easier for malware to target specific addresses and attack the system. c) Man-in-the-Middle: MITM: Due to the plaintext communication and no authentication mechanism built into the protocol, the PLC can be compromised by a MITM. We manipulate messages, resulting in a successful MITM attack which ultimately leads to subverting the control. The PLC is integrated with the HMI and communicating plant floor data via Modbus-TCP. An operator operates the facility using the HMI. An attacker (maybe a malicious script) first executes an ARP spoofing attack and then replay the packets coming from the HMI to the PLC. The PLC allows an unauthenticated machine to establish TCP sessions and then any command coming from the attacker is executed on the PLC. We successfully subvert the open/close operation of the circuit breakers using the same. d) Malicious command execution: This is a result of our vulnerability assessment related to the authentication in the Modbus-TCP protocol. Any malicious script running in the network in line with the Modbus-TCP protocol can command the control system and harm the system. Modbus-TCP server running in the PLC accepts connections without authorization and serves the client by executing commands. We have written a script that can make connections with the PLC and inject commands. We are able to change the breaker status.
5. Vulnerability in CIP: The vulnerability can have unauthorized access to the PLC.
6. Vulnerability in SNMP protocol: Using the SNMP vulnerability, the attacker exploits the network activity, configuration changes, information leakage, etc. a) SNMP truncate packet: Denial of service by SNMP Truncate packet can cause a communication failure. In case an attacker attacks the port 161 of the device, then all the commands given by an operator will be scheduled in a queue. When the attacker releases the attack (i.e. before connection reset time else all commands will drop), then all the queued commands will be forward to the device for execution. b) Community string: Attacker first sniffed the community from the network and later he used this community string to extract the fruitful information from PLC and later he used it for further exploitation part. c) Configuration changes: After using this above vulnerability he attacked the PLC in order to change the network configuration like MAC address, disabled the network interface card and remove all devices which are connected to this device.

VAPT of the RTU

1. Vulnerabilities in the Firmware: The Latest firmware available on the site of the OEM has been downloaded and using reverse engineering we have found that there are hard-coded FTP credentials that are known publicly and have not been fixed till date. We are able to get, put, and update files.
2. Vulnerabilities in Operating System: TCP/IP protocol implemented in RTU is prone to Ping of death etc.
3. Vulnerabilities in embedded Web Server: Vulnerabilities [CSRF, Insecure communication, DoS, Weak password management] found in the embedded web server in the PLC also were found to have the same exploits in the RTU.
4. Vulnerabilities in IEC-60870-5-104: a) Denial of service (DoS): Crafted 104 packets floods the network to prevent a legitimate users from accessing the device. If an attacker overloads the server with requests, the server cannot process further requests which are a case of a denial of service and the operator has to reboot the device. b) Insecure Communication: 104 1communications between RTU and SCADA host is in plaintext, which disclosed the mapped address of the RTU. c) MITM: Man-in-the-Middle Attack: The RTU is communicating with the SCADA host using the IEC 608705-104 protocol. We observed that there is no encryption or authentication mechanism built into the protocol and all commands are being sent in plain text. The command flow can be manipulated with very little effort, resulting in a successful MITM attack which ultimately leads to control subversion. Similar to the Modbus-TCP implementation in the PLC, the RTU is also accepting forged requests and allowing an attacker to subvert the control of the plant. d) Malicious command execution: Similar to Modbus TCP, There is no authentication mechanism in the 104 implementation. Thus the RTU is accepting the forged packets and allowing the attacker to subvert the control of the plant.
5. Attacks on Application layer: Modbus-TCP: The RTU used in the testbed also supports the Modbus-TCP protocol and has vulnerabilities found in the PLC i.e. DoS, insecure communication, MITM, and malicious command injection.

HMI: a) Vulnerability in X11.1: During the scanning of the panel-mounted HMI we found that port 6001 and 501 are open. Successfully flooded the port with sync packets. During the sync flood, the HMI suffers denial of service. During this, if we simultaneously try to command the actuators, the commands get queued, and when we release the attack, all the packets are forwarded to actuators with a delay and too fast to cause damage to the actuators. b) Vulnerability in Modbus/TCP port which is mainly dedicated to listening to the communication with PLC for reading and writes from HMI panel. But the attacker can send data (read, write, diagnostic information, etc.) from HMI using Modbus/TCP vulnerability. SCADA Host: a) Credential Dumping: Since the SCADA client runs as a medium integrity process, any process with the same Integrity level or higher is able to read the process memory and dump it for credential harvesting. Host memory analysis reveals that the credentials of the SCADA application were present inside the process memory, which can be read by any other malicious application. There also resides links to all visited URLs from Internet Explorer which can lead to information disclosure. b) Violation of input sanitization: Vulnerability related to overflow & memory corruption” in the IO server of the SCADA software provided by M/s. Schneider Electric. This attack requires to modify the value of the variable only which leads to the complete server crash.