Has this flaw been fixed?

ESPHome
21

Well, now the common believe seems to be that it is not a backdoor. But sorry, I cannot categorically say it is, but I cannot categorically say it isn’t.

This original post was about flash encryption, and when you put together encrytion with these HCI hidden debugging commands, I might have some concerns this could be used indeed as a backdoor, even acknowledging this might not have been necessarily espressif’s intention.

There is no 100% safety, unless you keep your devices permanently off and disconnected, but then you cannot of course use them. A boat in the harbor is safe, but probably a boat was not designed to stay in the harbor…

Being pragmatic, I do not think anybody is interested in hacking my custom made ZigBee energy counter… I might have some more concerns on somebody trying to access my lighting network, but I am definetely concerned about somebody being able to open my home door.

All these would require special interest, and I am not (as far as I know :wink: ) a person of interest, so the concern is merely academic in my case, but there are other cases.

Other than that, I do not think many of us are using firmware encryption to keep our home doors closed (I do, by the way, but again mostly out of sort-of-academic interest), and definetely not in the hunderds of devices we may be using and bought online.

So this is more a sort of mere academic discussion, at least in this forum, which does not anyway, in my understanding, lessen the value of the conversation. More on the contrary, security awareness is something that we are too much leaving aside in DiY world.

22

I can’t really think many of devices that allow full local control and ownership to an extend as it is possible today with esphome compatible espressif MCUs. Even the 10 year old esp82xx’s still gets easy ota (security) updates and are still supported by the manufacture. :medal_sports:

It is an ease to use espHome nodes fully offline (essentially the default if you don’t add components that require online sources) and the api encryption gives an extra layer on your WPAx psk/enterprise isolated VLAN :brick:

At the moment their even seems to be progress on one of the last bigger blobs (WiFi driver) for the esp32, which might end up being open source :raised_hands:

Well, if your door which previously only had ome (mechanical) attack vendor now gets more added (wirelessly/electronically etc.) it probably doesn’t matter much if the firmware (blob?) is encrypted or not - in any case it might just be unfavorable for the doors “security” :door: :boom:

So people continue buying random devices with random blob(ed) firmware they have no control (let alone ownership) over :tada:
And often even require other people computers to work :man_facepalming:

23

Of course, a new attack vector always lessens security, and as I cannot omit the need for the mechanical lock (look at what happens to Teslas when electrical lock fails…) adding an electronic opening is always less secure.

But at least I want it to be as secure as possible. And I give you a real example: some of my custom made devices are ESPs in the garden, connected to my wifi. I used flash encryption in them because otherwise anyone stealing one of the devices (the garden is quite accessible), could extract my external wifi credentials. My IoT wifi is isolated from my home one, but in any case it would already be one broken barrier, which shouldn’t be.

The found commands do not allow for this kind of attack, but I indeed tried a use case where these could have broken the security of the design: I intended to use a Bluetooth beacon sending OTPs for my mobile to use as credentials to open the door when approaching (yes, overcomplicated but mostly academic on my side). As BLE and Wifi did not coexist well, I was using two encrypted devices communicating to each other. I was not using the HCI interface, but I could have easily used it. The point of encrypting the devices was to protect the stored keys and credentials in case a device was stolen… So this comes too near the use case where the found issue could at least be tried to be exploited.

That’s why the finding concerned me. Because it can break some security designs, and because found one, there is a door open to think there might (or not) be more

24

If you wouldn’t use PSK for WiFi… :person_facepalming:

You also forgot that flash encryption is broken (in hardware), see first post :point_up:

It’s a bit like the clients that by default backup their encryption key to other people computers (Microsoft/Apple/Google cloud) and often are even based on insecure “trusted” platform modules that open hardware attack vectors :raised_hands:

It’s called security through obscurity what you are doing :bulb:

25

