Ciberseguridad en IoT: Analizando ZigBee y Thread

Today we are going to talk a little bit about Zigbee and Trade. For those who have not had the opportunity to analyze these networks or do not know them yet, we are going to talk a little bit about how they work, how we can sniff them, what tools we can use and practical cases or analysis that have been carried out. with these technologies. Something very interesting about these technologies is that Zigbee has been in the market for a few years, but it has just started to rebound again. E-Trade is relatively new, something that characterizes it is that it is also open source, so we will have the opportunity to work with it. We are going to see three important points:

Zigbee, Trade, and what tools we can use. For those who don't know me, my name is Kevin Hasiel. I'm a firmware developer at Electronic Arts. - So, I would appreciate it if you could give me some, because I don't know many cafes here in Mexico City. So, if anyone has a good one, seriously, please tell me. And, well, the first part, Zigbee. Zigbee is developed by the Zigbee Alliance. It is based on the IEEE 8.2.15.4 standard. It is important to know the standard because this will help us know in which radio frequency we should operate and if we are operating at the correct frequency when we are performing our sniffs. It is characterized by its low consumption. Zigbee, like Bluetooth, has low-consumption devices that allow us to

put them in sleep mode, to just send packages every once in a while, when they are activated, and to be able to save energy. A little later we will see the profiles of Zigbee, where we will understand a little more about this low-consumption part. Another of its characteristics is that it has a mesh-type topology. The mesh-type network is when we can interconnect many devices between them and they are all interconnected. If anyone has had the opportunity to see Bluetooth conferences, or if you were in today's workshop or in HGDL, you gave a conference on Bluetooth and you learned a little bit about how the Bluetooth structure works. In Bluetooth we have point-to-point, which is one

of its types of topologies. In the case of Zigbee, it's all mesh. So we're going to find several devices when we're analyzing. And another important thing is that it uses an 128-bit AES encryption. This is done by Zigbee because it is a protocol that is characterized also by its security that they handle. If anyone has had the opportunity to also sniff Bluetooth, the implementation that it performs depends a lot on the code that the programmer makes. In Zigbee, by default, everything comes encrypted. So they give you an extra layer of security for when you are developing a device and so that it is not so easy to sniff. Let's see what it is. Simple, in

quotes, everything has a difficulty and it also depends a lot on the ability of the person who is doing that part. Cv is an intermediate layer that we will find before the application layer and after the mac layer. This picture here shows us the structure of a Zigbee application. We will find the lowest layer, which is the radio frequency, the physical layer. Then we will find the MAC layer, which is the one that will manage the addresses. We will find the Zigbee layer, which is the one that will allow us to communicate, which is the one that will give us all the necessary tools with cryptography, with accesses. And then we will find the application

layer, which is where we can find the applications that we are going to use to communicate with these devices. SIGV has three main components that make it characteristic, unlike some protocols, and later others took very similar steps to make its topology. The first is that SIGV has a coordinator. The coordinator is in charge of managing the connections. It is the device that will allow us to generate the access keys, that will allow us to pay the devices, that will be in charge of redirecting all the traffic between the network. Basically, the one that coordinates, as the name says. The router is very similar to what we would find in in a colloquial language, a Wi-Fi

range extender, will allow us to redirect the packages we have from our Zigbee device to the coordinator, and from the coordinator, the application will connect. So, we will find networks where we also have routers, mainly when we want to extend the range of our networks, and some market devices also have the characteristic of becoming routers. In the case that there is already a coordinator, then our network will still be extended. And finally, it is the final device, or end device, These are also known as low-function or reduced function. They will only send us signals from the devices or the sensor they have. In this case, it can be a light bulb, it will only receive

the value of on and off. It can be a temperature sensor, where it will be reporting its measurements. And these are the devices that enter the modem. The computers and the routers will always be connected. Let's go back to the structure of how SIGVIM works, to see it a little more in greater terms. The physical layer, what I was telling you, is the radio frequency transmitter. We are going to have three regions, which is the global, of 2.4 GHz, the American one, which is the 915 MHz, and the European one, which works at 868 MHz. Why? There is the global, the American, the European. There are some countries that, by normative, have to work under

