ICS Testing Guide
ICS Security Testing Guide Content
This is a work-in-progress structure focused mainly on security within energy sector (power generation and distribution)
- 1 Essentials for ICS/SCADA defence
- 2 Physical security
- 3 Review of security policies
- 4 Social engineering
- 4.1 Mass or targeted (spear) phishing campaign via email
- 4.2 Dropped USB sticks with malware nearby and inside targeted objects (buildings).(baiting)
- 4.3 Dropped CD with malware nearby and inside targeted objects (buildings) - (baiting)
- 4.4 Phone inquiries of changing passwords or performing malicious activities
- 4.5 Tailgating
- 5 Infrastructure
- 5.1 Network Segmentation, DMZ
- 5.2 Firewall
- 5.3 VPN
- 5.4 (N/H)Intrusion Prevention System/(N/H)Intrusion Detection System
- 5.5 Monitoring and SIEM
- 5.6 Network scanning and analysis of network traffic (IPv4 and IPv6)
- 5.7 Layer2 attacks
- 5.8 802.1x (NAP)
- 5.9 Vulnerability Assessment of Critical Infrastructure
- 5.10 WiFi
- 5.11 Mobile/Radio networks
- 5.12 Workstation security
- 5.13 Honeypot
- 6 Air Gap security
- 7 Inventory and cataloging of IT assets
- 8 Backup and recovery tests
- 9 Antivirus
- 10 Patch management
- 11 Disaster recovery scenarios and tests
- 12 Incident response
- 13 Revision of assets managed by third parties
- 14 Passwords
- 15 Security training for employees
- 16 Industrial Control Systems testing
- 16.1 Discovering communication interfaces
- 16.2 Identifying the processor architecture and OS
- 16.3 Firmware
- 16.3.1 Encryption
- 16.3.2 Signing
- 16.3.3 Updates
- 16.3.4 Modifications
- 16.3.5 Dumping
- 16.3.6 Static and dynamic analysis - Disassembling/Debugging
- 16.4 Communication protocols identification and analysis (Modbus, DNP3, OPC, S7, custom..)
- 16.4.1 Network protocol analysis - data structures
- 16.4.2 Network protocol cryptographic analysis
- 16.4.3 Authentication, Authorization and Access Control
- 16.4.4 Protocol fuzzing / input validation
- 16.4.5 Replay attack + TCP/IP hijacking
- 16.4.6 Denial of Service
- 16.5 Unused services
- 16.6 Timing attacks
- 16.7 Validation of the configuration file
- 16.8 Penetration testing of ICS web interfaces - OWASP Testing guide / OWASP TOP10
- 16.9 Malicious USB drive
- 16.10 Password policy
- 16.11 Logging and auditing
- 16.12 Documentation reviews
- 16.13 Review of historical vulnerabilities, security incidents, vendor fix times
- 17 SCADA
- 17.1 Vulnerability assessment
- 17.2 Communication protocols identification and analysis
- 17.3 Static and dynamic analysis - Disassembling/Debugging SCADA software
- 17.4 Unused services
- 17.5 Penetration testing of SCADA web interfaces - OWASP Testing guide / OWASP TOP10
- 17.6 SCADA updating (security patch management)
- 17.7 Password policy and local accounts rights
- 17.8 Firewall
- 17.9 Logging and auditing
- 17.10 Review of historical vulnerabilities, security incidents, vendor fix times
Essentials for ICS/SCADA defence
The challenging and ever-changing landscape of cybersecurity and the IT Sector in general is a prime example of the need for continuing professional development and as an undergraduate, BSC(Hons) IT Security, the desire to gain practical skills to complement the theory led me to a Central European internship during this summer vacation – working for Citadelo; a tightly knit team of IT security professionals dedicated to finding vulnerabilities in corporate IT environments.
The need to test every possible angle for intrusion was clarified for me whilst having an informal chat with Tomáš Zaťko, CEO. Tomáš described how Junior team members would take advice from Senior Pentesters when faced with an IT environment not revealing its vulnerabilities. This combined effort would always prove fruitful.
This, to me, indicates a number of things including the professionalism and camaraderie that is prevalent, the determination to test every possible attack vector and the CEO having a strong connection with staff, their challenges and interactions.
What it also indicates is the requirement for a thorough, determined and methodical approach to penetrate a system and this has been an overriding factor during my internship researching ICS/SCADA network security and the superior nature of some of the malware they are faced with. The ICS Battleground
As a mature student, with a background in programming, testing and application support, I was delighted to be assigned research in this complex and challenging arena – “Arena” may not be descriptive enough as it is becoming something more of a battleground for cyber-espionage and cyber-terrorism.
If you are not familiar with terms such as ‘STUXNET’ and ‘SCADA’ you may be wondering what the fuss is about? Allow me to offer a brief overview…
Industrial Control Systems (ICS) are responsible for most of humanities basic needs; heat, light, food, fuel and medicines are met by systems governed by Industrial Control; those that are part of process and manufacturing environments.
Synchronised Control and Data Access (SCADA) is the internal network for the Control System and a term that is commonly misused to represent ICS. ICS Timeline
From the following timeline it becomes obvious these systems were designed before the internet reached its current level of maturity – when they embraced Ethernet/TCPIP they became connected and this makes them highly vulnerable to attack as security provisions were not in-built.
18th Century saw the commencement of the Industrial revolution 1900s and we see remote systems being controlled by electrically operated switches (relays) 1950s Industrial hardware controlled by ticker and punch paper tape 1960s Systems become subject to distributed control 1969 Embedded systems – Programmable Logic Controllers (PLC) 1979 Modicon invented Modbus – a serial line protocol for communications between electronic devices 1986 : General purpose computers become control points for PLCs 1992 : ICS embrace TCP/IP and gain connection to the internet
Challenges and Threats
The threat, for potential cyber-espionage, on these control systems is serious, potentially catastrophic and gaining popularity in the ethical and non-ethical hacking communities. Government agencies are proactively seeking ability for the monitoring and domination of these systems.
It is a recognised fact that critical infrastructure providers can not afford complacency. Systems that were historically built for reliability, control and safety have, since their embrace of Ethernet/TCPIP, become vulnerable to cyber threats.
When you are pitted against heavily financed and military trained groups which may be umbrella’d under cyber-terrorism or cyber-espionage, the threat and potential for significant service disruption, hardware damage, financial costs and worst-case – the loss of life, cannot be overlooked.
If we ask ourselves “What has been solved?” in regard to cyber security, we have to consider the definition of the word. It can be viewed as effectively dealing with a problem. Has cybersecurity been solved? The answer can only be “No”.
Whilst the necessary analysis of known and specific malware can raise awareness and implementations to counter these attacks; focusing on particular malware examples can shrink the mindset of the defenders. There are many tools and techniques available for hardening of your system but malware is continuously evolving.
It is not unreasonable to deduce that security implementations are becoming more and more layered. There is good reason for this, for example, many ICS systems cannot tolerate downtime – they measure performance in milliseconds.
If we consider Black Energy malware, which was recently used in part on the Ukrainian Power Grid attack in 2015, which resulted in over 225,000 Customers’ electricity supply being disrupted for hours, we can find documented evidence that during 2015 at least 12 different versions were in circulation. Yes! Black Energy is still alive and well and these versions indicate that their targets are specific.
The challenge is increasing exponentially. Attacks are more and more frequent, more elaborate, more strategically planned, designed and executed. We have to think like Hackers; very serious and highly experienced Hackers. Next, we have to think ahead – will the next attack be an evolvement of existing malware, a combination or something as yet un-encountered.
“Forewarned is Forearmed” is a relevant adage and some experts recommend ‘Attack Trees ‘as the best defence against future attacks but there are arguments against this type of modelling. An attack tree aims to map out all the possible entry points into a network or system which is far from irrelevant but we need to consider the underpinning methodology.
What is needed is a collaborative effort where the gain is not financial but relevant to all those involved in cyber security and, certainly not least important, the essential involvement of the ICS industry whose knowledge and experience must be taken into careful consideration. Historical consequences
The issue of security of ICS systems became largely significant especially after the huge exploit in particularly sensitive area of nuclear development in 2010. The Stuxnet virus attacked alongside others mainly Iranian research centers and destroyed the whole fifth of their nuclear centrifuges. The whole attack aimed primarily at the so-called Programmable Logic Controller (PLC) which is a set of end controllers that directly communicate and manage the actual process or task. Any committal capable to affect the PLC functioning is an immense risk which effectively means that the attacker – hacker – is able to replace the management of the operation by his own commands. Despite the fact that the antiviral programs and tools for analyzing and detecting threats are quickly improving, cyber mafia is ahead and offers its clients offensive means based on the so-called zero-day vulnerabilities, i.e. yet unknown vulnerabilities and exploits which can be used for a successful penetration. It is more than naive to believe that the ICS area would remain outside the spotlight. On the contrary, at the hacker forums can be noticed further development of the tools similar to Stuxnet and one can only guess how far their development has advanced.
Protection of the server room
Protection of external objects
Protection of access to internal networks
Review of security policies
Mass or targeted (spear) phishing campaign via email
Dropped USB sticks with malware nearby and inside targeted objects (buildings).(baiting)
Dropped CD with malware nearby and inside targeted objects (buildings) - (baiting)
Phone inquiries of changing passwords or performing malicious activities
Network Segmentation, DMZ
(N/H)Intrusion Prevention System/(N/H)Intrusion Detection System
Monitoring and SIEM
Network scanning and analysis of network traffic (IPv4 and IPv6)
Vulnerability Assessment of Critical Infrastructure
Air Gap security
Types of attacks
Mosquito Attack (2018) https://thehackernews.com/2018/03/air-gap-computer-hacking.html
Inventory and cataloging of IT assets
== Penetration testing of web applications (web applications hosted in critical infrastructure and accessible from the Internet)==
Backup and recovery tests
Disaster recovery scenarios and tests
Revision of assets managed by third parties
Password policy and rotation
The authentication mechanism is often as strong as used credentials (particularly passwords). Therefore, the passwords that protect privileged areas of ISC devices must meet a strong password policy. Insufficient or weak passwords increase chances for an attacker to gain an access to the ISC device by leveraging a dictionary attack or a brute-force attack. Notorious passwords such as "admin, root, 0000, 1111, system.." and their other deviation, that can be easily guessable are still present. An attacker may use automated tools to gain a password within few minutes.
The goal of this test is to verify if the ICS system implements an anti-bruteforce technique and to determine complexity of the password - length; old-password reuse, expiration time.
How to Test
1. What is the minimal and maximal length of passwords?
2. Do the passwords have to contain uppercases, lowercases and numbers?
3. Do the passwords have to contain special characters? (e.g: %$#!)
1. Is it possible to use a username as the password?
2. How often is a password change enforced?
3. Is it possible to change password to the same value as old passwords had?
1. What kind of anti-bruteforce technique is implemented? (Is the account blocked temporarily or permanently?, an implementation of CAPTCHA)
Open source tools: • THC Hydra - https://www.thc.org/thc-hydra/
o A very fast network logon cracker which support many different services.
• Ncrack - https://github.com/nmap/ncrack
o Ncrack is a high-speed network authentication cracking tool. Protocols supported include RDP, SSH, HTTP(s), SMB, POP3(s), VNC, FTP, SIP, Redis, PostgreSQL, MySQL and Telnet.
• Metasploit - https://www.metasploit.com/
o Metasploit is a vulnerability scanning and exploit development tool. It contains several modules for brute-force login.
Proprietary tools: • XXX • YYY
Example: Bruteforce attack using THC Hydra for ICS web interface protected by HTTP Basic Auth.
root@kali:~# hydra -l admin -P passwords.txt -t7 -f myics.local http-get / Hydra v8.2 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2016-10-26 12:30:10 [DATA] max 7 tasks per 1 server, overall 64 tasks, 7 login tries (l:1/p:7), ~0 tries per task [DATA] attacking service http-get on port 80 [http-get] host: myics.local login: admin password: 0000 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2016-10-26 12:30:11
The abovementioned example proves that the ICS device does not implement any anti-bruteforce techniques. A string password policy is not implemented either, since the revealed password is not a complex one.
Should it be the case that the login to the web interface is performed by a proprietary protocol and a documentation is not publicly available, an attacker has to utilize techniques of reverse engineering. For more detail information about reverse engineering refer to the section “Protocol analysis”. After the process of reverse engineering the attacker must implement his own automated tool for the brute-force attack. This process may be time-consuming, however it does not stop the determined attacker. It is recommended to leverage one of the popular programming languages such as Python or Ruby, which provides many modules and allows even non-proficient programmers to write it within few lines of code.
See also OWASP "Use and misuse case https://www.owasp.org/index.php/File:UseAndMisuseCase.jpg"
References and Resources
Enforce usage of strong passwords policy. A password strength policy should contain the following attributes:
• Minimum length
• Mixture of special, uppercase and lowercase characters and numbers
• Maximum password age
• Must be unique from all previous passwords
• Passwords must not be the same as the username
• Default factory passwords should be changed immediately after first usage
Moreover, implement: • Two-factor authentication (2FA) • Anti brute-force mechanism