Shelly firmware 1.10 signed?

1. offizieller Beitrag

    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.

    Einmal editiert, zuletzt von doron (27. Juni 2021 um 00:59)

    One of the things why I love Shelly devices (and grown a profound dislike for cyber sec guys), is that like Tasmota, Raspberry Pie, etc. these vendors give us something we can work with to use and tweak as we (the general public) sees fit.
    Sure, you could close up the eco-system and make it much more secure. Look at Apple. They have closed up their ecosystem, and allow only signed, verified apps in their store. But it also means that without a paying developer account, I can't even write an app myself and put it on my own phone...
    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.

    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.

    For myself, I only use these devices within my home network, and they never need to connect to the internet. I would like you to insert malware in a firmware downloaded from Shelly, please do it.
    I don't see any real danger there.

    Finally, I would like to point out many manufacturers use firmware without this 'signing' bit. Take Pioneer, Dreambox, for example.

    So, when you can make it more safe and better, without impacting user experience, than please suggest ways to do it. It's too easy to stand on the side and just note how things could go bad.

    For me, I'm already very happy when Shelly resolves the bugs in their firmware. Millions of devices sold, no issue to what you are referring too has been met so far.

    Finally, maybe it's a little bit with target audience: for people to insert nasty things in software: it's gotta be worth it. Hence why Windows is such a wonderful target (why is the industry even still using Windows, the most dangerous and prone for attacks software, plagued by virusses and worms all the time. Why cling to such a bad OS?).
    Maybe Shelly as a platform is simply not even worth writing bad firmware for?

    In summary: for me it's a typical security guys overdoing it point that always comes back with security guys. Sure you need them, but you don't want to over do it either.
    I think the primary goal would be to have happy customers that can use the gadgets for their intended use. And I think Shelly is well succeeding in that. When you know of ways making it better for the audience Shelly meant these things for, be my guest: come up with answers, not questions (what my boss always used to say :D :D )

    Have a great day!

    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

    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

    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

    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 :S

    • Offizieller Beitrag

    Hi doron , welcome to the forum. :)

    Please open a ticket to the producer Allterco.

    I look forward to the answer of Allterco.

    You're most welcome :)

    I tried "Let's encrypt".

    So, I do not own any DNS domain.

    I don't want to pay for it, because I do not need it.

    So, in this case, the computers that are physically not reacheable from the internet are deemed unsafe, simply because they have no DNS name that can resolve them "on the internet".
    But I don't want to be "on the internet". I have a local DNS server that does the internal DNS serving.
    And it seems for this case, "Let's encrypt" will not issue a certificate, and all web browsers are always complaining the https servers are 'unsafe'.

    This feels to me like some scam where the world wants me to pay someone for having my own servers.

    It's sad. And that is why I don't like security advice, when all it does is asking me to go public on the internet, take additonal risks, pay additional money - all things I never asked for...

  • Dieses Thema enthält 5 weitere Beiträge, die nur für registrierte Benutzer sichtbar sind, bitte registrieren Sie sich oder melden Sie sich an um diese lesen zu können.