Home » Cybersecurity » IoT & ICS Security » Smart Bulb Offers Light, Color, Music, and… Data Exfiltration?

Smart Bulb Offers Light, Color, Music, and… Data Exfiltration?

by David Sopas on November 21, 2018

Smart bulbs are widely known as a successful offering in home automation and IoT products, as they are internet-capable light bulbs that allow home users to customize the colors, schedule on and off times, and control them remotely. Some even play music and could improve your sleep. Any device that can wireless connect with phone applications must be rigorously tested for potential safety and privacy implications, so our security research team investigated the smart bulb market.

Understanding the Smart Bulb

In our research laboratory, we tested different bulbs to see different perspectives. In the end, we tested with one of the most popular smart bulbs in the market – Magic Blue. The price for this bulb and similar ones are around 5€ to 10€, depending on the seller.

Device characteristics:

Works On >= Android 4.3 or > iOS 7.0
Power: 4.5W
Lúmens: 350Lm
Color Temperature: 2800K – 3200K
Bluetooth Version: 4.0
Registered Manufacturer: IEEE Registration Authority

Besides identifying some common components on these type of devices, looking at the “insides” of this bulb shows us that it’s possible there is a universal asynchronous receiver-transmitter (UART). However, after connecting to it, it didn’t output anything. From what we saw, these bulbs have the following first three bytes on their Bluetooth address (bd_addr),which usually represents the manufacturer:
F8:1D:78

After a few Google searches, we found that a Chinese company called Zengge makes these bulbs. They have the following information on their site:

Zengge works as partners supplying famous brand like Philips and Osram etc. [sic]

Other bulbs have similar characteristics, and the Android application supplied even works on different bulbs.

As a side note, some Bluetooth Low Energy (Bluetooth LE, often referred to as BLE, formerly marketed as Bluetooth Smart) bulbs on the market are sold as Bluetooth Smart, but in reality, they’re Bluetooth Smart Ready and the technology used to communicate with the mobile application is the radio frequency communication (RFCOMM) protocol on the host Bluetooth stack and not the Low Energy Attribute Protocol (ATT). We focused our research on bulbs that used ATT to communicate.

The pairing method for our target is Just Works, which allowed us to sniff the communication.

Sniffing Communication Between the Bulb and the Mobile Application

This process involved the following hardware:

3 Ubertooth (aka uberteeth)
Smart Bulb
Mobile Phone
Laptop

We paired the mobile phone with the iLight app with the smart bulb and started changing colors. At the same time, we connected three ubertooth dongles (to cover all advertisement channels – 37, 38 and 39) to our Linux machine and used the following command:

ubertooth-btle -U 0 -A 37 -f -c bulb_37.pcap ubertooth-btle -U 1 -A 38 -f -c bulb_38.pcap ubertooth-btle -U 2 -A 39 -f -c bulb_39.pcap

After a while, we get traffic that we can analyze using Wireshark.

Packet 1061 that we captured with bulb_37.pcap has a write command from the phone to the bulb with the value:

5639ddff00f0aa

At this point, we can store this value for later, like the handle – 0x000b. Just by looking at it you can find some possible HEX color codes, like the ones already disclosed in the wild. Using the BLEAH tool, we can also confirm that this handle provides the Write permission:

By the way, we could also use the HCI dump log from Android, but we wanted to keep things as real as possible.

We used the adb tool to download the Android application and used jadx to analyze it. Our objective was to make sure that the changing color commands are the same as what we found by sniffing the application. Connecting the phone with our laptop and using:

adb shell pm path com.Zengge.BluetoothLightDark

Returns the path of the package:

package:/data/app/com.Zengge.BluetoothLightDark-1/base.apk

Now we can download it to our desktop:

private BluetoothGattCharacteristic getSendCharacteristic() {
    	if (this.f4737f != null) {
        	return this.f4737f;
    	}
    	if (this.f4736e == null) {
        	return null;
    	}
    	for (BluetoothGattCharacteristic bluetoothGattCharacteristic : this.f4736e.getCharacteristics()) {
        	if (Long.toHexString(bluetoothGattCharacteristic.getUuid().getMostSignificantBits()).substring(0, 4).equalsIgnoreCase("FFE9")) {
            	this.f4737f = bluetoothGattCharacteristic;
            	return bluetoothGattCharacteristic;
        	}
    	}
    	return null;
  }

