Security Advisory: Critical Vulnerabilities in EV Charging Stations: Analysis of eCharge Controllers

Since the advent of electric vehicles, we’ve been observing a steady increase in the apparition of companies selling EV charging stations controllers. Some of them are using in-house developed firmwares based on RTOS, like Autel, and others are building their work from a starter pack sold by Charge Byte. Charge Byte sells EV charging stations controllers hardware with a minimal system and some kind of SDK so that you can pack update files for it. This is what Phoenix Contact is using for their CHAR-X controllers for example.

Even if multiple vendors are using OEM’d devices from Charge Bytes, the security level of the upper layer added by final vendors can vastly differ and this blog post will be a demonstration in how bad things can really get.

Initial analysis

It all started with an advisory published by Offensity where they demonstrate authenticated remote command execution as root on “cPH2 charging station produced by eCharge Hardy Barth GmbH”.

At the time we had recently integrated our PHP static analysis feature on the ONEKEY platform and we wanted to check if we could find more PHP vulnerabilities. We got the firmware from Hardy Barth website and loaded it up on our research platform.

Given the results we observed, we immediately started searching deeper.

Full System Emulation

Since we had access to the raw filesystem and valid kernel, we were able to use a similar approach than  our BlackHat EU 2023 workshop to perform full system emulation. From there we simply scanned the emulated host to assess its exposure.

PORT     STATE SERVICE     REASON         VERSION
22/tcp   open  ssh         syn-ack ttl 64 OpenSSH 8.9 (protocol 2.0)
80/tcp   open  http        syn-ack ttl 64 lighttpd 1.4.67
443/tcp  open  ssl/http    syn-ack ttl 64 lighttpd 1.4.67
1883/tcp open  mqtt        syn-ack ttl 64 Mosquitto MQTT
5355/tcp open  llmnr?      syn-ack ttl 1  DNS resolver
9001/tcp open  tor-orport? syn-ack ttl 64 Mosquitto MQTT over WebSocket

We can see that we have three major attack surface:

• web administration interface
• MQTT broker and connected clients (no auth required)
• Internet communications (firmware updates, cloud connectivity, etc)

By looking at each service, we found ways to fully compromise the device, starting from an unauthenticated user perspective.

Identified Vulnerabilities

Unauthenticated Remote Command Execution over LAN (CVE-2024-11665)

Summary

The whole web administration interface runs on PHP with a bunch of makeshift PHP scripts glued together. None of these scripts is protected against unauthorized access and feed user controlled input to system commands without prior sanitization.

Impact

Remote unauthenticated users connected to the same local network than the EV charger controller can execute arbitrary commands with elevated privileges on affected devices.

Affected Systems

• Hardy Barth eCharge Salia PLCC firmware versions<= 2.0.4

Description

All issues listed below are exploitable by unauthenticated users. It's due to the fact that lighttpd is configured to enforce authentication, but none of those apply to vulnerable PHP scripts.

‍

Some of those scripts are obviously leftover from debugging sessions. The one below gave our taint tracker some hard time.

We also found out that the CVEs reported by Offensity were not properly fixed. This is version 2.0.2 where the vuln was found by Offensity:

‍

And this is version 2.0.4 that supposedly fixed the issue:

‍

No change. At all.

‍

The web admin interface can also be used to get the device to connect to a nearby wireless access point:

There's also a network checking utility that tries to connect to services on the device or check DNS, NTP, ICMP reachability. Again, command injection all the way:

‍

Finally we have another network check utility, where we have command injection again:

‍

Unauthenticated Remote Command Execution over WAN (CVE-2024-11666)

Summary

Affected devices beacon to eCharge cloud infrastructure asking if there are any command they should run. This communication is established over an insecure channel since peer verification is disabled everywhere.

The firmware is full of connection establishment over HTTPS with certificate validation explicitly disabled.

It’s done with curl:

‍

$c = 'curl -k -H "Authorization: Basic REDACTED" -m '.$t_out.' --connect-timeout '.$t_out.' -X POST -d @/srv/salia/tmp_upload '.$dst_url.'upload.php >/dev/null 2>/dev/null';
$c = 'curl -k -H "Authorization: Basic REDACTED" -m '.$t_out.' --connect-timeout '.$t_out.' -X POST ';
$c = 'curl -k -H "Authorization: Basic REDACTED" -m '.$t_out.' --connect-timeout '.$t_out.' -X POST -d \''.$filedata.'\' '.$dst_url.'upload.php >/dev/null 2>/dev/null';

