Several security loopholes in Siemens’ SINEC industrial NMS lead to DoS, credential leaks, remote code execution

Claroty’s research arm Team82 revealed the presence of about 15 vulnerabilities in Siemens’ SINEC network management system (NMS). These loopholes, if exploited, pose a number of risks to Siemens’ devices on the network, including denial-of-service attacks, credential leaks, and remote code execution in certain circumstances.

These vulnerabilities “could allow a user to escalate their permissions, gain administrative rights to the system, leak sensitive information, cause a denial of service on the platform, and even achieve remote code execution on the hosting machine using NT AUTHORITY\SYSTEM privileges,” Noam Moshe, a Claroty researcher, wrote in a company blog post. 

Team82 said that all versions before V1.0 SP2 Update 1 are affected, while Siemens advises users to update to V1.0 SP2 Update 1 or later version. With its central position within the network topology, SINEC requires access to the credentials, cryptographic keys, and other secrets granting the administrator access in order to manage devices in the network, according to Moshe. 

The NMS holds a critical position on an OT (operational technology) network, allowing administrators, among other things, to discover assets, and understand their connections and dependencies, apart from managing them. 

From an attacker’s perspective carrying out a ‘Living-Off-The-Land’ type of attack where legitimate credentials and network tools are abused to carry out malicious activity, access to, and control of, SINEC puts an attacker in a prime position for reconnaissance, lateral movement, and privilege escalation. 

“We chose to demonstrate how we chained two vulnerabilities in order to first escalate our privileges in the system and gain administrative access (CVE-2021-33723), and then obtain a file-write primitive on the system (CVE-2021-33722),” Moshe wrote. “Using this primitive, we wrote a malicious webshell on the system’s web root directory and invoked it by accessing it, thus achieving a remote code execution vulnerability,” he added.

Team82 identified an account-takeover vulnerability that allows any authenticated user to gain access to the administrator’s account and to functionality accessible only to administrators of the SINEC system. 

“The SINEC permission model is based on group membership; only users of corresponding groups are able to perform certain actions,” according to Moshe. In general, whenever a user tries to perform an action involving other users, such as creating another user account, viewing another user’s account details, and/or changing them, the server requires the user who performed the action to be a member of the administrative group that is allowed to perform those actions, he added.

In all routes that involve changing a user’s password, the server correctly checks that the user performing the action is an administrator, Moshe said. “However, one action which any user is allowed to perform is changing their own details, email, etc. In the routes that handle this request (/edituserprofile), no administrative permissions are required. A user can simply supply a JSON payload containing information about their account, and the server will change the view model of the given user, and the account details.” he added. 

Moshe said that however, two problems exist in this route. “First, since the user attributes are updated directly through this request, we can supply certain fields that the server did not intend to change, like the user password. By simply supplying a password variable in our request, we change our user’s password. Furthermore, the server does not check whether the user performing the request is actually the user whose account is being edited, thus by supplying an ID and username of the administrative account, we can simply change its password, gaining access to the account,” he added.

In the case of the second vulnerability, after gaining access to the system with administrative privileges, “a wide range of functionality was opened to us, and we were able to identify a few vulnerabilities that allowed us to achieve remote code execution on the system,” Moshe said. As part of SINEC’s business logic, an administrator can create containers, which are a bundle of files, ranging from compiled programs, text files, and graphics. “The administrator can use these containers and push them to any managed devices they choose. Our vulnerability involves this functionality, specifically the option to export and import those containers to the SINEC platform,” he added.

“First, we create a container that contains a malicious file we intend to drop on the hosting server’s filesystem, for example an executable file or a webshell. Then, we export this container using the  /exportFWContainers API route,” according to Moshe. “This route takes a container ID and a name under which it will be exported. The server then takes all of the container’s items (including the malicious file we’ve uploaded to it) and transfers them to a directory under the given name, and finally archives it. However, the files under the given directory name are never deleted,” he added.

As it turns out, the server never checks the user-supplied name for the container, and instead moves the container files to a directory under this name, the post said. 

“We could abuse this by supplying path traversal characters (../) in the given name, thus gaining the ability to copy the files inside this container to arbitrary locations on the host machine’s filesystem,” Moshe wrote.

“Abusing this vulnerability, we managed to achieve a simple file-write primitive that allowed us to write arbitrary files on the host’s filesystem,” according to Moshe. “In order to escalate this primitive into a code execution vulnerability, we chose to drop a simple webshell on the target’s web root directory. Since the web server was written in Java, it allowed a .jsp (java server page) to be executed whenever a client requests them through an HTTP request, which meant we could write a malicious .jsp webshell that would allow us to execute arbitrary commands,” he added.

In its advisory, Siemens has identified that customers can restrict access to the affected systems, especially to port 443/tcp, to trusted IP addresses only, in order to reduce risk.

Last September, ​​Claroty identified chain vulnerabilities in network management systems used in various IT, IoT, and OT networks, such as Nagios Core monitoring software. Team82 researchers detected, among other things, remote code execution with root privileges, privilege escalation, and credential theft security loopholes, and privately disclosed 11 vulnerabilities in Nagios components, all of which were fixed in updates released in August.

Anna Ribeiro

Industrial Cyber News Editor. Anna Ribeiro is a freelance journalist with over 14 years of experience in the areas of security, data storage, virtualization and IoT.