I know. That’s when I started losing confidence with ESP. But that HW flaw is a side channel attack, so not something to be easily considered a backdoor. Even several gaming consoles and TPM devices for computers are vulnerable to it. Security has its limits,… and I am quite sure Espressif is working hard to fix it in future HW designs. Just not so easy.

Storing credentials in an encrypted sealed HW is not security through obscurity. But effectively doing it in an ESP requires full flash encryption. The security in this case is not provided by encrypting the firmware, but anything that pretends to be called minimally secure, and uses credentials, needs to store these in a way they cannot be accessed from out of the sealed environment, regardless of whether these are PSKs, certificates, or whatever.

All of our unencrypted ESP devices and home projects store our wifi credentials in such a way it can be easily retrieved from a stolen or lost device. That’s where I come to:

To be honest, I do not think my IKEA Tradfri’s or any cheap Tuya or Wifi device I bought are doing better. But discussing about ESP and ESP encryption, it was meant to “do the right thing” if you wanted to use the feature. This is the whole point of the discussion.

This is what I understand can be broken by these HCI commands if you are using the device as a comms slave.

Others might argue that it can also lead to leaking industrial property secrets stored within an encrypted firmware. That’s not my case (i do not have any industrial property), but I understand it may be an issue for others. Consider the case of i.e. proprietary Zigbee Pro keys stored in an ESP and meant not to be retrieved. I myself believe this kind of vendor secrets is a bad idea (once leaked, no fix possible), but it is common in the industry :man_shrugging:

In terms of code safety, and I am an open source advocate: nothing further away from security through obscurity…

26

Again, storing a pre shared key (shared among various devices!) is not something a person with “security awareness” would do in the very beginning. :unlock:

I’m not sure which your relations are with Tarlogic (“experts”) but it seems almost too obvious what your mission here is since you joined one day ago :wink:

I for myself would be quite pissed working hard to qualify for the espressif bug bounty (:moneybag:) program just to find out the “backdoor” my team found isn’t a real (remote exploitable) one :person_shrugging:

27

Interestingly enough, you and @tom_l seem quite aligned here. See my response to it in another other post #29.

Gratuitously and publicly accusing somebody of having a conflict of interest without knowing anything about him, and not even asking before in private, just to undermine his credibility because you do not like what he says and cannot reasonably argue with him, just won’t work.

An apology would be appreciated.

So now please tell me how your wifi PSK is stored in the ESP when you connect it to the network. Enlighten me, because it is plain text.

28

Again, people with “security awareness” would not do this in the very beginning but instead use an enterprise authentication to don’t have the risk of PSKs getting out of hand :warning:

If you would be here as long as some of us you would know that this is exactly how trolls act when they are on a mission. They sign up and overintensively hog on one topic that is often completely separated/independend from home assistant or esphome. The fact that you continue hard after challenged with few replies does even worse… :person_shrugging:

Talking that you came here to open threads for your HA tools you are using for years… only we can’t see anything :eyes:

1 Like
29

Again, people with security awareness will develop properly designed solutions, but:

  • Normal users of these solutions will not use EAP. Normal users have PSK in their wifi.
  • Even with EAP, the credentials and keys to access the wifi will still be stored in the ESP, so you are not really making any difference if the ESP memory can be read from the outside, are you?

Sorry guy, I just left an awareness note on an ongoing post, and you started literally attacking me. I have even publicly identified myself in one of the previous posts. Not exaclty what a troll would do.

But you keep attacking. Now you call me a troll. It is not me precisely who is acting a troll here. Problably you should read your own posts and look at yourself in a mirror.

Thanks for keeping me answering to what any decent person would consider gratuitous attacks, instead of being able to do something useful like documenting a little bit these tools to publish them.

Too much energy wasted here, but as far as you keep trying to publicly undermine my credibilty just by letting go gratuitous unfunded assertments and being totally disrespectful, I will keep defending myself.

30

You know, you can just stop responding to what you consider to be gratuitous attacks. Sometimes saying more just makes it worse. Or, as the song says:

You say it best when you say nothing at all
When You Say Nothing at All - Wikipedia

I am interested in hearing more about what you have created. I am also interested in what you are doing to keep your system secure. Perhaps if you focused on that you would convince people that you are here to help others. You might be right that there is a (some size) threat with the esp32. With your current writing I don’t believe you have convinced anyone of that. So, what is your real goal? Don’t tell us, show us with your responses.

3 Likes
31

HOW?? Your internet credentials are not flashed to the device, just your local network. If someone wants your net credentials there are far, far easier ways than physically stealing an IOT device.

You can’t possibly be this paranoid.

32

You both are saying the same thing. It is the Wi-Fi credentials, which would give someone access to that network. If they are smart enough (may not require nation state level, but definitely more than basic) they can figure out how to get elsewhere (connected networks).

33

Off-topic on this thread, but will heads up to you when posted.

Well, not trying to convince anybody of anything. This is more informative than anything else.

You will find out I am saying mostly the same thing other people is saying.

General case (standalone ESP32):

  • The found HCI debug commands do not represent in general an extra threat at all for ESPHome users.
  • This is because in a typical application the ESP32 works standalone, and the application firmware itself can already anyway access whatever these HCI commands allow to do.

ESP32 as a comms slave (not so common):

  • ESP32 can be used as a slave processor to provide communications to another processor, which contains the main application.
  • This may make use of these HCI commands, in which case, as stated by Espressif, ESP32 memory could be accessed only if you have physical access to the chip.
  • This again poses a zero extra threat for ESPHome users, because you already have physical access to your device, and are anyway able to read and write to flash at wish.

But I disagree to statements saying this is a non-threat at all in all and every possible sceneario, disregarding the finding as futile, smoke, or click-baiting article.

Encrypted ESPs: :point_left:

  • When the ESP is encrypted in production, the designer assumes the memory should not be accessible at all from outside the device.
  • This means that when using the ESP32 as a comms slave, and encrypted i.e. to keep user credentials safe, these HCI commands could - and this should yet be tested - become a breach in designs meant to be secure.
  • Again this poses a zero threat to ESPHome users, because, as far as I know, using ESP device encryption is not common at all, and do not know if it is even supported by ESPHome.
  • But it could still an issue for other ESP32 applications that were meant to be secure, and I would not freely disregard the topic as a zero threat in general not to be investigated further.

This brings also the point that, having nothing to do with the recent HCI commands issue, but indeed with the original post that was about encryption:

  • In general ESPHome applications are not secured against physical access to the device, as user credentials (wifi PSKs, EAP Certificates, ESPHome transport encryption keys, whatever) are stored clear text in the ESP32 memory, so having the ESP32 unencrypted, lets anyone that may get their hands on one of your devices gaining access to your credentials very easily, to be used at wish. Do you have a device in the garden or ever lost one? So then not so far from reality.
  • This is not an issue only for ESPHome, which is of course not to blame for this. Just raising the point that we should probably work to make the DiY community more “security aware”.
  • Off-the-shelf products are not better either. That is not anyway a reason to disregard the conversation of whether somebody might want his DiY devices to be better and more secure than most off-the-shelf ones.

As it happens, I suffered strong push back from both topics:

  • Stating that the HCI commands topic should not be so easily disregarded, means that I am somehow related to Tarlogic (which I did not know even existed before they published the paper). As it seems, it is better not to investigate further.
  • Highlighting we should leverage more the device encryption capabilities to try keeping at least user credentials safe, seems not to be a good idea. Probably it is better to leave things as they are, because considering that user credencials (wifi passwords, EAP certificates, transport keys, etc…) saved into the device memory - as needed of course for the device to connect, and that as of today are cleartext and readable by just getting hands one of the devices, is not proper security (?)

BTW, the guys at Tarlogic shot at their own feet when disclosing the finding as a backdoor too easily without having a workable or at least theoretical PoC to demostrate it, but I still think it is good they found and published it. They just run too much.