$c = 'curl -k -H "Authorization: Basic REDACTED" -m '.$t_out.' --connect-timeout '.$t_out.' -X POST -d @/srv/salia/tmp_upload '.$dst_url.'upload.php >/dev/null 2>/dev/null';
$c = 'curl -k -H "Authorization: Basic REDACTED" -m '.$t_out.' --connect-timeout '.$t_out.' -X POST ';
$c = 'curl -k -H "Authorization: Basic REDACTED" -m '.$t_out.' --connect-timeout '.$t_out.' -X POST -d \''.$filedata.'\' '.$dst_url.'upload.php >/dev/null 2>/dev/null';

‍

Peer verification is also explicitly disabled everywhere in PHP code:

$postdata = http_build_query($data);
$opts = array(
    'http' => array(
        'method'  => 'POST',
        'header'  => "Authorization: Basic REDACTED,Content-type: application/x-www-form-urlencoded\r\n",
        'content' => $postdata,
        'timeout' => 10
    ),
    'ssl' => array(
        'verify_peer' => false,
        'verify_peer_name' => false
    )
);
$context = stream_context_create($opts);
$ret = file_get_contents($url, false, $context);

Impact

Remote unauthenticated users  suitably positioned on the network between an EV charger controller and eCharge infrastructure can execute arbitrary commands with elevated privileges on affected devices.

Affected Systems

• Hardy Barth eCharge Salia PLCC firmware versions<= 2.0.4

Description

Devices regularly check-in with the eCharge infrastructure over an insecure channel since peer verification is disabled everywhere. Of course if you're in a hurry you can force the device to beacon by sending a message to an MQTT topic like this (yes there's no auth required):

mosquitto_pub -L mqtt://[controller IP]:1883/ -t port0/salia/portal -m 'start'

In the background, there's mqtt.php that listens for MQTT messages and acts like this:

1. if a message with topic (port0/salia/portal) arrives
2. if the payload equals "enable", "start", "1", or "true"
3. launch portal_start.sh
4. portal_start.sh does this: php-cgi -q /srv/salia/portal_send.php >>/srv/salia/portal.log 2>&1 &
5. so portal_send.php executes

A request gets sent out to eCharge infrastructure, holding telemetry data (hostname, version, IP, logs, etc) and the server answers with this:

HTTP/1.1 200 OK
Date: Fri, 22 Dec 2023 14:13:29 GMT
Server: Apache/2.4.25 (Debian)
Content-Length: 56
Connection: close
Content-Type: application/json

{"result":"ok","remote_command":"","serial":103878160}

We looked into mqtt.php and identified that a chain of events can lead to arbitrary command execution if you send a payload like the one below:

HTTP/1.1 200 OK
Date: Fri, 22 Dec 2023 14:22:51 GMT
Server: Apache/2.4.25 (Debian)
Content-Length: 113
Connection: close
Content-Type: application/json

{"result":"ok","remote_command":{"type":"internal", "topic":"uri","value":"$(id>/tmp/lol)"},"serial":103878160}

Hardcoded SSH AUTHORIZED_KEYS

The device embeds hardcoded SSH Authorized Keys, which seems to indicate that eCharge can remotely login to all devices at will. Probably by using the beacon feature to establish tunneling first.

‍

SMTP Credentials Leak

The firmware runs a web administration interface on PHP. Looking at the PHP engine configuration,./etc/php/apache2-php7/php.ini contains plaintext SMTP credentials for a eCharge company account belonging to one of their engineers:

./etc/php/apache2-php7/php.ini
[PHP]
date.timezone = "Europe/Berlin"
max_execution_time = 1800
max_input_time = 1000
memory_limit = 64M
post_max_size = 2000M
upload_max_filesize = 1500M
max_file_uploads = 400
allow_url_fopen = On
allow_url_include = Off

SMTP = smtp.strato.de
smtp_port = 465
username = s.scharnagl@echarge.de
password = REDACTED
sendmail_from = s.scharnagl@echarge.de

Hardcoded API Credentials

The firmware contains a PHP script at ./var/salia/portal_send.php that talks to a cloud service at https://saliaportal.echarge.de/salia/.

