Hacker News new | comments | show | ask | jobs | submit login
I bought some awful light bulbs so you don't have to (mjg59.dreamwidth.org)
270 points by compsciphd on Feb 25, 2016 | hide | past | web | favorite | 84 comments



So, you could; buy lots of these. Take the bulbs and hub and modify the software further. Since they come in a 'box'; you can put them back in the box and then give them to people as gifts or promotional items.

You are now behind their firewall.

If you are a hacker and you manage to get into a factory in China or Taiwan or wherever that is making these; you swap out the base firmware with one of your own that dials home. You are now behind the firewall of all customers.

Just some random thoughts before bed.


Assuming the box is resealable you could just return it to the store in selling condition. Or little more unlikely you could by 10 from a different store, hax 'em, go to another store and put them back on the shelf


IoT is yet another reason firewalls are obsolescent as a security measure. A device is secure or it is not. There is no such thing as a safe network. Never really was, but now there really ain't.


Uh, pretty sure firewalls are exactly how we can fix this. Use your firewall to enforce each device can only talk to what it needs to and can't do any harm internally.

Without firewall: Here's direct access to everything on my network.

With firewall: Oh no, you can hack all my smart lightbulbs and change their colours.

This kind of thing is exactly you need firewalls for. Without a firewall this could pose a serious threat, with a firewall it's probably a good practical joke at best.


If your systems have a local firewall, services are jailed, OS is patched, etc. then direct access to it is not dangerous.

Somewhere we decided to accept crap system and device security as normal because oh we'll just firewall it. That was never a good idea but the more cloud connected things we deploy it becomes completely untenable.

Large corporate networks are already hostile territory due to BYOD. The only way to maintain the firewall as anything other than security theater is to lock everything down so much that nobody can get anything done.

The whole approach is braindead. We don't see how stupid it is because it's grandfathered in.


Haven't read TFA yet, but I think you're expecting too much from your firewall here. These bulbs are hosts, and they're inside the perimeter. They have been hacked, so they send malicious traffic to other inside hosts. What the hell is a firewall going to do about that?


I'm not talking about an edge firewall - I'm talking internally, firewalls are able to trivially stop traffic from reaching the hosts which they could attack. Now, depending on your network configuration this may need to be done partially by the switch (ie: separate VLAN for such devices) and edge firewall, by separate NATs or by firewalls on the hosts themselves.

EDIT: My simple solution (the one I had in mind) is to make a firewall box - a cheap linksys router with custom firmware can be set up to act as a switch but will also follow iptables rules. This serves the same sort of purpose as a hardware firewall in the middle of a corporate network but at lower performance. Bulbs connect to switch/WAP outside of firewall, hosts connect inside it. Everything behind it is then restricted from accessing the bulbs or viceversa.


Haha that's not what I thought of when reading a response to api's comment. If you want to call it a "firewall on the host" after 'api called it a "secure device", then perhaps the disagreement is merely one of terms. Either way, the host uses some method to ignore unwanted packets. I don't think this new "on the host" version of "firewall" is very much in keeping with etymology, which is probably why I was confused.


Well as I mentioned there it doesn't necessarily have to be on the host, that's just one option. At home I use the linksys based solution I mentioned in my edit which was more the way I was thinking - and probably more comparable to commercial firewall appliances like you might be thinking of but deployed internally and on a cheaper scale.


Just don't route packets from the bulbs to your other devices.


That's a good idea, but that logic has to be on the switch. Unless one has a very simple network, the firewall is somewhere else.


WiFi networks already have to have substantial smarts in the router. Adding firewall logic to that wouldn't take much. On simple networks it's typically the same device already.


VLANs can be used to achieve this goal with a non-trivial network too.


"All or nothing" is not how risk management works in the real world.

P.S. 'Network security' is just a specific case of risk management.


I agree that defense in depth is a good idea, but one key factor to consider is cost. Having a basic firewall makes sense, if for no reason other than “documenting” your public services in one place, but many places are either lulled into a sense of complacency or spend inordinate amounts of time managing tons of rules trying to segregate internal hosts, update for every new network app, etc.

It's that latter group which really needs to hear the truth that they should invest in endpoint security instead unless they have a high security threat and enough resources to do both.


I believe that at this point in time any network traversal should be considered an ultrahazardous activity. As most networks are beyond the control of the users and have little to no change control, it makes little sense to apply risk mitigation controls to them. When you consider the fact that users demand their information be available at all times, it makes much more sense, from a risk mitigation perspective, to focus on the elements you do have a semblance of control over -- the endpoints where the sensitive data is stored and processed and the protocols by which they communicate. There are well known and trusted means of securing data in transit. There is no excuse for relying on policy for mitigation where your policy can have no effect.


