 So it's Erwin and Matt Day, let's give him a big DEF CON welcome! Okay, good morning all. Thanks for being here early for some of you who don't have kids yet. So just a quick introduction. So I'm Erwin, that's Matthijs or Matt if you may want to call him. We both work at Nixu, which is a Finnish company but we actually work for the Dutch branch office. So we're based in Amsterdam. As you can see it took us quite some time to get here. So what is it what we're going to talk about? Well we're going to talk about Warnish industrial sensor networks. But it's always good to look back at like what has been done before. As you can see the earliest research was already done in 2009, more academic research about potential attacks. And the attacks were described but not demonstrated. There was no information how you could actually recreate the attacks yourself. And that sort of continues because then in 2015 was actually a PhD student in the Netherlands who did also similar research and actually tried to build a tool to interact with these networks and he didn't really succeed. So he was using SDR based systems initially. In the end he didn't really succeed in actually capturing traffic or modifying traffic. So then we came along and we did a presentation at S4. And then we already opted the idea to actually create a toolkit to be able to actually capture traffic, inject traffic, etc. That's a couple of years ago but unfortunately we never got around to actually doing it because we soon left the company we were working at that time. And in the meantime we had Lake Johnson again using SDR based approach to interact with these networks. But again no code was released, no tools, nothing. So I mean these networks are around for quite a while but still there are no tools. And we strongly believe in Wright's principle which is written down there. The guy Joshua Wright who actually said that well if there are no tools security will not improve. So we were actually attending DEF CON last year and not as a speaker but as a regular visitor and we're like well let's build those tools because it's still missing. And just to give you an idea what the industrial revolution is for these type of systems. So first we're talking about industrial control systems here. So first we had the air pressure systems in the 1940s. In the 1950s they started using analog current loops. In the meantime I'm well familiar with that part because it actually allowed me to destroy some of the components we were testing. But later on they actually started creating digital protocols. So on top of the current loop they implemented for instance the heart protocol which you may be familiar with or not. And in late 2000s they thought well let's do wireless and they created two standards wireless heart and ISA 111A commonly named ISA 100. So is anybody familiar with this protocol? Have you ever heard about it? No? Not that many. Okay. So it's for most people it's very niche but still it's interesting. And if you're wondering where these systems are being used for instance oil and gas fields you can see those transmitters. So you see the blue ones. They're actually field devices. So those are transmitters and they're actually measuring things like pressure or temperature. And they transmit wirelessly to the central system. But we get to that. But since it's an industrial control loop, process control loop I think it's good to sort of explain how that works. So basically you have a flow transmitter all the way on the right. And there's a signal being sent to a central controller. And that for instance indicates the flow rate. That's called the process value. And that process value is actually checked against set points. And if it's within range nothing happens. But if something needs to happen there's actually control output. So that's the bottom line. And then the valve is actually changed from open to close to adjust the flow. So this is the typical process loop. And what you see is that typically up till now mainly the measuring part is done wireless. Either with wireless heart or ISO 100. So if you look a bit more at wireless heart it's actually the same hard protocol the application layer. But they created a wireless status tag for it. So it's compatible with the hard devices out there. It does use encryption so it's not the most insecure control protocol. But it's symmetric encryption and we get to that in the later slides a bit more. It's based on wireless technology from DOS networks because they are also the ones creating the radios. So the radium system on the chip. And you see there's a couple of vendors who actually built equipment for wireless heart. So ISO 100 there are fewer companies actually supporting it. The main driver is Yoko Gawa and also Honeywell. And there's actually a whole bunch of standards it's based on. So there's six low WPAN. There's IPv6 surprisingly and UDP on the top of that. And it's allows you to tunnel under other protocols. So it's not like they took an existing protocol as with wireless heart and built a wireless stack for it. But you're able to tunnel. And so it's more vendor neutral. And the main it's developed by a company called Nevis who created the system on the chip initially. But now there are more chips out there from different vendors. So what does a typical topology look like? Well these are mesh networks. So there is not, well there is a central system that orchestrates the mesh. That's the gateway network manager slash security manager. Typically that's just one box, one device as you can see on the right. But there are field devices out there. And there's a couple of different ones you can see in the picture. So you have the field devices that actually measure stuff that have wireless transmitter themselves. Or you have the situation where for instance where you have a heart enabled transmitter and then you can add an adapter and they can communicate. But since it's a wireless mesh network also the field devices can route traffic for other devices. So it's not point to point only. And you have on the right hand side you have the wireless heart hand held and that's being used to actually configure the devices. So before they can join the network you have to configure them and then they will join the network. So if you look at the protocol stacks you can see that on the heart side there's actually on the left hand side you can actually see the traditional heart and on the right hand side you see the wireless heart. So it's based away to 15.4. But they used only a very thin layer of that protocol. But everything they build on top is specifically wireless heart. And one of the things to pay attention to is the channel hopping because we get back to that later. That's something that was challenging to solve. And also on the ISO 100 side we see a similar thing. So it's again a thin 8 or 2.15.4 layer and then you see the whole protocol stack on top with UDP etc. etc. And although it's not listed in this overview they also do channel hopping as well. So to summarize the similarities because we have two wireless protocols out there which are somewhat similar and we thought well can we build a toolkilled to actually assess both of those systems. So they both have the 8 or 2.15.4 layer although they both have a different version, subversion. And they both work at 2.4 gigahertz. And they both do time slot the channel hopping. And the reason they do that is how they hop from channel all the time. And the reason they do that is actually to minimize interference. Because I mean these systems are being used in plans, in industrial sites. So there is a lot of interference from other systems that are out there. And also to mitigate multi-part fading. So that means that if a signal gets reflected back you might cancel out the signal and because you hop the channel you actually prevent that. Because there's a lot of metal around large storage containers etc. So there's a lot of reflections. So they both have a central network as a security manager to orchestrate the communication between the nodes. It doesn't mean that the nodes itself can also route traffic for other nodes but there is a central point that controls the network. So we thought well we can probably build a sniffer for both protocols. So we, if we look a bit more at the pinks that share is that they actually use the exact same ES, CCM star encryption. So at the network layer they use it for integrity only. So either 2.54 is only integrity. But at the transport layer they apply encryption. And both systems have actually a joint process where they actually share the encryption key. And that's a handshake with the network manager. So that's the central component. And for wireless heart it's only shared secrets. So that's really an interesting thing. Symmetric encryption. So how do you get the key across and where do you store it? And ISO 100 also supports certificates. Although we haven't seen it being used. So ISO 100 supports both shared secrets and certificates. And there's a lot of different keys. So if we start at the left you have the ISO 100 and the top three keys are actually used during the provisioning phase. So you have the global key, the key open, key global. And during the provisioning phase the master key is being shared. And from that master key they derive two keys, the D key and the T key. It's not so important that you remember all the different keys. It's just to show there's a lot of different keys out there. And the same is true for wireless heart. So the well-known key is used at the network layer. That's actually an encryption key, but an authentication key because they don't do encryption in the network layer. And there's a network key, then the joint key for the joint which is being shared during the joint process and derived from that there's two session keys. So both for broadcast and unicast. So first question of course is how do you get key material? One of the things you could do is actually re-documentation because there's a lot of default keys out there. And I must admit that since we've done the research two years ago a lot of the documentation is not publicly available anymore because we back then already published some of the keys that are default keys. And it seems a lot of the documents have vanished. So not all the keys we list here you can still publicly find. But we're pretty sure that we initially found them somewhere. And ISO 100 specifically also has over the year visioning of devices. So that's also a weak part where you could sniff the transaction or the handshake. But then you need to be able to sniff of course. And previous research we've done we actually took apart transmitters and looked at if we could interface directly with the radio shock because actually there's multiple components and there is a radio shock on there. And I turned out that they actually had JTAC SPI enabled at least for wireless hard because back then we only looked at wireless hard. And we showed that you could actually sort of locate where the encryption key is. And worst case you can always dump the complete firmware and load it onto another similar device and then you can also join the network. So there's a couple of ways to actually obtain those keys. So if you are a plant manager and you're getting rid of old equipment also pay attention to the last one because you might not erase those keys and if it ends up on eBay somebody might buy it. So there's a couple of default keys for wireless hard. We haven't located any default keys for ISO 100 yet so that's why I'm only list wireless hard keys. The first one you see a lot and that's actually has to do with dust network to create the socks and that's why they use dust network rock at a lot of locations. So you can see it's a 16 bytes, hexadecimal key so it's quite long. But you can see they use a couple of values out there. And the third one, the Emerson one is also interesting because that's taken from an Emerson wireless hard gateway and if you do a factory reset it actually sets the key like this. So you see a lot of zero. So the key space is really, really small. So if you ever have reset those devices and use the default key you might be able to easily brute force it. And sometimes you can see it's also the name of the vendor so the last one is actually exactly Emerson Houser, but in hex. So if we look at the sniffer hardware we first looked what's out there because we want to build something new. And during previous research we used the beam logic which basically is just a sniffer but it sniffs on all 16 channels simultaneously. So it has no injection support, very basic wire shark dissection. It's quite expensive. It's the box on the right. So yeah, it's expensive and also quite limited what you can do with it. Initially we thought about using the Admiral RC Raven stick because also the regular transmitters used an AVR based system but already reached end of life and it's very hard nowadays to find at the studio somewhere. So then we looked for other options and we went on to the B-Kit from NXB. And by default that already allows you to sniff on one channel with the standard firmware although the standard firmware is not open source but that also reached end of life. So we continued our search for another one, another stick from NXB. So this one is still supported, has a free IDE and it allows you to sniff on a single channel. It's quite powerful and we need that for the channel opening. Matthijs will explain later. And you can actually modify the PCB a bit to put an external antenna on it. It's extremely small so I already ruined the device trying to do it. But it is possible and you could go to war driving. Yeah, there's documentation out there in examples but only with a few important omissions here and there. So I just want to show you the default application that's already provided by them. I hope you can see it. So basically this is a default application. You just select the channel so it's sniffing 802.15.4. You can start Wireshark and you can at least see packets. You can see the packets but if you click on actually on the bottom side you can see that it's just data so it doesn't have a detector for this protocol. But the base is there. We can already sniff packets on one channel so that's a start. So then we figured out, okay how does this actually work? Because there's a whole SDK around it but actually it's relatively simple because the hardware is detected as a virtual comport. Both on Windows and Linux so that's already a plus. But they implemented their own protocol which is called FSCI. It's developed by NXP and it's a communication protocol over serial. And there's a host SDK available with Python bindings. But we thought well we don't want to ship a tool with a whole host SDK around it. We might run into legal issues. So can we communicate directly? And as it turns out we can actually do that. So we created a driver for Killerbee and Killerbee can directly drive this stick now so we don't need to have full SDK anymore. So this is what it looks like. Schematic directly. So the KW-4-1-Z is actually the M Cortex. There's a second one on there where you can actually load different boot loaders. And that way you can also provision new firmware on the device through USB. So you actually have the MCU Expresso it's called. MCU Expresso IDE and actually allows you to develop a firmware for this device. Thank you, Evan. So we wanted to build something more powerful than was out there. So we thought we found our hardware platform that we could develop on. So we started building the device and we started building the tool set. And the first thing we wanted to accomplish is we'll sniff the packets ourselves and not relying on the SDK that came along with the hardware. So actually we built a driver for the Killerbee framework. Killerbee because it's just the same RF layer 802.50.4 protocol. So that seems quite a good match. And we also developed extensions to Skappy. So we were also able to inject packets rather than just listening on the traffic. And to bring packets sniffing to the masses, we also decided to build a wire shark detectors for protocols wireless heart and ISI 100. So we'll show you a short demo. This is an action. So you can see we use the ZB wire shark utility that comes with Killerbee. And we also built a network. And here you see we are picking up traffic. In this case, ISI 100. And you see also the wire shark detector in action. On the left of the screen you see we decode the packets. So the next challenge was the channel hopping problem. So like Aaron told, the protocol uses a fast based channel hopping algorithm. And when we started developing and studying this toolkit, we thought, okay, there's a new extension for 802.15.4. If I remember correctly, that's the D amendment which also uses time-stopping mechanism. So we thought, well, maybe we could use that. Because that primitive was already supported by the SDK. But it turned out that it was not usable at all. So we really got to get our hands dirty and write a pretty extension to the firmware itself. So none of us having a better development background. It turns out to be quite a challenge. So if I mean fast based channel hopping, that means that the intervals you see here on the slide are 10 milliseconds. So every 10 milliseconds, the frequency change. So in order to keep up, you have to think through how you're going to accomplish that. As I said, we need to rely on the firmware itself, on the hardware, because, yes, you can change channels from the host system. But as soon as you send an FSI command to the USB device, the time slot already has lapsed. So that doesn't work in practice. So you really need to implement this in firmware. So that we needed to deep dive into embedded development, which was new for us. Yeah, there are a couple of approaches you can take. So for this type of devices, you can rely on a real-time operating system. There are quite a few arounds. One of them is free RTOS, for instance. But it is pretty complex in the sense that it's pretty complex in the sense that it's not a full-flash operating system, but it has a task scheduler that will pre-empt. So that means that it will interrupt your code right in the middle of your function. And you can get all kinds of challenges, like race conditions you have to deal with. So you need to mess around with semaphores and other synchronization mechanisms. The other approach is use a bare metal task scheduler that will not interrupt right into your code section, but as soon as the task is scheduled and is running your code, you're responsible for releasing resources. So that means that in practice, you have to make sure that your code doesn't run for longer than two milliseconds. Otherwise, you will start other tasks. And that means that, for instance, there are separate tasks for collecting the packets. Yeah, you can make sure that you change channels, but if you don't pick up the packets, you don't have anything at all. So as I said, yeah, it requires quite some discipline in programming. Well, the upside is that you can achieve fast execution because you don't have the overhead of a real-time operating system. So this is what a glucose like. These are the modules in the firmware. A part is offered by the framework itself. So you have a memory management task that is taking care of allocating the heap and stuff. You have the MAC file layer that's taking care of picking up the packets from the radio. And the serial manager obviously because these packets need to go to the host. You have a bunch of timers that you can program and will wake your task so you can do actually something useful with these packets. And of course, everybody needs blinky lives. So on the right side, you see actually what we needed to do. The MAC file layer was only partially useful. We needed to implement the channel hopping. Yeah, that is called the MAC extension layer because we needed to obviously extend these capabilities. On top of that, we actually get to the industrial protocols, ISA 100 and wireless heart. And we also needed to parse information out of these packets on that layer because we needed the information in order to calculate one particular time slot occurs where you're interested in. So how to do this? 10 milliseconds. If you program a timer to wake up your task every 10 milliseconds, we found out that you're always too late because you're never guaranteed to get a wake up call within every 10 milliseconds. It's either 10 milliseconds or 11 or 12. And when you start tuning into the channel, you're too late. So what we did is we parsed the packets that came along. So in the advertisements of both wireless protocols, you'll get information where the slots of interest are. For example, the join slots. These are the time slots where field devices actually can tune in to start a handshake for getting on to the network. Those are of particular interest. Also from a tech perspective. So what we started to do is tune in in advance. So if our tuning code gets cold, we measure, okay, the next slot of interest is three time slots away. Okay, we'll tune in right now. And, well, the other task will take care of picking up the packets there. So that gives us some more room. Like, for instance, around 40 milliseconds, rather than 10 milliseconds. So that turned out to work pretty well. And we'll show you how we actually achieve channel hopping. Again, ZB Wireshark. We had to hack in a non-existing channel. Channel zero means that we activate the channel hopping in the firmware. And as you can see, we get quite some more traffic here than in the first case, where we only were tuned into one particular channel. And I don't know if it's readable, but here you can see on the left part that we actually hop to different channels. So what can you do if you can tune on these intervals of interest, these time slots? Well, these are a few attacks that have been theorized. And now we can execute in practice. One is just the signal by sending a garbage on a particular channel. And you can block, for example, advertisements. And if you do that successfully, no new devices can join the network. Because I don't, they are not able to synchronize with the network. Or even existing field devices will lose at some point the synchronization with the network. So in practice that means that the field devices are unable to send their process values. And yeah, depending on what control system you have, you can work havoc. Of course, being able to inject traffic, you can also transmit fake advertisements. So you can enter a few devices to join your network rather than the existing network. And yeah, we'll give a short demonstration of how you can gem. And here you see the victim was happily receiving advertisements. And we turn to the attacker, which will start our tool to gem the signal. We found the network. And on the victim's side, you see a few packets coming in and next comes to a halt. Silence. So that's all, that's all nice. That we can do things without actually being on the network. But suppose you have some, gathered some keys, or you found these in the manuals, or you brute force these. Well, you can do all other nasty stuff. The way this works is that the encryption actually is derived from a non-set has for large part predictable values. So there is, in the advertisement data, there is a counter that you need. And that can be snipped from the network without being authenticated. But even if you don't know how to, you can mess with this nonce value. Because there is a replay protection in place that's supposed to protect against obviously replaying fake values. But the thing is, if you mess with the nonce, and you'll guess a valid nonce, and it will be picked up by the device, if it's larger, say it's much larger than the timestamp of the network that is currently in the network, it will reject all packets from valid devices. So you can really bring down entire sensor network this way. Of course, if you also have access to other key material, for example, when capturing a joint process, and you have access to the session keys, you are free to mimic a real field device, and you can really mess with process values. And that's where it's getting really scary. So, to summarize, what did we learn along the road? This, these sensor protocols are highly an explored area. And there are a lot of things that we learned as we, as in the introduction. We suspect that it's mainly due to the fact that no real good, real good tools exist. So, yeah, we picked up the task and hope that we will, we can promote other researchers to explore this very interesting area. So, yeah, we intend to release the tool set we created. And, yeah, another thing we want to, to give to the asset owners who deploy these systems. We see a trend that people are getting very confident with this technology because it's around for 10 years. And it has never been hacked. So, must be secure, right? So, you see a trend that these protocols are not only being used for monitoring systems, but also for control. Yeah, I would like to, to, well, probably that's, that's the not a real good idea. So, they might want to reconsider that. All right. We have some time questions, five minutes I see. So, these are the future research areas. These are the future topics we want to expand upon. So, we'll support more attacks that have been theorized so far, but no, the tooling exists. We want to create support for war driving industrial networks. When we do order the hardware, we were happy to see that it had an external antenna connector. But once it arrived, it was not on the board. So, you're kind of disappointed. And, of course, with the capability of actually interacting with this network and the capability of injecting packets, yeah, we are free to actually first these protocols from the radio side of, of these systems. Okay. Well, thank you for your attention. And we can take some questions now.