Pwning(owning) a Raspberry Pi EO EVSE> PV &pwrwall use, rooting a Botnet

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Pwning(owning) a Raspberry Pi EO EVSE> PV &pwrwall use, rooting a Botnet

Electric Vehicle Discussion List mailing list
Pwning a Smart Car Charger, Building a Botnet
06 Nov 2019  Mike Polydorou & Andrew Tierney

 EO Charging
 FLIR One Pro thermal camera image (5078 Lines)  pi code (1615 Lines)
 wireshark shows tcp stream
 VPN not implemented

…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

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

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

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.

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.
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. (5078 Lines) (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


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.


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.

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

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 13th 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

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.

Visitors to Linganore winecellar get taste of owning electric car
2019-10-27  Teslas and other electric cars lined the parking lot at
Linganore Winecellars Sunday afternoon for the EV – Electric Vehicle ...

For EVLN EV-newswire posts use:


Sent from:
Please discuss EV drag racing at NEDRA (