ESP32/ESP8266 Wi-Fi Attacks • Hacker News Board

Re: ESP32/ESP8266 Wi-Fi Attacks

#121

Post by Klathmon » Wed, Sep 04, 2019, 1:40 AM UTC

fyfy18 wrote: post #120

Klathmon wrote: post #15

Earlier quoted context omitted.

They are also really capable processors on their own with some nice I/O, and they can be integrated to be really low power so things can run on battery power for months to years.

Can they really last that long (on their own)? I looked into this when the ESP8266 first became popular maybe 4 years ago as I wanted to build WiFi temperature and humidity sensors. My calculations were that a set of AAA rechargable batteries (~2000mAh) would last a few days at most, with the device in deep sleep most of the time and waking up every 10 mins to take a reading and send it over WiFi. Right now I'm looki…

Yeah, although it's a bit more involved than just getting any NodeMCU board.

A bare chip makes it much easier, and you need to balance what comes online and how long it sleeps to still work in your use case.

It's not all that easy in some cases, but it can be done. I've used [1] as a resource before in my own projects.

[1] https://github.com/z2amiller/sensorboard/blob/master/PowerSa...

Re: ESP32/ESP8266 Wi-Fi Attacks

#122

Post by Gibbon1 » Wed, Sep 04, 2019, 1:46 AM UTC

fyfy18 wrote: post #120

Klathmon wrote: post #15

Earlier quoted context omitted.

They are also really capable processors on their own with some nice I/O, and they can be integrated to be really low power so things can run on battery power for months to years.

Can they really last that long (on their own)? I looked into this when the ESP8266 first became popular maybe 4 years ago as I wanted to build WiFi temperature and humidity sensors. My calculations were that a set of AAA rechargable batteries (~2000mAh) would last a few days at most, with the device in deep sleep most of the time and waking up every 10 mins to take a reading and send it over WiFi. Right now I'm looki…

Not totally sure about the ESP8266. I used a WiFly RN131 in a sensor product that woke up every 15 minutes and sent a reading. AA batteries lasted probably 18 months.

Biggest problem we found was enterprise networks would randomly kick you off if you were using DHCP. I think because they would assume that if you hadn't transmitted in five to ten minutes it meant you'd gone away. Using static IP fixed that.

Edit: Friend of mine that mucks with ESP8266's uses the low power timer to reset and wake the device up out of deep sleep. (Via a simple hack I think just connecting a timer pin to the reset).

Re: ESP32/ESP8266 Wi-Fi Attacks

#123

Post by bpye » Wed, Sep 04, 2019, 2:00 AM UTC

microtonal wrote: post #47

stefan_ wrote: post #21

Earlier quoted context omitted.

Uhh, their WiFi implementation is hacked-together old open source code distributed as statically linked binary blobs. And that is just the software part, there isn't much visibility into the silicon side..

Plus they are a Shanghai-based company and can be compelled by the Chinese government to place hardware back doors. (They are great for makers though, very affordable, lots of features.)

Ive looked - a lot - to try and find a reasonable alternative. I haven't found any devices that are as inexpensive and convenient as the ESP chips. Microchip have some relatively inexpensive WiFi modules that need to be used with another MCU and Silabs have some modules including an ARM MCU (WGM160P). These still need blobs but I'm a little happier with a larger more established silicon vendor.

Re: ESP32/ESP8266 Wi-Fi Attacks

#124

Post by Gibbon1 » Wed, Sep 04, 2019, 2:05 AM UTC

bpye wrote: post #123

microtonal wrote: post #47

Earlier quoted context omitted.

Plus they are a Shanghai-based company and can be compelled by the Chinese government to place hardware back doors. (They are great for makers though, very affordable, lots of features.)

Ive looked - a lot - to try and find a reasonable alternative. I haven't found any devices that are as inexpensive and convenient as the ESP chips. Microchip have some relatively inexpensive WiFi modules that need to be used with another MCU and Silabs have some modules including an ARM MCU (WGM160P). These still need blobs but I'm a little happier with a larger more established silicon vendor.