How about completely separated WiFi network for all IoT junk?


Good idea. A lot of high end routers have an option for a "guest network" these days. Or just invest in a cheapo access point just for IoT devices.


But... As soon as your bridge for the lights is on some sort of guest AP/network, your client on your phone can't reach it anymore, and thus has to be on that same network. And that will annoy you quick enought to not try to install the extra or guest AP at all...


Depends on the IoT device, some only have web interface that is controlled via manufacturers website, so as long as the actual device has internet connectivity you can do everything. Or maybe you can setup a "thorwaway" PC as a sort of proxy? Or maybe just one of the old (and sad) tablets/phones, depends on what you need/want to do and what kind of interfaces your IoT devices offer


Using a device that is controlled by an external "cloud" server is even worse - you've just given an untrusted 3rd party root access to a device on your lan.


Plus, devices like that are almost guaranteed to become garbage very rapidly when the vendor decides to stop operating that central command server, wherever it is. And unless you're paying a maintenance fee, they're going to cut that off pretty quickly once they stop selling new units of that particular model.

It's the biggest reason why I'm skeptical about all things IoT: too much "cloud" without an SLA or any guarantee of longevity on the service side.


Not if you keep IoT devices on a separate network


Does a 2000 mile data path to a light bulb seem dumb to anyone else?


Just as dumb as 2000 mile data path to a doorbell or security camera, but that still exists.

I personally haven't really thought about getting a IoT light bulb, but I would imagine you would program them to turn on when sun goes down, that shouldn't need direct connectivity and the bulbs can't tracks your phone moving aruond the house (or at least I doubt they can), so you either have to turn them on with your phone as you move along or just flip the switch or install actual movement sensors.

I'm probably completely missing the point of smart light bulbs, maybe you have actual use cases?


Depends on your paranoia level if you trust something like that, but most people have old wifi enabled routers just laying around


When you say firewall, do you mean a firewall on the edge of a home LAN? Because I still see a firewall on each individual networked machine as being extremely important.


You don't need a firewall on individual machines either; just don't run network-facing services in the first place.

At most, as a belt-and-braces security measure, you might want a system-wide prohibition preventing programs from listening on non-localhost (with exceptions for intentional servers, which should almost never happen on a client system). But that prohibition should primarily exist to catch programs misconfigured to listen on non-localhost, rather than leaving those programs running and just using a firewall to block them.


"with exceptions for intentional servers, which should almost never happen on a client system"

But these light bulbs _are_ servers. With IoT, everything becomes a server. Your home system will have to be able to query your couch and your smart watch whether someone still is there and awake, and control the tv, the lights, the curtains, your fridge/microwave/phone (to call emergency services, if needed) accordingly.


The current thought is that IoT devices should only be clients, mainly for security reasons. If your fridge needs to talk to your TV, both should be clients with a secure connection to a, often cloud based, server.

(In the wild, things are less well though through...)


This sounds wonderful for a) people who want to run said service and charge you money for something you don't need and b) people engaged in mass surveillance.


And for people who get paid to hack cloud-based servers so they can control the domestic appliances of entire countries.

Sounds comical, but turning up a few million fridge or aircon thermostats would cause serious load issues on most local and/or national power grids.


... or flush every toilet in New York at once. Barrels of fun.


So, will all of my light bulbs poll that server to see whether they need to execute a state change? Will my doorbell poll the server to check whether it has to ring? Will my fridge poll the server for spot electricity prices and the weather forecast so that it can decide whether to raj the freezer now or in 5 minutes? Will the fire alarm poll the server to check whether one of the heat and smoke detectors triggered?

Some of these will have to poll fairly frequently. For example, users expect lights to go on the moment they flip a switch, not 0.1 seconds later.

Possible? Yes, but taking duty cycle into account, that 5W lightbulb may use more power while switched off than while switched on.


This problem has been solved for a long time. You can use long polling, websockets, server sent events or some of the older hacks that preceded those mechanisms. Heck, you don't have to use HTTP, you can just use a long lived TCP connection.


Maybe if your fridge has a touchscreen that will work. But how on earth can the user configure a client light bulb? (More realistically, a client light fixture, but TFA seems focused on bulbs...) Don't tell me that the bulb will just connect to the bulb company's server, because then I have to choose between buying bulbs from only one company or having to deal with nine different light bulb servers. My choice will be bulbs from a different light bulb company.


For initial setup, there's tons of different methods, though I don't know about light bulbs specifically, but the different IoT devices I've set up have included:

