Pwning a Smart Car Charger, Building a Botnet

…or Why We Don’t Build Commercial IoT on a Raspberry Pi.

A positive story of disclosure and remediation.

We’re quite into our electric vehicles at PTP, so we started hunting for a smart car charger. There are plenty of industrial chargers out there and some research has been done in the past.

We got close with a Rolec charger that was being advertised, but discovered that it was vapourware at the time. I’ve since ordered one so watch this space…

Instead, we settled on the EO Car Charger which fortunately was real, available and had around 4,000 customers already.

eoHUB

This is the interesting part of the installation. It hooks up to the chargers through an RS485 connection, then on to a wired network through the below RJ45

Image credit: EO Charging

At £480 it wasn’t cheap but was capable of controlling up to 30 chargers. It clearly had the ability for OTA firmware updates, adding capability. Interesting:

Image credit: EO Charging

I had just acquired a FLIR One Pro thermal camera, so had a look at the box:

Hang on a sec – that looks very familiar. Opening it up:

Er – that’s a Raspberry Pi in a box. About £30 cost, plus the PSU and case. I’m expecting a lot of the software, given the ~£400 of remaining differential cost!

“Rooting” It

Yeah, not exactly 1337 skills required here: Remove the SD card, inject root account, boot up device and SSH onto it with newly created credentials. Root.

Source Code

I wasn’t expecting it to be quite this easy. The device runs from two Python scripts, both of which were fully commented by the developers.

Gen.py (5078 Lines)

EOBootStrapper.py (1615 Lines)

Thus far (10mins) , we have:

• Full “Source Code” of device.
• An overview of the network topology from the hardcoded strings.
• FTP Credentials
• SMTP Credentials
• Encryption / Decryption Keys

What next? Let’s see how it talks back to the mother ship.

Boooo! Its all encrypted. Worry not as we have everything we need to decrypt the flow.

Reversing the Encryption

A few moments later we have DecryptEOr.py

So:

The cleartext commands are defined in the source, meaning that we have a complete understanding of the underlying communication.

The developers set out to send this traffic over a VPN connection but have not actually implemented it.

Botnet?

To date, EO has made almost 4,000 chargers, with around three-quarters installed in the UK. We could push our own code to the device:

So now one could push rogue code and create a smart car charger botnet. If enough chargers could be compromised, it might be possible to create spikes on the power grid by synchronously turning all the charges on / off / on.

Disclosure

The Good News: Whilst the product itself was a bit of a security train wreck, the response to disclosure was definitely NOT the usual IoT car crash.

I think EO should be commended on their response. They responded fast, took detailed advice, engaged an expert third party and moved hell and high water to get fixes out within a 90 day disclosure deadline

Quick Response

Here’s what we sent them on 13^th June

Then they proactively called the following morning to discuss the detail, following up with this:

The next step didn’t go quite to plan, as I don’t think they understood that the complete lack of identity, secure access control and secure authentication to the hub (as a result of building on a Pi) meant that the installed base couldn’t easily be securely updated.

I suggested instead that they needed external advice, so recommended a few options for IoT security implementation consultants. They chose David Rogers of Copper Horse, who we know well through involvement with the IoT Security Foundation and the DCMS IoT Security Code of Conduct.

They’ve helped them assess risk, come up with a reasonable plan and push updates.

Here’s what they sent us a few days ago. It’s very honest, it doesn’t try to cover up issues and takes the problem seriously.

Lack of strong identity of device

The identity of the device is used to determine what actions are to be completed on the hub, servers, and all involved APIs, either directly or via other means. The disclosing party reported that the identity of the device was not strongly associated with any single device and as such was easy to impersonate. PKI routines have been developed to enable a strong identity of all hubs in the network. Each hub will be issued with a certificate which is strongly bound to its identity.

This certificate then plays a key role in the ability for the hub to communicate using encrypted channels with the server. Furthermore, the heterogeneity that is inherent in these unique identities combined with strong access control makes us confident that attacks from one hub to another are now prevented.

Poor authentication for bootstrap/activation process

Activation and bootstrapping were not tied to any identity. This meant previously anyone could perform the bootstrapping and activation process. Bootstrapping and activation is only permitted with administrative interaction on the EO cloud. Further improvements have since been made that mean these actions are only possible inside known and trusted network segments. Future software upgrades will be communicated using the strong encryption and integrity provided by the strong identities which are also now implemented.

Inadequate transport encryption

The encryption techniques used provided no authentication, were malleable, and used a common shared key across all devices. The strong identities now in place enables strong and mutually authenticated encryption to be enforced between the hub and the server.

Hardcoded credentials

Multiple hard coded credentials of a variety of kinds were found in the device’s file system.Each stored credential has been independently reviewed and corrected. There are now no credentials stored in plaintext and no shared credentials between multiple devices. Wherever legacy code was found which included a credential, the associated services have been decommissioned and the code has been removed.

Inadequate protection from device takeover

There is no protection against a local attacker altering the file storage and gaining full access to the local device as “Root”. Plans are being drawn to replace the hardware with a suitable device and chipset that can prevent easy access to the file system. The replacement hardware platform will have a TPM / TEE or similar trust anchor by which keys and digital signatures can be validated, as well as the use of seamless Full Disk Encryption (FDE).

As this involves significant hardware updates, and those tasks can take many months, this vulnerability has not been corrected directly. Instead immediate and prioritised action was taken to ensure that vulnerabilities that could have been used for “lateral movement” or “pivot” attacks were corrected. Server-side monitoring is also being implemented in the meantime to provide a belt and braces to potential attacks.

I wish all IoT vendors were like this. Congratulations EO

Whilst it would have been much better for the product to have been secure in the first place, through a good response to disclosure and bringing in expert help, the problem is largely resolved.

What a refreshing end to an IoT security issue; a cool vendor.