ABB Terra AC Improper Authentication Can Lead To EVSE Takeover (CVE 2023-0863 & CVE 2023-0864)

The vulnerabilities discussed hereunder, CVE-2023-0863 and CVE-2023-0864, affect all the ABB Terra AC charging stations with versions 1.6.5* or lower. It is recommended to update to the latest firmware version, already published and provided by ABB, as soon as possible and follow the mitigation steps below.

* ABB Terra AC models have multiple variants, please refer to the ABB security advisory – link.

TL;DR

The SaiFlow research team has discovered two vulnerabilities in high severity (CVSS scores: 8.8 and 7.1) in ABB’s Terra AC chargers. These vulnerabilities enable an authentication bypass to the charger’s management interface, which is used by field operators (aka installers), and consequently allow remote and unauthorized users, within the range of a Bluetooth Low Energy reception, to change the charger’s configuration: CVE 2023-0863, CVE 2023-0864.

ABB Terra AC models expose a management interface over Bluetooth Low Energy (BLE) communication with a proprietary protocol whose implementation can be reversed-engineered from ABB’s TerraConfig and ChargerSync mobile applications. Threat actors might exploit this vulnerability to overtake the charger’s management and perform energy theft, or to exfiltrate chargers’ data and identities of drivers (ID tags).

The vulnerability exploitation can be executed in a few seconds from a nearby device with BLE capabilities. For example, a threat actor driving by a charging hub with an exploitation tool with BLE capabilities could remotely exploit all charging stations in proximity – It is worth noting that ABB Terra AC Wallbox chargers are equipped with BLE 5.0. The maximal outdoor range of BLE 5.0 can reach 300m, which can be leveraged by adversaries to exploit the charging station from a distance (In practice, however, the maximal range will be less than 300m).

The impact of adversaries exploiting these charging station vulnerabilities from behind the fence or by passing through a charging hub, such as mall parking lots, will be severe. Charging Point Operators (CPOs) should update their ABB Terra AC charging stations to the new firmware version, published and provided already by ABB, to mitigate the exposure.

These vulnerabilities and the research done by the SaiFlow research team demonstrate several severe risks and mitigation steps that Charging Station Operators (CPOs) should be aware of:

1. EV Chargers expose management interfaces in different methods and they might go under the radar in your risk assessment. CPOs should take into consideration the attack surface exposed by field operators and local management interfaces, such as BLE communication. In contrast to “classic” network monitoring of Ethernet and WiFi traffic, chargers commonly expose additional communication channels that are overlooked and should be taken into account.
2. Lack of continuous visibility and monitoring of settings and configurations applied to EV chargers could increase the likelihood of vulnerabilities being exploited without the awareness of the security systems. The settings of EV charging stations might change over time due to the activities of field operators, such as configuration updates, firmware updates, or other reasons.
3. Patch management and security updates policy should be enforced on your EV charging stations. Depending on the charging station’s model and vendor, some have the capability to be updated seamlessly over-the-air (OTA), but others are not equipped with these capabilities, like the Terra AC chargers. CPOs should monitor for known vulnerabilities to reduce the risk of compromising and exploiting charging stations.
4. As of Terra AC version 1.6.6, ABB has started using OCPP Security Events Notification messages to indicate attempts of exploiting the described vulnerability. The security event is of AttemptedReplayAttacks and the techInfo field indicates bleAttacks. We recommend monitoring these events as they might indicate malicious activities performed over BLE channels.

Charge point operators (CPOs) should minimize the attack surface exposed by local EVSE management interfaces, such as BLE communication, and continuously monitor for new vulnerabilities, configuration changes, and security events.

In the research below, we provide an overview of our complete journey from the starting point of a newly connected Terra AC Wallbox charger, in our lab, to the final stage of setting the charger with our own custom CSMS provider.

Bringing Down The Grid ⚡️

Adversaries can exploit the described vulnerabilities to damage the power-grid and cause regional blackouts by manipulating the charging stations’ OCPP “charging profiles” and perform what is known as Load Altering Attacks.

Power consumption telemetry and EV charging data are necessary for implementing dynamic load balancing. Without that, power-grids might experience blackouts and charging stations will never be able to utilize their full power. To overcome these issues, the OCPP standard enables CPOs to manage the power that EV charging stations can deliver by utilizing what is known as “charging profiles”. Moreover, CPOs can set the allowed charging time windows, charging power limits, and tariff information using the OCPP standard.

