2

UPDATE:

Looking at the product again, I don't think this even has built in Wi-Fi (it uses bluetooth for the connection).

I don't know what I am looking for here in Wireshark, but I added the host 192.168.40.59 and ran it for about 15 seconds and there was a constant packet that was captured, maybe a ping?

enter image description here

enter image description here


I was going through my connected client list trying to add some alias names to my devices to help keep track of what is connected to my network.

I noticed one device that I didn't have a name for, and had trouble trying to track down what it was.

Checked the MAC address to try and find the vendor and got some basic details, enough to recall what this was.

I have a "Smart Wifi Lightbulb" which comes with an app to change its colors etc.

When I ran NMAP on the IP, it said that service=IRC was running on port 6668. I know that there are only a limited number of ports so there are bound to be devices that share ports that might not be what they are actually for.

As a test, I pulled up an IRC client and put in the IP and the PORT and it connected. It stays open for about 30 seconds and then disconnects.

Anything I should be worried about here or further things I should check into?

Product: https://www.amazon.com/gp/product/B07CL2RMR7/

MAC: 68:57:2d:12:bf:d2  
Vendor: HANGZHOU AIXIANGJI TECHNOLOGY CO., LTD
Main Products: Smart LED Light Bulb, Smart Plug, Smart Switch, Smart Module

Mac-mini:~ $ sudo nmap -sS 192.168.40.59
Password:
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-21 10:01 MST
Nmap scan report for 192.168.40.59
Host is up (0.076s latency).
Not shown: 999 closed ports
PORT     STATE SERVICE
6668/tcp open  irc

Nmap done: 1 IP address (1 host up) scanned in 1.12 seconds][1]][1]

enter image description here

1
  • The worst would be an attacker in your network might change light colors.
    – yeah_well
    Jan 21 '20 at 17:24
1

Short answer: Nothing to worry about, mostly.

The bulb you have is really common, sold under multiple brand names, and the IoT implementation can be found in plugs and switches, as well.

The bulb you have has an ESP8266 inside. It's controllable via a library called ESP8266MOD, I think. But I've always seen it referred to as Tuya, and the tuyapi, or python-brihome provide implementations that work using the UDP interface the device provides.

I happened upon your question looking for information on the Cree Connected Max bulb, which is definitely the same bulb. These bulbs are equipped with both WiFi and Bluetooth. The Bluetooth, I think, can be used for control of the bulb in general, but with mine, it was only used as a convenient way to talk to the bulb for the purpose of configuring WiFi security.

As for the mostly part...

I haven't taken the Cree protocol apart like I did the Ankuoo, but I poked at it a little bit this weekend. The biggest concern I had on the Ankuoo device, I think (5 years ago) was that when you sent the command querying bulb state/info, there was a large part of that packet which appeared to be encrypted. And, I think, the packet actually contained my SSID. There's just no good reason for them to send that out, and since I was able to perform every function of the app, and read every value the app displayed (along with several others), I didn't trust that data.

The good news is if you're concerned about the security of the device, you don't necessarily have to toss it.

My solution was to treat it as untrusted: I isolated my bulbs; they cannot talk outside of the subnet they are on which is reserved for IoT; my Home Assistant server can reach it, but it can't be seen from the subnet. I also created a separate SSID for it, with its own shared key. I allow broadcast from the bulb and traffic to the bulb. This makes all of the cloud features fail, but I configured Home Assistant to manage the bulb and simply control it through UDP broadcast.

And frankly, the user experience ends up being better this way. When I issue a command to the bulb, the UDP broadcast is picked up instantly. There's no round-trip to a Chinese[0] Command/Control server.

If the small company behind the product goes out of business, the bulbs are still controllable -- as far as they know, the company is out of business.

[0] That sounds derogatory, but was simply meant as fact. With the cloud services enabled, my Cree and Ankuoo devices communicate exclusively with servers hosted in China, but I wouldn't care if they were hosted in the US

1

Nothing serious to worry about from the data provided. It might be how it talks to a control station or receives commands. I'd run a packet capture on it to investigate further. I'd also want to run some IRC commands.

It does appear that it's unencrypted. But the risks on an unencrypted line of commands to a light bulb might be very low.

Is it "face-palm-worthy"? Oh yes. Is it a major security issue? Not from the data you provided, but I'd still want to see that packet capture to know more.

There is a possibility that IRC functionality means that there is a Linux server in the bulb, which means that an attacker might be able to log in, install things, and keep connection to the network in your home. But these things would have to be confirmed.

This is a reason why it is recommended that you place IoT devices on their own network. It segments off weird stuff like this away from your user computer devices.

1
  • Thanks for the info. I do have my IoT devices on their own VLAN for reasons like this. I did some more research on the product, and it doesn't even look like it has WiFi built in, it uses bluetooth. This could be another device on the network perhaps. I updated the post with two wireshark screenshots from the packet capture.
    – SBB
    Jan 21 '20 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.