Exploiting Automation License Manager using DFS for PCS 7 Takeover

Siemens Automation License Manager (ALM): Unveiling Vulnerabilities and the Urgent Need for DCS Environment Hardening!

Executive Summary

• Siemens Automation License Manager (ALM) is a common component installed as part of many engineering, monitoring and control solutions by Siemens.
• The ALM, on Siemens PSC 7 servers, is exposed to the network by default, allowing different license management options, such as adding new licenses to remote machines.
• OTORIO Research team discovered two 0-day vulnerabilities in the ALM service, leading to Remote Code Execution and full file access as a high privilege user (SYSTEM).
• The vulnerabilities are highly severe as they do not require advanced exploit development and impact many critical components in OT networks from Historians to WinCC HMIs.
• This vulnerability emphasizes the importance of hardening DCS environments.

Introduction

Siemens Automation License Manager (ALM) is an integral part of different Siemens software products responsible for managing licenses for various Siemens solutions. It enables users to utilize and manage license keys over the network on remote machines or locally on the same machine it is installed on.

As part of a comprehensive research on DCS (Distributed Control Systems) solutions. The ALM was identified as a common component installed in many engineering, monitoring, and control solutions by Siemens and is present in various systems such as PCS 7, TIA Portal, STEP 7, SIMATIC HMI, SIMOTION, SIMATIC NET, SINAMICS, and SIMOCODE.

OTORIO Research has alerted Siemens about multiple vulnerabilities in the ALM last year, seeing it a severe risk due to it being enabled by default on all PCS 7 servers we’ve tested. Additionally, earlier this year we’ve detailed the potential attack vectors of these vulnerabilities and the urgency to patch or mitigate them, notifying clients and users that might not be aware how severe the possible damage these vulnerabilities pose if successfully exploited.

We are now disclosing additional technical details that we believe will allow better understanding of these vulnerabilities to assist the relevant stakeholders with enhancing the security of the affected (and probably similar) systems.

Common SBOM for Siemens Software

The ALM is typically installed automatically as part of other Siemens products, such as PCS 7 servers, allowing different license management options, including the ability to add new licenses to remote machines.

During installation process of Siemens solutions we can usually find it listed as one of the components to be installed by default:

While it is usually not meant to be used on its own, it is addressed as a separate solution by the vendor, and users should address it as they would address a 3rd party SBOM which is not managed by the vendor. Therefore, clients are expected to be aware of its existence as an independent piece and follow relevant advisories independently from other components of Siemens products (e.g. no advisory will be provided for PCS 7 in case of a vulnerability in the ALM software).

Under the Hood

The Automation License Manager (ALM) has a client-server architecture  - a Windows service that operates on TCP port 4410 and a client application used for connecting to the service. The service component operates with a privileged SYSTEM account and is responsible for managing licenses on the system. Users can utilize the client application to establish connections with the ALM service, both locally or remotely.

OTORIO's network exposure enumeration open-source tool

Once connected, various actions can be performed through the client application, such as server configuration, license management, and organization of licenses into folders. Authentication is not required, but certain operations are restricted from remote connections by default. For instance, on PCS 7, the default configuration allows remote clients to add keys, create key folders, and rename them while disabling actions considered "privileged," such as key deletion.

The ALM service manages all local keys in hidden directories located at:

[VolName]:\AX NF ZZ\[keys_folder_tree]. 

Communication between the ALM client and server utilizes an XML-based protocol. Since all default operations are regarded as "safe," no security measures are implemented.

To illustrate, a simple folder rename operation requires multiple protocol requests. These include:

• session initialization (open_session)
• initialization of relevant ALM plugins (initialize_plugins)
• gathering necessary information for the request (get_target_lists, get_list_objects)
• sending the rename request (rename_licensekey_folder)

Here is an example of the XML request for renaming a license key folder:

CVE-2022-43513: Beyond “rename”

One interesting observation, looking at the rename request above, is that the client application sends the full path for both the old and new folder names. Upon further investigation, we discovered three important points:

1. The `license_key_folder` GUID in the request was not being verified against the source folder, allowing freedom to select any “old” license folder name.
2. There is a path validation mechanism in place that restricts both folder paths from being outside the license directory tree (e.g., "C:\AX NF ZZ\...").
3. The file renaming operation is performed using the `_wrename` WinAPI.

Although renaming folders within the license directory may not have impact, the `_wrename` function, when executed with files as parameters, can also be used for moving files. Since the source (“old”) path is not verified for being a directory.

Microsoft rename function documentation

This introduces an interesting behavior as it enables the renaming or moving files on the target machine. Since the impact is limited to causing license issues due to the path verification functionality mentioned above, we’ve decided to continue further into this sanitization function.

CVE-2022-43514: Path Sanitization Bypass

Now, the only barrier between us and arbitrary file movement with SYSTEM privileges on the target machine is the path validation function, performed both on the old_name and new_name parameters.

This function verifies a "[VolName]:\AX NF ZZ\" prefix for the files, utilizing multiple WinAPIs for this purpose. The function flow is as follows:

