Siemens SIMATIC PLCs (Security Bug Reveals Hardcoded Universal Key)

Once again, another networked device has been found to implement some shockingly poor security features with the use of a universal private key that is common to all devices across its product range. What exactly happened with the SIMATIC PLCs, how does poor security threaten devices, and what do engineers need to do?

Siemens SIMATIC PLCs (What’s Happened?)

A recent announcement from security researchers at Claroty has revealed a serious vulnerability with Siemens SIMATIC range of PLCs. The PLCs that face the newly discovered vulnerability are designed for use with continuous control environments commonly found in most manufacturing processes such as motor control, conveyor belts, the timing of actuators, and part counting.

The vulnerability, which has now been given the designation CVE-2022-38465, results from the use of a single private key that is common throughout all similar PLCs. The key is used to encrypt data locally to the device, and as this key is identical for other SIMATIC PLCs, having access to the key allows an attacker to exploit all other PLCs.

Additionally, the researchers were able to obtain the key via an earlier exploit, CVE-2020-15782, which allows for a remote attacker to write arbitrary data and code to protected areas of memory over a network using TCP port 102. To make matters worse, this prior vulnerability allows for unauthorised access over the port meaning that outside attacks can be easily staged once internal network access is available.

Finally, the researchers noted that the hardcoded private key allows for full control over the PLC, and as such allows for an attacker to remotely interfere with industrial processes. According to Siemens, the vulnerability can be mitigated against by following the recommendations outlined in SSA-568427 while also updating the TIA Portal to V17 and the CPU firmware.

How does poor security threaten devices?

In the case of the SIMATIC PLCs, Siemens stated that the use of a singular private key common amongst all devices resulted from the decision to use symmetric cryptography in its device range. At the time of manufacture (2013), Siemens claims that there were no practical solutions for dynamic key distribution and management, especially for industrial control systems. 

While this claim may be true to some degree, the ideal of having thousands of devices available on the market all using the same private key is begging for vulnerabilities. It may turn out that symmetric cryptography only allows valid firmware to be downloaded onto the device, and this does help to prevent unauthorised firmware that could be infected with malware. But alternatives to symmetric cryptography do indeed exist with one example being certificates. It is more than possible to use standard internet protocols to not only create encryption methods to protect firmware from infection, but to also use certificates and checksums to validate the contents of downloaded firmware.

But by far the biggest vulnerability faced with modern devices is the very thing that makes them useful, an internet connection. The moment a device has remote access capabilities, all kinds of problems arise which require engineers to be extremely careful about what ports they open, where they store keys, and protocols used that may or may not allow for binary data to be shared, stored, and executed. If strong security practices are not followed, the deployment of thousands of devices around the world leaves the device owners at serious risk.

One common attack deployed against IoT devices is to gain network access. A network that has strong passwords is only as strong as its weakest link, and if an IoT device can be hacked to get the network SSID and password, then an attacker can exploit that to gain unauthorised network access, and from there, either control the network or use the connection for illicit activities.

Another common attack experienced by poor security in IoT devices is the deployment of bots (also known as zombies). In essence, a remote IoT device is targeted with rouge firmware that allows the device to continue as normal, but also allows for remote control. Whenever a hacker wishes to perform a large-scale DDoS attack, they can initiate thousands of IoT devices around the world to start making bogus connection requests to the target server, and this can cause the server to fail. 

What do engineers need to do?

With the increasing number of security concerns, it is becoming more clear what engineers need to do; start with security in mind and compartmentalise.

When starting new projects, engineers need to establish security from the very first line of code right up until the last line of code. For example, functions that can be arbitrarily called need to ensure that they are foolproof such that buffer overflows do not cause illegal use of memory or incorrect data types cause the function to behave unexpectedly.

Firmware should also refrain from any hardcoded keys or passwords, every device manufactured should be programmed uniquely during manufacture, and firmware updates need to take advantage of the certificate validation and other asymmetric security measures. Even the ush of a physical button to enable updates can provide enormous amounts of protection against OTA firmware updates containing malware.

Overall, engineers need to recognise that devices connected to the internet are vulnerable to numerous dangers that must be protected against. If projects are not built from the ground up with security in mind, it can be extremely challenging to identify security threats after the fact.