Smart car chargers. Plug-n-play for hackers?

Over the last 18 months, we’ve been investigating the security of smart electric vehicle chargers. These allow the owner to remotely monitor and manage the charge state, speed and timing of their car charger, among many functions. We bought 6 different brands of chargers and also reviewed security of some public charging networks.

The mobile apps all communicate with the charger via an API and cloud-based platform, with the chargers usually connected to the users home Wi-Fi network.

TL;DR

• We found vulnerabilities that allowed account hijack of millions of smart EV chargers
• Several EV charger platforms had API authorisation issues, allowing account takeover and remote control of all chargers
• One platform had no authorisation at all: knowing a short, predictable device ID allowed full remote control of the charger
• The same charger had no firmware signing, allowed new f/w to be pushed remotely and the charger used as a pivot on to the home network
• One public charging platform exposed an unauthenticated GraphQL endpoint that we believe also exposed all user and charger data
• Some EV chargers were built on a Raspberry Pi compute module, which could allow an easy extraction of all stored data, including credentials and the Wi-Fi PSK
• As one could potentially switch all chargers on and off synchronously, there is potential to cause stability problems for the power grid, owing to the large swings in power demand as reserve capacity struggles to maintain grid frequency

All API and hardware vulnerabilities were successfully disclosed to the vendors involved. All API flaws were remediated, though one vendor only responded and took action once we had involved a trusted journalist.

The Raspberry Pi hardware issues remain, however the risk of compromise seems low, given the need for physical access to the charger. As a precaution, one could disconnect the charger from home W-Fi and change the PSK. Another option may be to glue the faceplate of the charger to the rear, though this seems a little extreme.

Smart domestic chargers

Several of the 6 different, popular brands we looked at had account hijack vulnerabilities in their APIs. All were accredited for UK government grant funding and included brands popular across Europe and the USA.

We looked at the following brands:

• Project EV / ATESS / Shenzen Growatt
• Wallbox
• EVBox
• EO Hub and EO mini pro 2
• Rolec
• Hypervolt

Project EV / ATESS / Shenzen Growatt

The Project EV charger was manufactured by ATESS with an API and platform provided by Shenzen Growatt.

These were the least secure chargers by far. We could hijack users accounts and prevent charging.

We could also push updated software (‘firmware’) to the chargers remotely. This allowed us to use the charge point as a remote ‘back door’ in to the users home network, from where we could potentially compromise further devices in the users home.

Project EV API checked for correct credentials on the first login request which was a POST on:

/ocpp/user

However, one didn’t actually need to log in – it simply assumed that all parameters that were passed to it after were correct!

This could allow an attacker to access and control any charger as long as they knew the username or the serial number of the charger.

Serial numbers had a predictable format which could be easily brute forced so that you could enumerate the existence of all chargers.

Example requests:

Locking a charger, stopping it charging:

POST /ocpp/api/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Content-Length: 64
User-Agent: Dalvik/2.1.0 (Linux; U; Android 9; Redmi 8A MIUI/V11.0.3.0.PCPMIXM)
Host: charge.growatt.com
Connection: close
Accept-Encoding: gzip, deflate

{"chargeId":"TTD0xxxxx","connectorId":1,"lan":1,"cmd":"lock"}

Unlocking a charger:

POST /ocpp/api/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Content-Length: 64
User-Agent: Dalvik/2.1.0 (Linux; U; Android 9; Redmi 8A MIUI/V11.0.3.0.PCPMIXM)
Host: charge.growatt.com
Connection: close
Accept-Encoding: gzip, deflate

{"chargeId":"TTD0xxxxx","connectorId":1,"lan":1,"cmd":"unlock"}

Disclosure

Project EV did not respond to our initial attempts to disclose, but after contact from the BBC, implemented strong authentication and authorisation, together with a firmware update for the chargers. Shenzen Growatt was also the largest platform by far – it had roughly 2.9 million devices on it, all of which could be remotely exploited through a lack of strong authentication and request authorisation.

Wallbox

Wallbox had two separate insecure direct object references in their API which allowed account hijack.

They also used a Raspberry Pi Compute Module for their chargers. We love the Pi, but in our opinion it’s not suitable for commercial use in public devices as it is very difficult to fully secure it against recovery of stored data.

Disclosure

We disclosed these to Wallbox, who fixed the API issues within a few days. They also offered us sight of their planned new hardware platform, but wanted an NDA signed. We declined, as we were more interested to know whether they would replace existing users chargers with the new charger for free.

EVBox

EVBox were the most responsive of all the charger manufacturers. The API vulnerability that allowed account hijack was acknowledged and fixed in around 24 hours, a very impressive response.

On the EVBox API it was possible to change your user role . This was possible by observing the response when a profile was requested and seeing the update to your profile request. Afterwards missing values were tried and verified to be working:

Response:

HTTP/1.1 200 OK
Date: Fri, 30 Jul 2021 12:30:48 GMT
Content-Type: application/json; charset=UTF-8
Connection: close
CF-Ray: 676e99a8ff6553cd-LHR
Access-Control-Allow-Origin: https://evbox.everon.io
Cache-Control: no-cache, no-store
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Via: 1.1 google
CF-Cache-Status: DYNAMIC
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, X-Access-Token, tenantId, tenant, Authorization
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, PATCH
Access-Control-Max-Age: 180
Expect-CT: max-age=604800, report-uri=https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Vary: Accept-Encoding
Server: cloudflare
Content-Length: 396

