Author | National Internet Emergency Center, Du Peng
1. Background and Current Situation
As the degree of digitization and intelligence of industrial control systems continues to improve, the traditional closed and isolated industrial environment is being broken, and the network security risks it faces are becoming increasingly severe. On one hand, viruses in the traditional IT field can easily spread to industrial control networks; on the other hand, driven by profit motives, industrial control systems are gradually becoming key targets for hacker organizations attempting to attack and extort. Below are two recent typical cases:
-
Foxconn Factory Ransomware Attack
In November 2020, the Foxconn factory suffered a ransomware attack, with 1,200 servers encrypted. The attackers stole 100GB of unencrypted files before encrypting the devices and deleted no less than 20TB of backups. Subsequently, the attackers published a link to a payment site, demanding Foxconn pay 1,804.0955 bitcoins as ransom (approximately $34.86 million), or they would sell the stolen data on the dark web. Foxconn did not pay, and at least some of the data has now been published on the dark web.
-
Colonial Pipeline System Temporarily Shut Down
On May 7, 2021, the largest fuel pipeline system in the United States was breached, with hackers deploying ransomware that paralyzed the pipeline system connecting the major oil refining regions in the eastern United States, causing several East Coast states from Texas to Louisiana to New Jersey to panic over fuel shortages. The infected system was the information technology network of Colonial Pipeline, not the operational technology network, with the former mainly responsible for running emails and routine functions, while the latter involves the critical operations for controlling energy transport. If the virus spreads into the operational technology network, the damage would significantly increase, which forced Colonial to quickly interrupt operations and temporarily shut down.
From the above cases, it is clear that industrial control hosts, due to their universality and wide application, often become key targets for network attacks. In fact, if physical isolation factors are not considered, some inherent properties and operational status of industrial control hosts also make them more vulnerable to attacks. The lifecycle of industrial control hosts is usually long, and for stability and compatibility reasons, industrial enterprises rarely patch or install security software on industrial control hosts, resulting in a norm where industrial control hosts operate under vulnerability risks. Some industrial control hosts may have antivirus software installed, but due to long-term unupdated virus databases, their actual effectiveness is very limited. How to improve the security status of industrial control hosts, and what kind of security technologies and products are suitable for industrial control hosts?
Analysis of Whitelist Technology Application in Industrial Control Host Security Protection
Industrial control hosts are typically computers that perform specific roles, characterized by singularity and determinism, meaning that the pre-installed operating systems and business software are rarely changed once put into operation. This property makes products based on whitelist technology relatively more suitable for industrial control hosts compared to other host protection software. First, whitelist protection software tends to have better compatibility with industrial software, resulting in a lower risk of false positives after running adaptations. Second, whitelist software generally occupies less system resources, usually not causing significant performance fluctuations, thus not affecting business real-time performance. Third, since the application software running on industrial control hosts is relatively fixed, whitelists do not need frequent updates, whereas traditional antivirus and network protection software require frequent updates to their virus databases to maintain detection capabilities, and they consume more system resources. Fourth, industrial control hosts rarely receive patches, and whitelist protection software only allows programs within the whitelist to run, which can mitigate the risks of unpatched systems and vulnerabilities being exploited remotely to some extent.
2. Functions Typically Found in Whitelist Products
2.1 Whitelist Control
Whitelist control typically begins with a complete root scan of the system, recording hash values for binary files and executable files, which are then saved in the whitelist. The kernel module controls program execution based on the whitelist. When a program is detected to start, the kernel module first extracts the hash value of the starting program, then compares it with the hash in the whitelist. If the whitelist contains that record, execution is allowed; otherwise, execution is denied. For industrial control hosts, only programs within the whitelist can execute, while other unauthorized programs are blocked, thus preventing attacks from viruses, Trojans, and malware, ensuring the stable operation of industrial control hosts.
2.2 Typical Functions
Currently, whitelist products on the market typically have the following functions:
3. Testing and Analysis of Whitelist Products
3.1 Whitelist Product Testing Plan
We are not testing the functionality of whitelist products, but rather aiming to verify the actual protective capabilities of the whitelist products. Therefore, we have divided the testing methods into two aspects: the security protection capabilities of the whitelist products and the security of the software itself. For each aspect, we designed specific testing plans based on the typical functions of whitelist products, as shown below.
3.2 Issues Enumerated and In-Depth Analysis
Below, we enumerate the issues found during the testing of whitelist products and provide in-depth analysis, divided into two aspects: security protection capabilities and self-security:
3.2.1 Security Protection Capability:
Issue 1: Can bypass protection policies to execute prohibited user commands
Description: The whitelist system should prevent the reboot command from taking effect; however, the reboot command in the /sbin path does not take effect, while the reboot command in the /init.d path remains effective. Similarly, the whitelist system should prevent the shutdown command from taking effect, yet the command line poweroff –f or /etc/init.d/halt can directly shut down.
Analysis: Operating system commands are based on paths, and often the protection policy only prohibits commands from a single path, while the same command from other paths can still take effect. The solution is to include all executable paths of the commands that need to be prohibited in the protection policy; the intention of the protection policy is to prohibit a certain behavior, but this behavior may correspond to multiple commands in the operating system. Therefore, the protection policy needs to include all commands with the same function to achieve the goal of prohibiting a certain behavior. Thus, a fully reasonable adaptation of the whitelist protection policy can better leverage the protective effects of the whitelist products.
Issue 2: Can remotely exploit vulnerabilities in the operating system or business software to invade
Description: When the 135 port of the industrial control host operating system is open, it can be exploited for remote invasion; there are vulnerabilities in the Sqlite_server component of the business software on the industrial control host that can also be exploited for remote invasion.
Analysis: Although successful invasion is possible, if the unauthorized closure or destruction of the whitelist product’s protection functions cannot occur, the protective functionality of the whitelist product remains effective and continues to protect the host’s security. However, for safety, all unused network ports on the host should be closed. If vulnerabilities are found in business software or new versions are available, they should be patched or updated as soon as possible.
3.2.2 Self-Security Aspect:
Issue 3: Protection policies are stored in plaintext
Description: The protection policies of whitelist products are stored in plaintext, allowing direct identification of the meanings of the protection policies.
Analysis: The whitelist system does not encrypt the storage of protection policies, but prevents unauthorized viewing of policy files through access control functions. The advantage of this is to avoid the resource overhead of encrypting and decrypting policy files. However, the drawbacks are evident: if the access control protection function is unauthorizedly closed or fails, the policy file can be obtained and directly identified. From the perspective of depth protection, using encryption to prevent direct identification of policy content can serve as a second line of defense in case of access control failure or loss of security protection. Therefore, encrypting the storage of protection policies can significantly enhance security.
Issue 4: Whitelist protection policies lack integrity checks
Description: After disabling the whitelist protection function and tampering with the protection policy to prevent a command line from taking effect, when the whitelist protection function is re-enabled, other policies remain effective, but the tampered protection policy is no longer effective.
Analysis: Whitelist protection policies lack integrity checks, and rely on the access control function of the whitelist system to prevent unauthorized access and changes to the protection policies. However, this still poses risks; once the access control function is unauthorizedly closed or fails, the policy file can be tampered with, causing the protection policies to not function normally. Additionally, some whitelist products have enabled data integrity checks on their policy files using general database software, but if the database itself does not have access control (accessible without entering a username or password), and the integrity check algorithm used is common, there remains a risk of policy file tampering.
Issue 5: Integrity field values in data packets are all zero
Description: Monitoring the data transmitted by the whitelist product revealed that the integrity field values in its data packets are all zero.
Analysis: To be able to resist common replay attacks, the data transmission of whitelist products should include integrity checks, and using VPN or higher-level secure transmission channels for data transmission can also be employed.
Issue 6: Protection functions can be unauthorizedly disabled
Description: There are multiple ways to cause the protection function of the whitelist product to be unauthorizedly disabled. For example, by using command lines to close the protection process; adding batch scripts during the host startup process to prohibit the whitelist protection process from starting; destroying the permissions that call the protection process, preventing it from starting; or using the whitelist product’s installation program on the industrial control host (with no identity verification before installation) or maintenance tools (with no password verification before running) to disable the protection function.
Analysis: During the boot process, except for a few drivers, the industrial control whitelist product needs to start first and ensure that the protection function is effective. Providing whitelist product hardware that does not require software installation, directly connected to the industrial control host, can begin scanning its memory data for loading from the moment the industrial control host is powered on, and fully protect against unauthorized closure or destruction of the whitelist process, thus achieving stronger protective capabilities.
4. Conclusion
This article shares the functions typically found in whitelist products, product testing plans, enumerated testing issues, and in-depth analysis, hoping to provide reference for future whitelist product development. Whitelist products have become an indispensable part of security protection for industrial control hosts. To provide stronger protective measures for the network security of industrial control hosts, it is possible to develop embedded protection products based on whitelist technology for industrial devices. In this way, both industrial control hosts and devices can be protected by whitelist products, significantly enhancing the network security prevention capabilities of industrial systems, moving towards building proactive defense and intrinsic security.
