>>For the next 45 minutes we’re gonna be talking about a series of offensive uh RF exploitation techniques. Particularly ones aimed at the physical and mac layers of wireless communication systems. Reason why is because mobile and IOT means that wireless technology is more diverse and incumbent than it’s ever been. So with that comes many more attack surfaces that we’re excited to talk about and enumerate. So my name is Matt Knight this is Marc Newlin, we’re both security researcher- researchers at Bastille Networks uh we’re motivated by wireless security uh we think it’s really exciting. We’re happy- happy to be here. So we’re gonna begin with a brief historical rundown of the development of wired and wireless security technology.  Uh after that we're gonna move on to introduce some key RF concepts and this is gonna be pretty light, just enough to frame the rest of the discussion. And then we’re gonna move into what is really the body of this talk, which is our methods of wireless exploitation. And what we’ve done with this is we’ve looked at a number of high profile attacks from the last couple years and for each one uh we’ve categorized them. We’ve broken them out in terms of the uh mechanics of how the attack is performed uh and then what we’re really gonna try to emphasize is analogues that exist on wired networks. And the purpose of this is to try to demystify really what’s happening in the in the wireless domain. Uh we’re gonna have some uh some uh demos and videos and uh then we’re gonna leave you with some uh some advice. So let’s jump right in. So say you’re a network security administrator in the 1990s, and you wanna take a look at what’s going on in your network, uh get some bits out, see what’s happening. Well it- you- are really 2 protocols that you’re concerned about you had ethernet and token ring. Uh looking into these protocols involved buying an expensive- expensive computer, running some proprietary software on it, totally proprietary, not that great. Fast forward to 1998 and Ethereal comes out. Uh it’s since rebranded we know it as WireShark. Um what this did was it massively commoda- umm it took the proprietary solution and it made it a commodity. So very cheap very easy to use uh and people were able to hack on it and extend it. So that’s great. So let’s look at what’s happened since the 2000s. The map of protocols that we’re concerned with is a little more complicated, right? So 802 dot 3 and you know you can probably still find token ring some places they’re still there. But additionally we have tons of  wireless, right? We’ve got this uh all these new protocols coming on line uh so it’s a lot more complicated. If you wanted to take a look at what was actually going on in the air, in the 2000’s you could go out you could buy an early software defined radio. Uh and this would, you know could easily run you 6 figures um it’d be a big PCIE card that you’d have to hook in- hook into a powerful computer or a you know network of computers. Uh so you know it was proprietary it’s expensive, it’s not that great. Uh fast forward to 2012 and a Finnish, I believe he’s Finnish, uh hacker named Antti Palosaari was looking at his DVB-T uh over the air receiver. It’s a USB stick that you can plug in in anywhere where’s there’s uh digital television with the um uh DVB-T standard, uh you can pull that down and watch it watch it on your computer. Well he was looking at the uh at the the front end for that, realized that you could put it into a debug mode that would stream raw IQ, that’s complex samples of the radio domain, back up to your host. So with a promiscuous driver you can turn this into a poor man’s software defined radio. It’s pretty sweet. So fast forward to 2017 and software defined radios are totally commodity. Uh for all sorts of price points um ca- capability levels targeting the hacker all the way up to the professional so then you can put newer products.Um this this in- this has revolutionized wireless security and the ability to look into these proprietary protocols. So in 2017 802.11 is really just a piece of the puzzle when it comes to securing, securing RF. We know that with the growth of mobile and IoT, uh there have emerged a number of different PHYs so really there’s a physical layer for every use case. Uh and many of these use cases target embedded systems. So embedded systems we know to have been designed around compromise. You know often times they’re battery powered so they have to last for years at a time uh. Maybe they are they’re limited in terms of the type of processing they can do on it, their ability to do cryptography, you know good and bad reasons for why systems might not support that. Uh additionally they may have limited network, um so you might not be able to push forward to them. Maybe they have non rewritable uh flash memory so you can’t uh push a new image to that. And just one picture that I really love just to emphasize how complicated the deployment of embedded systems can be, I have up there on the slide. Uh what you can’t see are 3 literal embedded systems. They’re embedded in concrete. So you can think that pushing forward into that is quite a bit more complicated than patch Tuesday. So combine that with an industry reliance on security through obscurity means that we as attackers have loads of targets. So uh that was a- a whirlwind run-through of the the history I’m gonna hand it off to Marc and uh he’s gonna get started. 
>>So as security practitioners you’re probably familiar with using tools like WireShark to look at layer 2 traffic from 802.11 and 802 dot 3 networks. And these allow you to use commodity hardware that give out these layer 2 packets. Uh with this kind of sniffing you can’t really look at the physical layer simply because the hardware you’re using does not support it. So in the case of a wifi adapter this is something called a hardware defined radio. And we say it’s hardware defined because the logic that makes it speak 802.11 is baked into silicon in the chip. However in order to look at wireless protocols, and when we say wireless we mean non 802.11, we need some different type of hardware. So on the left here we have an picture of a spectrogram showing a few different RF physical layers. And we can see that they’re visually different. This is manifested in how they actually communicate over the air. And because we have all these different physical layers that you can’t communicate with using a wifi adapter, we need to use something called a software defined radio. And a software defined radio is a flexible generic reconfigurable radio front end, and so you can change the center frequency, you can change the channel bandwidth which is how much data you’re pulling down, and you stream this raw radio data either to an FPGA or to your host computer. And this is great because all the logic that defines how the protocol operates, so whether its 802.11 or Bluetooth or some proprietary protocol, this all exists in software. So instead of having one hardware defined radio for every different protocol, you can have one software defined radio and simply change the software on your host computers to speak these different protocols. And one of the downsides of software defined radio is that it can be fairly complex. And if you look at this image on the left, this is some RTL from a 802.15.4 software defined radio decoder that Matt implemented. And as you can see it’s super clear what’s happening there, a nice level of complexity. And you know w-one of the you know, concerns people have with STR is this assumption that you’re going to need to know a lot of digital signal processing and other complex domain specific knowledge. And Matt and I have given a lot of time thinking about how to make software defined radio more accessible to people. And to this end we’ve given a series of talks titled “So You Want To Hack Radio?” And the whole point of these talks is to explain how you can use great open source software and hardware written by some very smart people to abstract away a lot of the complexity. And one of our favorite tools for this is called GnuRadio. And on the right here we have a picture of a GnuRadio companion float raft. And this allows you to drag and drop these great open source signal processing blocks and implement your transceivers, transmitters and receivers, without having to understand the math that goes on under the hood. And I want to point out that Michael Ossmann and Balint Seeber have some great videos on STR and GnuRadio in general on Youtube and I highly encourage you to look at those. Also a lot of very very smart STR people hanging out in the wireless village if you want to go talk to them. And now Matt is going to talk to you a little bit about some fundamental RF concepts.
>>Alright so the purpose of this next section is not to make you experts with digital signal processing. It’s just to provide enough context around communications in the wireless domain to be able to frame the rest of the discussion. So when we talk about wireless protocols we’re invariably involving the physical layer. The physical layer is the lowest layer in our uh communications model. And in wired protocols it essentially defines how your ones and zeros get mapped into voltage hemming and wiring, kind of the physical properties that underline the communicate- the communication standard. In wireless however, it defines how your ones and zeros get mapped into patterns of energy that are being sent over the RF medium. So RF uh  is essentially the electromagnetic spectrum. Uh you know all wireless signals um if you sum them all up you get a picture like this. This is a spectrogram uh you have signals at different frequencies carrying information. It’s kind of just like one big shared medium. Uh so manipulating RF can be done with a radio. As Marc outlined they can either be soft, er hardware defined or software defined. But the key function that the radio performs is called the modulation. And the modulation is a function that exactly maps how those digital values get mapped into RF energy. It’s kind of the core element of your wireless physical layer. So I’m briefly gonna run through what happens uh from the perspective of a radio when you tell it to send a message. Eh eh if you’ve developed a wireless system before, you probably get to the point where you call driver dot send and you pass it a buffer, right? So you make an API call. And then that writes it out over Spy or I2C or some interface to to radio chip set, but what does that really do to make, uh to make your bits magically appear in another system that could be some distance away? So the first thing that that radio is gonna do when it receives the buffer, is it’s going to append some information to it. So it’s going to prepend a header which includes a preamble, a state of frame delimiter and maybe some some header specific values. And it’s gonna append the CRC so that it can check for errors that might occur during transmission. It’s then gonna perform that modulation function where those ones and zeros are gonna get turned into a wav form. That waveform then gets run through an RF front end, which can include some filtering, and uh and some game stages to make it more powerful, and then it gets pushed out to an antenna. And it goes out into the electromagnetic spectrum, into the RF medium that carries it to its destination. The receiver is a little more complicated. So your waveform gets picked up by the antenna get gets run through a demodulator, now produces a stream of bits that wind up in a f in a physical layer state machine. And if you uh were to break this down it looks something like this um we’re not gonna go through this in detail. If you want to learn about how these physical layer state machines work, that’s all what that talk so you wanna hack radios is all about the one that Marc mentioned earlier. Uh so we’re not gonna cover that here. Um there's some content out there if you wanna know how it works. But essentially the physical layer state machine spins on that stream of, uh stream of information coming from the demodulator and ultimately presents a layer 2 frame back up to your backup to your your uh your host. So uh the key concepts to take away from this is that radios are state machines and they’re deterministic, right? What happens isn’t magic and the implementation of these state machines is informed by the fact that RF is very complicated. You have lots of contention from uh, from other interferers other other um actors within the medium. Whether they be uh unintentional or intentional. You know you could be unintentional just in terms of you know being in the 2.4 gigahertz ISM band where wifi lives, wifi is really active, or it could be intentional, if you have the case of somebody trying to jam you. Anyway these radios are designed with features to compensate for the fact that this medium is very uh, very complicated and failure prone. So between all this we can find some some interesting cases that we can begin to abuse uh to construct some novel attacks. So that brings us to our methods of wireless exploitation. So what we’ve done here is we’ve categorized the major wireless attacks that uh that have occurred in the last couple of years uh and we’re going to present them to you. For each eh each category we’re gonna show the method of how the attack was performed, the impact that it enables, and number 3 is the big one. We’re gonna highlight analogous attacks that exist on wired or IP networks if such ones exist. And again this is just to provide as much context around wireless domain in terms of how it’s similar and how it’s different than wire- eh wired attacks. We’re gonna present some uh limited- limiting factors, whether it’s incidental or intentional uh mitigations and limitations. We’re gonna provide some examples and then we’re gonna provide some demos as well. So uh to kick it off I’ll pass it back over to Marc and he’s going to take you through sniffing. 
>>So when we speak about stiffing in this context we’re talking about sniffing the physical layer. And there’s really no analogues to this in the wired domain. As I said with like the ethernet adapter for example. You’re unable to see the physical layer package, you're only looking at layer 2 and higher. Sniffing allows you to observe the RF medium that’s in use by other devices that you do not control and recover data that they’re transmitting if they’re unencrypted for example. Or you can have a reconnaissance goal and enumerate devices in an environment for future attacks. The big limitation of RF physical layer sniffing is range. And you have to be physically proximate to a device. And when we say physically proximate we don’t mean in the same room we just mean within range of the budget of your antenna and your amplifier. There are a couple interesting sniffing attacks in the last couple years. Uh Matt has demonstrated that you can recover the cryptographic key from this Zigbee door lock by sniffing the pairing sequence that happens between the lock and the smart hub. And then you can operate the lock yourself and walk into somebody's home. Last year I did a bunch of research into wireless keyboard security. I demonstrated that a lot of the keyboards on the market are actually unencrypted and vulnerable to keystroke sniffing. So for a demo here I’m going to be looking at the HP classic wireless desktop keyboard and this is based on a transceiver from a company called Mozart Semiconductor. And this is a unencrypted wireless keyboard transceiver that I reverse engineered last year and it’s actually over the air compatible with these common Nordic Semiconductor nRF24L transceivers. So it all uses off the shelf hardware defined radio to sniff unencrypted key strokes from this particular device. Now we’re just going to switch over to a quick video demo here. So on the left we have a keyboard focus on this terminal on the right we’re running a sniffer script with one of these Nordic nRF24L dongles and as we see when I’m typing with the focus on the left terminal the loads the actual input from the keyboard and on the right it’s actually sniffing these unencrypted keystrokes and printing it out. And this is a uh you know pretty low complexity example of a sniffing attack. And now Matt is going to speak to you about wardriving.
>>K so wardriving is really a nuance on uh on the sniffing attack. Essentially wardriving involves conducting sniffing but while doing so scanning for identifying features of a protocol or device of interest. Optionally we have the ability to actively beacon to attempt to induce traffic from devices that we’re looking for. So the impact here is we’re able to discover and en enumerate exploitable devices or networks that might be present within your physical environment. Uh and wired analogues uh to this is port scanning; you know using NMap to go and knock on doors to see what services uh might be might be present on a system or a network. Uh on the right we have a screenshot from Kismet which is a really popular umm uh really popular wireless um kind of reconnaissance framework that enables uh enables wardriving. Among other things. Uh so some limitations, uh you have the same constraints placed on you that you do with sniffing. Uh additionally you need to manage uh channels if you’re looking for a system that might be on on multiple channels. You might have some uh some front ends to manage in terms of how you you share your time among all- all the different frequencies you could be looking at. Additionally active wardriving can be very easy to spot if you’re defender knows to look for it. Cause you might be hopping from channel to channel, kicking off a beacon on each one uh if if you’re aware of that that’s going to leave a big footprint that you’re going to be able to identify. So a classic example of wardriving is of course your your 802.11 AP discovery. And you know think guys like back in back in the uh you know early 2000s driving around with their laptops and custom made cantennas looking for free wifi. Uh it’s kind of the the classic example. However a more uh modern and IoT focused focused example is uh wardriving for 802.15.4 coordinators. Uh so 802.15.4 wri- war driving I’m going to show you a quick video of it in a minute. Uh for this I used the Killerbee exploitation framework to crash broadcast beacon request messages. And then I used the ApiMote hardware defined radio board to send them out and listen to responses. So what this’ll do is uh it’ll channel hop through all the uh, the 802.15.4 channels in the uh 2.4gigahertz band sending out these requests, and if a coordinator sees- is present and sees that, it’ll respond with a- with a response. We’ll see what that looks like. Do we have the video here?
>>Yeah [inaudible off mic]
>>Ok. I’m not sure if the midi video made the transition with all the uh the AV stuff, so. We’ll get that up online you can watch it afterward. So the next attack is a replay attack and a replay attack is a command injection attack that involves retransmitting a previously captured physical layer frame. Now this can either be a frame that you demodulated and have the uh have the the bits for and then you resynthesize with the with the modulator and send out. Or it can even be as easy as re-transmitting a roth captured physical layer frame, your raw radio information. The impact here uh is command injection. You can change the state of a network or device by getting it to recreate previously observed uh activity. Uh so the wired analogue is exactly the same. You can have replay attacks on wired networks too. So some uh limitations of this is that the replay attack is pretty easily defeated with uh uh using and enforcing freshness, so sequence number or authentication. Having a uh a cryptographic handshake uh to establish the authenticity of the message. Uh so one high profile example of this uh came just a couple couple months ago. Uh you may have seen in the news that uh at around 1:30 in the morning on a Tuesday or Wednesday all 156 uh emergency tornado alert sirens in the Dallas metro- metropolitan area started going off and just playing this really shrill loud noise. It took the authorities about 90 minutes to get it under control and and get those turned off. Uh obviously that inconvenienced people who in Dallas who were woken up by it but it also uh gave people a lot of cause for concern because uh this was right around when some saber rattling with North Korea was happening so it made a lot of people pretty uncomfortable. Uh we at Bastille have done a lot of analysis on on what we believe this is. We’ve concluded that we believe that it’s it’s an RF replay attack. The systems are tested uh I believe it’s quarterly, so it would be trivial for an attacker with a software defined radio to capture that signal and then go back and replay it uh at a later date to induce that behavior. So the logistics of getting an authentic tornado siren uh into Caesar's Palace is a little bit, it’s a little bit much um so instead I have a surrogate uh that I’m gonna show you. I have a Fortress Security Safeguard panic button. Uh so this is gonna be our surrogate. Uh essentially you’ve got this little siren, little remote control to control it. Um it’s a very simple uh on/off key protocol, no freshness or authentication so I’m just gonna grab some raw IQ and then we’re gonna replay it to uh to induce the attack. And um I’m gonna do it in the Faraday cage here we were gonna do our uh our cellular demo in here but I brought it all this way and I wanna use it so bare with me. [inaudible off mic]
>>So now we’re going to capture the output from the transmitter for this device. Then we’re going to replay this and demonstrate that we can set off the siren just from this RF capture. 
>>I had the siren turned off I’m going to turn it on again and we’re going to play the signal into it. 
[Beep] [Siren wailing] Here you go.  [audience applause] You you really shouldn’t clap for that. It’s very easy. [audience laughs] Ok uh so that brings us to our next attack which is jamming. And I’ll pass it over to Marc. 
>>So the concept behind jamming is pretty straightforward. And it’s somewhat analogous to a denial of service attack except a little bit lower complexity. So imagine we have Alice Bob and Carlos trying to communicate on a wireless medium and Donald wants to come and blast a bunch of nonsense noise to prevent them from communicating. In this case Donald would be implementing the jamming attack. And jamming allows you transmit noise to prevent the RF medium from being used by other devices or networks. So you can block traffic or potentially disrupt the network’s state. There are a couple uh you know limitations to jamming attacks one is that a lot of devices implement a jamming detection mechanism where they can see if somebody is trying to jam them and then alter their behavior. The other big downside is that if you’re trying to jam a network you don’t have the ability to both jam and listen to the network at the same time. So if you’re trying to do reconnaissance you can’t prevent traffic as well as receive it. There’s a good uh example of a jamming attack our colleague Logan Lamb discovered 2 years ago, he was looking at home security systems provided by ADT and he discovered that you could actually jam the wireless link between these door and window sensors and the control panel that sets of the alarm. And so in this case the door and window sensor when you open and close it, it will transmit a RF message to the control panel and tell the control panel that the state has changed in this case a door or window has opened or closed and then set off the alarm. What Logan discovered is that you can jam the 345 megahertz channel that these devices operate in and then simply walk into somebodies home and the alarm system will not off. So to demonstrate this we have a video we recorded about an hour ago inside the Faraday cage. 
>>It’s this one?
>>Yeah. So here we have the control panel for this home security system. We’re opening and closing the sensor and we can see that the alarm state has not changed. In this case we’re jamming it so now we go and we stop the jammer and now we’ll be able to actually open and close the sensor and we see that the alarm is triggered. And this is a very very simple attack. So for these simple kind of jamming attacks, uh there are actually uh some different types of smart jamming that we can use to evade these jamming detection mechanisms. So there’s a concept called Duty Cycle jamming. And a lot of hardware defined radios will only try and transmit when other devices are not transmitting on the channel. The reason they do this, if you have 2 devices transmitting at the same time, they will accidentally jam each other. And there’s a feature called clear channel assessment where a hardware defined radio will listen to the energy level in the channel it’s trying to use and if it detects another device it will not transmit. So for example if we have a packet length of 10 milliseconds, the device will say “if the channel is occupied for more than that 10 milliseconds then it’s likely somebodies jamming” and then alter the behavior. So what we can do is pulse our jammer on and off, and we can jam for 9 milliseconds and then turn it off for a millisecond and then turn it back on. And by doing this we can still effectively jam a channel without actually triggering these jam detection mechanisms. And Matt has publicly demonstrated this with an 802.15.4 anti-jam detection evasion. And we also have something called reflexive jamming and this allows you to target specific devices or packets on a wireless network. The way this works is you listen to the packet coming in you could decode the header, then you make a determination based on one of the addresses in the header or the specific packet that's being transmitted, and then you start jamming as soon as you make this determination. And this allows you to jam the end of the packet and for example cause a CRC failure. Uh a good public example of this is Samy Kamkar’s RollJam device which he released. And now there’s a bit of a virtual jamming we can do that takes advantage of a mac layer reservation system and 802.11 networks. So if you’re a 802.11 device and you’re trying to transmit a packet, you include a duration field in the mac header. And this duration field specifies the amount of time you expect it to take for you to transmit your packet and receive it back. Other devices on the network or within range will listen to this duration field and assume that the channel is going to be occupied for this amount of time. They will then turn off their radios to save power instead of sensing the RF energy on the channel. So we can actually take advantage to this by sending a zero payload link 802.11 packet with a duration field set to the maximum and trick other devices for not transmitting for the next 32 milliseconds. This allows us to have a very low duty cycle of transmission but effectively jam a channel. So for a demo here I have a single 1 line Scapy script which I’m going to transmit some of these packets on and we’ll demonstrate that we can prevent another device on a separate network from communicating. So here on the right we have a device a client pingless access point.  I run this Scapy script and on the right we can see that the pings have stopped, I’ve sent 50 packets in this case. Then after a few seconds we’ll see that the pings start again. And this is uh pretty neat because I was able to send only 50 packets and effectively jam the channel for several seconds. Now we have a type of attack called an Evil Twin. And this is something you may have heard of. Uh as you can see by the beard here on the right this is an Evil Twin access point and the concept behind an Evil Twin is that we can convince other devices to connect to our access point or base station instead of the access point or base station they are intending to connect to. And this allows us to man in the middle of the traffic. This is very similar to an ARP spoofing or ARP cache poisoning attack on a wired network. The big limitation here is that there is often trust that exists between the client and access points or base stations. And so in order to effectively implement an Evil Twin attack, we need to either be able to turn off that trust or replicate the state of that cryptography. The Wifi Pineapple is a good off the shelf device that allows you to implement a wifi Evil Twin attack. Their device is called IMSI Catchers which allow you to do the same for cellular networks and convince devices to connect to your malicious base station. So for a demo here we’re going to use a fake base station that we spun up with a software defined radio and use the openBTS software. And I want to point out that it’s very very illegal to try and trick other people's phones to connect with your base stations so please do not do this. And now we’ll show a quick video demo. So here we have a cell phone in the Faraday cage and at the time we started this video I’ve also turned on a cellular base station which is running on a software defined radio in the cage. And right now we can see at the top of the phone that it’s not connected. And as soon as we turn on our fake base station, the phone is searching for the network and it’s starting to register. And then now we have the phone, you can see the change here the phone is now registered on our network and this is something we’ve spun up with open source software on a software defined radio. And now Matt is going to speak to you about malicious over the air firmware updates. 
>>K we’re gonna cover this one quickly. So a malicious over the air firmware update attack involves first modifying a firmware image to suit your liking. Right? This could be adding any value to it that you might want. Uh you then exploit the fact that your target device uh if it has one uh has an over the air firmware update mechanism, where you can use its wireless network to deliver new software to it. So the impact here is you can you can basically extend the device to to conduct behavior that the manufacturer didn’t intend. So this can include remaining persistent on the device, uh you know denial of service is a big one that we saw uh last year um with BrickerBot which is a Mirai variant. You can also be uh self self propagating too, just like a traditional uh your traditional input malware or worms. So uh the limitations here is that this is pretty easily defeated by um by signing your code. Using secure boot or an equivalent technology uh or encrypting your network and doing so well. Uh if you do either of those things you're going to make it a lot harder to execute an attack like this. So there are 2 examples we’re just going to des- describe briefly. Uh the first was uh uh Cesar Cerrudo from IO Active uh his hypothetical um uh traffic light sensor worm. Uh which was an 802.15.4 based system he’s fit uh analyzed it a couple of years ago at BlackCat found that it was uh completely unencrypted and they weren’t signing their images. So it was trivial for him uh to uh make his own and and push it. And he then theorized that you could make it self propagating and, and go from there. Uh such a- an IOT worm was actually demonstrated at the end of last year with a Philips Hue Zigbee Light Link worm. There were a number of researchers that contributed to it, uh they did such a good job with this, I’m just going to direct you to their website um the paper is really good and their video is awesome. They strap a 15.4 radio to a drone and fly it up to a office building and patch the lights. It’s cool. Um so um check that out they do a better job of showing it than we could. So this is our last atte- uh type of attack that we’re gonna highlight in this session. And that’s what we’re gonna call physical layer selective targeting. And I’m just gonna first talk about this so it’s a little bit I think it’s pretty interesting. So when it comes to developing wireless standards, you have your standards body. You know your I triple E um your uh 3GPP they get together and they determine what they want the protocol to look like, and what features they want it to have, uh what the physical layer looks like, how it integrates with other systems et cetera. They then take take those thoughts they turn them into you know a several thousand page document; it’s very technical, lots of details. That document then gets handed off to a chip set manufacturer who has to interpret it. Right? So they take that and they kinda take their best best effort to implement that standard as well as they can. Well as you might imagine, they there are some nuances as to as to to how how accurate or how similar they all do that. So we can exploit that. We can exploit the fact that different chip sets have different radio state machines. So what we can do is we can fingerprint the state machine and then ste- send standards non-compliant transmissions to exploit corner cases within it. And the impact here is we can do things like uh selectively avoid certain targeted receivers. Uh which is useful in the case of avoiding an IDS uh for example. We can also de- do device fingerprinting. We can uh send a number of of frames of different characteristics see what comes back and with that we can figure out what kind of radio chip set is present within our environment. Uh so this has been uh demonstrated on 802 dot 3 ethernet networks uh in the case of avoiding Lan taps, but this is far more practical in the RF domain where the domain is really defined by promiscuity. The fact that you don’t have to be physically connected to a bus in order to get at it uh makes this quite a bit more interesting. So some limitations here, in order for this to work uh your your counting on network participants being on different chip sets. If they are all on the same chip set, they’re gonna be able to see the same type of malformed message. So I’m gonna show you a quick example of an 802.15.4 receiver evasion attack which is pretty interesting. Uh essentially I'm using uh 1 transmitter in ApiMote to craft various, uh variously deformed 15.4 messages and then I’m gonna use 2 different receivers that have different chip sets thereby different state machines to receive that. So I’ll just roll a quick video and talk you through it. So up on top we have our transmitter and then we have 2 15.4 receivers on the bottom. On the left we have an Atmel receiver and on the right we have a TI receiver. 5 compliant messages to get started now I’m gonna insert 2 extra symbols into the header of uh of the 15.4 file. And you’ll see that the RC USB stick receives that but the ApiMote does not. Now I’ll...uh the video is cut short. Umm I’ll release the full video online um by taking 2 symbols out of the header we’re able target the um, we’re able to target the the uh TI radio and avoid the um the Atmel radio. Which brings us to the end. Uh so we’ve looked at a number of different types of attacks uh and we’ve drawn some analogues between them. They key thing that I wanna highlight with this is that some attacks are quite difficult to implement, but some are very hard to mitigate. So anything involving uh RF promiscuity is very hard to avoid just by, by nature of how the RF medium works. The fact that uh that you’re electromagnate- magnetic energy radiates outward means that for a stood off attacker, there are lots they can do with it. It’s very hard to conceal that. Additionally this is a non-exhaustive list. Uh as you start to get into wireless I’m sure you’ll find many other ways of exploiting wireless. Uh we think we’ve done a fairly comprehensive job of boiling down kinda the essence of many of these attacks into a few different categories to kind of get you started. So as attackers, uh the bits of advice I’ll leave you with is to always look for low hanging fruit first. Because the easiest attacks um are are uh you know you want to start with the easy attacks before you go to more complex things because the complexity goes up in a hurry. As we’ve seen there are uh analogous attacks on wired networks so you can lean on your existing skill set wherever possible. Additionally leverage open source intelligence. These are things like FCC regulatory filings and data sheets cause they’ll make your life easy. If you want to learn more about that, Marc gave an entire talk on that at Hack in the Box in 2016, go look that up if you’re curious. And one last note this is both a um, this is both a uh a challenge to everybody in the room and also a warning to developers. Know that we’re living in the golden age of RF hacking. It’s because software defined radio has been commodity for more than 5 years. That really means that every wireless PHY is in scope. Uh obscurity is not relevant any more uh you can buy the tools you can make the tools to expose just about any wireless PHY that you'd like. So uh go forth uh own the airwaves. If you’re an attacker go make them your own. If you’re a defender, be aware of these threats. Uh we have some uh radio resources if you want to learn more about this uh we just tweeted them out. So don’t try to take pictures of the slide, you’ll be able get them online. Uh want to acknowledge our team at Bastille and DEFCON for having us. And uh thanks very much. I appreciate it. [applause]