certain regulations. Rangos de radiofrecuencia. Incluidos, por ejemplo, Estados Unidos puede trabajar a dos tipos de radiofrecuencia. Tanto la de 2.4 como la de 915. Depende de dónde esté situado y cómo sea la normativa en ese punto. Por eso es importante conocer el protocolo y entender dónde estamos posicionados o dónde vamos a realizar el ednifeo para entender si nuestra tarjeta con la que vamos a ednifiar tiene la capacidad de trabajar bajo estas frecuencias y si estoy a frecuencia correcta para ednifiar. and the MAC is the one that is in charge of managing. The SIGGVI stack is everything that contains the information to manage the connections. Right now we are going to see that it has some

endpoints where we are going to be able to communicate. And finally, the application layer. The SIGGVI application profile is a feature that developed very similar to how the APIs of the web would work, where we place an address in the browser, we access it and we can perform different actions, whether it is to obtain information, update, delete, And in Zigbee we will have something similar. The application profile is a collection of descriptors of devices. Now we are going to see that descriptors are repeated a lot between the descriptions of Zigbee. This is handled by the standard itself, where everything is called descriptors. But it is correct because it is a layer after layer of Zigbee.

We can see it as blocks or crates that have the biggest, then the smallest, and then the smallest, and so it is taken to Zigbee. So, it allows commands to request information, process commands and requests. These application profiles define the type of message. We will have application profiles like Home Automation, LightLink, and Smart Energy. Smart Energy is the one I was telling you about, which is a device with the characteristic of being low-consumption. If a normal device is low-consumption, the Smart Energy still optimizes its operation to enter a mode of energy saving. and can only send with the best optimization for the resources contained in that device. Home Automation is the most common that we

will find when we are with the IoT devices of the market, which are few right now, because it is the most common profile. Normally when we use a Zigbee device, we keep it for our home, to automate our lights, our entrances, some locks, things from the home. So this profile is the most common that we will find. From there, inside this application profile block, which is the highest layer, which is the one that communicates with the applications, we will have the device descriptor. The device descriptor is a description of the device in the application profile that defines the basic information of the device. Descriptor will give us all the information about our device. It's the

one that exchanges values when it makes the connection. It's the one that gives us what profiles we're going to have inside all the internal blocks of ZigBee that we're going to see later. And it's the one that has a unique value. This device descriptor, which can be 1, 2, 3, it depends on the device, which is exchanged when the paving process is done. The cluster identifiers are also part of the block and inside the device descriptor. It's another layer inside, still. This Cluster Identifier tells us how the device is built, what values it has, where we have to write our values to be able to write data or read them. We can also define it

as a collection of attributes and commands that are used to find aspects of the device. Here we see a small diagram where we find the Cluster ID, its attributes and its commands. The Cluster ID is a value that will define how we are going to access that Cluster. It can be 10, it can be 6, and as if it were an API, we are going to give it "sign in slash 6" to go to the Cluster ID. and a get to have the attributes, to give an example. Then, if we wanted to write a command, well, we have to give a little more inside that API. These ID bases are represented by what I was

saying, these IDs that come in the norm, and each one represents a certain type of device. We can find the generic ones, those that are related to the light, alarm systems, and each one has a description. This description represents the type of device. If you do tests, for example, with the SP32, H2 and C6 that already support IEEE, will find that their examples use generics. Why do they use generics? Because generics allow us, or the applications that are made to communicate with Zigbee, to access values without having a context of how the application is built or the program in this case of the card itself. When they are specific, it is when we find the

light ones, the alarm systems, which are values that the manufacturer, when he is already programming the device, . We have a device that we know, that we can visualize, that we can have the technical file, anything that helps us identify and have a relationship with that device. But if we were at this moment, looking for and looking for CD connections, we would have to have a reference at least of what device we could be facing. That's why the device ID helps us. If we find something that is generic, and that has a value of 2, for example, is that it is an on/off output. It can be a focus, or it can be a value that can be acted

as a binary. It could be a remote switch, a relay, something that only has two states. A little alive, but it gives us a little more context that we can have on that device. Let's see the security model. This is important. Zigbee has two main ones, which is how to manage the network. This how to manage the network will also help us to identify what we are sniffing, how we are sniffing it, and how we can obtain values. The first is a centralized network. The centralized network is based on all end devices connecting to the coordinator. It's the only thing there is. One end device, or several end devices, and a coordinator. The coordinator is

