Team82 Research
Team82 disclosed to Siemens a deserialization vulnerability found in its SIMATIC Energy Manager (EnMPro) product
The vulnerability, CVE-2022-23450, was assessed a CVSS v3 score of 10.0, the highest criticality score possible; given the severity of the vulnerability, Team82 has chosen to delay disclosing any technical details until now in order to give users time to update
An attacker successfully exploiting this vulnerability could remotely execute code and gain complete control over an EnMPro server
EnMPro is software used within plants to manage and visualize energy consumption values and energy flow within processes, compare energy efficiency, and create energy management plans
Siemens urges users to update to V7.3 Update 1 or later as all versions up to V7.3 contain this vulnerability
See Siemens’ security advisory for additional information
Even though many think deserialization vulnerabilities are a thing of the past, we still see them pop-up every now and then, affecting popular applications. These vulnerabilities stem from the insecure process of object serialization/deserialization—the process of converting objects from their in-memory representation to a binary format that can be transferred remotely (and the opposite for deserialization). However, if a server does not correctly limit the types of classes users can create during the deserialization process, it is possible to exploit this into a full-pledged remote code execution (RCE) vulnerability.
Team82 found one such vulnerability in Siemens’ SIMATIC Energy Manager (EnMPro) software suite and developed a proof-of-concept attack for CVE-2022-23450 (CVSS 10.0) that exploits a deserialization vulnerability we uncovered in the EnMPro communication protocol. That flaw could allow an attacker to send a malicious payload before the authentication flow initiates.
We privately disclosed our vulnerability to Siemens, which patched the vulnerability in V7.3 Update 1, and in later versions. All versions up to V7.3 contain this vulnerability. An attacker who successfully exploits this vulnerability can gain complete control over an EnMPro server.
Siemens SIMATIC Energy Manager (EnMPRO) is a software used within plants to manage and visualize energy flow and consumption values, compare energy efficiency, and strategize an energy plan accordingly.
Behind the scenes, EnMPRO is a .NET service (called BDataWIndowsService) composed of a .NET executable, listening on port TCP/4444. This executable handles most of the EnMPRO server’s core functionality, allowing clients to connect to it remotely using a proprietary messaging protocol. Using this protocol, clients can invoke different functionality in the server, including retrieving or altering data in the server, calling different functions, creating graphical interfaces or periodic procedures, and more.
Throughout our research into EnMPro, we were able to identify several critical vulnerabilities in EnMPro’s web server and desktop application. These vulnerabilities, when exploited, could result in a malicious actor compromising and even gaining full control over the server running EnMPro. In this blog, we describe our research process and provide some technical details about the most severe vulnerability, CVE-2022-23450.
In order to allow remote users to interact with the main EnMPRO server, Siemens created a very simple network protocol over TCP/4444, allowing the desktop application (Client UI DocLiber.exe) to interact with the main server’s application (BDataWindowsService.exe).
We reverse engineered the server’s binaries, as well as looked at a dump of the network communication statically, trying to understand and eventually reconstruct the protocol’s messages and capabilities. We looked at different functionalities the user can invoke through the client, and watched how the packets would change, trying to better understand different fields of the message. We discovered that after a short protocol-specific handshake and session creation, most EnMPro messages implement the following structure:
Lets analyze each of those four parts of the packet we’ve marked in different colors:
Packet Size: The first 4 bytes of each packet are the packet’s size (excluding the packet size header), sent in a Little-endian byte order. In this packet, we can see that the packet size is 0x01B2.
Packet Flags: After the packet size, the next 4 bytes are a bitmap specifying different flags for this packet. Flags include indicators whether the packet is compressed (using GZIP), if the packet is chunked, etc.
Packet Type: The next byte in the packet represents the type of the packet. This byte is an enum, and it decides what is the message type, and what fields/members should be sent inside the message. The message types are defined:
After the packet type is read, the server/client will try to construct the message using the correct message type deserializer.
Message Contents: The actual message data, which will be read and parsed using the correct message parser. The message contains the different fields/members used by this specific message type.
Immediately when we saw the packet type enum (called FastSerializationMessageMode), one message type jumped out at us: Off_UseBinaryFormatter. From its name, containing the words BinaryFormatter, along with the fact the enum name contains the word serialization, we noticed a potential vulnerability.
In C#/.NET, the BinaryFormatter class is used for object serialization and deserialization, which is essentially the process of constructing an in-memory class instance from a byte-stream and vice versa. However, Microsoft warns in its documentation the BinaryFormatter class is inherently insecure, and should not be used unless it is completely mandatory.
The BinaryFormatter class should not be used, in particular, to deserialize objects, especially objects coming from user-input, because it could easily allow remote attackers to achieve code execution. The reason for this is that the BinaryFormatter serializer does not sanitize the types of classes it deserializes, instead it has the ability to create arbitrary classes.
By using classes known as Gadgets (classes that when constructed, can cause unintended side effects, including code execution) researched and discovered by the community, it was possible to achieve remote code execution. We were able to create a malicious serialized class (using the ysoserial.net tool), which will result in arbitrary code execution whenever it will be deserialized.
Then we created a simple client that will initiate a session with the EnMPRO server, and then send the malicious serialized class to the server to be deserialized.
The result of our proof-of-concept exploit:
In this specific case, we were able to force the server to deserialize our packets even before we authenticated, meaning this remote code execution vulnerability does not require us to bypass authentication checks.
Siemens has fixed a critical remote code execution vulnerability in its SIMATIC Energy Manager (EnMPro) product, used in plants to monitor energy consumption within processes.
The vulnerability is a classic deserialization bug found in EnMPro’s use of a .NET BinaryFormatter class. BinaryFormatter, according to Microsoft, should not be used to deserialize objects, especially those coming from user input. Its usage puts instances of SIMATIC Energy Manager at risk of remote attackers executing code of their choice, giving them full control over these servers.
Our proof-of-concept exploit initiates a session with the server before sending a malicious serialized class that is then deserialized by the server, resulting in arbitrary remote code execution. The attack is carried out pre-authentication, meaning an attacker would not need to have a previous foothold on the server.
This vulnerability was assessed a CVSS v3 score of 10.0, and was addressed in EnMPro V7.3 Update 1 and later. All previous versions carry this vulnerability.
Team82 wishes to thank Siemens for its cooperation throughout this disclosure, and working to address this critical vulnerability in a timely manner.
The affected system allows remote users to send maliciously crafted objects. Due to insecure deserialization of user-supplied content by the affected software, an unauthenticated attacker could exploit this vulnerability by sending a maliciously crafted serialized object. This could allow the attacker to execute arbitrary code on the device with SYSTEM privileges.
CVSS v3: 10
A DLL Hijacking vulnerability could allow a local attacker to execute code with elevated privileges by placing a malicious DLL in one of the directories on the DLL search path.
CVSS v3: 7.3
Affected applications improperly assign permissions to critical directories and files used by the application processes. This could allow a local unprivileged attacker to achieve code execution with ADMINISTRATOR or even NT AUTHORITY/SYSTEM privileges.
CVSS v3: 7.3