1. `GetFullPathNameW` resolves the full path for the input, also ensuring it is free from classic directory traversal attempts. For example, "C:\AX NF ZZ\..\Windows" would become "C:\Windows".

2. `PathStripToRootW` extracts the root of the folder. For instance, "C:\Windows" would return "C:\" (or an error for invalid paths).
3. `PathAppendW` appends "AX NF ZZ" to the extracted root, transforming "C:\" to "C:\AX NF ZZ"
4. `PathCommonPrefixW` used for verifying that the appended path from step 3 is entirely included as a prefix for the (full) input path from step 1.

Well, WinAPI is not always perfectly documented and may have some unexpected behaviors that we can leverage. Inspecting the different WinAPI functions, we’ve noticed an interesting behavior of `PathStripToRootW`. While it is documented to look for a "drive letter", it also accepts UNC paths. This basically allows us to pass the initial validation steps using a path in the form of "\\IP\SHARE\AX NF ZZ\...".

MS Documentation for the PathStripToRootW WinAPI

It means that now we can move files between the license directory on the target machine and an arbitrary network share in our control (e.g., SAMBA share on our attacker machine). Here is an example:

Well, this allows us to steal licenses and maybe fill up some storage, but that’s not enough, right?

Arbitrary File Read-Write as SYSTEM

Our next objective is to get arbitrary read-write to the remote machine. For this, we first thought about using Junctions, linking to a root folder on the target. For example: \\<target_ip>\Network share\AX NF ZZ\<junction_to_C_drive>\Windows. However, this would require write access to the root of one of the network shares exposed by the target machine, as junctions can only link to local volumes. This may not be so rare to find, but we’ll try to avoid this requirement...

In our pursuit of getting a non-local junction-like behavior, we realized that the Distributed File System (DFS) might be the key.

DFS is a Windows capability to logically group shares on multiple servers and to transparently link them into a single hierarchical namespace. These are commonly used for large network shares in organizations.

Windows DFS

So why don't we just set up a DFS share on our machine (the attacker side) and create a DFS link on it, linking to the C$ share of our target? This way, we will get a similar junction-like behavior, but over the network and with full control over the path.

Excited to see this in action, we created a DFS share using Samba and created a DFS link to \\127.0.0.1\c$, forwarding anyone who tries to access it to its local machine's C$ share. However, when we tested it, it didn't work. After exploring the SMB authentication behavior of the Local System account and diving into the network captures, we concluded that it might just be that the Windows 10 machine may not be able to serve as a DFS host and would not accept redirections from DFS links to itself.

But, while Windows 10 machines may not cooperate with our DFS links, Windows servers definitely do and are very common in PCS 7 installations. Attempting the DFS link redirection on a Windows Server, we managed to redirect the target device (ALM service) to \\127.0.0.1\c$, essentially accessing the local C: drive with full privileges (interesting behavior for authorization, but not for this blog :) ).

Below, you can see an example of renaming a source "folder," which is actually a UNC path leading to a DLL located on the attacker’s machine, and a target "folder," which is another UNC, this time leading to an attacker DFS link redirecting back to the target's C$ share, ultimately writing a DLL file to the C:\Windows path.

This way, we were finally able to successfully bypass path sanitization and execute code on a PCS 7 Server (e.g., OS-Server, Historian). This is how it was done:

1. Attacker hosts a Distributed File System (DFS) service on their own machine using Samba: \\Attacker_IP\DFS_SHARE$\
2. Attacker opens a shared directory and creates a directory within it named "AX NF ZZ": \\Attacker_IP\DFS_SHARE$\AX NF ZZ\
3. Attacker creates a DFS link to \\127.0.0.1\c$ within the internal folder: \\Attacker_IP\DFS_SHARE$\AX NF ZZ\DFS_LINK_TO_127.0.0.1_c$
4. At this stage, the directory path validation can be completely bypassed. For example, if the target receives a path like \\Attacker_IP\DFS_SHARE$\AX NF ZZ\DFS_LINK_TO_127.0.0.1_C$\Windows\, it will be accepted, and the target will be redirected to itself on C:\Windows\ as the SYSTEM user.
5. By bypassing path sanitization and utilizing the rename vulnerability to move files around, we were able to execute code by replacing executables or dropping files into PATH directories such as C:\Windows. This exploitation was demonstrated on all PCS 7 servers we tested, with default configurations (e.g., OS-Server, Historian).

Mitigation and hardening

As these vulnerabilities may impact many environments, we urge users who have not mitigated these vulnerabilities in their environment to promptly do it.

Mitigation of this issue can be done by updating to the latest version of the Automation License Manager. Users are also recommended to use additional precautions and follow the recommendations detailed in the latest hardening guide of the vendor, including disabling the ALM remote connection option on their machines, even when enabled by default:

Disabling remote connections

In general, clients should make sure that hardening guides of the vendor (e.g., “Process Control System PCS 7 Compendium Part F - Industrial Security”) are followed and implemented in their environment as installations are commonly configured insecurely by default. More details about DCS security risks, along with recommendations, open-source tools, and a checklist for securing these environments, can be found here.