{"firstName":"egw1","lastName":"egw1","email":[email protected],"language":"en-GB","status":"ACTIVE","roles":["ACCOUNT_ADMIN","ACCOUNT_OWNER"],"id":"bd4358ca-838c-4119-9f7a-99a2a747770b","oktaUserId":"00uascl0k2XXZXT8w416","lastLogin":"2021-07-30T12:30:15Z","createdAt":"2020-12-03T09:15:04Z","invitedBy":"","blocked":false,"activated":true,"accountId":"8663791e-6ae9-44a2-934c-6ca737f619b8"}

Adding the roles array with any of the accepted role names( that were obtained from the error messages when a random value was added) would make a privilege escalation possible. When adding the tenantadmin role the user had full admin right to the tenant and all chargers that were controlled by it.

PATCH /api/users/profiles/00uascl0k2XXZXT8w416 HTTP/1.1
Host: api.everon.io
Accept: application/json, text/plain, */*

{"profile":{"firstName":"egw",
"roles":["ADMIN","ACCOUNT_OWNER", "tenantadmin"]
}}

Giving admin privilege on the platform:

EO Hub and EO mini pro 2

EO were the first to market in the UK with a smart charger, using the EO Hub for control, but suffered from ‘first mover disadvantage’ in terms of security. The charger ‘smarts’ were also built on a Raspberry Pi, which is difficult to secure, given bootloader security issues. EO responded quickly to our disclosure and re-architected their entire system on to a new, more secure platform. This work is covered here.

However, we were surprised to find that the EO mini pro 2 used the Raspberry Pi again. We have an earlier EO mini pro, which does not use a Pi. This seems to be a backward step.

The charger on the left is the earlier EO mini pro owned by us. A Zentri MCU can clearly be seen, which offers improved hardware security compared to the Raspberry Pi. However, on the right is an image of the interior of the more recent EO mini pro 2, taken from the EO installation guide. It has clearly taken a backward step and uses the Pi. We’re not sure why EO have done this, given their prior efforts to re-platform.

Along the way, we also noticed a vulnerable service on our EO mini pro. TCP port 2000 has no authentication and one can both read and write config to it, potentially preventing it from communicating and also exposing sensitive data such as the PSK. As an example, we’ve changed DNS here:

However, the impact is somewhat mitigated, as one would first have to crack the owners Wi-Fi key.

Rolec

Of the above, Rolec was the most secure, particularly as it used a SIM and mobile data for transmission of data. This made traffic interception somewhat harder than with a Wi-Fi connection, though not impossible.

Hypervolt

The Hypervolt also used a Raspberry Pi, so offered minimal hardware security.

Smart public chargers

Public charging can be  a little painful, given the number of different operators and apps that one needs to use. Some inter-operation between charging networks is emerging through the Open Charge Point Interface (OCPI). This means that a user with an account on one charge providers system can use other providers systems and be cross-billed, a little like international roaming for smartphones.

We found an exposed GraphQL endpoint in Chargepoint, a large US provider of charging infrastructure with both their own and ‘roaming’ agreements with around 150,000 chargers across the US, Europe and elsewhere. The endpoint allowed introspection which allowed the viewing of the details of its APIs.

We didn’t poke further than this, as there was an immediate risk that the endpoint would dump all of its sensitive content to us in response to further queries.

However, we believe that it would be possible to attach a user account to another and obtain a free charge on someone else’s dime, for example

Disclosure

Chargepoint were particularly responsive and quickly acknowledged the issue. It was fixed in around 24 hours. Cool vendor!

In hindsight, as Chargepoint had a good vulnerability disclosure program and willingly engaged with researchers, we could probably have investigated further without causing issues. This was only apparent once we had started the disclosure process though.

Wider issues with public chargers

The increased interoperability of OCPI creates some intimidating security problems: it means that a vulnerability in one platform potentially creates a vulnerability in another. Any one platform that a charging firm have an OCPI connection to potentially exposes their own chargers and security.

The consequences include:

• Theft of electricity by account compromise, charging the costs to legitimate users
• Preventing legitimate users from charging, by sending messages to stop the charger
• Causing grid stability problems by stopping, starting and stopping charging across many chargers synchronously

Destabilising the power grid?

Fast car chargers consume a LOT of power. One station in Gretna Green has four of these, consuming 1.4MW if all are in use concurrently. That’s roughly the same as 1,000 homes!

Our power grid is less resilient to large swings in power consumption now that renewable energy has taken over from coal: the ‘everyone making a cup of tea at half time during the World Cup match’ problem.

By switching on, off, on, off a large number of powerful chargers at once, one can destabilise the power grid. Whilst our power generators make huge efforts to maintain stability, these powerful chargers and security flaws combined have inadvertently created a cyber weapon that others could use to cause widespread power cuts.

Conclusion

There has clearly been a distinct lack of security assurance in the smart EV charger space. There’s something of a EV ‘gold rush’ going on as homes equip themselves with chargers and the public charging infrastructure offer more and more powerful charging.

Basic API security has been missing, as has some basic secure hardware choice. Manufacturers have exposed users to fraud and/or prevented their cars from charging. They’ve also unintentionally created a method for others to destabilise our power grid.

Hopefully this research will encourage charger manufacturers and regulators to ensure security is taken more seriously.