[personal profile] mjg59
I maintain an application for bridging various non-Hue lighting systems to something that looks enough like a Hue that an Amazon Echo will still control them. One thing I hadn't really worked on was colour support, so I picked up some cheap bulbs and a bridge. The kit is badged as an iSuper iRainbow001, and it's terrible.

Things seemed promising enough at first, although the bulbs were alarmingly heavy (there's a significant chunk of heatsink built into them, which seems to get a lot warmer than I'd expect from something that claims a 7W power consumption). The app was a bit clunky, but eh - I wasn't planning on using it for long. I pressed the button on the bridge, launched the app and could control the bulbs. The first thing I noticed was that they had a separate "white" and "colour" mode. White mode was pretty bright, but colour mode massively less so - presumably the white LEDs are entirely independent of the RGB ones, and much higher intensity. Still, potentially useful as mood lighting.

Anyway. Next step was to start playing with the protocol, which meant finding the device on my network. I checked anything that had picked up a DHCP lease recently and nmapped them. The OS detection reported Linux, which wasn't hugely surprising - there was no GPL notice or source code included with the box, but I'm way past the point of shock at that. It also reported that there was a telnet daemon running. I connected and got a login prompt. And then I typed admin as the username and admin as the password and got a root prompt. So, there's that. The copy of Busybox included even came with tftp, so it was easy to get copies of tcpdump and strace on there to see what was up.

So. Next step. Protocol sniffing. I wanted to know how discovery worked, so reset the device to factory and watched what happens. The app on my phone sent out a discovery packet on UDP port 18602 which looked like this:


The CLIP and CLPT fields refer to the cloud server that allows for management when you're not on the local network. The mac field contains an utterly fake address. If you send out a discovery packet and your mac hasn't been registered with the device, you get a denial back. If your mac has been (and by "mac" here I mean "utterly fake mac that's the same for all devices"), you get back a response including the device serial number and IP address. And if you just leave out the mac field entirely, you get back a response no matter whether your address is registered or not. So, that's a start. Once you've registered one copy of the app with the device, anything can communicate with it by just using the same fake mac in the discovery packets.

Onwards. The command format turns out to be simple. They start ##, are followed by two ascii digits encoding a command, four ascii digits containing a bulb id, two ascii digits containing the number of following bytes and then the command data (in ascii). An example is:


which decodes as command 5 (set white intensity) on bulb 1 with two bytes of data following, each of which is an f. This translates as "Set bulb 1 to full white intensity". I worked out the rest pretty quickly - command 03 sets the RGB colour of the bulb, 0A asks the bridge to search for new bulbs, 0B tells you which bulbs are available and their capabilities and 0E gives you the MAC addresses of the bulbs(‽). 0C crashes the server process, and 06 spews a bunch of garbage back at you and potentially crashes the bulb in a hilarious way that involves it flickering at about 15Hz. It turns out that 06 is actually the "Rename bulb" command, and if you send it less data than it's expecting something goes hilariously wrong in string parsing and everything is awful.

Ok. Easy enough, but not hugely exciting. What about the remote protocol? This turns out to involve sending a login packet and then a wrapped command packet. The login has some length data, a header of "MQIsdp", a long bunch of ascii-encoded hex, a username and a password.

The username is w13733 and the password is gbigbi01. These are hardcoded in the app. The ascii-encoded hex can be replaced with 0s and the login succeeds anyway.

Ok. What about the wrapping on the command? The login never indicated which device we wanted to talk to, so presumably there's some sort of protection going on here oh wait. The command packet is a length, the serial number of the bridge and then a normal command packet. As long as you know the serial number of the device (which it tells you in response to a discovery packet, even if you're unauthenticated), you can use the cloud service to send arbitrary commands to the device (including the one that crashes the service). One of which involves the device then doing some kind of string parsing that doesn't appear to work that well. What could possibly go wrong?

Ok, so that seemed to be the entirety of the network protocol. Anything else to do? Some poking around on the bridge revealed (a) that it had an active wireless device and (b) a running DHCP server. They wouldn't, would they?

Yes. Yes, they would.

The devices all have a hardcoded SSID of "iRainbow", although they don't broadcast it. There's no security - anybody can associate. It'll then hand out an IP address. It's running telnetd on that interface as well. You can bounce through there to the owner's internal network.

So, in summary: it's a device that infringes my copyright, gives you root access in response to trivial credentials, has access control that depends entirely on nobody ever looking at the packets, is sufficiently poorly implemented that you can crash both it and the bulbs, has a cloud access protocol that has no security whatsoever and also acts as an easy mechanism for people to circumvent your network security. This may be the single worst device I've ever bought.

I called the manufacturer and they insisted that the device was designed in 2012, was no longer manufactured or supported, that they had no source code to give me and there would be no security fixes. The vendor wants me to pay for shipping back to them and reserves the right to deduct the cost of the original "free" shipping from the refund. Everything is awful, which is why I just ordered four more random bulbs to play with over the weekend.

What about these?

Date: 2016-02-25 02:07 am (UTC)
From: (Anonymous)
I know they're bluetooth, but could a bridge make them work as hues ?


Re: What about these?

Date: 2016-02-27 10:26 am (UTC)
From: (Anonymous)
I recently created a library for some BLE lamps that might interest you: https://github.com/mcuelenaere/bluelight
It's written in Node.js as I couldn't find a decent Python library at the time.

Re: What about these?

Date: 2016-06-22 02:34 pm (UTC)
From: (Anonymous)
I also created a library for a BLE Smart Bulb with Elixir:

Date: 2016-02-25 03:19 am (UTC)
brainwane: several colorful scribbles in the vague shape of a jellyfish (jellyfish)
From: [personal profile] brainwane
Wow! That's terrible!

Date: 2016-02-25 05:10 am (UTC)
morineko: Hikaru Amano from Nadesico (Default)
From: [personal profile] morineko
I'm an interior design student and there is a lot of buzz (not the kind the lamps tend to give off) about the Internet of Things among interior designers these days. I'm semi-enthusiastic but this is the sort of thing that puts the "semi" in that statement. The ideas are intriguing, the implementation frequently infuriating.

National Standards bodies?

Date: 2016-02-25 09:14 am (UTC)
From: [identity profile] phil [hands.com]
Have you considered contacting the likes of the BSI to see if it might be possible to make the not doing this sort of nonsense a condition of getting a kite mark? (in the hope that that might eventually turn into being declared unfit for sale and/or illegal to import)

Shipments of mains adaptors exhibiting a similar ignorance of best practice would presumably be seized by customs and destroyed.

If we could establish a how-not-to checklist that could be used to provoke a similar response then (and probably only then) things might get better.

These are after all controlling mains power, and that could perhaps be spun as putting the safety of people's homes at risk, in addition to all the rather harder to explain risks you've already highlighted.

Re: National Standards bodies?

Date: 2016-02-26 01:49 pm (UTC)
From: (Anonymous)
There's an organization of IT-security enthusiasts who join up to influence legislators and industry. They started out not long ago, and are already having some impact (after seeing car hacks, I guess companies realize they need to pay attention.) The organization is https://www.iamthecavalry.org/

Re: National Standards bodies?

Date: 2016-02-27 12:46 pm (UTC)
From: (Anonymous)
> Shipments of mains adaptors exhibiting a similar ignorance of best practice would presumably be seized by customs and destroyed.

What makes you think they'd be detected. Customs does not have the expertise, or the time, to check every box of electronics for this sort of stupidity. And the prevalence of substitute, poorly secured, generic devices relabeled as better quality, previously approved devices is a problem ranging from high quality network security devices such as firewalls to children's toys. Forgeries *will* get through.

Re: National Standards bodies?

Date: 2016-02-28 10:15 pm (UTC)
From: [personal profile] vatvslpr
>Customs does not have the expertise, or the time, to check every box of electronics for this sort of stupidity.

Customs may not, but standards bodies ought to. Most electrical products- including even cheap things like light bulbs- are already supposed to be listed by a recognized testing lab before they're sold. That testing often extends to testing products purchased at retail to make sure the products continue to meet standards. As I read it, the parent is suggesting that those testing standards be extended to computer security for computerized products. It seems like a reasonable suggestion.

Date: 2016-02-25 05:46 pm (UTC)
damerell: (computers)
From: [personal profile] damerell
I am hoping the Internet of Incompatible Things mitigates the bad effects of the Internet of Insecure Things.

Sadly, I ain't even joking.

Date: 2016-02-25 06:50 am (UTC)
From: (Anonymous)
Most of this seems like the kind of slapped-together system that people regularly put on a private network. But exposing the end-user's private network is completely ridiculous; how could *anyone* think that was a good idea?

Date: 2016-02-25 07:06 am (UTC)
shortcipher: (Default)
From: [personal profile] shortcipher
Wow, this is all rubbish. It may have been a tiny amount less rubbish before Google rightly prevented access to device MACs in Marshmallow (by always returning 02:00:00:00:00:00). I expected that people were mostly abusing it as an advertising ID, not in an attempt at authentication!

Also, the combination of my RSS reader notifying me about this comic (NSFW) at the same time, and Android collapsing newlines in notifications, meant that I initially saw the title of this post as "Peak mjg59: I bought some awful light bulbs so you don't have to". :-)

Date: 2016-02-25 12:37 pm (UTC)
From: [personal profile] rohaq
Regardless, a MAC address shouldn't be used as any kind of authentication key. They're publicly broadcast, and easily changeable. Even if the control traffic wasn't sniffable, this would still be a terrible implementation.

I treat my home network as part of the Internet

Date: 2016-02-25 07:26 am (UTC)
From: [identity profile] m50d.wordpress.com
I mean, it's not like I trust my ISP's router to be secure. So if I need to run an unsecured service then I use my VPN. Devices like this, or visiting friends' computers, are outside the trust boundary, and as a bonus accessing my home server while travelling is exactly the same as doing so from home.

Not that making it easy for attackers to control my lights would be a good thing, but at least with this setup they wouldn't help attack my more important machines.
dsrtao: dsr as a LEGO minifig (Default)
From: [personal profile] dsrtao
Err, no. The presence of "crash while flickering" suggests that "crash while bursting into flame" is a plausible failure mode. Coming back home to discover that the building has burnt down is not an acceptable trade-off in my life. Your mileage may vary, of course.
ext_267968: bjh (Default)
From: [identity profile] bjh21.me.uk
<bjh21 silently curses behaviour of Return key on Dreamwidth comment page>
ext_267968: bjh (Default)
From: [identity profile] bjh21.me.uk
One might hope that the bulb would be engineered such that it can't be made to burst into flames from software. On the other hand, if their electrical engineering is as good as their software engineering...
emperor: (Default)
From: [personal profile] emperor
Come on, the "halt and catch fire" instruction is a fine and honourable tradition.

Date: 2016-02-25 09:38 am (UTC)
From: (Anonymous)
MQIsdp in the header, maybe it's using MQTT v3 as the network protocol, if so the command packet is probably using the device serial as the topic name of an MQTT publish.

Leave a review on the amazon page

Date: 2016-02-25 10:02 am (UTC)
From: (Anonymous)
At time of writing, they still have a rating of 3.3/5 stars at amazon. Why not leave a review there? You could link this page or just paste the whole lot. The manufacturer will still sell them if the amazon reviews don't highlight the problems.

Re: Leave a review on the amazon page

Date: 2016-02-25 10:53 am (UTC)
From: (Anonymous)
Isn't that an extra reason to leave a bad review?

Re: Leave a review on the amazon page

Date: 2016-02-25 09:26 pm (UTC)
From: (Anonymous)
You may want to contact amazon about the refund. Amazon is not a fan of dodgy products and poor customer service.


Date: 2016-02-25 12:19 pm (UTC)
From: (Anonymous)
I do hope you get a full refund. This is beyond ridiculous. Thank you for testing these bulbs out Matthew!

Homebrew lights

Date: 2016-02-25 12:47 pm (UTC)
From: (Anonymous)
I came across a post a few days back, about a diy version.

It's open source so security can be checked.
It's the same story with open source software and security.
So open source hardware is probably the way to go to fix this problem.

Re: Homebrew lights

Date: 2016-02-25 01:09 pm (UTC)
From: (Anonymous)
Unfortunately it's not a Hue clone as it doesn't behave as a Hue.

Christophe then did the silly mistake of not reprogramming that cheap controller that he found (it has an ESP8266 inside) that is widely documented on the web eg http://hackaday.com/2015/08/25/esp8266-in-commercial-products/


Date: 2016-02-25 05:00 pm (UTC)
From: (Anonymous)
Anyone working on stuff like this and likes Python may want to use/help out with Pytomation. www.pytomation.com

I've had it controlling my lights for a few years. Hue, Arduino, Insteon,X10 and others are supported.


Re: Pytomation

Date: 2016-02-26 02:16 am (UTC)
From: (Anonymous)
pyromation - halt and catch fire feature...


vint cerf

Date: 2016-02-25 07:34 pm (UTC)
From: (Anonymous)
I made a t-shirt design about this: http://www.customink.com/designs/iotsucks/pqs0-00af-mtwd/share/

IoT trap, core dumped.

Date: 2016-02-26 10:24 am (UTC)
From: (Anonymous)
More like the Internet of zings.

This is fantastic

Date: 2016-03-03 07:34 am (UTC)
ext_1788459: A cuddly master of free software, plus me. (Default)
From: [identity profile] teaparty.net
Mood lighting that is pretty much guaranteed to put you in a bad mood; therefore, it only has to implement unhappy colours, probably black, thus making it quicker-to-market. Genius!

Date: 2016-03-04 08:01 pm (UTC)
From: [identity profile] dlazerka.livejournal.com
For legal reasons, the fact that it was designed in 2012 and is no longer manufactured doesn't seem to matter. What matters is where it's being sold.

"Legal reasons"?

Date: 2016-03-13 07:38 am (UTC)
From: (Anonymous)
Not sure what you mean by "legal reasons".

And for human reasons, what matters is that it's still used. -- @pcarrier

They still sell it

Date: 2018-07-23 01:30 pm (UTC)
From: (Anonymous)
I hit this post today, in July 2018, and lo and behold - the Amazon offer is still active, with a review which contains the findings from this article being the top review.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags