[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:

INLAN:CLIP:23.21.212.48:CLPT:22345:MAC:02:00:00:00:00:00

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:

##05010002ff

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 ?

http://www.amazon.com/gp/product/B00GZQBQHE?psc=1&redirect=true&ref_=oh_aui_search_detailpage

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.

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". :-)

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.

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.

Ridiculous

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.
https://medium.com/@christophe.smet1/flux-irl-building-a-hue-clone-bd62df85a456

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.

Pytomation

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.

Cheers
George

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.

Profile

Matthew Garrett

About Matthew

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

Expand Cut Tags

No cut tags