I think I'm missing a few major points. I wonder if someone here might be able to clarify.
1. The real meat of this "pwning" was (it seems) a google search to identify the WEB API endpoint. Then it turns out that sending POST requests to this endpoint can turn the light on/off, change its temperature, and change its brightness.
2. In order to turn a light on/off using the "found" api, it is first necessary to connect to the lamp's network. So if I were doing this on my own linux machine, which cannot as far as I can tell connect to multiple wireless networks at the same time, my script to change the settings on the light would include disconnecting from my true wifi network, connecting to the lamp's network, sending the signal to the lamp, disconnecting from the lamp, and then reconnecting to my own network. Is that right? Is this what the bash scripts and apps mentioned in the post are doing?
3. If I lived in the apartment above the OP's (say), and I were malicious, I could even now also access the lamps' networks and, say, set their values to be whatever I wanted. And there is simply no way of stopping this (S in IoT, after all).
One thing I haven't seen mention much with these "smart" devices is how inconvenient lack of physical buttons is. Instead of just reaching over and adjust the volume/brightness whatever, I now have to unlock the phone, find the app and do some gestures to achieve same results, all of which now requires some mental bandwidth for these banal tasks.
Pretty sure that title was coined by Steve Gibson on his Security Now! podcast[1] (at least that's where I've first/only heard it).
If you want to, you can turn it into a Home Assistant plugin (or even add it to the core). It's a great project that aims to provide this kind of interface for all kinds of "smart" devices in a user-friendly way.
The open KNX Standard seems to be the answer to IoT's woes. But nobody seems to have heard of it.
https://en.wikipedia.org/wiki/KNX_(standard)
This classic talk - Learn how to control every room at a luxury hotel remotely (2015) [has eng subtitles]:
This is a great article explaining the need for open standards and non-proprietary approaches to IoT just like we have in the digital world. Vendor lock-in is a real issue for security and non-dependancy as well.
> A brief search returned the web API URL path that returns a JSON structure
A brief search of what?
IKEAs zigbee devices are cheap, realiable and accessible and works great with Home Assistant + the deCONZ usb dongle. No WiFi connected devices, not internet access. When I'm out of the house I "phone home" with a VPN to adjust the temperature and turn off the lights if I forgot. I have automated several basic things, like the color temperature of the lights and the temperature of my heaters when electricity prices spikes.
Unfortunately this is not really accessible for regular consumers, only for nerds who know their way around a terminal and vi(m).
Another problem: Even when the device is working as it should, there needs to be a "lock" mode that says, "don't download new firmware." Nothing like having your smoothly-functioning lighting setup FUBARed by an unnecessary and buggy firmware update - especially if you're far away from home when it happens.
I imagine it's mentioned elsewhere in this commentary, but the key point I think this chap missed was not connecting to a wifi network under his control.
"A browser hitting that returned a page to connect the lamp to local WiFi. That is a no-go ..."
You can buy prosumer routers nowadays for $99 USD which enable one to setup different subnets and VLANS such that a device is accessible on the network but unable to access the internet.
I'm not afraid of IoT like some other tinfoil types commenting here - just make sure they can't call home (I'm looking at you Samsung TV)
Software needs to be updated though, certificates need to be checked and all that. That's only possible with Internet - unless you run your own CA, Package Mirror on the local network. That said, there is also a trade off between having a having ports open for REST vs. having a gateway (whether that's on the local network or on the Internet). Also it's probably a difference whether one plans to update the installed system every now and then or whether that should be fully automated...
This is why I just flash ESPHome firmware on all all the IoT stuff I buy to make them useful, trusted, and easily updated elements of my home.
I even run tuya-convert to switch over my dozens of light bulbs.
Anything that can't run open firmware I control doesn't get to live on my internal LAN.
Can you believe Generac standby generators need you to download an app and receive an activation code which no doubt you key into the generator before it will work. I nearly got caught out with this when we were looking to replace our cottage genny. We don't have internet access how stupid a concept is this. Thankfully I found out before completing the purchase so I bought a different brand but I'm with this guy all the way. I'm not connecting my lightbulbs, toaster or intelligent microflushing loo to anything internet just to use the product.
Chipset developers like Silicon Labs* are developing very advanced but approachable security capabilities into their latest products (secure boot, secure debug, physical protection (DPA countermeasure, anti-tamper), key management, key storage, crypto engine, etc.)*.
The tools are there now to address this, and this should go a long way toward actually securing the application, the data, the IP, and overall simplify lifecycle management.
* - disclaimer, I am an employee * - https://www.silabs.com/security
Shameless plug: We are working on the solution! Our motto is actually "Put the S into IoT" :D by working with security researchers on an automated tool which can scan and find vulnerabilities in all kinds of IoT firmwares. Check it out: https://www.iot-inspector.com/
Our old UI is "not very nice", but we already have a GraphQL API and pretty UI very soon.
If you are a security researcher or IoT shop, you should contact us!
AppleTV Airplay kind of fits this for me. Maybe it's secure, but, and MacOS Big Sur surfaced this for me. I click the screen sharing icon on my Mac and my 2 shares show up. I go to select the one I always select, asynchronously MacOS scans for more Airplay receivers. It finds my neighbors and adds them sorted alphabetically to the menu in real time. Result, 50-70% of the time I click the AirPlay device for another apartment since by sorting the list the positions change under my mouse. I've learned to click the screen share menu, then wait about 3 seconds for my neighbors' devices to appear, since the position of the device I want to click will move.
But, here's the thing. AFAIK a display pops up on my neighbor's TV showing a code I'm supposed to type into my Mac. Further, AFAIK, if the TV was off the device (usually an AppleTV) will turn on the TV on via HDMI. So, I've possibly interrupted my neighbors viewing. Or if it's late at night I just turned on their TV (no idea if it shuts it self off).
I know Apple has this feature to make it zero configuration but I'm not convinced it's the best feature. I've thought about figuring out how to send the same packets and building a small device/app that tries to connect to every Airplay device constantly. Then I could drive around the Apple campus and interrupt meetings.
Or, I could just put the app on my phone and walk around and hope that Apple will get enough complaints from users about "why does this code keep popping up on my TV" until Apple fixes the issue.
I think the issue is that the AppleTV uses Bluetooth as an extra communication channel to setup a session and you can turn it off but I suspect most users have not.
Is that a security issue that I can turn on my neighbors TVs and AppleTVs remotely?
Isn't this just a vailed SEO/Content filled blog post/Ad for puri.sm?
Ah yes. Elgato Key Lights.
Let's be thankful that they are, in fact, using ESP32 for a central control chip and use a very simple REST protocol. It could be a lot worse, a lot more proprietary.
These are simple devices, but expensive as far as lights go. You can very easily get dumb lights that have only physical controls. For a lot cheaper too.
IoT runs across a range of use cases and connections. There is a lot of emphasis on WiFi IoT applications, but this makes things hard in other places.
I'm working on various IoT sensor products that require a cellular connection - NB-IoT is preferred for this use case due to the good penetration characteristics. But the problem is that UDP is recommended as the NB-IoT transport layer due to the problem with TCP ack timeouts due to NB-IoT latency. That means that you are practically reduced to MQTT-SN as a data protocol, which in turn means you lose TLS.
There are partial solutions - we whitelist our MQTT data sources (i.e. only the Cellular provider's NB-IoT gateway), and we can verify and whitelist the IDs of all connected devices). But it is a partial and imperfect solution.
Security is hard...
Is there a curated list of IoT devices from a security perspective? Like is the firmware flashable with open code, how chatty is the device/callhome, update frequency (if any) etc?
Good point by the author, but iiuc neighbors can just walk up and control the lamp too if operating on the lamp's presumably open wifi?
Missing from the home IoT security works is a decentralized auth infrastructure story. I don't fully subscribe to the notion that people do this because they want to monetize... That may be the case sometimes but here I tend to believe you get to this kind of solution if you want something that is usable by average consumers and has some form of auth.
Just out of curiosity, if that web API request is made while connected to the lamp via its WiFi access point, I am guessing that means whenever they wanted to control the lamp using this custom app, they'd have to make their phone disconnect from the main WiFi, reconnect to lamp WiFi, do actions, then reconnect back to main WiFi (I suppose that could all be automated within the custom app) Wish the lamp would just put that control as a knob on the lamp..
Well, hacking such devices gets immediately easier when you can google the API endpoint, and that endpoint is REST (or REST-like).
I have a wifi radio (Ocean) and I tried several times to hack it so that I can programmatically start and configure it but failed every time because the whole system is completely closed and non standard.
I would love to buy a radio that has an API (actually I would buy three right away)
Usually the factory default WiFi network that IoT devices create during setup is open. No password required. It seems the author left the device in that state when he reverse-engineered the API. So anyone in the vicinity of the network can connect to his lamp and control it. I wouldn't call this "secure."
Good overview of how to hack a specific internet connected lamp to avoid installing the manufacturer's app.
Ok.. so he needs to scan for an unique AP first and then send the command to the device on this network. Is the phone capable being connected to multiple 2.4 networks or does controlling the light mean having to first scan and the connect to a network? This approach sounds slooow.
My way to deal with IoT devices: A virtual "guest" WiFi w/ AP isolation using DD-WRT. Devices in there can access the Internet. That's it. They can't see other devices in my local networks. That makes me sleep better.
>>The S in IoT is for Security<<
I cant help noticing, the s in IoT comes last, after all other things and is lower case, and not even important enough to appear in the acronym /s
I’d encourage anyone who enjoys these projects to check out Home Assistant. It’s an incredible open source project with support for countless devices.
This is just a Librem 5 / pureOS ad right?
One can't spell "idiot" without "i", "o", "t".
There doesn't have to be an S in it to be secured since the T is for Trustworthiness.
As in the S is missing! :-)
somehow ironic that he uses flatpak for his "secure" app, considering an article about flatpack security hit the HN frontpage a few days ago
The SH in SHIoT is for Security Hardened IoT.
The P is for Privacy.
> Full Lamp Stack
:D
and P in IOT is for privacy lol.
The S in IoT should be for "Stop buying stupid disposable junk." I can't listen to anyone complain about climate change while they fill their homes with cheap consumer electronics from globalized supply chains that spy on them.
I also can't imagine letting an internet connected anything in my home, and I keep all internet electronics in one room. Sure, other people can live in a surveillance zoo, but I prefer to keep mine limited.
If it has a circuit, stow it.
Poignant way show show how there is no security in IoT
Took me a moment to get the joke, pretty clever title.
The U in Smart (devices) stands for user-friendly.
We need an app to control a stupid lamp but at the same time are expected to buy a "smart home" system so that we don't have to pull the phone out of the pocket. Originally smartwatches were marketed for the same purpose, but I guess now there's also the severe risk of having both hands unavailable at the moment so we need to be able to delay the system update via voice command. Of course with tracking so they can "improve the user experience", and the occasional personalised ad.
Meanwhile I'm wondering how people got convinced this is better than just pressing a physical button, but then I remember even $500+ appliances nowadays are built with such cheap buttons that after a few years I'm forced to learn where to smack the fist on the front cover so they work again for a few minutes.
Many of these WiFi-LED lamps contain esp8266 devices, which have a lot of open source alternative firmware available, like esphome[0] or tasmota[1]. You can reflash them by opening them & connecting a cheap (1$) usb-to-tty adapter.
If that isn't an option (for reasons like not wanting to permanently damage them or being afraid of electrical shocks) a lot of them come with tuya firmware, which you can (still) often exploit and convert with TUYA-CONVERT [2].
I found the Tasmota Device Templates Repository[3] to be a really valuable resource, although I've been using zigbee devices for lightbulbs.
[0]https://esphome.io/
[1]https://github.com/arendst/Tasmota
[2]https://github.com/ct-Open-Source/tuya-convert
[3]https://templates.blakadder.com/index.html