I think (at least a couple of years ago) you could get a dev kit for Microchips parts. The difficulty was then you're responsible for keeping the WiFi stack up to date.

Re: ESP32/ESP8266 Wi-Fi Attacks

#125

Post by jsjohnst » Wed, Sep 04, 2019, 2:22 AM UTC

ChrisLomont wrote: post #119

jsjohnst wrote: post #118

Earlier quoted context omitted.

Yes. The specific scenario GP described is about SuperMicro and Amazon if my memory is correct on the parties involved. Edit: it was for sure SuperMicro and Amazon. https://www.bloomberg.com/news/features/2018-10-04/the-big-h...

That story was widely debunked in followup stories. No one ever demonstrated any of the claims in that story.

I didn’t say it wasn’t debunked, I said that it is what GP was talking about. I didn’t think the “debunked” part was relevant to the question asked that I was responding to. I guess you think it is, so my apologies.

Re: ESP32/ESP8266 Wi-Fi Attacks

#126

Post by skataz » Wed, Sep 04, 2019, 3:05 AM UTC

That's why I keep them in my network only

Re: ESP32/ESP8266 Wi-Fi Attacks

#127

Post by GeorgeHahn » Wed, Sep 04, 2019, 4:09 AM UTC

kyledrake wrote: post #46

This is interesting for screwing up badges at Defcon, but I wouldn't lose too much sleep over it. They're neat devices but not really used for anything critical. I'm also not sure they're being used for a lot of consumer devices. If you war drived a major hackerspace you might reset an led light art project.

In addition to products mentioned by others, Espressif parts are used in a few of the new LIFX devices.

Re: ESP32/ESP8266 Wi-Fi Attacks

#128

Post by jbarham » Wed, Sep 04, 2019, 4:21 AM UTC

wysifnwyg wrote: post #67

joezydeco wrote: post #40

Earlier quoted context omitted.

"avoiding patent infringement lawsuits via opacity"

Has there been any successful patent infringement lawsuits over the last three years that targets a Chinese company that has infringed upon a US company? Isn't that part of the issue in the current trade deal talks with China?

Several years ago Scottish chip company FTDI took matters into their own hands by releasing a driver that would brick counterfeits of their USB to serial converter chip: https://en.wikipedia.org/wiki/FTDI#Driver_controversy

Re: ESP32/ESP8266 Wi-Fi Attacks

#129

Post by stiray » Wed, Sep 04, 2019, 4:32 AM UTC

nabla9 wrote: post #68

squarefoot wrote: post #55

Earlier quoted context omitted.

Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary push for open drivers/firmware (Broadcom itself, just to name one, has had strong ties with the US govt for a long time). I can imagine a meeting in which some high rank officer says "Here's our backdoor blob, you merge this to all your chipsets firmware, so when necessary we can…

> Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary This is false. In most western countries governments cant force HW makers to add backdoor.

https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill... https://en.wikipedia.org/wiki/Dual_EC_DRBG

Re: ESP32/ESP8266 Wi-Fi Attacks

#130

Post by Matthias247 » Wed, Sep 04, 2019, 5:40 AM UTC

fra wrote: post #14

First and foremost, this speaks to the ubiquity and hacker friendliness of Espressif's chips. Most of their competitors (I'm looking at you, Broadcom), prefer security through obscurity and make it extremely difficult to get access to chips, let alone SDKs. I am certain that similar vulnerability exist in every embedded WiFi chipset out there. That being said, the status quo is completely untenable. Connectivity has…

> Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability.

Having worked for a while with the state of the art of microcontroller internet connectivity I can unfortunately second this. Some vendor SDKs are a mess of copied together source code (e.g. old versions of mbedtls and LWIP libraries), random modifications, no clear integration and often quite a few multithreading and memory issues right out of the box. And that's not even to mention that there are often exists exactly 0 unit-tests.

I really hope the state of this space improves in the future, e.g. through new higher quality stacks. Rust would be a great candidate for these things, since it prevents lots of the issues upfront by refusing to compile. But building better stacks takes a lot of time and effort, and someone would first need to start those invest this.