So I will just leave it here because I already dedicated enough time to this topic, unless of course somebody is asking for more details or clarifications.

34

This is exactly what I was saying :point_right: “extract my external wifi credentials” :wink:

Why not? :wink:

Now, seriously, not that paranoid. But when designing a solution, you must put yourself on the worst (but reasonable) scenario, and try to make your design resilient to that scenario.

It is not unreasonable to say an attacker could rob one of your external devices, as an entry point to your network. This is just one more attack vector to cover, specially if you do not design your devices only for yourself.

From Wikipedia - Security by Design:

  • Expect attacks
  • Avoid security through obscurity (:point_right: personal note here on ESP32 obscure blobs and ROM…)
  • Fewest privileges
35

First one: I ended up developing my own solution to run JavaScript automations for personal use. I decided to make it publicly available after more than a year of stable use, which is why I created the account to join the community. Just published it.

This one is not security related, but sure will be useful for many people who is more confortable with JavaScript than Python for complex automations. There will be more, but cleaning up code to make it publicly available (and minimally document it) takes time…

Any followup on this, anyway, please on the dedicated topic to avoid off-topic on this one.

36

First, start with a problem.

Security by design is essential for planning business and large facility networking where there may be sensitive data such as trade secrets or a cache of personal data. Either of which would have resale value to a black-hat hacker. To not follow security protocols could be fatal, or at least very expensive to the corporation.

But not to the average homeowner. Unless you work in a sensitive industry or have a few million dollars in unencrypted bitcoin in C:/documents/bitcoin.txt, you are simply not worth the risk.

Why would any hacker risk capture by stealing your property when the much more valuable data is already exposed on many corporate-level networks?

37

No way, you are telling me no one is interested in how many time my dog drinks from her smart bowl, when my light turn on,when my pond is low on water etc…

I’m disappointed :stuck_out_tongue_winking_eye:

1 Like
38

The problem is that it is too easy to currently get wifi passwords and other keys from IoT devices if you have physical access, including ESPhome ones, to whomever is willing to get them.

For some people it may no be important, in other cases it can lead to stealing sensitive information.

The average homeowner does not have ESPHome devices.

But the average ESPHome homeowner probably has a NAS, and other nice pieces of shared services in his home network, with wonderful information.

The same way I would not leave a sticker with my wifi password in the garden entrance, I would not leave a ESP with the unencrypted wifi password in its internal memory.

Not so easy to read for a passer-by, but easy to read for whoever has interest.

Because it is much easier.

Lots of security countermeasures in a big company vs none in an “average user” homeowner. More things to get that are usable by a robber, too…

But it looks like I am preaching in the wilderness :wink:.

Anyway, happy to have risen my hand :raised_hand: if just one single person has become aware of the fact that wifi credentials are not generally safe in wifi IoT devices, and decides to do something to mitigate it l.

At least using a separate wifi for IoT devices…, which solves part of the problem.

39

People using phones, tablets, computers or other clients with a operating system from microsoft, apple or google already sharing all their WiFi “secrets” without any physical access (thanks to the :cloud:) by default. :unlock:

Beside people put all their private stuff (even banking!) on their (unsecure) black box phones that even features independed :door: baseband processors allowing great shenanigans :scream:

Only part, you need to do better! :point_down:

As previously told you can make use of WiFi without a single pre shared key (that you fear to loose) and (with the help of HA for example) automatically cut any network access to individual device-(credentials) that do loose connection (robbed from your garden for example) until manually reviewed. :raised_hands:

Think of it as kind of a sand boxing - wouldn’t that be a great project for you to explore and share with us? :rocket:

Meanwhile I stay with my backdoorfree :tm: (?) ESP82XX that don’t include broken hardware encryption :hugs:

40

This is a wise piece of advice. I will stick to it by now.
Thanks! :wink:

1 Like