The “charging profile” allows for customization and control of charging sessions, enabling features such as peak shaving, load balancing, and dynamic pricing based on the power-grid conditions and user preferences. On the other side, if an adversary gains control over a group of charging stations, they could cause a local blackout or even bring down the grid as reported by Jay Johnson, a cybersecurity researcher at Sandia National Laboratories: Hackers already infiltrate EV chargers. It could only get worse.

In our case, an adversary can gain control over multiple charging stations by manipulating the charging stations’ configuration and connecting them to a malicious charging management system (CSMS). The adversary can request from the group of compromised chargers to deliver high power to the EVs that are connected to them. This can be done by sending an OCPP SetChargingProfile message with the profile purpose type of ChargePointMaxProfile or TxProfile during the charging transactions.

In order for an adversary to bring down the grid, the same method described above could be used to perform a more sophisticated attack such as Dynamic Load Altering Attacks.

The ABB Terra AC Wallbox Research Details

The SaiFlow research team invests resources to analyze and model the EV Charging Infrastructure (EVCI) attack surface. This attack surface still evolves as the EVCI industry expands to private fleets and public charging stations. Through this research, we have analyzed our new ABB Terra AC Wallbox charging station.

When we received our new ABB Terra AC Wallbox charge station, the first thing we wanted to do was to configure it and add it to our charging station management system (CSMS) that we use to control the chargers in our lab. Unfortunately, configuring a dedicated CSMS can be done only by a certified and verified ABB operator that uses the ABB’s “TerraConfig” mobile app. The TerraConfig is the main app that is being used by field operators to configure the Terra AC charger.

The table below lists the use cases of ABB’s different digital tools and when to use each tool. As you can see, the TerraConfig application is mainly used for the installation and commissioning process, which includes setting the charging station’s OCPP server endpoint (the CSMS endpoint).

Note: The above table is detailed according to ABB’s Terra AC Wallbox digital tools overview. ABB Digital tools

ABB Operator POV

