Internet of Things (IoT) is an ecosystem of connected physical objects that are accessible through the internet. The ‘things’ in IoT could be a person with a Wi-Fi enabled heart monitor or a car with inbuilt navigator and digital dashboard or even your smart house, i.e. objects that have been assigned an IP address and have the ability to collect and transfer data over a network without manual assistance or intervention.
The Internet of Things (IoT) is already one of the hottest technology trends currently. And in the near future the IoT ecosystem will explode with billions of devices going online. All of these devices are being developed to have some level of connectivity or the other – in a lot of the cases to the Internet! The progression in IoT is expected to offer services that goes beyond M2M (Machine-to-Machine) communications and is anticipated to herald automation in nearly all fields. Industrial product vendors and consumers are imagining connecting almost everything to the Internet.
One can say that one of the important core of the IoT is the Communication Network. This involves two wireless networking methods:
WLANs : A wireless LAN (or WLAN, for wireless local area network, sometimes referred to as LAWN, for local area wireless network) is one in which a mobile user can connect to a local area network (LAN) through a wireless (radio) connection. The IEEE 802.11 group of standards specify the technologies for wireless LANs.
WPANs : A WPAN (wireless personal area network) is a personal area network – a network for interconnecting devices centered around an individual person’s workspace – in which the connections are wireless.This communication network uses technology . The major protocols in IoT ecosystem are the wireless protocols used for this communication. Some of the major being 802.11 group, Bluetooth ( esp. BLE) , Zigbee .
In this post we will be dealing with the exploitation of the BLE enabled smart light bulbs. So before moving on towards the exploit, let’s get acquainted with a few things about BLE .
First of all BLE is an acronym of Bluetooth Low Energy. BLE is the power version of Bluetooth. It was built for the Internet of Things (IoT). It is a wireless technology standard for personal area networks and is targeted for very low power devices i.e, devices that can run on a coin cell battery for months or years. It was introduced as part of the Bluetooth 4.0 core specification. Even though there is some overlap with the classic Bluetooth, BLE actually has a completely different lineage and was started by Nokia as an in-house project called ‘Wibree’ before being adopted by the Bluetooth SIG.
One of the common ways to establish a Communication Network is the use of networking layers.
Physical Layer (PHY)
BLE PHY contains the analog communications circuitry responsible for translation of digital symbols over the air. It is the lowest layer of the protocol stack, and provides its services to the Link Layer.
It splits the 2.4 GHz ISM band into 40 channels.
- 37 channels are used for connection data, and
- The last three channels (37, 38, and 39) are used as advertising channels to set up connections and send broadcast data.
The Link Layer directly comes under the physical layer . It interfaces with it and it is usually implemented as a combination of custom hardware and software. It is responsible for scanning, advertising and creating/maintaining connections. It also takes care of the BDA (Bluetooth Device Address) . BDA is a 48-bit number which uniquely identifies a device among peers.
Host Controller Interface (HCI)
It is the pseudo-protocol referring to any standardized communication between the host stack (e.g., a PC or mobile phone OS) and the Bluetooth IC over a serial interface usually UART or USB. It must expose enough functionality to allow the host: to configure controller properties; to discover, add, & manage devices on piconet; to write directly to the baseband’s buffer for eSCO and SCO streaming; and to set up, manage, and release logical transports & links.
Logical Link Control and Adaptation Protocol (L2CAP)
L2CAP the part of the host stack. It is layered over the Baseband Protocol and resides in the data link layer. L2CAP provides connection-oriented and connection less data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstraction .It permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length.
The L2CAP layer is in charge for routing two main protocols: the Security Manager Protocol (SMP) and the Attribute Protocol (ATT) . The ATT forms the basis of data exchange in BLE applications, while the SMP provides a framework to generate and distribute security keys between peers. Let’s keep SMP aside for now, since it is not crucial to our exploit.
Attribute Protocol (ATT)
ATT is a wire application protocol. The sole building block of ATT protocol is the attribute. An attribute is composed by three elements:
- a 16-bit handle ;
- an UUID which defines the attribute type ;
- a value of a certain length .
Most of the ATT protocol is pure client-server, i.e client takes the initiative and the server answers to it. However ATT has notification and indication capabilities. What happens here is that the server takes the initiative of notifying a client that an attribute value has changed, saving the client from having to poll the attribute. The function ATT server is to store attributes. But an ATT client stores nothing. It uses the ATT wire protocol to read/write values on server attributes. If there is a pending request, no further requests can be sent until the response arrives. ATT itself does not define any UUID; this is left to GATT and higher-level profiles. The following set of operations are executed over ATT: Server Configuration, Error Handling, Find Information, Read Operations, Write Operations, Queued Writes, and Server Initiation.
Generic Access Profile (GAP)
GAP is an acronym for the Generic Access Profile, and it controls connections and advertising in Bluetooth. GAP defines how the Bluetooth device can make themselves visible to the outside world, and determines how two devices can (or can’t) communicate with each other.
There are two mechanisms, which are subjected to the Generic Access Profile (GAP) guidelines that a BLE device can use to communicate to the outside world:
Based on above two mechanisms a device can join a BLE network by adopting these roles specified in GAP: the role of a Broadcaster or Observer, and of a Central or Peripheral device.
Generic Attribute Profile (GATT)
GATT is an acronym for the Generic Attribute Profile. It comes on top of the ATT. It adds a data model and hierarchy. It also defines how data is organized and exchanged in between different applications and how two Bluetooth Low Energy devices transfer data back and forth using concepts called Services and Characteristics. It describes in detail how attributes (data) are transferred once devices have a dedicated connection, meaning that one has already gone through the advertising process governed by GAP.
The peripheral is known as the GATT Server, which holds the ATT lookup data and service and characteristic definitions, and the GATT Client (the phone /tablet which sends requests. All transactions are started by the master device, the GATT Client, which receives response from the slave device, the GATT Server.
Now coming towards the exploit ,our aim is to take over the control of a BLE based smart bulb and change it’s color along with venturing some security aspects of BLE. For that let’s assemble our arsenal. We would need:
- Laptop with Bluetooth services ON and with any Linux distro .
- An Android Phone (preferable Android 4.0 or up) with adb.
- hcitool software
- gatttool software
- A BLE enabled Smart Bulb
First we need to connect our Smart bulb to a power socket and the Bluetooth dongle of the bulb to a usb power source (5v). We need to make sure the device is properly working (You can also test it’s connectivity with a smart phone).
We will use hcitool to discover all the available BLE devices present near our host machine.
We find the BDA address of the Bluetooth device(s) around our host system. After going through we know that the required BDA of the bulb is 20:91:48:5D:68:60 . And the Bluetooth name of the bulb is Cnligh
We can use gatttool to view the services running inside the target device. Use gatttool -I to switch to an interactive mode and connect to the target device using the particular BDA.
Now checking the GAT services we get the following
In the above image, there are three primary service running among the three UUIDs. 00001800 and 00001801 is Bluetooth SIG defined service and the UUID 0000f371 is not one of the service defined by Bluetooth SIG.
Now we need to list all the handle in a particular UUID (0000f371). We will use char-desc command . It’s better to specify the attr and end group handles, which in this case is 0x0010 0xffff .
>char-desc 0x0010 0xffff
We get the complete list of handles, for the particular UUID 0xffff
Due to the presence of various handles and our tottering knowledge regarding to which handle we can write the data, let’s try reading the handle with their handle value.
While trying to read the handle we get an error message. This is so because we don’t know that, to which handle we can read/write data and we don’t even know the packet format.
Now to know the packet format and the handles, we need to capture the packets . Generally one can do that by using a Bluetooth Packet capture and sniff the packets.
Alternatively one can also try this out using an android phone ( Android 4.4 or up). In this exploit we have used an android phone in place of any Bluetooth packet capture dongle.
Sniffing GAT protocol communication require us to follow a certain procedure.
- First enable developer options in you Android device.
- Enable the Bluetooth HCI snoop log.
- Now connect your phone to the smart bulb and control it using your phone. This will generate packet logs.
- Now pull the btsnoop_hci.log file from your phone.
Now we have the packet capture file.
Now comes the part of analyzing the above attained log file. Extract it with wireshark.
The above picture shows the captured packets as can be seen in wireshark.
Now to get the UUID values we need to lookout for packets with ATT protocol .You can do that manually by scrolling or simply type the require condition in the wireshark filter. Now type:
btl2cap is acronym for Bluetooth Logical Link Control and Adaptation Protocol. And 0x004 is the channel id. Applying this filter gives up the following output with only ATT packets:
Now it’s time to get the values that we need to change the color of the bulb .For that we need to checkout for the write request packets(these are the same that were generated when color was changed using the connected smart phone).
We observe that data is written to the 0x0012 handle. So we need to find out the UUID to which this handle belongs and obtain thehe value for color chan.
So for handle 0x0012 we get the values ..
Now the Final Step of exploit. We will use gatttool to write the values to the required handle and achieve our desired control .
>char-write-req 0x0012 00660006000a03000100000059ff00000000
Similarly other values can be used to change other colors . Like :
00520006000a0300010000a400ff00000000 // Magneta
00630006000a0300010000ff007800000000 // Mexican pink
00660006000a03000100000059ff00000000 // deep sky blue
003f000600110300020200ff000000000200 // White
Now For a code say
00 66 00 06 00 0a 03 00 01 00 00 00 59 ff 00 00 00 00 , the bytes highlighted in red represent the OFF/ON . Simply replacing the 00 with 01 will turn OFF the bulb .
The part highlighted in chromium represents the color value. Remember to make it zero while turning off the bulb