All the requests to that cloud service are authenticated using Basic authentication and a hardcoded account:

function file_post_contents($url, $data){
	$postdata = http_build_query($data);
  $opts = array(
  	'http' => array(
    	'method'  => 'POST',
      'header'  => "Authorization: Basic REDACTED,Content-type: application/x-www-form-urlencoded\r\n",
      'content' => $postdata,
      'timeout' => 10
		),
		'ssl' => array(
    	'verify_peer' => false,
      'verify_peer_name' => false
    )
  );
	$context = stream_context_create($opts);
  $ret = file_get_contents($url, false, $context);
  unset($postdata);
  unset($opts);
  unset($context);
  return $ret;
}

‍

The credentials are valid and shared by all the eCharge devices.

Cloud Infrastructure Information Leak

Since we can access the cloud infrastructure with the account mentioned above, we managed to find a few issues based on how the PHP code interacts with it.

First, exposed directory listing allows us to obtain detailed information about all the echarge devices deployed in the field. Each device has a unique ID and they use that ID to upload to https://saliaportal.echarge.de/salia/data/{id}:

We don’t need to enumerate the IDs since the upper directory is also exposed:

Cross-Tenant Access in Cloud Infrastructure

When accessed with the hardcoded account, the web interface of the cloud infrastructure looks like this:

‍

As we can see, there is an empty domain field. Since we had access to directory listing with scripts named intech.php or references to baumann we tried these values as domain and found out that it’s the only thing protecting against cross-tenant access.

We can access chargers of any customer:

And we can send arbitrary commands to these chargers:

‍

We reported, or at least tried to report, these infrastructure issues immediately and did not went further than observing the behavior of our emulated device with the infrastructure.

Key Takeaways

If you have ever been part of procurement for a security conscious company, you know it's tradition to perform a pentest on devices submitted by vendors participating in the tender. With the ONEKEY platform, you can already have a good sense of what you're getting into simply by uploading the firmware for each device you're inspecting. In this case, uploading different EV controllers firmwares - even if they're all built upon ChargeByte hardware - gives vastly different results.

On the vulnerabilities being reported here, this has been the worst vulnerability disclosure process of my career and I had really bad experience in the past, trust me. Right now there are 313 unique devices exposed on the Internet and since eCharge did not implement automatic updates, they're all running on different versions. As far as we know ,there was no communication with customers. We can't find any public advisories related to those issues. They shipped updates in April and May 2024 but we were not made aware of that fact. We tried to get them to improve their product and infrastructure security posture in a holistic way rather than a few fixes here and there but failed.

If you're private or corporate customer of eCharge, we strongly recommend that you put these devices behind a firewall and cut access to everything once the device is properly configured. Outbound traffic to saliaportal.echarge.de and cloud.echarge.de should be explicitly blocked unless requested by eCharge. When they do, ask why.

Disclosure Timeline

• 22/12/2023 - ONEKEY sends an email to Hardy Barth on info@echarge.de as soon as we discovered information leak
• 02/01/2024 - ONEKEY reaches out to info@echarge.de again
• 04/01/2024 - ONEKEY reaches out to info@echarge.de, support@echarge.de, h.barth@echarge.de
• 04/01/2024 - ONEKEY reaches out to Offensity asking for a contact at Hardy Barth
• 09/01/2024 - ONEKEY reaches out to info@echarge.de, s.scharnagl@echarge.de, support@echarge.de, h.barth@echarge.de
• 24/01/2024 - ONEKEY sends the report to German's BSI
• 23/02/2024 - ONEKEY reaches out to info@echarge.de, s.scharnagl@echarge.de, support@echarge.de, h.barth@echarge.de
• 26/02/2024 - eCharge gets back to ONEKEY since they got notified by the BSI
• 28/02/2024 - Meeting between ONEKEY and eCharge
• 08/03/2024 - Meeting between ONEKEY and eCharge
• 10/03/2024 - ONEKEY validates early fixes
• 02/04/2024 - eCharge publish version 2.1.0 with partial fixes
• 02/05/2024 - eCharge published version 2.2.0 with proper fixes
• 24/11/2024 - ONEKEY files CVE-2024-11665 and CVE-2024-11666
• 26/11/2024 - ONEKEY release its detailed advisory