FFE9 is, in fact, the only writable characteristic.

public void sendData(byte[] bArr, int i) {
  	BluetoothGattCharacteristic sendCharacteristic = getSendCharacteristic();
  	if (sendCharacteristic != null) {
      	sendCharacteristic.setWriteType(i);
      	sendCharacteristic.setValue(bArr);
      	this.f4734c.writeCharacteristic(sendCharacteristic);
      	"---sendData:" + C1425a.m7435a(bArr) + "   by:" + sendCharacteristic.getUuid();
  	}
}

To be sure we’re catching the real function, let’s search for “sendData” using logcat:

adb logcat | grep sendData

10-25 10:04:42.748 21822 21822 V SMB     : sendData:56ff0d0700f0aa

We clicked on the mobile app for a “reddish” color, so let’s try to extract this hex value sent to the bulb.

56ff0d0700f0aa

56 is definitely a command byte because other options, such as music, use a different byte.

FF0D07

If we go to the mobile app, it shows the exact corresponding RGB pick – 255, 13, 7.

Now we already know the color position on the sent value. The other bytes are related to color temperature (warm) values:

0%
10-25 10:15:37.060 21822 21822 V SMB     : sendData:56000000ff0faa

50%
10-25 10:26:46.351 27546 27546 V SMB     : sendData:560000007f0faa

100%
10-25 10:22:02.072 26557 26557 V SMB     : sendData:56000000020faa

For the sake of this research, we don’t need anything else. We can now play with color and warm levels, which for us is the only thing needed to exfiltrate data.

Exfiltration Plan

The main plan for exfiltration was to use light as a channel to transfer information from a compromised device to the attacker. Light can achieve longer distances, which was our goal. Imagine the following attack scenario: a BLE device (smartphone) gets compromised with malware. The malware steals the user’s credentials. The stolen information is sent to an attacker using a BLE light bulb nearby.

The attacker receives the exfiltrated data using a smartphone, which could be connected to a telescope for wider range, without the victim noticing that any type of exfiltration took place.

With typical eyes, green is the center of the visible range and can be detected at lower levels than other colors. The reason for this is that two types of cones respond it—green and half of the red ones. We based that information on the following spectrum:

Eye Color Sensitivity — Image source: https://en.wikipedia.org/wiki/Color_vision#/media/File:Eyesensitivity.svg

For that reason, we chose to use the blue channel to create a stealthy air gap exfiltration.

Creating the Apps

We created two apps, the first app for sending the exfiltrated data and a second one for receiving it. The app that transmits the information changes the blue light intensity – weaker for binary 1 and stronger for binary 0. The app has two options: Normal mode and Stealth mode. The first one may be visible to human-eye and the stealth mode is very hard to detect because of the variations of shades of blue used.

The transmission is quite simple; for each byte there is a preamble and trailer.

The receiver app uses the smartphone camera to detect and process the data (low frames per second, or FPS). The receiver doesn’t even need to have BLE, just a camera.

We have a few videos to demonstrate the proofs of concept; Pedro Umbelino presented one at hack.lu.

Pedro Umbelino created another video to demonstrate the light bulb hack:

Normal Mode

This mode on the smart bulb exfiltration app is visible to the human eye, but at the same time allows the attacker to reach higher distances using, for example, a telescope connected to the smartphone.

App scans for the vulnerable bulbs
Detects it and starting sending the payload
Starts the loop of exfiltration data

Stealth Mode

This mode uses the shades of blue that prevent the human eye from easily noticing it. This stealthy mode makes the air gap exfiltration very hard to detect.

App scans for the vulnerable bulbs
Detects it and starting sending the payload
Starts the loop of exfiltration data

The focus here is that the receiver reads and waits for the RGB modification and decodes the exfiltrated data.

Final Thoughts

An important note to mention. These methods will work on every smart bulb that allows control by an attacker. In the future, we would like to create a better proof of concept that allows us to test a database of vulnerable bulbs and even implement AI to learn and implement new bulbs along the way.

David Sopas

David Sopas is an AppSec Research team leader at Checkmarx and co-founder of Char49. Google, Yahoo!, eBay, Microsoft, US Dept. of Defense and many other companies and organizations have acknowledged his work. As a former part-time bounty-hunter, he’s still top5 on Cobalt and top100 on HackerOne. These days, David enjoys breaking IoT devices and hacking his life as much as possible.