Can you only communicate to a PLC using associated software?

Question

Apologies if this isn't the right forum, but I'm trying to understand SCADA network architecture, and specifically how the Stuxnet virus was able to change the control logic on PLCs. I think that it used the STEP 7 software running on a computers connected to PLCs to update their logic, while simultaneously changing DLL routines for the STEP 7 software so that anyone querying the logic on said PLCs would see the original logic. I gather that to read the logic on the PLC the STEP 7 software must be able to read the memory blocks and then 'decompile the code', since PLCs seem to be programmed in assembly code (or a graphical representation of it), and as such there is a 1-1 mapping with the machine code on the PLC. Is all of this correct so far?

My main question is about whether it is possible to change the logic on a PLC without using programming software, just by sending a command over a SCADA network, and also if PLC memory can be read without using said software. The documentation for the Siemens S7-400 PLC seems to suggest that physical hardware interactions are needed to change the logic (a knob on the PLC has to be turned), so did Stuxnet exploit a vulnerability in the Siemens STEP 7 programming software to bypass this, or was this feature perhaps only introduced after Stuxnet as an additional security measure?

This question extends to other PLCs as well - not just Siemens.

Many thanks.

Answer 1

The book, Hacking Exposed Industrial Control Systems: ICS and SCADA Security Secrets & Solutions, covers PLC discovery, scanning, modification, intrusion, malware, et al very-well.

For PLCs that connect to TCP/IP-based Modbus or Step7 Communications, in particular, the book mentions many ways to control the PLCs over the network without using the vendor-supplied apps.

For example, with Modbus TCP, one can use modbus-cli to control PLCs including reading or modifying memory (e.g., coils, registers). If you want to discover Modbus TCP devices, you can use the Nmap NSE script, modbus-discover, and to conduct packet-level operations use Wireshark (or tshark) for capture and modbus-vcr for man-in-the middle attacks.

Other tools such as plcscan will discover Modbus TCP and Step7 (s7comm) devices. The s7-info Nmap NSE script will provide more information on the s7comm devices found.

Hacking Exposed Industrial Control Systems also covers Stuxnet in varied depth with links to many other papers such as Symantec's w32-Stuxnet Dossier and the BlackHat 2011 Talk by Dillon Beresford on S7 PLC Exploitation. Here are the basics that the book summarizes:

Stuxnet’s total composition consisted of three modules: one worm and two payloads. Stuxnet was traditionally introduced into an environment via a USB flash drive or external hard drive. Immediately on insertion of the infected media, Stuxnet’s worm capability laterally looked for any system with Siemens Step7 software running. Stuxnet performed this search by using techniques such as peer-to-peer RPC (https://en.wikipedia.org/wiki/Peer-to-peer) to help bypass the system’s possibility of not being Internet connected. If Step7 was not found on any laterally connected system, Stuxnet went dormant for a period of time before rescanning the environment. In the event that Step7 was identified, a combination of one or both payloads were executed.

Of the two payloads contained within Stuxnet, one attacked the Siemens S7-315-2 PLC, which was primarily being used in high-frequency drives controlling Iranian centrifuges. The other payload, which is less known, performed a Man-in-The-Middle (MiTM) attack within the PLC. The payload took any input going to the PLC’s I/O modules and faked them so any logic within the PLC worked off incorrect logic. The payload then told the PLC what to do, instead of the PLC listening to the logic on the system itself. This was the first time any known malware hid modified PLC code, making Stuxnet the first “PLC rootkit”

and on Siemens S7comms:

S7comms, or Step 7 communications, is a Siemens protocol implemented on an ISO protocol that is not open and has very tight controls. For the 200/300 families of PLCs, you can find some basic information about the protocol via a Wireshark dissector that is only partially implemented.

including a packet trace of S7 in action with Wireshark:

The book provides many other resources which I've supplied here along with some others for additional reference --

• ICS devices on Shodan -- https://www.shodan.io/search?query=port%3A102
• Step7 attack (e.g., brute-force) scripts -- https://github.com/atimorin/PoC2013/tree/master/S7
• ScadaStrangeLove SCADAPASS -- https://github.com/scadastrangelove/SCADAPASS
• https://github.com/atimorin/scada-tools
• https://github.com/ITI/ICS-Security-Tools
• http://www.samuraistfu.org/resources
• http://www.robertmlee.org/a-collection-of-resources-for-getting-started-in-icsscada-cybersecurity/

Answer 2

The short answer is no, you do not necessarily need the official software.

For certain vendors, the community has developed tools to directly interact with PLCs.

For Siemens, you have snap7 which is a open source S7 (the proprietary engineering protocol Step7 uses) communication library. A python wrapper also exists (python-snap7).

You can then start/stop the CPU, download/upload logic, etc.

The programs you manipulate with snap7 are programming blocks in the form of a bytecode called mc7. It is not readable but there is a mapping to assembly-like language STL (Statement List) which is one of the programming language featured in Step7.