* WiFi direct

* Setup over Bluetooth

* Device broadcasts for autoconfig, get settings from a gateway or local master node.

* Static configuration entered in the IoT gateway based on the physical port the device is plugged into.

* Dip switches

* Initial configuration needs to plug into a PC via USB or serial port and a custom windows program.

* Cryptic sequence entered via IRDA remote control.


Thanks, I can see these would be relevant for many different devices. Actually you've reminded me how many VoIP phones use DHCP for this, which would be great for any device that supported it.


> You don't need a firewall on individual machines either; just don't run network-facing services in the first place

I disagree. Firewalls fail closed under user error. The solution you proposed (we'll call it conscientious-wall) fails open under user error. That's to say, once a firewall is set up it will protect me from outside intruders unless I specifically tell it not to. A "conscientious-wall" will not protect me from outside intruders unless I specifically remember to apply it whenever I install an application or download a software update.

I'm still firmly in the camp of having at least an inbound firewall on every machine.


Sounds like we need a firewall in the switch/AP


These days it's just as important to monitor and filter outgoing traffic to detect trojans and unfriendly devices trying to phone home.


IoT isn't the issue, cellular and long-range wifi networking is the problem -- there is no network boundaty anymore.


It's just yet another nail in the firewall's coffin. I cringe now when I read security people still talking about them as a first or really any meaningful line of defense.


I think there's an important distinction between firewalls for client security and firewalls for server security.


Luckily, our devices have beefier security now. It`s much harder to spoof gmail or facebook or paypal these days.


Sounds like just giving these to someone without modifying them would achieve the same effect.


Brilliant. As always, stay safe and stay legal.


Well, that didn't go over well. I'll show myself out.


I wasn't proposing illegal activity. I was in an obscure way, pointing out how badly insecure devices are actually a double threat. They are a threat in their own right, but they are also a threat in that you can't assume they haven't been tampered with.

I didn't down vote your comment or anything; but I think the general idea is to add to the conversation. Short quips generally turn gray... the rest of the thread under mine is mostly discussions of security options/concerns in regards to firewalls and networks.


Didn't mean to imply you were - just a saying in the locksmithing community. If you look below, I have contributed a tad more than a short quip. No worries.


I didn't know it was a locksmithing term, that's actually interesting and I'll have to Google a bit. It also puts the comment into context; but I was probably not the only one to miss the whooshing sound.


No worries -- there are times I feel I reside under a flight path so I'm sorry I sent a jet your way. Regarding the saying, I've probably heard it more often in the locksport community, actually. That's probably what I meant to say instead of locksmithing.


I just started watching videos on opening locks, and I instantly caught the reference. It really reinforces the old hacker mentality, I think, where you're doing kiiiinda in the grey area, but just because it's interesting. Whitehat-ish, I guess.


I am shocked, shocked to learn that the iSuper iRainbow001 brand is being tarnished by a substandard product.


On the bright side, it hasn't burst into flames yet.


"Candle mode"


If you are after some cheap 'ok' wireless bulbs take a look at MiLight / LimitlessLED (they have various brand names). You can pick up bulbs for under $15 and the bridge for about the same from AliExpress.

They have the same issue as these in that white and RGB are seperate modes (so you can't control the saturation), but other than that they work fine and don't have any cloud "features".

The protocol of the bridge / app has been reverse engineered, and there are various libraries on GitHub:

https://github.com/mwittig/node-milight-promise


Beware: the bridge for Milight bulbs also communicates outbound to a mystery server for Internet control of the bulbs. The actual RF protocol has been documented and implemented as Arduino code, though, which is what I use for my installation.

https://github.com/henryk/openmili


I have one of these and this is why I blocked the wifi bridge from any outgoing network access. The mystery server then just uses the MAC address of the bridge as the "authentication" of where you get to control the lights via the app.

Having a separate wifi network (and separate VLAN for wired) IoT devices sounds like a good idea, and is something that I'll be doing this weekend...

(Also will port-scan the MiLight bridge to see if it's got any other interesting services on it)


Do you have any details of the outgoing network access, as I couldn't find anything?

You can also remove the wifi part, and communicate with the bridge via serial:

https://servernetworktech.com/2014/09/limitlessled-wifi-brid...


Last time I looked into the MiLight devices, it seemed like the protocol didn't support RGB but instead converted it into a more constrained space - is that accurate?


The JavaScript code linked suggests that it indeed uses 19 levels of brightness and 256 levels of (rotated) hue. [1]

[1] https://github.com/mwittig/node-milight-promise/blob/c52d3e4...


This is correct, if you want to use these for mood lighting you probably also want RGB+saturation as the effect will be much nice. For a cheap bulb that can be controlled programatically these are great though.


I'm surprised that this isn't up on the internet of shit twitter yet[1].

[1]: https://twitter.com/internetofshit


The future awaits, ladies and gentlemen: https://twitter.com/ow/status/701528914691227648


https://pbs.twimg.com/media/CbxU0EzWAAIA2Dq.jpg

Guy with the macbook looks really grumpy.


Oh dear.


"Everything is awful, which is why I just ordered four more random bulbs to play with over the weekend."


Heh, I read this in Matthew's voice, this article is written exactly as he talks.

Sadly, no surprises here about the internet of insecure things.


The biggest risks to my home network are my kid's friends. They bring their gaming laptops over and connect to the house network. No telling what is going on within my perimeter!

I used to run several internal networks, each with their own static external IP addresses, all mediated by pf on OpenBSD. There was a network for the kids, one for my wife and a couple for me. That was so much work and my wife always teased me that my machines always had better quality of service so I've gotten lazy and don't enforce security in the internal networks like I should--I'm even thinking about putting in a Ring doorbell.


The better question would be why would lightbulbs need wireless connectivity.


I've had some of the Hue bulbs for a year or so, and I definitely wouldn't go back.

I now see two distinct kinds of lighting: task and ambient. For task lighting, I still want fast manual control, for which dumb bulbs are fine. But for ambient lighting, I want it to be almost entirely automatic.

In the morning, my lights gradually come on, starting very dim and warm. In the middle of the day, they're bright and like daylight in color. In the evening, they slowly dim and shift toward red. They go out on their own about when I want to go to bed.

One good part is that I don't have to mess with lightswitches all the time. But the much more valuable part is that it helps me establish a strong diurnal body clock. I now wake up on time without an alarm, I get enough sleep, and my mood is more even.

One alternative would be to put the smarts in the switches, as early home automation had it. But my old wiring isn't compatible with that. And even if it were, that at best gets you brightness control, not color temperature control.

If anybody's curious, my code is here: https://github.com/wpietri/sunrise


Wow, I did something similar with the Hue bulbs, but I just used the rules api on the bridge combined with the virtual 'sunlight sensor' (and really long transition times) to trigger the light shifts. Similar setup to yours in effect though.


Ah, cool. I think they added the rules API later, otherwise I could well have done that. That's in some ways better; last year when my router died, my lights stuck on.

For what it's worth, I avoided tying the lights to actual daylight hours. In winter I tend to get a bit gloomy, and so part of my goal was to make my brain think that it was never really winter. It seemed to help this winter, although it's hard to say for sure.

How are you liking your setup?


Pretty good. My first pass at this did a very similar thing where I had a script running on a raspi to change the lights. Completely fair point about wanting to extend the lights during the winter. They switch to evening mode way too early lately and I kind of wish the rules api allowed you to do date based conditionals. That said, I have to do exactly 0 maintenance on it since I got the rules configured, so overall its pretty solid.


Fab. If you're interested in collaborating, drop me a note. I wrote my current software in Scala as an experiment, but I'm unlikely to do future work in Scala. I've been meaning to rewrite sunrise in something else, and I'm open to suggestion.


I was skeptical of this, but voice control of my lights has turned out to be incredibly useful. I can turn on the main lights while I'm taking my shoes off, before I'm in reach of the switches. I can dim lights from the sofa while watching TV. I can turn off individual lights. It's nothing earth-shattering in terms of importance, but it's something that does make my life better.


I can see the use, but what confuses me is why there's so much emphasis on putting the smarts in the bulbs. It would make a lot more sense to me to use normal bulbs and put the smarts in the switches. I'm sure there are switches out there like that, it's just not what people talk about.


There are modules like this: http://aeotec.com/z-wave-in-wall-switches/170-micro-smart-ap... that work with hubs like wink or smarthings, but home electrical wiring isn't consistent, so the installation isn't like the 1-2-3 easy setup you get from something like Hue.


Others have chimed in on the ease of bulb installation VS ease of switch installation. One other point is that the most you can get from a remote switch-only installation is variance in brightness, no RGB control.


It's a heck of a lot easier to swap out a bulb than a switch.


Eh, it's a little easier. With the switch, when the lighting bits die (less common with LEDs now, but it still happens) you don't have to toss all the expensive switch electronics.


Turning lights on and off over the internet is the blinkenlights of IoT - the very first level of adoption.


The manufacturer exhibited such disdain for the GPL. Amazing.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: