Hacking a Virtual Power Plant

> A major selling point for me was that they have a local network API which can be used to monitor and control everything without relying on their cloud services.

That would be a MAJOR selling point for me, too! Especially because most of the companies that do this for residential are getting a huge portion of the profits using YOUR batteries, rather than getting that profit yourself. Unfortunately, where I live, that is mostly because energy utilities are hostile to anyone except large middlemen installers and their VPPs. It would be simple for them to also allow individuals to sign up for dispatch if they were half-competent. I can't find any companies providing battery systems plus solar that are able to be fully local in my area of the USA, either, even if I wanted to try and go "off grid" using massively overbuilt batteries linked to solar.

None of this would have happened, if the token were a traditional strong random number backed by a database on their API server. I've always disliked JWT for that reason: it keeps too much state in the untrusted client, depending solely on the strength of the cryptography to protect it, and any slip-up (like this one, or the classic alg=none, or failing to correctly using a random number with ECDSA) means the client has full control. With a strong random token, all the state is in the database in the server, and the worst the client can do is leaking the token.

> Expecting developers to know that 512 bit RSA is insecure clearly doesn’t work. They’re not cryptographers. This is not their job. The failure wasn’t that someone used 512 bit RSA. It was that a library they were relying on let them.

I disagree. Anyone using a library should have enough knowledge to use it properly, else they shouldn't be writing serious software. The flip side is that the library should be documented clearly enough to prevent a competent professional developer from making that mistake by accident.

I don't have an issue with a library supporting outdated standards since that can be useful for writing (hopefully temporary) code to interface with legacy systems. Again, as long as it's documented properly, and the devs understand the potential ramifications.

> the legitimate ones I’d initially generated still worked

This spooks me. I take this to mean either:

- They are still using the compromised key for validation, meaning if you have access to any old token, you can still mutate that, maybe needing to play around with the issuing times

- They built an allowlist of all permitted tokens, and check that list first. In which case, might as well use random session ids instead of JWTs, and at the same point where the allowlist is being checked, mutate the request to inject a JWT that the backend can use.

Also, kind of curious why the switch to RSA4096 instead of elliptic curves, since they are generally faster / smaller.

Now imaging the amplitude of a deliberate attack not to personal domestic p.v. productions but en-masse against the grid: most hybrid systems also can inject, p.v. and eventual batteries can inject all together, eventually ignoring grid frequency burst. So far probably those systems are not so common do generate widespread damage, but once they'll be spread it would be easy to generate a large scale blackouts.

Just to say that no proprietary devices should be ever allowed to have remote connections, FLOSS must be mandatory from the early stage of a project to allow third party inspect the codebase not starting with a gazillion SLoC, being de facto unable to understand them, instead of starting from the first SLoC following at the project evolutionary speed.

Nowadays it start to be again damn easy to plan any kind of "unexpected logic" in gazillion of devices, potentially at State intelligence level, from cars to energy systems, TLCs active devices, ... not a new thing at all, but easy enough to be dangerous enough to MANDATE FLOSS if those who care of a nation security have at least an idea of the current role of IT in a society and it's enormous mean attack surface.

Not much about the potential severity of hacking something like this: You could probably blow circuit breakers in MV substations with a vulnerability like this if there are enough batteries under control in the same area and you get them to all discharge at max current at the same time. Serious, expensive damage. They could be substations connected to essential services like hospitals (though they’ll have backup gensets).

The energy transition is going to be a fun time for infosec!

My parents have one of these systems installed - the guy that did it took the password off their WiFi since it "doesn't support it". Even with a password on the home WiFi it defaults to broadcasting it's own open SSID that will happily display the wireless key to anybody that connects to it. Apparently these don't support Ethernet either..

The Ars Technica article may also be of interest - it has a statement from the company.

https://arstechnica.com/security/2024/08/home-energy-system-...

> not only was I no longer able to mint my own API tokens, the legitimate ones I’d initially generated still worked

can someone explain what's meant by this? i presume the private key identified by the author still works, but will stop working after 7 days?

(based on the sample JWT in the first section, the expiry time of the token seems to be 7 days)

"They’d switch to a 4096 bit RSA key, but not only was I no longer able to mint my own API tokens, the legitimate ones I’d initially generated still worked."

I wonder how the old JWTs signed with the 512-bit key still work safely, isn't that 512-bit key cracked??

I do wonder how you got in contact with them? No security.txt or other obvious ways to report a security issue.

Great blog post. The company response was really great, but there was no mention of a bug bounty. This would be a perfect example if he got paid for his findings.