To use the TerraConfig mobile app and portal, you need to submit a request to become an ABB operator, and they will create an account allowing you to login into the TerraConfig services (https://forms.abb.com/form-39881/Antrag-Connected-Services-AC-Terra).

ABB split the use of TerraConfig into two different roles: one for the mobile app used by the operator in the field, and the second role is for the portal operator which sets the configurable values that the field operator can use. For example, the list of available CSMS providers that the field operators are allowed to configure for the chargers can be defined and set only by the portal operators using the TerraConfig portal.

Assuming the wanted CSMS endpoint is already configured in the TerraConfigu portal – in order to configure the Terra AC charger, the field operator has to go through a dual authentication phase:

First, the field operator login to its TerraConfig app account. Second, the operator needs to connect to the charger using the Bluetooth Low Energy (BLE) service with the relevant charger’s serial number.

To complete the pairing of the charger with the app, an identifying PIN code is requested from the operator to proceed to the configuration screen. The PIN code is delivered with the papers that come with the charger itself.

So, as the owner of the new charging station, we had the PIN code for the pairing process, but we didn’t have the operator account’s credentials to configure our charger to connect to our CSMS.

Luckily, during the research process, we encountered a couple of CSMS providers publicly sharing their TerraConfig app “operator” accounts thus allowing private users to join a 3rd party CSMS service and “bypass” the vendor lock.

However, as we explain in this blog, we found out during our research that both the PIN code requirement and the operator account credentials could be easily bypassed to configure the ABB Terra AC Wallbox charging station without any authentication requirements.

Reverse Engineering The TerraConfig App

SaiFlow’s research team started with reverse engineering the TerraConfig mobile app to see what an operator could do, how ABB implemented the charging station management app, and whether we can configure the charger without the required authentication process. We started by decompiling the Android APK file using MobSF framework.

At first, we started with a simple static analysis of the decompiled code in Java and combined it with dynamic analysis.

A virtual Android device could be helpful for this use case but it has its limitation with support for BLE connectivity, so to overcome this without struggling with creating a custom mobile setup, we used a real rooted device and continued our research work.

The setup for our research work is as follows:

• The Android device is connected to the lab’s WiFi network with access to the internet.
• The Android device is also connected to our workstation by using a USB cable for ADB (Android Debug Bridge) communication.
• To intercept the network traffic, we set the Android device’s WiFi connection to use a proxy with the address and port of our workstation running a MITM proxy.
• Run a MITM proxy (such as Burp) and set it to listen on all the workstation’s ethernet interfaces.
• Use Frida to overcome certificate pinning using this script with the goal of being able to observe the encrypted traffic. Also, we use the proxy to mock responses of dedicated HTTP requests in order to bypass the login screen and essentially connect to the charger’s BLE service.

After we got to the screen of the OCPP server configuration, we examined the HTTP requests that are sent to ABB’s API service. During this stage, it was hard to determine the purpose of certain fields expected by the app in the response and it was difficult to understand what exactly is the responsibility of ABB’s services in the process of configuring the charge station. Our research team likes this type of challenges, so we dug deeper into the mobile app logic.

It is worth mentioning that it was only later in our research process that we found the publicly available TerraConfig credentials, which could have helped us understand the responses of the TerraConfig API service faster.

PIN Code “Client-Side” Authentication Process

Diving deeper into the app logic we noticed that when an operator uses the app to configure the charger, the requests for the PIN code and the login are used only for authorizing requests sent to ABB’s API services, but they are never being used for authorizing messages sent to through BLE channels.

In the figure below we can see that the BLE connection to the charger is made when the device serial number and PIN code are authorized and ABB’s API service responds with a successful verification.

It’s worth noting that the Terra AC charger also doesn’t require a Bluetooth pairing code during the pairing process. Bluetooth pairing code is referred here as the common request of code that is being used to pair two Bluetooth devices, similar to the paring process of home devices like screen mirroring. This is regardless of the PIN code implementation of ABB that is being used, as we found, only for user authorization through their app API services to the cloud.

To conclude, to send management messages to the Terra AC charger, we won’t need the charger’s unique PIN code value. So we can send management messages to any Terra AC Wallbox charging station out there.

Reverse Engineering of the Management Protocol

We started to analyze the TerraConfig app logic that handles the user interactions, to get to the piece of logic that sends the messages over BLE channels, and to understand ABB’s proprietary management protocol.

As a reminder, we looked in the BLE protocol for the usage of the PIN code to see if it is being used as part of the authentication process for the BLE channels between the app and the charging station and we didn’t find any indications for that.

We focused on the management protocol, sent through the BLE, and started with discovering the relevant GATT services that are being used by the mobile app. For anyone who is not familiar with BLE GATT services, here is a quick recap:

• GATT (Generic Attribute Profile) is a protocol used in Bluetooth Low Energy (BLE) technology to define the structure and behavior of the data exchanged between two BLE devices. The GATT server can have multiple services.
• GATT services are defined by a 16-bit UUID, which identifies the service and its characteristics. Each service can have multiple characteristics, which describe the data exchanged between the devices.
• The GATT characteristics for a service can be:
  • Read: allows a device to read the value of a characteristic.
  • Write: allows a device to write a value to a characteristic.
  • Notify: allows a device to receive notifications when a characteristic value changes.
  • Indicate: similar to Notify, but requires an acknowledgment from the client.
  • Write Without Response: allows a device to write a value to a characteristic without requiring an acknowledgment from the receiving device.

Finding The Right Code Segment

At this point, we wanted to make sure we were reversing the right segments of code, and to do that, we used our Terra AC charger in our lab. We are going to follow the breadcrumbs, step by step until we will get to the interesting class: the CDBleClient class.

Using a “top to bottom” approach, we started by scanning our charger in the lab to discover the BLE GATT services, characteristics, and descriptors that are being advertised by it. We found the characteristic UUIDs prefix: 0x0000fff3, 0x0000fff4, and the service UUID prefix 0x0000fff0. These can be seen in the scan results shown in the figures below:

We searched for the found UUIDs strings in the app decompiled code and we found their prefix in the APK at the AndroidManifest.xml file. (Note: this file is often in binary XML format and to make it readable you can download it from MobSF static report page or you can use public tools to convert it to “human readable” XML).

After finding the strings we got a higher confidence in the code segments that are used for the BLE communication implementation.

Following The Search For The BLE Protocol’s Messages Structure

The search process described above allows us to follow the breadcrumbs that led us to the important class, CDBleClient. We reached it by following the usage of CDBleConfig class fields and functions as can be seen with: parseUUID, serviceUUID, and descriptorUUID. Those are being used when connecting to a BLE device (our Terra AC).

The CDBleClient class implements a long list of commands that the TerraConfig application can send to configure the Terra AC charger like power control, WiFi network, query device system information, and a lot more. This class also contains the object with access to the notify function of the BluetoothClient class that is part of Android’s SDK.

We analyzed those commands and came to the conclusion that each command here is represented by a number and a payload which is sent to a wrapping function (wrap) and then sent through the BLE “write without response” channel (0xfff3).

We saw that some of the commands have an empty payload. For example, querySysInfo function doesn’t require any parameters. This can be the perfect message to later try and craft without too many complications and hope the Terra AC charger will parse it successfully.

We analyzed the logic of the wrap function to determine the structure of the proprietary protocol of TerraConfig and to reimplement its function for our own POC exploitation tool. In the wrap, we see a reference to a Token value concatenated to the message payload. We see that the Token is all zeroed when a CDBleClient is initialized and a new BLE connection is made. So we will craft our first attempt with a zeroed token and see if we get a valid response by just using it this way. (Spoiler, we were rejected but hey… at least we got some feedback 😅).

Now it’s time to dive into the wrap function, understand the proprietary management messages structure, analyze the core logic of how the management messages are generated, and try to reimplement it to craft our own management tool.

Crafting The BLE Management Messages

Our reimplementation of the proprietary management protocol was done using Python. This is a personal preference but the end goal was to have a better control over the messages’ build process and to provide us with future abilities, such as fuzzing abilities.

We used Bleak framework for the BLE communication and created a simple stub according to Bleak’s example. Based on this easy-to-start template we were able to write to the charging stations characteristics and simultaneously receive notification.

At first, we decided to follow the request and respond to the simplest message that we found (querySysInfo). This message required the least arguments and had a short response that was easy to parse back and validate.

To craft the message we go back to the wrap function. The wrap function takes two parameters: the command code and the command arguments. The command argument is a pre-generated byte array that was built according to the relevant type of request, then it is been passed to the wrap function.

Further analysis of the wrap function revealed the management message structure, and it is illustrated in the figure below:

Note: During our research, we didn’t find any use for most of the unknown bytes. They were redundant during all of our work and their value was always set to zero.

The command payload size is limited to the max value of 2 bytes representation.

Commands codes are predefined in a list of enum values, each one indicating a different command, and are handled differently when sent to and received back from the Terra AC charging station. for example, the querySysInfo command code is 0xb1 (a.k.a 177 as can be seen buildQuerySysInfoRequestbody).

Command payload contains the command parameters as a blob. The payload is generated differently for each type of command and it is then sent as part of the message. In our case, the payload for querySysInfo is null. Accordingly, the payload length will be 0.

The checksum value is calculated based on XOR-ing all message bytes (without the checksum byte located at “index” 7).

The only field that is missing now is the message code. According to the wrap function and notifications flow, we found out that 0xfe indicates a message request and 0xaa indicates a message response. There are a couple of special commands where the message code will be different but we will not cover those in this blog.

Now, let’s try to send the message according to what we just described and see what happens 🫣.

Note: The message payload might be split into junks and received on multiple notification events. This is depending on the MTU value of the BLE device.

We can already see at first glance that no system information was actually received back 😣. To understand the response, we had to go into the CDBleResponse class and follow the parsing logic of the process function in this class. Based on this function analysis, we revealed that the 3rd byte in the message structure is used for error codes.

Although we were happy to discover one of the unknown bytes of the message structure, we actually received an error back from the charging station. According to the list of error codes in the mobile app, the value 0x13 means that the message we have sent was “rejected”. The first thing to blame was our naive assumption that a zeroed token would just work.

At this point, we looked for all the references for the Token property of CDBleClient class and found that the token is set after a successfull response to the authentication request. The TerraConfig app sends an authentication request to the charger over the same BLE protocol as described above to receive back a token that will be used later for all the rest of the messages.

We can see in the figure above that the token is set after a successful response to the identityAuth request, which is just another type of command code that has its own command arguments as can be seen below in the figure and the description for each argument.

To build the authentication message, we need two pieces of information. But, both of them are already revealed to us publicly without any special requirements:

1. Device number – a.k.a charging station identifier which is broadcasted through the BLE channel.
2. Encryption key – A constant value hardcoded in TerraConfig mobile app ⚠️

To test everything we discovered, we sent our crafted authentication message from our tool to the charging station and finally got a successful response with a valid token! This token will be used for the rest of the commands. The authentication response also included the versions of the charging station and the communication protocol. It is worth noting that the encryption key was only used for the process of the first authentication as described above. Afterward, and for all the rest of the management operations through the BLE, the token received from the authentication response stays constant across all the command messages to that BLE connection.

From this point, it was easy to implement the querySysInfo command and all the other command types that the charging station supports.

By bypassing the PIN code authentication requirements and reimplementing the BLE management protocols, an adversary could reconfigure and exploit any Terra AC Wallbox charging station in the BLE range without leaving a trace. For example, an adversary could set an RFID card number as a backdoor to steal energy.

Even worse, an adversary could take control of the EV charging station by setting its OCPP endpoint server to its own service and take full control over the charger.

Taking Control of Terra AC with a Malicious CSMS Configuration

Now that we have our implementation and abilities to craft management messages to the Terra AC charging station, it is time to take control of our charger in the lab and configure it to use our own CSMS server. For the testing, we used an open-source CSMS platform that supports OCPP 1.6J: SteVe – OCPP server.

We reversed-engineered the management message which configures the charging station OCPP server endpoint.

The parameters that we have set for the command payload are listed below. When the configuration is set without a TLS connection, like the configuration we currently set, the certificate parameters are not required. Also, the tag parameters are optional so they weren’t included.

• server enabled = 1
• csms URL length = 38 (driven from the length of the csms URL)
• csms URL = http://<SERVER_IP>:8080/websocket
• csms port = 8080
• protocol type = 2 (Chargedot = 1, OCPP = 2)
• protocol version = ocpp16j
• security key length = 0
• security key = not exist
• tls enabled = 0

After a successful configuration, we can now manage our charger with our own CSMS server as can be seen in the figure below. We used SteVe as our “malicious” CSMS for our demonstration. SteVe, which is an open-source CSMS service, implements the OCPP1.6J protocol and can be easily installed as a self-hosted service.

SteVe provides “Charging Profile” functionalities to control the delivered power to the connected EVs. Those configurations can be abused to cause blackouts by scheduling charging profiles on a group of chargers to deliver the maximal amount of power. Alternatively, Charging Profiles operations can be used to execute dynamic load-altering attacks.

It’s worth noting that the lack of a Bluetooth pairing PIN code, when connecting to Terra AC, makes it easier for an adversary to perform this attack from a distance within a couple of seconds. The lack of a pairing code allows those adversaries to perform this attack on a large scale just by passing through a charging hub and sending crafted messages.

If an adversary aims to exfiltrate the ID tags of drivers and charger’s data, he could execute the same exploit to change the EV charger’s CSMS endpoint to a malicious service that performs MITM attack, while keeping the connection between the EV charger and the original CSMS. This way, the CSMS operator will have an active indication of the EV charger while the adversary keeps persistency and intercepts OCPP messages that expose sensitive data over time.

Summary

A threat actor can take over unpatched Terra AC chargers from a distance over BLE communication, overtaking them by changing their management service (CSMS) and all of that will be under the radar of the CPO (unless the original CSMS is monitored) and without any signs on ABB’s online services. The TerraConfig authentication process of the field operator was entirely decoupled from the authentication process to the Terra AC BLE management interface.

Adversaries who compromise charging stations on a large scale can cause a blackout or bring down the grid when controlling a group of chargers on sites.

TerraConfig has functionalities such as OTA firmware updates through the BLE channel or uploading a certificate file for validating a CSMS service when using a TLS connection. Those file-handling capabilities are interesting to reverse engineers and check for potential exploits that might provide remote code execution (RCE).

As of Terra AC version 1.6.6, ABB has started using OCPP Security Events Notification messages to indicate attempts to exploit this vulnerability. The security event is of AttemptedReplayAttacks and the techInfo field indicates bleAttacks. We recommend monitoring these events as they might indicate malicious activity performed over BLE channels.

Notes

The SaiFlow Research team wants to salute the security researchers who independently also found the vulnerability. They provide an additional angle to the technical research: BLUTACC and also a POC tool: GitHub – blutacc.