Tales From the Road: BESS and SCADA Network Assessment — Is Your MQTT Traffic Secure?

Three areas to secure to ensure your critical infrastructure isn’t vulnerable to a Machine-in-the-Middle (MitM) attack.

A multinational corporation in the energy industry enlisted our services to perform a comprehensive security assessment of their XRT Merging Unit. The merging unit sits on the power grid and is responsible for taking battery data from the company’s battery energy storage system (BESS), consolidating it, and sending it to a software system that then pushes it down to the SCADA system. Since the SCADA network is responsible for controlling the power management system, it was especially important to identify any potential security issues with the MQTT traffic and communications.

Putting the Merging Unit to the Test

DirectDefense consultants used a simulated battery to mimic communication with the merging unit, a.k.a the “Man-in-the-Middle” (or actually to be more specific, the “Machine-in-the-Middle”), and the SCADA system by sending a simple data transmission from the battery to the merging unit in order to test the software and the merging unit. Right away it became clear that the merging unit created a weak point in the communication channel between the battery and the SCADA system. MQTT communications weren’t encrypted, meaning someone could view the data as it was being transmitted. However, even worse, the MQTT communications between the BESS and the merging unit were found to be unauthenticated, which would allow a bad actor to send malicious data to the SCADA system if the internal network or device was compromised, potentially creating serious disruptions to the power grid.

We’re Looking at the Machine-in-the-Middle (MitM)

This assessment highlights the importance of looking at the MitM – in this case, the merging unit – and emphasizes the need to keep the data communication path to your critical infrastructure devices secure from threats. 

Continue reading to learn the three key areas that were compromising the security of our client’s BESS and SCADA network and our recommendations to secure the MQTT communications being sent across their critical infrastructure.

1. Unencrypted Web Applications

The merging unit’s monitoring web application for tracking power data wasn’t configured to use encrypted channels. This lack of encryption could allow an attacker on the local network to passively read all traffic sent between the application and the browser and view power reading data and web application credentials in plaintext. An active attacker could intercept the connection with a MitM attack and modify request or response data, allowing them to steal credentials, receive sensitive information protected by authentication controls, and make arbitrary requests with the user’s permissions.

Our recommendation:

Configure the web application to provide and enforce HTTPS connections. If a client connects via HTTP, redirect them to HTTPS. Additionally, use HTTP Strict Transport Security (HSTS) to instruct browsers to only connect via HTTPS for subsequent connections.

2. Unauthenticated MQTT Connections

The merging unit used an MQTT broker to manage MQTT communications on the network and push power reading data downstream to the SCADA system. The MQTT broker allows for new connections without authentication. This lack of authentication could enable an attacker on the network to read all MQTT data handled by the broker. Additionally, and much more detrimental, an attacker could publish their own MQTT data to the broker, which would send the attacker-controlled data downstream to the SCADA system. Depending on security controls beyond the merging unit, sending malformed data to the SCADA system could lead to serious consequences such as malicious data injection and Denial of Service attacks.

Our recommendation:

Enable MQTT authentication on the MQTT broker and deny any connections made from an unrecognized source.

3. Unencrypted MQTT Communications

The merging unit didn’t encrypt MQTT communications on its internal network. A suitably-positioned attacker would be able to read all traffic sent to and from the MQTT broker service. This exposes sensitive power reading data to anyone with access to the network and aids attackers by making internal communications easy to understand and forge.

Our recommendation:

There are two main ways of encrypting MQTT traffic: TLS or payload encryption. TLS encryption is generally preferred since it provides security at the network level and is not vulnerable to replay attacks. Payload encryption involves implementing end-to-end encryption on the MQTT message body.

It is important to note: Both MQTT vulnerabilities need to be fixed to fully secure the merging unit’s MQTT traffic, since if authentication is enforced, but encryption isn’t, an attacker can steal the unencrypted credentials. And if encryption is enforced, but authentication isn’t, an attacker could still connect and subscribe to the broker.

Defend Your Critical Infrastructure

For organizations like our client who are transmitting data to a SCADA system that controls operations on the power grid, testing becomes all the more critical.

Implementing controls to mitigate the impact of a breach ensures you’re prepared if an incident occurs, and makes it more difficult for an attacker to leverage your devices as vectors to perform malicious activity on your system. If you don’t test, you’ll never notice when something is bypassed at the endpoints – and the security in the middle won’t have an impact. 

Contact Us Today!

Set up a security consultation or call us at 1 888 720 4633.

Prev
Next
Shares