Introduce security for local HTTP API

[ai91]

Firmware v055.8 allows to enable local HTTP API v2, which is great. Unfortunately the HTTP API is not secured anyhow. What means anyone who got access to the local network may send any request, including configuration modifications. Also potentially dangerous, like increasing limits, like ama, amp, etc.

Suggestion: add some minimal security, like Basic Auth.

[l3u]

If you don't trust people in your own network, then you'll have to turn this feature off I guess …

[erxbout]

If you don't trust people in your own network, then you'll have to turn this feature off I guess …

+1 Basic auth would be pretty useless because the traffic is still HTTP so its unencrypted and it does not matter if an attacker is already in your network.. But what you could do is using mqtts

[ai91]

If you don't trust people in your own network, then you'll have to turn this feature off I guess …

+1 Basic auth would be pretty useless because the traffic is still HTTP so its unencrypted and it does not matter if an attacker is already in your network.. But what you could do is using mqtts

I disagree. Please don't mix up different attack vectors: HTTPS covers MITM attack, while BasicAuth enforces access control. If attacker is already in your network - it doesn't automatically grand him access to network traffic. Yes, with Basic Auth credentials are transmitted without any encryption. But it still doesn't allow anybody to capture your packets if they are connected via WiFi to your network.

Also, connection to your network, doesn't automatically mean they are hackers who penetrated with some physical access to your router, or using Wifiphisher or something. They could be legit users: your guests, visitors of small hotel, etc. If you are not skilled enough engeneer to configure separate networks, your charger's configuration can be easily screwed.

Also. I don't really need to be in your network!. Don't forget also that current implementation of go-e Charger's HTTP API works via GET requests - I can send you a email with url in message body (it could be a <img src="http://192.168.1.202/api/set?delw=0">, or one of other 100500 ways to force your brower to make a GET request. Email may include 100500 <img> tags with whole 192.168.0.*/192.168.1.*/etc IP ranges). Even answering here I can prepare list of images, and you get email notification. Once you open email - your charger is misconfigured.

The perfect solution would be, of course, full modern security: HTTPS + BasicAuth or JWT or anything like that. But we are talking about pretty limited device. It would be great to have a full stack. But as a starter I'm proposing at least something which is pretty cheap in terms of implementation and resources.

Otherwise I would not recommend to enable HTTP API to anyone. Seriously.

[l3u]

Well, there you are completely in line with the official docs IIRC (or was it the Fronius HTTP API docs?!) – only enable the HTTP API if you know what you are doing.

But seriously. I'm all for security and whatnot. But why would anybody want to mess with the settings of my private charger, located in my locked garage? Just to f**ck with me? Sure, there are attack scenarios you could think of. But again: Why would anybody do that?

But about your specific attack: That's why I configured KMail to view plain text by default. And even if I did not, in this case, KMail warned me about your mail being potentially malicious due to hrefs pointing to local IP addresses, without loading anything.

If you have security concerns and still want to use the HTTP API, then put the charger in a network separated from your normal LAN and maybe separated from the internet. Or just don't use it.

I think implementing a full-featured security stack would only blow up the whole thing (speaking of complexity software-side and after all cost for the hardware) and complicate the very stuff people do with it. IMHO there's no real attack vector. Of course, this is not secure. But it also does not have to be.

After all, this is something the devs have to decide, I'm also just a user …

[ai91]

But seriously. I'm all for security and whatnot. But why would anybody want to mess with the settings of my private charger, located in my locked garage? Just to f**ck with me? Sure, there are attack scenarios you could think of. But again: Why would anybody do that?

Same reasons as millions of other attacks on printers exposed to Internets? Ever heard of them? IP cameras, child trackers, smart bulbs, routers, etc. For fun, because I can. 99.9% of viruses in early 90es till 2010es were non-profits, just to fuck ppl up.

But about your specific attack: That's why I configured KMail to view plain text by default. And even if I did not, in this case, KMail warned me about your mail being potentially malicious due to hrefs pointing to local IP addresses, without loading anything.

Good for you. You are an expert. But most users of the charger are not. Even here, among those who use github, IT-related folks, I bet many of them are vulnerable to attack i described above. Even developers of the charger didn't see how bad their API design in terms of security.

I think implementing a full-featured security stack would only blow up the whole thing (speaking of complexity software-side and after all cost for the hardware) and complicate the very stuff people do with it.

I'm only proposing basic auth. It doesn't require sophisticated security stack with various cyphers implementations. They already have base64 in codebase.

IMHO there's no real attack vector. Of course, this is not secure. But it also does not have to be.

I hope you see how void your arguments are.

Do you know how many companies were down because of similar fuckups? If some guy make a global attack with massive chargers bricking - go-e as a company is fucked. Just imagine stackoverflow attack from internet page. Even your KMail won't save you from such attack.

Side notes to developers @0xFEEDC0DE64 @CommanderRedYT : best thing you can do - is to request a security audit from external company who specializes on network attacks and on hw-specific attacks (like stackoverflow attack mentioned above). I love your devices, even consider to purchase a second controller ;)

[schinagl]

I see both sides, but I agree with security. I work for a large Graz (the one with the 3 letters😉) automotive supplier company and we are in the process of changing all our web apis to https, because and this argument has not been mentioned:

Our customer do not accept non https connections. The IT departments opinion on German car manufacturers is that crucial that we simply will not sell things if we don't comply. So easy. Unfortunately.

The IT departments are professionals when it comes to read the vulnerability databases and this is enough for them. 'Their way or highway' to speak with Trinity. 😉

So we are putting lots of effort into security even if it is a major effort to get our codebase towards being safe...

But being just Hermann, I like the ease with which I currently access go-e http api. You see I have a split mind😅

[chk2902]

https locally is a PITA due to certificate issues. Connections using the cloud are a PITA too IMHO.

go-e V3 (and Fronius) do already have an undocumented REST protocol with authentication and encryption. So you can leave MQTT, HTTPv1, HTTPv2 APIs disabled and use this one. The data records are still the same format as HTTPv2, but the protocol is plain websocket, encrypted and authenticated. Not easy to implement due to the missing documentation, and it was modified recently due to the mobile network support (some strange compression used for the JSON data), but it can be handled - my app uses that protocol and it works nicely.

Or use the cloud API of go-e as this is HTTPS if the cloud is OK for you.

[schinagl]

Shouldn't the use of the API be documented? What is the endpoint? Do you have code snippets?

[chk2902]

Whether it should or should not be, that's a question to go-e. I think it is because it makes it easier to make unannounced breaking changes (as they did recently). My code is not public domain or open source as it took me a lot of time to understand the protocol, but the WWW has some resources for this (like https://github.com/joscha82/wattpilot/tree/main/src/wattpilot or https://github.com/safepay/sensor.fronius/issues/48