ICS security professionals should report ICS vulnerabilities to the vendor before attackers discover them and offer the vendor with remediation suggestions, mitigation measures, and security solutions to avoid network attack risks before the vulnerabilities are malicious exploited.
Compared with Windows systems, a quite different method is used to assess ICS systems due to their heterogeneity. In other words, ICS systems involve various protocols and hardware configurations and more than one vendor, making it easier to develop exploits that are challenging to develop otherwise.
Before creating exploits, you must have a full grasp of ICSs. Introduction to ICSs is not a key focus of this document and therefore omitted here.
Risk assessment for ICSs consists of six steps:
Select a target.
Since ICSs are unlike typical PC systems and networks, for assessment of attacks against ICSs, you must first identify targets. With dozens of protocols and vendors, you need to first determine what is the target, such as a protocol like Modbus, a particular programmable logic controllers (PLCs) like Siemens S7-1200, or a specific industry like the oil pipeline industry.
If you choose to target a specific target, you need to do more research in systems, protocols, and PLCs used in this industry. Take the oil pipeline industry as an example, research is needed to learn that Honeywell PLCs using the PROFIBUS protocol are the most popular in this industry.
Study the target file.
In most cases, manufacturers release documents online in PDF format, providing essential information to developers and customers. These documents describe what a system is supposed to do. This documentation can be a rich source for finding and developing key vulnerability information.
For instance, if you were working on developing an exploit for the ubiquitous Siemens S7-1200, Seimens provides us plenty of documentation at its website. This 864-page manual gives us detailed information on the inner working of this widely-used PLC. You can study it carefully for hints at vulnerabilities in this system, especially the sections on Device Configuration, Basic and Extended Instructions, and Communication and the Web Server. Nearly each manufacturer provides online user manuals.
List and prioritize accessible Interfaces.
In most cases, the risk assessment object has at least one interface for communications and system management. This interface can be a TCP socket, sensor, USB port, or any manner in which any information can go in or out of the system. In rare cases, the object is offline, making it difficult to exploit but not impossible (remember that the Iranian uranium enrichment facility at Natanz, the target of Stuxnet, was offline).
Most of ICS systems implement communications via TCP sockets, which can be considered as a factor for introduction of risks.
Analyze and test each interface.
Once you have the interface list and priorities in hand, you can set out to assess system risks. This phase is a key step and also may be the most time-consuming one. You can complete this step with at least three methods which may require advanced skills.
- Fuzz testing
Fuzz testing is a process of throwing large amounts of random data at an interface and watch to see what happens. The fuzzy testing process is automated by a fuzzy testing program such as Powerfuzzer, Peach, Aegis, or Defensics.
If the random data sent to the system contains a string that can compromise an application or system, we may be on our way to a vulnerability. Such a string may be exploited for denial-of-service attacks and potentially causes other risks, finally triggering a buffer overflow that could lead to remote code execution.
Learning about the format of network packets of certain major communication protocols, you can compile data templates to assess and verify risks in a targeted manner.
- Static binary analysis
Static binary analysis involves opening and analyzing binaries without running the code. In this way, we can have an in-depth understanding of the actual role played by the code. Usually, this requires disassembly programs like IDA Pro.
- Dynamic binary analysis
Sometimes we need to actually run the code to understand what it does. This is exactly where dynamic binary analysis comes in. In static binary analysis, we need a robust disassembly program like IDA Pro. In dynamic binary analysis, we need a tool to run the code and suspend its running at a breakpoint to analyze what instructions are being executed and what is in various memory locations. Such a tool is known as a debugger and IDA Python and Immunity are good examples.
Code can run in a debugger which in turn traces the code running. In this case, developers will study and analyze assembly code at key points and check contents at crucial memory locations. In this process, it is easier to find code defects that are exploited to compromise the system.
Assess risk verification results.
After making this analysis, you have discovered at least one vulnerability in the code or system. Sometimes, these vulnerabilities will include running a bit of code to stop the PLC (DoS) or running remote code on the target system enabling you to take control of the system. Many of these systems have hard-coded passwords that when discovered will enable you to take control of these systems. From the business perspective, special attention should be given to risk points during risk assessment of ICS environments.
Provide remediation methods and protection suggestions.
Security suggestions should be provided to explain how to mitigate risk points. Generally, such suggestions will be provided at the following levels:
- Code-level
Defect risks that are found in the system will be submitted to the system manufacturer whose developers will address the defects at the code level. This proves to be the most effective way for defect remediation. However, this method is not perfect as it takes a long time from patch release to patch application on all concerned systems and system update may bring high business risks.
- Network-level
Communication behaviors are managed and controlled for vulnerable objects to make sure that communications are conducted among trustworthy and controllable devices.
- Business-level
Risk assets will be divided into regions based on their business properties. Inter-region communications will be controlled and managed according to security policies that include but are not limited to measures at the network level and physical level. Risk forecast should be made and security operation manuals should be developed in advance to make sure that emergencies can be handled properly.
In short, security is a process in which attackers and defenders fight a long battle with each other. For ICSs, risk assessment should be conducted regularly (such as during breakdown maintenance) for different objects in different phases to make ICSs better withstand attacks and ensure the continuity of ICS business.
Reference:
