r/ReverseEngineering • u/nickfromstatefarm • 1d ago

No-open exploit for code execution on the Wyze WLPA19CV2 LED bulb

https://github.com/nickdaria/wyze-bulb-color-pwned
7 Upvotes

89% Upvoted

8 comments sorted by

1

u/tron21net 1d ago

Start with your bulb fresh out of the box OR factory reset. It should be pulsing green when powered on.

Congrats you figured out how to use the failsafe firmware update procedure that is only available when the device isn't yet configured, of which is very common in Bluetooth and WiFi devices, and didn't exploit anything.

1

u/nickfromstatefarm 1d ago edited 1d ago

When the factory reset procedure is literally flipping the light switches an additional 3 times, I think it’s fine ;)

And perhaps it’s not an overflow exploit or anything interesting, but it does take advantage of hardcoded credentials that were certainly not meant for public use.

This could have been securely implemented with signature checking, secure boot, or 20 other things under the sun that you would expect from a consumer product…

1

u/i_like_brutalism 12h ago

its not nothing, but its not what you present it as.

its certainly not pwned, but its neat.

1

u/nickfromstatefarm 11h ago edited 10h ago

It does require physical power control, but at the end of the day it is wireless code execution and flash write capability. My career is in the world of embedded reverse engineering and compromising a device (code execution/flash write) has always been the literal definition of pwned for embedded. Especially when board access/side channel attacks are not necessary.

From a security standpoint, this could easily be made nefarious. You could easily swap out the payload with a patched Wyze firmware that connects to your own server and grants you internal network access. You can also pull the WiFi creds out of NVRAM.

As far as I can tell, the only other reasonable entry points have to be approached from the home network side which is much less desirable as the bulbs have to be set up with the crappy app first. I didn’t want to do that.

And yes it’s what I present it as. If they had bothered to enable firmware signing as recommended by espressif (and should be the bare minimum for consumer products) then this wouldn’t be an issue.

1

u/i_like_brutalism 10h ago

you cant take the wifi creds out of nvram if it hasnt been setup.

sure, resetting after setting it up makes the device vulnerable.

it all depends on the threat model and if its reasonable.

id say this is not a reasonable threat model, but you might still get a cve for this :)

2

u/nickfromstatefarm 9h ago edited 7h ago

I agree it’s not a big deal, and I certainly don’t care enough for a CVE - but to be pedantic I do think there is a real threat vector.

  1. Bad actor knows a target has a lamp with a Wyze bulb.

  2. Bad actor waits until target leaves the house, and then approaches

    the

  3. outside electrical breaker with a battery powered ESP32 serving a patched Wyze payload (perhaps reaching out to a command server)

  4. Bad actor does the power cycling to your outdoor master breaker to deliver the attack

  5. Target returns and eventually realizes the lamp has stopped responding and sets it back up (pretty typical with the crappy firmware)

  6. Bad actor now has whatever access they want + WiFi creds.

Not saying it’s likely or worth it, but I am saying it could happen to me and I wouldn’t even realize it.

PS: I believe the wifi details persist in NVRAM on factory reset, they do not do a full clear. I’ll check tonight.