> [...] we did find what appears to be Zaptec’s means of remotely debugging their devices. The first is a function called RunRemoteCommand. This passes the contents of a message received from the cloud directly to Process.Start. [...] A second interesting function called StartRemoteTunnel appears to allow Zaptec to create a reverse shell back to an SSH listener on the internet. [...]
I don't know if things have changed, but back in the day this sort of thing would be called a "backdoor". Yeah, only the manufacturer can use it, for now, but that lasts only until the manufacturer gets compromised, and either the relevant keys get leaked, or the manufacturer systems themselves get used as a jumping point.
This isn't a charger. It is a fancy electrical junction box. The voltage into the box and the voltage out is the same. The only function of the box is to switch the power on and off. And the car already has a switch in to switch stuff on and off anyway. So this box of expensive electronics is entirely redundant.
And they don't even provide much power - typically 32 Amps at 230 volts. Ie. about the same as a caravan hookup. But a caravan hookup doesn't need to run Linux...
That is false. These are much more sophisticated than a mere relay. Sure, there is basic logic between vehicles and EVSEs which is basically a smart relay: https://en.wikipedia.org/wiki/SAE_J1772#Signaling
...but the electronics you mentioned are for onboard controls (energy monitoring, Time of Use enforcement, load balancing between multiple units, etc). Some EVSEs are very simple, but many -- including the one in the article -- also handle upstream communication like OCPP: https://en.wikipedia.org/wiki/Open_Charge_Point_Protocol https://www.chargepoint.com/files/OCPP-Fact-Sheet.pdf
Here is an example of integrations for the model in the article: https://zaptec.com/downloads/ZapChargerPro_Integration.pdf
There are also implementations of power line communication over the Control Pilot pin in J1772, which most people notice when charging via CCS at a DC Fast Charger, but that is not limited to L3 charging. Note that QCA7005 chip in the article: https://www.qualcomm.com/products/application/wireless-netwo...
See also: Plug and Charge https://en.wikipedia.org/wiki/ISO_15118
There’s a nice open source implementation called OpenEVSE.
Isn't that the sort of thing that can typically be accomplished with nothing more than a resistor or two?
Typical caravan hookup here is single phase, 230V, 16A. This is ~3.5kW. Typical EVSE is 3-phase and 32A — ~22kW. That is fast enought for fully charging an EV overnight/during a working day. In fact there are plenty of EVs where AC charging is limited to 11kW. This is not a roadside fast DC charger, the application is quite different. Statistically most people charge less than 20kWh to get to the full battery in such scenarios.
This always gets me: "secure" meaning "the manufacturer remains the owner even after selling the device".
What does getting root access have to do with security? Does the threat model include the buyer of the device? If the box is physically opened by a random person, the damage has already been done - they can mess with the electrical installation already. What's the benefit of hiding the software in that situation?
Exercise your rights as the owner and ask for the sources instead. Linux is covered by the GPL.
> Damien Cauquil held a presentation at HITB Amsterdam in 2019 that went into detail about how this process works on I.MX based processors. Lucky for us, he released a tool that removes the OOB data. It produces a binary file similar to what U-Boot or Linux would see when interacting with the NAND flash.
Having it signed would provide no value for residential customers, where the chargers ostensibly would be physically secured, and should in that case actually be considered an anti-feature.
It seems to me they just included that "recommendation" because they couldn't find anything else to write.
Such a charger needs to be presented some kind of authorization, but the amount of energy transferred (and thus the amount charged) is only determined later.
Is the logic for that server-side, or is it triggered from within the charger? If the latter, could you avoid being charged by power-cycling the computer inside the charger before finishing the charge?
Probably the safer option would be for the charger to send a message like "for authorization XYZ, I've, until now, supplied 5.003kWh" every 5 seconds, then a server-side stream processor can detect the end of the charge and initiate billing.
A reboot will stop the charging process.
There are many different implementations, and different charging vendors tend to have varying degrees of functionality, so I would expect a pretty wide assortment of vulnerable chargers (and backend servers). A lot of them also seem to only communicate via static IPs.
So, nothing to brute-force except the two public SSH keys, which seem (eyeballing from the length of the key) to be at least 2048 bit RSA keys.
