As white-hat hackers, ultimately we want to be able to develop exploits for SCADA/ICS systems. In this way, we can find vulnerabilities and exploits before the Black Hats and patch the vulnerability before any bad guys take advantage of it. In this article, I want to give you a basic outline of the process of developing a zero-day exploit against SCADA/ICS systems.
Developing a zero-day exploit for SCADA/ICS systems is distinctly different than it is with Windows systems. The key difference is the heterogeneity of SCADA/ICS systems. In other words, there are multiple protocols, multiple vendors and multiple hardware configurations. This heterogeneity can make exploit development is some cases much easier, and in other cases, much more challenging.
I hope it goes without saying that one needs to understand SCADA/ICS systems before pursuing exploit development. Make certain that you have studied my entire series here on SCADA Hacking before pursuing SCADA exploit development.
There five basic steps to zero day exploit development in SCADA/ICS systems.
1. Select Your Target
Unlike typical PC systems and networks, when beginning to develop an exploit for SCADA/ICS system you must first settle on a target. With dozens of protocols and vendors, you need to first determine what is your target. This target can be a protocol such as MODBUS, a particular PLC such as the Seimens S7-1200 or a particular industry such as the oil pipeline industry.
If you choose to target an industry, you will need to do additional research on what systems, protocols and PLC’s that industry is using. So, for instance, if you are targeting the oil pipeline industry, you would need to do your research to know that the Honeywell PLC’s using the PROFIBUS protocol is among the most popular in that industry. Knowing that, you will then need to learn everything there is to know about that system which takes us to step #2.
2. Study and Research the Target’s Documentation
Once you have selected a target, you should study the target’s documentation. In most cases, the manufacturer posts its documentation online in a PDF form to provide developers and customers the necessary information. This documentation can help you to understand what the 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 their website. This 864-page manual gives us detailed information on the inner workings of this widely-used PLC. Study it carefully for hints at vulnerabilities in this system, especially the sections on Device Configuration, Basic and Extended Instructions, Communication and the Web Server. Nearly every manufacturer provides similarly detailed operating manuals available online.
3. List and Prioritize Accessible Interfaces
In most cases, the target will have at least one interface that is used to communicate and manage the system. These interfaces can be a TCP socket, a sensor, a USB port or any way that information comes in or goes out of the system. In some rare cases, the target may be totally offline which makes exploitation more problematic, but not impossible (remember, the Iranian uranium enrichment facility at Natanz, the target of Stuxnet, was offline). For now, let’s focus on those facilities with an accessible interface.
Most SCADA/ICS facilities have a HMI or Human Machine Interface for monitoring and controlling the facility as well as a Data Historian to archive information about the system. Both of these usually communicate through a TCP socket and may provide an entry point to the SCADA system.
4. Analyze and Test Each Interface
Once we have a list and priority for each interface, now we can begin the analysis and testing phase. This is a key step in the exploit development process and probably the most time-consuming.
We have at least three ways to approach this process and they require some high level skills. These include;
1. Fuzzing
2. Static Binary analysis
3. Dynamic binary analysis
It is beyond the scope of this article to detail each of these processes, but I will try to provide a short summary below.
Fuzzing
Fuzzing is the process of throwing large amounts of random data at an interface and watch to see what happens. This is usually an automated process conducted with a fuzzing application such as Powerfuzzer, Peach, Aegis, or Defensics.
The idea here is to attempt to break the application or system with this random data. If we can find a string that breaks the application or system, we may be on our way to a vulnerability. Obviously, a string that breaks the system has the potential to be used as a DoS attack and may lead us towards other vulnerabilities. Ultimately, we are hoping that it might lead us to a buffer overflow that could be exploited to run our remote code.
Static Binary Analysis
As the name implies, static binary analysis involves opening and analyzing binaries without running the code. In this way, we can gain some insight into what the code actually does. This usually requires a dis-assembler such as IDA Pro. IDA Pro is the standard for disassembly in this type of analysis (look for my upcoming series on Reverse Engineering and Exploit Development using IDA Pro).
Dynamic Binary Analysis
Sometimes we need to actually run the code to understand what it does. This is where dynamic binary analysis comes in. In static binary analysis we use a dis-assembler like IDA Pro. In dynamic binary analysis we need a tool that allows the code to run and enables us to stop it at breakpoints to analyze what instructions are being executed and what is in various memory locations. These tools are know as debuggers. Tools such as IDA Python and Immunity are excellent debuggers.
These tools will allow you to run the code, breaking at key points to study and analyze the assembly code and then examining what is in key memory locations. Often, in this process we can find flaws in the code that will enable us to break the system.
5. Exploit Vulnerabilities
After running this analysis, hopefully, 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 run remote code on the target 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. These can often be found in the documentation in Step #2 or take a look at my SCADA default password list.
I hope you now have a basic framework to work from to develop your zero-day SCADA exploit. I will be starting a Reverse Engineering series in January where we will learn how to do both static and dynamic binary analysis using IDA Pro and Immunity for exploit development, so keep coming back my aspiring hackers to learn the most important skill set of the 21st century-hacking!
