Hijacking ABB 800xA Communication for Admin Privileges

By Ariel Harush, Security Researcher, OTORIO

Research Finds Default-Configured 800xA DCS Installations Vulnerable to Unauthorized Modifications

In our previous articles, we placed DCS and SCADA security under the spotlight, discussing the fundamental role they play in modern industrial control systems and examining different security aspects to be considered.

We've noticed that security guidelines from vendors often only followed partially at best. Therefore, we aim to emphasize the necessity of system hardening for these devices, which should be regarded as a requirement, and not as an optional precaution.

To underscore the importance of adhering to these guidelines, we share one of our findings, discovered during the examination of ABB’s 800xA DCS. This security issue, posing a significant risk to the environment, was declared by the vendor as the user’s responsibility to mitigate, by following the system security guide.

Executive Summary

- OTORIO Research assessed the security of ABB 800xA DCS, focusing on its security features, communication protocols, and auditing capabilities.

- Among various security issues discovered by the OTORIO Research team, one demands particular attention as it represents substantial risk despite not being classified as a vulnerability.

- The OTORIO Research team showed how default-configured 800xA DCS installations could be vulnerable to unauthorized modifications in the Aspect Directory service, a core part of the 800xA system, potentially enabling an adversary to manipulate the process via a Man-in-the-Middle attack.

ABB 800xA’s Aspect Server and Directory

The ABB 800xA architecture consists of varied nodes, such as Domain Server, Connectivity Server, Application servers, Operator Stations and the Aspect Server, each fulfilling different roles. While the environment includes many interesting servers and services, our main focus in this article will be on the Aspect Server, and more specifically - the Aspect Directory, serving as the hub of the DCS object management and security. 

The Aspect Server is exposing the Aspect Directory as a network service, listening on a dynamically allocated TCP port, obtained from another service (similar to Microsoft RPC Endpoint Mapper). The Aspect Directory service is accepting connections from different servers, and commonly used for serving “Workplaces”, the graphical interfaces where operators and engineers can view, modify and control the plant process and settings, depending on their user’s permissions (also stored within it).

This protocol incorporates NTLM-based user authentication, host IP validation, and user access controls, showing that ABB has taken a mindful approach to security. But unfortunately, it is missing encryption, and integrity checks - allowing it to be easily hijacked and tampered with once an attacker achieves Man-in-the-Middle access.

Hijacking ABB 800xA Aspect Directory Service Connections

Since we haven’t seen any indication for encryption or integrity checks within the Aspect Directory communication, we assumed that once the protocol handshake - including the NTLM authentication and host IP verification was done - it could be possible to hijack an already authenticated privileged connection by performing a MitM between two servers in the environment.

Once a connection is hijacked, this would allow an attacker to perform any change, including changes to users permissions and adding IPs as approved nodes in the system, leading to full control over the Aspect Directory.

Phase 1: Discovering Messages for Privilege Escalation 

In pursuit of bypassing the ABB 800xA Aspect Directory Service permissions, our first step was to find the right messages and structure used for performing our wanted action: adding a weak DCS user, with limited privileges, to the “System Engineer” group, which holds high privileges.

To generate samples of these messages, we performed different actions over the Engineering Workplace interface, captured the network traffic and learned the specific structure and pattern of relevant messages, allowing us to later generate similar ones after a connection was hijacked.

Phase 2: Establishing a Man-in-the-Middle (MITM) Attack

The second phase was to execute a MITM attack. This technique allowed us to position ourselves as intermediaries between the 'Aspect server' and another node in the environment. By doing so, we gained control over the flow of data between these two components.

Our methodology of choice was Address Resolution Protocol Poisoning (ARP Poisoning). This technique essentially involves the manipulation of networked devices through spoofed ARP messages.

Phase 3: Hijacking a Privileged User Connection

Carefully monitoring the intercepted data, we looked for connections of privileged user logins. A privileged user, in this context, would be one who had access rights to the 'System Engineer' group in the Aspect Directory. 

Once we find a valid connection to the Aspect Server, originating from one of the intercepted DCS nodes, we can initiate the “hijacking”, basically denying any new messages from the original source and sending spoofed messages as part of its already connected and authenticated TCP session.

Phase 4: Packet Injection to Admin Privileges

Once a privileged user session with the 'Aspect Server' is intercepted, what’s left is to inject a message of our choice, such as the “add to group” request, on behalf of the hijacked connection. 

By performing minor changes in the messages we’ve captured on the first phase, such as changing the username field and the desired group according to the payload structure, we could easily create a valid request perfectly tailored for the attacked environment. Successfully injecting our crafted request, we managed to transform our low-privileged user into a member of the 'System Engineer' group providing us with control over the system.

Demo

Conclusion and Mitigations

The exploration into communication security issues in systems like ABB 800xA highlights the subject of vendor-user responsibilities in securing DCS environments. While solution providers in some cases might address these issues, there are instances - such as this - where the responsibility is passed to the users. Solution providers may rely on users to further harden their environment's security as instructed in security guidelines, without taking additional steps on the software side. In this specific scenario, ABB recommends users to add an additional layer of security, by configuring IPSec for the DCS Servers, and segmenting the DCS network properly.

ABB 800xA security guide recommending the usage of IPSec for communication security

To optimally protect your systems, appropriate hardening measures should be followed, as a requirement, not an option. Thoroughly following the vendor’s security guidelines is one of the most effective proactive actions to reduce the likelihood of security vulnerabilities and ensure the continuity and reliability of your critical industrial operations.