Two years ago, mobile technologies were widespread, but IoT mania was only beginning. Today, no one is surprised at the appearance of an IIoT. The idea of putting your logging, monitoring, and even supervisory/control functions in the cloud does not sound as crazy as it did several years ago. If you look at mobile application offerings today, many more ICS related applications are available than two years ago, according to Alexander Bolshev, Security Consultant for IOActive and Ivan Yushkevich, Information Security Auditor for Embedi, authors of a new whitepaper published today by IOActive.
SCADA and Mobile Applications
ICS infrastructures are heterogeneous by nature. They include several layers, each of which is dedicated to specific tasks. Figure 1 illustrates a typical ICS structure.
Mobile applications reside in several ICS segments and can be grouped into two general families: Local (control room) and Remote.
Based on the threats listed in the whitepaper, the authors, Alexander Bolshev, Security Consultant for IOActive and Ivan Yushkevich, Information Security Auditor for Embedi, explain that targeting mobile SCADA applications can be sorted into two groups:
Directly/indirectly influencing an industrial process or industrial network infrastructure
This type of attack could be carried out by sending data that would be carried over to the field segment devices. Various methods could be used to achieve this, including bypassing ACL/ permissions checks, accessing credentials with the required privileges, or bypassing data validation.
Such attacks could exploit the following scenarios:
- Acting as a MiTM over an insecure communication channel, an attacker alters commands from a mobile SCADA application to the remote endpoint, which reaches the field devices.
- Attackers steal a device and extract remote SCADA endpoint credentials from it. Using them, they connect to the SCADA environment and send malicious commands. Alternatively, the attackers just take photos of the application’s settings (including credentials) when the device is left unlocked and unattended.
- Engineers unwillingly install a malicious application on their BYOD, which initially stays dormant to avoid raising any suspicion. Later, the malicious application exploits vulnerabilities in the victim application to subvert the communication process with the backend servers or extract valuable data. Another possible case is when SCADA mobile applications store data on partitions with insufficient permission checking and the malicious application alters/reads it.
- The backend servers are attacked using approaches from typical web or infrastructure application penetration testing (e.g., OWASP Top Ten risks) or by reverse-engineering the protocol between the mobile SCADA application and the remote endpoint. Then, the attackers leverage the vulnerabilities they have identified and send data to the backend servers, which will directly/indirectly influence some parts of industrial process/infrastructure.
Compromising a SCADA operator to unwillingly perform a harmful action on the system
The core idea is for the attacker to create environmental circumstances where a SCADA system operator could make incorrect decisions and trigger alarms or otherwise bring the system into a halt state. In other words, if attackers subvert the signal channels between the application and the actual system, they could confuse the SCADA operator about the current state of the system. This could be achieved by subverting the data going from the system to the HMI panel or mixing the signals going from the panel to field devices. Based on this maliciously altered information, SCADA operators could take harmful actions in good faith.
The following are example attack scenarios:
- Using MiTM over an insecure communication channel, attackers alter the data going from a SCADA system to a mobile application. This means that operators will see a completely different system state on their mobile screen.
- Attackers use physical access, malicious applications, or vulnerabilities in other applications installed onto the same device to alter the mobile HMI project database stored on the SD card, exploiting a lack of proper ACLs. This will allow attackers to completely subvert an operator’s understanding of the system. For example, they could change displayed data, hide events, or subvert switch controls behavior (e.g., make the “OFF” switch execute an “ON” state and vice versa). Besides physical compromise and mobile virus, this also could be achieved using a ZIP traversal vulnerability (described below).
According to the researchers, if the mobile application vulnerabilities identified are exploited, an attacker could disrupt an industrial process or compromise industrial network infrastructure, or cause a SCADA operator to unintentionally perform a harmful action on the system.
Bolshevik's and Yushkevich’s research focused on testing software and hardware, using backend fuzzing and reverse engineering. In doing so, they successfully uncovered security vulnerabilities ranging from insecure data storage and insecure communication to insecure cryptography and code tampering.
Specifically, the research revealed the top five security weaknesses were: code tampering (94% of apps), insecure authorization (59% of apps), reverse engineering (53% of apps), insecure data storage (47% of apps) and insecure communication (38% of apps).
“This new vulnerability report proceeds original research conducted by Alex and Ivan two years ago, where 20 mobile applications were tested,” said Jason Larsen, Principal Security Consultant at IOActive. “At the time, there just weren’t as many SCADA applications on the market. This latest white paper reinforces the fact that mobile applications are increasingly riddled with vulnerabilities that could have dire consequences on SCADA systems that operate industrial control systems. The key takeaway for developers is that security MUST be baked in from the start - it saves time, money, and ultimately helps protect the brand.