Introduction
During the development lifecycle of a new product, it is tempting to quickly fulfill security requirements by blindly applying protection primitives on top of already existing components. However, implementing security measures without a proper understanding of the underlying context and the effective threat model may actually result in a decrease of the overall security posture of the product.
Recently, we had the opportunity to do a security analysis of the Siemens PXC4.E16, a building automation system (BAS) of the Desigo/APOGEE family for HVAC and building service plants. In this blog, we are publishing the details of a vulnerability (tracked under Siemens SSA-626968 and CVE-2022-24040) that was caused by an improper implementation of the password-based key derivation mechanism for user accounts. It also could have been abused to perform a Denial-of-Service (DoS) attack against the controller.
Secure Password Storage
Storing credentials in cleartext into a memory device (be it persistent storage, or even the device RAM if for a long time) constitutes a risk for the overall security of a system. There might be multiple ways in which a cleartext password can be compromised: directly dumping its value from the physical memory, obtaining access to a primitive that allows it to read it logically, indirectly analyzing exported backups of the device, etc.
To avoid this problem, passwords were first substituted with digests generated via cryptographic hash functions. For example, one-way functions that rapidly produce a fixed size output given an unbounded input will simultaneously make it mathematically hard (given a certain output) to recover the generating input.
Although perfectly adequate for many security-related use cases, directly using cryptographic hash functions for password storage purposes did not prove to be the correct solution. In the case of digests solely generated from password values, pre-computed tables of hashes (the so-called “rainbow tables”) allowed the search time of a password, given the generated digest value, to be drastically reduced. Additionally, the fast nature of cryptographic hash functions in generating digests from inputs made the generated digests severely at risk of cracking attacks, especially when executed via highly parallelizable computing devices such as GPUs.
To solve these and other issues, password hashing functions, over time, have been replaced by password-based key derivation functions. These functions are algorithms that perform a considerable number (usually thousands) of sequential iterations of cryptographic hash functions to generate a digest from an input password value, with the final aim of making brute-forcing attacks on average computationally infeasible. Noteworthy examples of these functions include Password-Based Key Derivation Function 2 (PBKDF2), scrypt, and Argon2.
Introduction to PBKDF2
PBKDF2 is one of the few key derivation functions recommended by the National Institute of Standards and Technology (NIST) and that has Federal Information Processing Standards (FIPS)-140 validated implementations.
As per RFC2898, besides the password, PBKDF2 requires inputs as:
- A pseudorandom function (PRF),
- A salt, as string,
- An iteration count, as a positive integer,
- The intended length of the derived key.
It is a developer’s duty to manually choose the PRF, the iteration count, the intended length of the derived key, and programmatically generate a unique, non-predictable salt for each password. Given these values, PBKDF2 generates an output key of a desired length derived from the password inserted by a user.
Among all arguments, the PRF and the iteration count are crucial values to set. Complex functions and high iteration count values increase the effort necessary for an attacker to perform a brute-force attack and thus the security of the obtained digest. They also slow down the computation for the legitimate device during the authentication process. On the contrary, simple functions and low iteration count values make the login effortless for the legitimate device but may result in loss of security for the generated digest. Therefore, it is important to find a correct balance between security and performance, to have digests that are robust and simultaneously guarantee adequate responsiveness of the system.
Finally, all the aforementioned arguments (PRF, salt, iteration count, and output length) are required to be saved on the storage device together with the derived key for the correct functionality of the authentication process. To perform a proper comparison of an input password with a stored digest, PBKDF2 must be configured with the exact same arguments at the time the digest was first produced, otherwise no matches can be obtained even when supplying the correct password.
Siemens Vulnerability Details
In the user profiles settings, the Siemens ABT Site software—the reference engineering and commissioning tool for the device—allows the user to set a “user profile access” permission to a role, which adds user management capabilities such as creating, updating, or deleting users.
This permission can be added even to low-privileged roles; in our analysis (Figure 1), it was possible to add the “user profile access” permission to a role with “basic operation” privileges, i.e., the lowest possible settings.
After creating a user with the aforementioned role and logging in, we completed a user creation process, and observed the following interaction (Figure 2).
In Figure 2, notice that the application, through the web interface, allows us to enter a normal plaintext password for the new user. However, in the background, we were surprised to find that the HTTP request responsible for the actual creation of the newly defined user carried the PBKDF2 string of that password, with the following format:
Prf ID $ Iteration count $ Salt $ Digest
Our hypothesis is that the maintainers tried to quickly implement a secure password storage mechanism on top of an already existing system that was previously storing a plaintext password or, at most, an unsalted hash, without performing proper in-depth changes to the backend code.
After doing a brief reverse engineering activity on the server binary responsible for handling web service communications (Figure 3), we discovered that no specific validation checks were done on the iteration count value, apart from verifying that the value was a parsable unsigned integer.
This implies that any malicious insider with user profile access privileges (or if an attacker manages to hijack an account with such privileges, for instance by exploiting the lack of “secure” attribute of the session cookie) could create a user with a PBKDF2 string having a slow PRF and an extremely high iteration count. They could then perform a Denial-of-Service (DoS) attack by CPU exhaustion against the controller just by attempting a login with the aforementioned user. In fact, the sheer act of performing the login on the device would trigger the long execution of the so-configured PBKDF2 algorithm to perform the password comparison, impeding any further actions on the device.
During our tests, we were able to cause the device to become completely unavailable for about 98 seconds just by setting a PRF of HMAC-SHA256 and an iteration count value of 1,000,000 (Figure 4). Considering that the device supports even more complex PRFs (such as HMAC-SHA512) and a maximum iteration count of 4,294,967,295, in a worst-case scenario it would be possible to make the device unavailable for days just by attempting a login. What’s most concerning is that nothing would prevent the attacker from reattempting the login other times, to further extend the downtime of the controller.
Summary
Building automation controllers are multi-faceted as they are used to control, HVACs, fire control systems, safety alarms, security cameras, and other systems necessary for the functioning of a facility. Our research displayed how threat actors can not only access a controller, but launch a denial-of-service, rendering the device inoperable for up to a few days. It is also possible that threat actors can attack BAS while simultaneously launching a catastrophic attack on other industrial control systems (ICS) within a facility. If the fire alarm system or other systems are DDoSed, it could intensify a cyber-physical attack. In the past, threat actors have targeted BAS, such as Uninterruptable Power Supply (UPS) while launching a multi-layered attack. Threat actors seem to value BAS as an attractive target.
Upon notification from Nozomi Networks Labs, the vendor released a patch addressing this vulnerability. We recommend updating the affected devices to the latest firmware version. Desigo DXR2 and PXC3 must be updated to V01.21.142.5-22 or a later version. Desigo PXC4 and PXC5 must be updated to V02.20.142.10-10884.
