First, thanks everyone for either coming out and waking up this morning or potentially
staying out and rolling in this morning.
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 is Blake.
I'm a consultant on the industrial control system team at Mandiant, 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 U.S. Midwest, Alliant Energy, and more recently
spent some time as the security engineer.
I'm 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 fun robots.
So today we're going to talk about trends in industrial wireless communication and the
exploitation that is possible with the additional attack 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.
You know, what's the point?
You're just opening up additional attack 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-precision I.O.
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. You know,
transporting signals reliably over long distance to very rural areas that are poorly served by
traditional ISPs and telecoms has always been the providence 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.
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 multipoint. And they're
multi point to multipoint 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 data that's available on the
web. The talk from yesterday, radio exploitation 101, that was Matt Knight and Mark Newland from
Bastille. Their slides are already up on the DEF CON 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 of service or jamming. But this is a very well known and well understood reliability issue
for wireless systems engineers. With decades of experience in the field of wireless systems, I've
worked with many of the systems engineers that have been using wireless for 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. So
security, 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 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 Kismet 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 hardware. 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. So that's the real heart of the talk today. Software-defined radio is a family of
BaiM节 algorithms based on the hardware interface to a companion CPU as a peripheral.
So those are a lot of words. But practically what it means, 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 an Etis Research USRP-B210. That's a
software-defined radio that covers from 70 megahertz to 6 gigahertz. That's what these guys do. So they're
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
screenshot 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 the 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 that are not as good as the hardware that you
need. 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
like myself who 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
U.S. companies. It's a general term for a family of U.S.
companies. This is a general term for a family of U.S.
Microsoft devices, 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
megahertz to 2 gigahertz which is great for starting. It gives
you enough to do that hello world program that we saw on the
last slide. It also provides sufficient coverage of some industrial frequencies, for
example, the unlicensed industrial scientific and medical bands at 430 megahertz and 900
megahertz in the U.S. But because they top out somewhere between 1.7 and 2 gigahertz, you
lose out on the unlicensed 2.45 gigahertz ISM and 5 gigahertz 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, you know, fantastic
really hobbyist grade gear. So for about a single order of magnitude increase in price, we're
talking about between three and four hundred dollars, 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, you know,
several hundred kilohertz up to about four gigahertz. I believe the HackRF will get up to
six gigahertz, but suffers some performance degradation above four. And then the other
thing is that they're relatively wide bandwidth, relatively sensitive receivers. So really, if
you want to toy around, you know, reverse engineering your garage door opener at home, or
even doing some simple assessments in your own environments or a client's 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 slide or two before, up to six gigahertz. So, you know, that's kind of the
way it works. So you can get six gigahertz 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 the hardware. So you don't have to go to
an address with very nice gooey front end called GNU radio companion. And what GNU radio
companion allows you to do is essentially attack the problem as a visual programming language,
building out a flow graph that 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 common energía
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 you'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, you're not going to be
able to see them. The width 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 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 definitely moving into that hobbyist grade gear up from the RTL SDR has the
biggest dividends is during this exploration phase. There are also options for automated
scanning across wide sets of spectrum. One is called hack RF scan. Which not surprisingly works
with the hacker F and the hacker F 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 a little bit more about what we're going to talk about today. So
this is in spectrum. I don't have a screen shot. 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 in spectrum. This gives you a similar view to what you're seeing in GQRX.
But critically what it allows you to do is pick out a single signal that you're going to be able to
measure. 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 then 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. All right. 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. So if you're interested,
you can go ahead and 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 Osman, who's the designer of the HackRF 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 the
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, the 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 HackRF 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 GNU 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 apiece, 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 Blesel is a European radio researcher with a security hobby, maybe, or a security
passion. And his blog is where he documents his experience, reverse engineering, and the
use of multiple consumer and industrial protocols. His work has influenced my work flow 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 mod bus
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 skills, 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, reasonable, and
easy to understand, it's basically sampling, 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. And it's really
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. But it's a little bit more complicated than that. It's a little bit more
complicated than that. But it's a little bit more complicated than that. 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 of this on GitHub. All right. So enough background. When you get
out into the field, what are you going to find? What do industrial signals look like? What are
these protocols? Why not just 802.11? What are you going to 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 protocol. It's 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 dash, our
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 Wireshark. So to give you a
little bit of a walkthrough 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 defined up
there. This block, the 802.15.4 OQPSK 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 Blessel, whose blog I
mentioned earlier. But because this opensource block is a very, very important part of the
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 Wireshark. And the good
news about Wireshark is, oh geez, good news about Wireshark is we know this. Right? We're
security researchers. We know Wireshark. This is, you know, this is exactly what I want to see.
So once we get into Wireshark, we can find some critical findings right off the bat just
by looking into the 80154 headers that Wireshark 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 hard implementation? Well, they're not leveraging the
authentication and encryption features that are part of the 802.154 standard. But, you know,
critically, Wireshark doesn't have that. They don't have the authentication and encryption
features. Wireshark 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. It turns out wireless heart does use authentication and encryption as far as I
can tell in the messages that contain sensor values. So, you know, it's a little bit of a
mystery. It's a little bit of a mystery. It's a little bit of a mystery. It's a little bit of a mystery.
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. So, you know, I'm
really excited to see what happens. But what you'll see here is kind of the broken down
version of the protocol message on the last slide. And what you learn from looking here is that
while 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 can 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 and process sensors and
actuators, not just the controllers that they interface with. All right. Last couple of
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 an
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, an audio signal that's then encoded onto or modulated onto narrowband 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. And so,
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 a signal through. But
fundamentally, I think, again, with a few days of research, you could, you know, you could do a
bunch of things here that you don't 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, 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. All right. 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 PyModbus essentially reading and writing coils as a Modbus client. So this is a
modbus server 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. All
right. So that's my time. I think I'm over. I'm in it. 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.