going to distribute all the keys that exist within the pairing, and everything is going to communicate to that. There won't be another device. The nodes can support codes. This is also important. When we are in a Zigbee device, . Then we have the distributed. The distributed is when we can now use routers to extend our network. And in this case the communication process is a little different. In centralized, when we do the pairing, it has a unique key that is shared between the devices and the coordinator is the one that will manage it. In the distributed, the final devices are the ones that will send us a security key. It will read it, whether it passes through the router to the coordinator or directly to the

coordinator, and they will make the data exchange. This network is very interesting. Home Assistant that you can install in Docker, in Raspberry Pi, and have it at home to manage your entire IoT network. It has several plugins that allow us to connect other communication protocols, and several tests were made using this interface, which is what maybe a maker, a provider, could even implement with a home assistant, personalized, and a network of SIGVY device protocols. This is a SIGVY communication that we are going to see in Wireshark. Important things: Application layer, what we have been mentioning, cluster, the profile, and the source input. The application layer is everything I marked in this part here. Then we

have the cluster library, which is everything I marked here. The application will tell us what type of device we are using. We see that it has a Home Automation profile, which is the one that I mentioned, it is a generic device that we are using at this moment. So it puts it as Home Automation. I remind you, The home automation is mainly used because it is already established. So it is easier for the applications to understand what devices are being communicated to. If you want, you can make your own endpoints, your own application profiles, but only the applications that you develop and point to these values will know that interface. The generic applications, unless they

continue to respect the standard endpoints, will be able to be used. We see that we also have a source endpoint. The source endpoint is where the information we are receiving comes from. When we are reading the values, we will see that we have a place to write, one where to read, they can be different, it can be the same, it depends on the manufacturer, in this case it came out of point 10. Then, in the cluster part, which is where we are waiting for that value, because we will be able to have the cluster where we find the information of the device, if it is maybe a more complex card, it can have control for

several focus, it can have relays, then it will have several endpoints where to point and it will have different attributes. The attributes in this case are ON/OFF, which at this point, if you didn't have the card, you wouldn't know if it's a switch, a light, a relay, or what characteristics it refers to. We will also see that it also handles the type of data, in this case it is a boolean, false, or true, on or off. And what control value is it? In this case it is in OFF. This, for those who reach the LEER within the source, which is the IP addresses, It shows us that it is Expressive, I am using a development

card, an SP32 to show you these packages. We are going to see an example with the Xiaomi kit. A very important thing with Zigbee, and we are also going to see it with Trade, is that they are handled via IPv6. This changes the communication a lot, how we are going to see the values, how we are going to communicate. So now we are not going to see IPv4 addresses, we are not going to see MAC addresses, but we are going to see IPv6 addresses. In Trade, that part becomes a little more complicated. And finally, I didn't mark it here, but those who have good eye will notice that it comes here. Not all Windows. These things

also fail. So... That's the part of Zigbee. Zigbee has many things that make it a bit extensive, and the idea is not to dive so much into the protocol to not bore them. So it was created by Google for its Nest project. Those who don't know Nest, well, it's a series of devices that have connections to different IoT devices, among them the most famous is Google Nest, the little screen. It is characterized by its low consumption, it uses topology based on the internet protocol. As I was saying, TREAD also implements IPv6 as part of its basic communication. It supports IPv4, but you have to configure these devices so that they accept IPv4 in a native way, and accept IPv6. Within TREAD, there is the TREAD

Border Router, which is the one that extends communication between between the devices. The Trade Border Router is a device that will allow us to connect to the internet, talk to the internet, be able to, if I were connected, I have my devices outside my house, from my cell phone, be able to control also all my network in my house. There are applications that do it directly with the internet connection. What it allows us is that we can have devices that work offline or that do not have an internet connection or wifi and be able to use them through Trade to communicate with the internet through the Trade Border Router. TREK has two main devices that

are the basis of all the communication it has. The Border Ripper, which is the one I was telling you about, which is the one that is in charge of connecting to the internet, managing the devices, and the NBAC, which are going to be all the final devices that are going to communicate with our entire connection. One of the advantages of TREK is that when using the IEEE 8.2.15.4, we can also use Wi-Fi or Bluetooth at the same time. So we have more communications that we can intercommunicate with our device and extend our network even more. Its main features, as I said, IPv6, it has DNS services, with this we will be able to find devices, search for devices through its hosts, and it supports TCP for

