Shelly firmware 1.10 signed?

Hi folks,

I'm new to Shelly products - quickly learning, testing the products and system for potential use. I'm a cyber sec guy and part of my testing is of this aspect. Hence also this question.

I've been looking at the various firmware packages downloadable via OTA and saw that they contain a digital signature component - this is critically important if you're doing OTA updates, all the more so since it seems that the Shelly OTA updates are being done via HTTP (and not HTTPS). I assume(...) that each device tests the sig against a vendor public key that is hardcoded in their existing f/w, and only if the signature matches, marks the incoming f/w package as valid and allows the update.

Now when I downloaded a 1.10.4 version firmware - e.g. latest SHPLG2-1.zip - and analyzed it, I could not find a trace of a digital signature. The zip file contains less files than in previous versions, basically just the manifest and bin files, and the manifest does not seem to contain such signature either. (It does contain SHA1/SHA256 hashes, but these do not validate authenticity - they can be used to assert integrity).

I'm sure I'm missing something - I don't find it conceivable that the vendor would remove such a critically important feature, and leave the OTA process open to trivial attacks.

Can anyone help me out here? Thanks for any insight.

Hi condiosz , thanks for taking the time to respond.

In spite of the tone of your post (what a welcome!), in practice we might be on the same side.

I'll just assume you've met some "security guys" in the past who rubbed you the wrong way.

I'm a long time open source enthusiast, who happens to also have vast security experience. The Shelly ecosystem, which for me translates to (a) a stable, safe and reliable vendor-provided software suite that can be trusted by the less computer-savvy customer, combined with (b) an open platform for modding and hacking for those who know what they are doing (you, and probably me and others on this forum), with a vendor who actually listens to those more savvy customers - is what drew me into considering this platform to begin with.

While (b) above is where I (and probably you) will spend most of my time, (a) is critically important. Without it, things like this are just a matter of time. If you want the company to thrive, you don't want that. And it's really simple to solve (maybe it is in fact solved - note that I asked a genuine question, not posted a rant or even a critique).

The risks involved with my question above are two: (1) The payload seems to not be authenticated, which would be a real problem for OTA updates, and (2) the firmware is moved via HTTP, which just makes it all the more simple to counterfeit. If (1) were solved then (2) would have been less of an issue. The combination (again, if I'm right about (1) - as I said, I'm just assuming! My OP was a request for assistance) is an accident waiting to happen.

Even if I will never let the smart switch connect to the Internet - and I never will - the firmware I download from the vendor's website and other locations who do archiving of sorts can be trivially modified to include malware, which I will never know about. That can't be good. Please read on.

Zitat von condiosz

Sure you have a point about all the technical points you are adressing above, and it is quite easy to ask these questions. However, I would also like if you could provide hints as how would you solve your points above, without making the user experience hell.

With pleasure. In fact the point I made in the question I asked is quite simple to solve, without any negative impact on users like you and me.

It's a bit awkward for me to presume, since as I said we've just met (Shelly and me that is), but since you asked (while attacking me), here's a sample solution. This type of scheme is quite widely used and is by no means special or unique:

(a) Digitally sign all payload (f/w etc.) that is to be carried OTA or downloaded from the vendor's website, with one of a few private keys whose public counterparts are hardcoded into the firmware.

(b) Have the firmware validate the OTA payload using the above signature, before allowing OTA to proceed.

(c) Have an "advanced / developer" type of setting in the UI, allowing you to override the validation in (b). "Allow unsigned OTA update" or something.

(d) Move the official f/w download sites to HTTPS (see below).

(This is with a wide brush - there are nuances to the above, all quite simple to address. Done that, multiple times.)

You now have a system that's (a) safe for the general, cloud-using public and (b) trivially hackable with no effort, either via the OTA API or via the serial cable, for you and me.

Don't think Apple - think Android.

Zitat von condiosz

You see, for us to use https, we would have to buy certificates - official ones - which cost money, which are an additional hindrance to use (the general public) in using the software.

No, not at all.

First, meet Let's Encrypt. For the past 9-10 years, they've been handing out free TLS certificates. Feel free to use those anywhere (on a public routable IP address).

Second, what I describe above re HTTPS, is only for the official sources of firmware. The general public will only benefit.

Zitat von condiosz

I would like you to insert malware in a firmware downloaded from Shelly, please do it.

No, you don't... Trust me on that one.

But one successful attack on just one site carrying the official firmware, is all it takes. Those things happen every day. Usage of HTTP only makes the attack surface wider.

Anyway to wrap up, I think we're seeking the same goals. Simple and secure out of the box, easy and hassle-free modification for the relevant crowd.

I hope the above somewhat reduces your "profound dislike for cyber sec guys". Then again, maybe not