 Yeah, first thanks everyone for either coming out and waking up this morning or potentially staying out and rolling in this morning. Yeah, like Larry said, we're here to talk about some radio stuff, so let's have fun. So first, a little bit about me, like Larry said, my name's Blake. I'm a consultant on the industrial control system team at Mandient, a FireEye company as the slides will remind you throughout the day. I've been a radio hobbyist for about the last 15 years and have been using radio more and more in my professional life for about the last three to five. I started my career in critical infrastructure security about five years ago working in electric power generation for a company in the US Midwest, Align Energy and more recently spent some time as the security engineer liaison for the information security team at Amazon to our fulfillment transportation and logistics practice where I got to play with all of our phone robots. So today we're going to talk about trends in industrial wireless communication and the exploitation that is possible with the additional tax surface that wireless provides and how you, most importantly, how you can get started understanding the radio frequency environment in the systems that you protect. So first, a bit of background, why radio at all? I think the natural answer to a lot of questions about radio in industrial environments is don't bother. What's the point? You're just opening up additional tax surface. But the reality is that lower per sensor component costs combined with the falling cost of storage decreases the marginal cost of tracking additional points of a process. That combined with cheap access to computational power and increasing availability of analytical tools means that engineers have more and more desire for more and more data. Not just from the process itself, but also sometimes less critical points that weren't worth tracking before. Things like machine performance data for predictive analytics and the IOT, so shots, right? So, but why radio? So engineers are limited by the practical constraints of running additional I.O. Most DCS I.O. cabinets look a little better than that, but there still is just the fact that running an additional cable to every sensor just doesn't scale. Sensor placement is limited when you have to run cables to every drop and with the availability of ultra low power embedded systems and sensors you have the ability to monitor additional points in your process with no additional power or communications cabling sometimes for months or years on end. There's also the field. So wireless communication has always been the backbone of long distance SCADA communications and telecommunications networks. Transporting signals reliably over long distance to very rural areas that are poorly served by traditional ISPs and telecoms has always been the provenance of microwave communications. And fundamentally some systems just move like my old friend the Kiva robot there. Systems like robots, trains, planes, automobiles aren't stationary and need to be reached with critical control traffic wherever they happen to wander. But yeah, fundamentally this isn't the pitch for the Wonderware Expo over in Henderson, so why do we as hackers care about industrial RF? The threat model is fundamentally different than hardwired networks or hardwired I.O. because of physics. It's fundamentally public. No antenna is perfectly unidirectional in practice and many systems are point to multi-point or multi-point to multi-point meshes which necessitate the use of omnidirectional radiating antennas at least in some endpoints. Even those systems that are designed to be constrained within a single facility often leak through the walls and the receivers on those systems may be sensitive enough to pick up signals that are sent from outside. So the types of attacks that end up possible, I really encourage everyone that's here and interested to check out the talk from yesterday, Radio Exploitation 101 that was Matt Knight and Mark Newlin from Bastille. Their slides are already up on the DEFCON Media Share so I'd really, really suggest checking that out. They go into detail about the form of several wireless attacks. Most common, obviously denial service are jamming but this is a very well-known and well-understood reliability issue for wireless systems engineers with decades and decades of research mostly going back to military electronics warfare. So this threat is generally very well understood and accounted for by any system engineer who's considering the use of wireless communications in practice. But protection from other types of attacks, the type that we typically see on IP or IT style networks have traditionally relied over time on protection by obscurity which is everyone's best friend. So things like data injection, malicious device association with networks have typically been dismissed over time as simply not needing treatment due to the lack of skills and a lack of availability of open source equipment to attack wireless implementations. So what changed? So now we're here, that's the background and you're all here because you want to be radio hackers too. Maybe you've even walked through a plant with a USB wireless card running Kizmet before, maybe you've even found some rogue access points that are stuck in an employee's drawer with a power cable drilled through the back of the desk to feed the AP. Things like that. So 802.11 has its benefits in that there's off the shelf hardware purpose built for security assessments even available online. The same applies to Bluetooth and to some extent even RFID. But historically the challenge has been that for every protocol and frequency pair that you want to assess you require either the purchase or the design and fabrication of purpose built hardware. Which is a challenge again for scaling arbitrary security assessments across multiple types of industrial facilities. So that's where we enter SDR. So that's the real heart of the talk today. Software defined radio is a family of applied digital signal processing techniques that leverage high speed analog to digital converters, that's the far right hand of that board. As well as DSP algorithms implemented in FPGA hardware interfaced to a companion CPU as a peripheral. So those are a lot of words but practically what it means is that it frees us from the need to implement specialized hardware for every type of radio system that we want to assess, understand and characterize. So to the left there is a EDS Research USRP B210. That's a software defined radio that covers from 70 megahertz to 6 gigahertz. So quite broad set of frequencies at an instantaneous bandwidth that's really only practically limited by the speed of the USB bus that you attach it to. And to the right I just have a screen shot from GNU radio companion which is the graphical user interface front end GNU radio. And this shows what's kind of become the canonical hello world program of receiving wide band FM or commercial FM broadcast. So the goal today is hopefully with a brief overview we're about to give that you'd be able to get to this hello world type program on your own with limited investment and maybe just an additional couple hours of your time. So to start there's kind of three components I would say to succeeding with a software defined radio project. One is the hardware because there are some hardware requirements. The second is the software which is really where your brain meets the problem. And the third is obviously the knowledge and theory that you have to understand in order to be at least skillful enough with digital single processing to get something done. But the good news is that because of advancements in both open source software and open source hardware this type of work is accessible even to those of us myself we don't have advanced degrees in electrical engineering and the community that supports this type of work is very strong and helpful as I've found over time. So to start with the hardware. So even until relatively recently software defined radios had a serious price constraint. We're talking professional test equipment running in the tens of thousands of dollars to even get started. But the good news is over the last five years primarily due to the reduced RF integrated circuit component cost driven by development of 4G networks primarily the cost has been falling and continues to fall to get started. So the most common way people get started is with an RTL SDR dongle. This is a general term for a family of USB devices based on a real tech integrated circuit chipset. They are receivers only so they're relatively limited with a general range of about 40 MHz to 2 GHz which is great for starting. It gives you enough to do that hello world program that we saw in the last slide. It also provides sufficient coverage of some industrial frequencies for example the unlicensed industrial scientific and medical bands at 430 MHz and 900 MHz in the US. But because they top out somewhere between 1.7 and 2 GHz you lose out on the unlicensed 2.45 GHz ISM and 5 GHz and above licensed and unlicensed space. So enough to get started, enough to learn, enough to get dangerous but once you get the taste you'll probably want to move up to some of these fantastic really hobbyist grade gear. So for about a single order of magnitude increase in price we're talking about between $300 and $400 you can move up to a really full featured and sensitive transceivers. So something that's capable of both receiving signals, decoding them and actually transmitting signals that you synthesize in software. I cover a few here they range between in their RF front ends between several hundred kilohertz up to about 4 GHz. I believe the hack RF will get up to 6 GHz but suffers some performance degradation above 4. They have relatively wide bandwidth, relatively sensitive receivers. So really if you want to toy around reverse engineering, you're garage door opener at home or even doing some simple assessments in your own environments or clients environments it is enough to get started. The industry standard really though for professional grade gear, are the USRP line from Edis Research. I have no affiliation to them. Don't consider this an endorsement but it is what I use for client engagements. Very well regarded in industry. The prices range into the thousands here but low thousands and so if you have a commercial need to actually support repeatable assessments it quickly starts to make sense. These cover like I mentioned I think a slider to before up to 6 GHz out of the box at an incredibly wide instantaneous bandwidth giving you a lot of flexibility for design and synthesis of your protocol decoders. So good times that's the hardware. On to the software. Really the heart of all of this is GNU radio. GNU radio is essentially a set of C libraries for digital signal processing algorithms. But the good news is that it also ships with a very nice GUI front end called GNU radio companion. What GNU radio companion allows you to do is essentially attack the problem as a visual programming language, building out a flow graph that describes the processing of your signal from source to sync. Allowing you to manipulate the data along the way using both its standard library of DSP algorithms as well as a large and growing set of community open source modules. I will have links to all of this. They're currently pushed to my github which I'll have a reference to at the end of the talk. So I'll be able to find all of these later. The next I put up there is actually what's pictured to the right. It's called GQRX. It's also an open source project and its primary use is for exploration of spectra. So this is very helpful for identifying previously unknown signals or confirming your understanding of signals that you believe might exist but aren't sure exactly where they are or what they look like. This is where I start. If I'm on a new engagement at a new facility and it's also helpful for capturing those signals for later offline analysis. This is where having one of the slightly higher end SDRs really pays off because you're limited. The width here that you see on the screen is dictated by the instantaneous bandwidth of the RF front end of the SDR hardware. Simply what that means is that the wider the bandwidth the less tuning around you're going to have to do to find new signals. The more you see at once. So this is where those, you know, definitely moving into that hobbyist grade gear up from the RTL SDR has the biggest dividends during this exploration phase. There are also options for automated scanning across wide set of spectrum. One is called hack RF scan which not surprisingly works with the hack RF and the hack RF only. But if anyone here in the talk has recommendations for me I'd love to hear about other kind of automated scanning tools especially any that implement the UHD hardware API. So come find me or raise your hand during the questions we can talk. The last thing here is in spectrum. I don't have a screenshot. This is a tool for offline analysis of a captured signal. So once you've maybe identified a new signal using GQRX, either one that you didn't expect or don't understand, you can use the recording feature of GQRX to capture a raw IQ sample and open it up and in spectrum. This gives you a similar view to what you're seeing in GQRX but critically what allows you to do is pick out a single signal, add a variable bandwidth from the capture and take derived measurements from it. So like a derived frequency domain plot. What this will allow you to do is start to reason about not just what the signal looks like in something like a waterfall graph but actually the nature of the digital modulation of the signal. So when you're starting to try to understand the signal and build out a new radio flow graph you're going to have to make a critical set of decisions about where to start. And in spectrum gives you the tools to at least reason about and understand the protocol before you start trying to just implement a receiver blindly in the software. Alright so that's a lot and I know if you're not taking vigorous notes you probably don't know exactly where to go from here. And honestly this topic is a little bit more than what you can cover in a half hour talk even to get started. But the good news is that even without a strong electrical engineering background I really believe you can get started in dangerous in about less than a day of reading and studying. If you start with some of the resources that I have up on the slide here. So the first one Michael Ossman who's the designer of the HACRF that was mentioned a few slides ago has a video lecture series on his website openly available. So this is a training that he sells at actually relatively high cost even earlier this week at Black Hat. But he makes at least a large portion of it. I'm not sure if it's the whole thing. Available for free on his website. Great Scott Gadgets. Again link will be in the GitHub. So at this point I think he's up to either eight or nine video lectures. I've watched them all. It's a fantastic introduction to SDR in general, DSP fundamentals and terminology and the HACRF in particular since that's the device that he makes. But realistically the lectures and the exercises in that series can be completed with any SDR including really with an RTL SDR dongle. And even the first three or four lectures are really just on digital signal processing and you can do just after downloading a copy of Canoe Radio without any external hardware to get up to speed with some of the fundamentals. So that is definitely the place I recommend everyone to start. Eight lectures about an hour long a piece and you'll be up and running and quite dangerous in less than a day. The second resource I have here is a blog called Carriers Everywhere. Bastion Blessle is a European radio researcher with a security hobby maybe or security passion. And his blog is where he documents his experience reverse engineering, multiple consumer and industrial protocols. His work has influenced my workflow quite a bit and you'll see some of his open source software projects later on in the slides when we get into 802.15.4. And even his work with mobile traffic light reverse engineering informs the Modbus work. We'll see in a couple minutes as well. The last two on here are textbooks. So if you have a little bit stronger interest and you want to round out your practical skills with some theory. The first one there practical signal processing is actually a very skinny textbook and it's really made for people that are using DSP technology not people implementing DSP technology so it's the perfect level to familiarize yourself with the GNU radio modules that are in the standard library to help make sense of terms like rational resampling which fundamentally means multiplying by a constant and dividing by another one. Not nearly as complicated as it sounds but without some of this guidance it might seem a little maybe too intimidating at first. So definitely a good place to start a couple hundred pages. The last one is a bit thicker. Complete wireless design. It's not DSP specific. It really focuses on the analog sides of radio frequency theory. So again it's a good resource if it's something you'd like to take on a little bit more seriously. So this is a grounding in the fundamentals of oscillators, filters, mixers, radiators, all of the fun analog RF stuff. And when I use this book it's to solve challenges that I run into that have to be addressed in the analog world. Some things simply can't be done in DSP. For example due to limitations of the RF front under your SDR. So an example of when I've used this book as a reference was on a recent engagement when I was asked to assess a signal for an oil and natural gas client that they were running at 11 gigahertz for their microwave backhaul. Well the USRP that I have only goes up to 6 gigahertz so how do I do this? There's really no SDR that covers 11 gigahertz at least not at reasonable prices that I could find. So the answer really is in this book with the design of a RF down converter which again seems intimidating. But once you break it down to its individual system components it's something that I think anyone who's a hardware hobbyist can achieve with a couple weeks effort. So these are all very good very good resources for someone getting started and for someone learning maybe over the course of their first three to six months of really digging into software defined radio. Like I mentioned links to all this on GitHub. Alright so enough background. When you get out into the field where you gonna find? What do industrial signals look like? What are these protocols? Why not just 802.11? What are you gonna find when you get out there? So the first example I brought today is a protocol called wireless heart. Wireless heart is an international standard process automation standard developed initially by the heart foundation and transferred to ISA as ISA standard 100. It's a field communication layer for talking with sensors and actuators in the field so there's layer zero and one devices. It's just a wireless implementation of the heart protocol which has a long history we won't get into. Wireless heart though depends on the 802.15.4 physical layer for transit so that's the same physical layer that's used for ZigBee and other popular home automation devices. So we get lucky here because there's been a lot of security research into home automation protocols that are built on 802.15.4 and ZigBee and now we get to leverage that in our research into the security properties of wireless heart for industrial automation. So a little background it is a mesh protocol where individual sensors can store and forward messages to a network manager which is typically a process manager or controller or gateway. So talking about the way that home automation security research paid dividends here you might see in the top right hand corner my flow block there for wire shark. So to give you a little bit of a walk through here this is the source block that defines the interface to the hardware radio that I have where it defines the center frequency at the 2.41 gigahertz with some offset that I think I had to find up there. This block the 802.15.4 OQ PSK Phi luckily we don't really have to understand what it's doing in order to get what we want. This was implemented by Bastion Blessle whose blog I mentioned earlier but because this open source work has been done we can just kind of ignore it. It's a black magic box. I plumb the lines in, I plumb the lines out and in the top right hand corner I get wire shark and the good news about wire shark is, oh geez, good news about wire shark is we know this all right. We're security researchers, we know wire shark, this is exactly what I want to see. So once we get in to wire shark we can find some critical findings right off the bat just by looking into the 805.4 headers that wire shark will understand out of the box. So if you look up here in the frame control data field the highlighted field as you might imagine the fourth bit from the right there in the frame control security enabled false. So what have I learned already about this wireless heart implementation? Well they're not leveraging the authentication and encryption features that are part of the 802.15.4 standard. But critically wire shark doesn't ship with a wireless heart protocol deceptor out of the box so I'm still left with this kind of mysterious payload in the bottom right hand corner and for all I know maybe they're implementing authentication and encryption further up the stack. But what we find is, well no. Turns out wireless heart does use authentication encryption as far as I can tell in the messages that contain sensor values or control statements. But critically what we've observed is that it does not give that treatment to advertisement messages. So the wireless heart standard is closed. It's a bit pricey to access and unfortunately the license for the one the price that I paid does not allow me to release tools based on it. I'm lobbying internal for us to spend the cash so that we can open source the work that we've done. But we do need to work that out with the heart foundation first. But what you'll see here is the kind of the broken down version of the protocol message on the last slide. And what you learn from looking here is that well malicious actors can't necessarily inject data values. What they can do is join the network as their own nodes by injecting advertisements which potentially congest the link layer of the protocol and can affect network routing because it's a mesh. So yeah if you see that Knight and Newland paper that I mentioned earlier you might get some more ideas about how you could abuse open advertisements. And I encourage you to check out Joe Weiss's talk at this village this afternoon on why you care about vulnerabilities in process sensors and actuators not just the controllers that they interface with. All right last couple minutes. Modbus RTU. These radios are ubiquitous for process control in North America. Everyone knows Modbus TCP is unauthenticated and so is its predecessor Serial Modbus. So what happens when you take the bits from Serial Modbus shove them into a modem and push them out in antenna. Fun and profit. So pictured here two really common modems both are well kind of by GE now. But this tradition extends all the way back to the 70s. You know it's not GE's problem necessarily. To now defunct manufacturers such as Daniels. They use a physical implementation a modulation called AFSK or audio frequency shift keying which is essentially a 180 degree phase shift and audio signal that's then encoded onto or modulated onto narrow band FM. So kind of similar to what you listen to in your car. In the case of the two radios pictured here these are unlicensed 900 megahertz spectrum but you can get them in licensed spectrum as well. The newer ones have encryption as an option but it's generally in my observations not implemented because they'll ship in what's called a compatibility or interoperability mode with no encryption. So we'll see here this gets a little more complicated right and the reason it gets a little more complicated is because this work hasn't been done in the open source literature before so there is no black magic box for me to just pipe signal through. But fundamentally I think again with a few days of research you could actually understand what's going on here mixing down to baseband, resampling to change the sample rate, you have an FM demodulation, clock recovery to match the beats, a squelch and then slice it out to binary and throw it out to a FIFO file sync. So what's that give me? Not perfect. It's cool enough and we can simulate the matrix so I don't even see the code. It's just anyway. Alright so what I'd like to get to next from that is this. So a functioning integration with a software Modbus server or client. So this was actually done offline because of some issues with my implementation of the framing for Modbus which we don't have time to get into the details of today because I'm out of time. But what you can see here is actually Pi Modbus essentially reading and writing coils as a Modbus client and decoding the Modbus server messages on the back end. So the implications here should be clear. These radios are deployed widely in North America for oil and gas pipelines as well as municipal water systems and they are fundamentally just public over the air. Alright so that's my time. I think I'm over by a minute. So I just want to thank Larry especially for dealing with me. The organizers, sponsors and volunteers at the ICS Village and all you guys for coming out and waking up this morning. That's about it. I do just want to mention I'm on the Mandiant team at FireEye industrial control systems we are hiring. So if this is the kind of work that interests you, you want to learn more, come talk to me after. And that's my GitHub that has the links from the talk, my Twitter if you want to continue the conversation that way. So that's it. Thanks so much. And if you guys have questions.