communication. This is a small comparative picture between BorderRoute and NDevice. Okay. This would be a topology of a Thread network. We will have the cloud where we will be able to communicate our devices, we will be able to see them. We will have our final devices, in this case, the lights and the padlock. And we will have the intermediate points, which can be other devices, it can be the same Thread device. And in the middle we will have our border router as well. Something that Trade handles, apart from its security protocol, is that it was done at the test of errors. What does that mean? That Trade devices can scale their own privileges, so that if another device is missing in the network, that is interconnected, this

device can continue sending the communication. In Trey we will find a router board, which is a device that also serves as a bridge between communication and Wi-Fi. If we do not connect it to Wi-Fi, we do not connect it to the internet, it can serve as a bridge between the other devices and we extend the range of our network even more. Now, we are experts, we are going to see the videos that are what interests us. You forgot that there was a part of tools. Two main tools with which you will be able to see this information. The Nodic, which have the NRF25840, the CatSniffer, and tools from SDR that support the protocol. They are

the tools that we will be able to use. Tools that will also help us, but in this case we have PyCatSniffer, which is a multi-platform tool, it communicates with the CatSniffer, in case the name is not very clear. It uses the PacketSniffer firmware. Why do we use this PacketSniffer? The CatSniffer supports various firmware with which we can load it, including Texas Instruments. Texas Instruments has support for Bluetooth and triple E, so This tool is designed to support both Bluetooth packages and the IEEE part. There are other firmware that we can use in Bluetooth too, but this tool is designed specifically for the Texas Instrument package. Later, its Hatch, for the Sigbee analysis part, if someone

has already entered, has a Sigbee sniffer, can use this tool to see the packages in WatchShark. And the other tool that we are going to have This is supported by the Open Trade website, where we can find the sniffer, and it works with the NRF25840. We load it and we have the sniffer. This uses the finger of the network coprocessors. The network coprocessors are trade devices that also serve us as part of extensions, as routers of our own network, and we will be able to use them. It is not as common to find them in devices as it is in a network coprocessor, since that is part of the functionality and the escalations that the

protocol itself has. So, when you see descriptions of trade devices, you will not find that they are network coprocessor devices, but they already come by default within the protocol. This video corresponds to the part of the Sniffen of Zigbee. Here we run the tool, we see which one we are going to use, we see which are the protocols it accepts, and we run the command to check the connection. And there we start. Wireshark, within our tools that we had to design to adapt the firmware of Texas Instruments, we had to make a disector. . and here our task is to find a connection package, a package that gives us a clue of what device it is, or anything that can be of use to

us. In this case, an association request was initiated, which is when we put the home assistant in pairing mode to add devices to our network, and another device makes the connection process for it. They start to to communicate with each other, pass the keys, give all the information of the device, and our job now is to find where we can find a key that has been shared in that process. By default, we will be able to see some packages, and we can use the own key of the SigBeech Alliance to decrypt information. If when we use that key we don't decrypt the information, it means that the device is using another key. What do I

mean by encrypting information? We can see, we can see information in a little more detail. If we couldn't see that information, it's because the information is encrypted and has another key that we won't be able to use unless we intervene with the device, do a firmware analysis, or look for some vulnerability that gives us that key. So here we start looking for any indication that gives us that key, and here we see an important package. the transport key. These packages are the ones that will give us the keys we need to decrypt the information that will proceed from our devices. So, by finding them, we will be able to continue with the snipping. If we start expanding our WildShark fields, we will find it down here, in all the

information. This key, which is the transport one, we are going to use it to input it in our pre-configured keys to decrypt the information. It's done. And we're going to be able to see all the information, so to speak. Now we just have to wait for our device to send us an update value. In this case, we're going to move it a little bit. There it is. Here we have a ZCL. ZCL is a part of the interface that Sigri uses to communicate. We're going to find some commands, and this is part of what reports the attributes. I'll mark in red what we're interested in. which are the packages that give us values of how

the state of our connection is, which is when the attributes are reported. So here we start looking for the packages where the information we occupy comes from, and down here, maybe you can't see it, but it tells us "control off". If we start looking among the other packages, we will find the control that will be in on. So we will have all that information.