Smart Lightbulb Using Common IRC port found in NMAP - anything to worry about?

Question

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?

---

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]

Answer 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

Answer 2

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.

Answer 3

Having irc open ports, services, and protocol in IoT device in a local network is worrisome. That is particularly true if that IoT device is at least in part controlled by an app that report and receive instruction from a server far away. IRC is the quintessential protocol used by bot herders to control individual bots in a botnet, using them for nefarious purposes.

After scanning, testing and doing the inventory of my LAN, I found two IoT devices that had the same issue:

PORT STATE SERVICE

6668/tcp open irc

Normally, IRC servers use port 6667 though; which makes it even more suspicious. The aforementioned devices in my LAN are: 1) Doorbell with Camera; 2) Front door lock gateway (used to control front door lock remotely)