SCADA HoneyNet
PLC Simulation Concepts, Design, and Implementation

Venkat Pothamsetty
Cisco Systems, Inc.
Critical Infrastructure Assurance Group (CIAG)

Background

Programmable Logic Controllers (PLCs) are common in some industrial applications (especially discrete manufacturing) and increasingly have network interfaces which support Ethernet and TCP/IP protocols as well as more traditional communication interfaces such as MODBUS, DeviceNet, ContrlNet, Foundation Fieldbus, etc.

As is the case with any network device, different vendors implement their own shells on telnet and support various FTP commands, depending on their application requirements. The Ethernet communication module of the PLC typically runs an embedded operating system that includes standard network protocol as well as implementations of industrial network protocols such as Modbus/TCP or EtherNet/IP. For example, telnet and FTP servers are common and have identifying information which can be used to determine the vendor and version of software. Even on the industrial protocol side, we saw that not all PLCs support all commands of a given industrial protocol, so that implementations can be fingerprinted. Depending on the type (and capabilities) of the device there may be slight differences in the protocol.

All of these characteristics make it possible for attackers to identify specific versions and vendors of device and allow us to be able simulate the devices as well.

Implementation Approach

We followed the following approach when simulating a PLC:
  • Implement the generic features so that users can easily change them, add new features and re-submit them
  • The feature implementation should be so that the code will serve as examples for the users to change it according to their own needs.
  • Once the users submit enough code for more implementations, we visualize putting them into templates so that a generic configurable engine can load them according to a defined configuration
  • Components Needed

    The following are the network components in a PLC that need to be simulated:
  • The TCP/IP Stack of the PLC
  • The simulation of the Modbus/TCP server implementation.
  • The simulation of the FTP server, that is found on some PLCs.
  • The simulation of the Telnetd server, that may be found on some PLCs.
  • The simulation of the management HTTP server, which increasingly common on PLCs and other industrial network devices.
  • Note that the scripts above can be used along with honeyd or standalone and need root permissions because they have to bind themselves to previleged ports below 1024.

    Simulating the TCP/IP Stack of the PLC Communication Module

    In order for Honeyd to simulate the TCP/IP stack of a PLC, adding the TCP/IP signature of the device to the honeyd's nmap.prints file would be sufficient. But in oder for the attacker to feel that the stack is a PLC stack, the signature has to be in the database of the scanning tool that he is using. Though we tested that by putting the signature in nmap-os-fingerprints file (which is Nmap's fingerprint database), we do not know of any scanner having the signature of any PLC at the time of writing this document.

    Simulation of the Modbus/TCP server

    The PLC can have multiple industrial protocol implementations which will listen at their corresponding ports for packets from the corresponding clients.

    We decided to simulate the Modbus/TCP server as a proof of concept because the protocol is simple. ModbusSrvr.py starts out with listen() method, which binds port 502 and waits for client connections. Once a client gets connected to it, it initiates a thread to serve the client and continues to listen on the port for further client connections. The thread calls the processData() method which extracts the top Modbus Header data and calls the method sendResponse() to send the correct response.

    In MODBUS protocol, the response depends on the function code of the query. Since we are not the experts of the protocol and we do not necessarily expect the users and developers of SCADA honeynet to be experts on industrial protocols, we followed and recommend the crude approach of observing and analyzing the communication packets between some clients and the PLCs. Based on the observation and analysis we chose to implement the "top responses" and to send an "error code" for the rest of the queries. The following are the observations:

    We implemented the responses to read_coil (function code 1), write multiple registers (function code 16), diagnostics (function code 8 and the exception response with code 1(unknown function code). We welcome the users to study and analyze other responses and implement them. The script can be found in plc/modbusSrvr.py file. We also included our test file, modbusScanner.py, to send modbus packets towards the modbussrvr.py implementation. The users should manually go into modbusScanner.py and he can edit values of different modbus headers.

    Simulation of the FTP server

    The honeyd has shell script based FTP simulation, we decided to rewrite it in Python because it is an easier language for and we want to add more functionality to it. We implemented the following commands:
  • The user command, when the user gives a username
  • The password command, when the user gives the password
  • The list command, when the user gives a ls command
  • The syst command, which gives the user information about the system
  • The port for transferring data for various commands
  • It has various points where it writes information into the logfile and the user needs to change that to suite his or her own needs just by invoking writeLog method and passing it the string to write. The writeLog methos opens up "/var/log/ scadahoneynet.log" and appends information to it by default. The user should change the responses given as variables given at the top (such as ListCommandResponse and Syst CommandResponse of the file which suites their needs. The script can be found in plc/vxworks-ftpd.py

    Simulation of the Telnet server

    We decided to write a specific telnetd script because most of the PLCs run embedded systems and the shell has a unique set of commands. We implemented help and ls and cwd commands and the user gets the list of commands when he just hits return. The script can be found in plc/vxworks-telnetd.py

    Simulation of the Web server

    Frequently the user connects to the web server of the device and a Java applet is downloaded to the client and runs within the web browser. In some cases, the applet will them make connection back to the PLC using protocols like Modbus/TCP and FTP for gathering data. The concept of an applet tracking the information of the downloader is new to the Honeynet world, we call them "Honey Applet". The problem with applets is that they would not be allowed to communicate with any other hosts other then the hosts that served the applet (http://java.sun.com/sfaq/). So make sure you have the hosIP variable as the exact hostname tof yours. Since each PLC has its own user interfaces, again our design and implementation goals are to write a generic enough proof of concept code which touches on most of the features in PLC applets. We used Java Swing classes to draw the Applet and we used Java SUN's 1.4.2 for development.
  • The Button, and feature to track button clicks
  • The Textfield, and feature to track text addition and removal
  • To connect back to a host on port 502 and give information back. the user can run netcat like TCP listener to get the data back from the applet.
  • The connectBack() will connect back to the ip described statically in the code, encoded into the variable, host. We called connect back when the CA button is pressed or when the test is changed in TransmittButton for Demonstration purposes
  • The use of threads and repaint with changing numbers in text fields
  • The script can be found in plc/StatusApplet.java It needs to be debated whether the Applet can be replaced with a PHP script and how much would an attacker know about it if it were a PHP script

    Send coments to scadahoneynet-talk@lists.sourceforge.net or ciag-tools@cisco.com

    SourceForge Logo