SCL Slip-Ups: Unveiling Siemens Programming Flaws That Hackers Love
In the intricate world of Industrial Control Systems (ICS) and Operational Technology (OT), the Structured Control Language (SCL) is widely utilised for programming Siemens PLCs. However, even seasoned developers can make errors that open doors to cybersecurity vulnerabilities.
In this article, I will explore some common mistakes made in SCL programming and how hackers can exploit them, providing examples to illustrate these points.
1. Inadequate Authentication and Authorization Controls
Mistake:
Neglecting to implement robust authentication and authorisation checks within the
SCL code that interfaces with the HMI (Human-Machine Interface) or other control systems.
Example: Consider an SCL program that manages user access levels:
FUNCTION AccessControl: INT VAR_INPUT
UserID : INT; END_VAR
CASE UserID OF 1: RETURN 3; // Admin level 2 TO 10: RETURN 2; // Operator level
ELSE RETURN 1; // Guest level
END_CASE; END_FUNCTION
Vulnerability: If user authentication is poorly managed, unauthorised users could exploit this by altering their ID to gain higher privileges. Without proper checks, a simple modification in the input can provide access to critical system controls.
2. Insecure Data Transmission
Mistake: Unencrypted or weakly encrypted communications between PLCs and other networked devices.
Example: Data transmission within an SCL program that sends sensor readings to a central monitoring system without encryption:
DATA_BLOCK DB1 SensorValue: REAL;
END_DATA_BLOCK
DB1.SensorValue := GetSensorReading(); SendToMonitor(DB1.SensorValue);
Vulnerability: Transmitting sensitive data without encryption can allow attackers to intercept and possibly alter the data, leading to misinformation or malicious actions on the network.
3. Lack of Input Validation
Mistake: Failing to validate external inputs that are used in control logic.
Example: An SCL routine that adjusts machine settings based on external sensor inputs without checking the validity of the data:
FUNCTION AdjustSettings: VOID VAR_INPUT
ExternalTemp : REAL; END_VAR
IF ExternalTemp > 100 THEN SetMachineSpeed(FAST);
ELSE SetMachineSpeed(SLOW);
END_IF; END_FUNCTION
Vulnerability: Without proper validation, this function is susceptible to injection attacks where false data leads to inappropriate machine behaviour. This can result in physical damage or unsafe operating conditions.
4. Error Handling and Logging Deficiencies
Mistake: Inadequate error handling and logging that fail to capture abnormal or malicious activities.
Example: An SCL program that controls a valve based on pressure readings but does not log errors or unusual activities:
FUNCTION ControlValve: VOID VAR_INPUT
Pressure: REAL; END_VAR
TRY IF Pressure < MIN_PRESSURE THEN
OpenValve(); ELSE CloseValve(); END_IF; EXCEPT
ON ERROR DO // Error handling missing
END_TRY; END_FUNCTION
Vulnerability: Without error logging, unexpected or malicious changes in pressure readings that cause the valve to behave incorrectly may not be detected or corrected in time, compromising the safety of the entire system.
5. Hardcoded Credentials
Mistake: Embedding fixed usernames or passwords directly in the SCL code.
Example:
CONST Username : STRING := 'admin'; Password : STRING := 'pass1234';
Vulnerability: Hardcoded credentials are a severe security risk as they can be easily extracted by anyone who gains access to the program files. Once discovered, these credentials can be used to gain unauthorised access to the system.
Conclusion
The examples above illustrate how common programming errors in SCL can lead to significant vulnerabilities. Developers must adopt best practices in cybersecurity, including thorough testing, code reviews, and ongoing education on security trends. By understanding and mitigating these risks, we can better protect our critical infrastructure from cyber threats.
Rodrigo Mendes Augusto
