All right, everybody who wants to break and enter, this is definitely the good place to do it.
Well, I mean, try not to break too much.
We need it to run.
That would be great.
Our next speaker is all ready to go.
This is Nick Delusky.
He is the managing consultant and penetration tester with Spirant.
And more importantly, he got approved because this talk just sounded way too much fun.
Who here knew about the SimpliSafe SDR hacks last year-ish?
Yeah, well, he's apparently got the whole thing just worked out in the funniest possible way.
So fail safe, yet another SimpliSafe attack vector because apparently it wasn't bad enough.
So please welcome Nick.
Thank you.
How's it going, everyone?
I'd like to just start off with a thank you to the Wireless Village
for giving me the opportunity to be here today.
I have to say I'm a bit humbled to be right in between two individuals
who design software-defined radios for a living.
So this talk sort of takes a different tack toward the SimpliSafe vulnerabilities
that were discovered before.
We'll get to a little bit of the history in a little bit.
A little bit about me.
My name is Nick Dolesky, you know, for the last name.
There's only one letter that you don't pronounce, which is not bad for a Polish name.
As I said, I'm a managing consultant for Spirant Security Labs.
My specialization is actually in network pen testing.
And I wanted to sort of do this talk to document a little bit about how I went about, you know,
trying to broaden horizons a little bit and go beyond just,
you know, the network pen test, but also taking a look at the general methodology I used
and sort of how I applied that same methodology to learning some new skills.
I have five plus years of pen testing experience.
Prior to that, I have a little over six years of security analysis and systems admin experience.
So with that being said, there's, you know, obviously the obligatory meme slide here.
You know, everybody at home who asks what I do, you know, my friends think that I'm, you know,
from hackers, my family are convinced that I work for three-letter agencies.
TV producers have a laughable concept of what network penetration testers do.
Just random people on the street think that, you know, absolutely everything that you see
on Mr. Robot is real.
Some days I think that.
You know, all I'm doing is collecting shells, but what I actually do is just drink way too much coffee
and do my job.
So a little bit of fair warning.
In my experience, as you can see, I come from a systems administration background.
I was never a developer.
I learned Python through my experience with other scripting languages.
I'm not going to be releasing full or finalized code today for a couple of reasons.
I will, however, be hitting the highlights of, you know, some of the milestones that I had reached
along the way, talking about some of the libraries I used to create the scripts that I used
and talking about the process.
Finally, I'm a sysadmin.
It's ugly code anyway.
I'm sure that if there are developers in the room, you could do it yourself and do it in a way cleaner way
than I did.
So when we're talking about anything...
You know, that has multiple components that interact with one another,
you know, you're still dealing with some form of a network system.
So the user still has to interact with the system.
The system components all still have to interact with one another.
Now, the way...
The mechanisms for this, not necessarily...
They don't look anything like what we're necessarily used to in the traditional client-server model
with, you know, laptops and enterprise applications.
However, we can still look at them mostly in the same way.
Now, when I am trying to reverse engineer a system, I generally start with the techniques that I'm most familiar with.
And that familiarity means that I know, you know, what those techniques are good at
and also where the blind spots are.
And I kind of start with the most familiar so that I know that I can get those out of the way early.
And then I can, you know, use my time wisely and learn more.
more skills along the way and that's honestly my goal with every project or every research
project that I do. So when we are doing reverse engineering essentially we're performing experimentation
over and over again. We're taking stock of what we can infer based on what we know and
we're also taking a look at how can we apply that knowledge to control the system and once
we have a little bit of control we're going to go in a constant loop to see what else
we can learn with that control and reassess and reevaluate.
So there are a lot of different organizations out there that have penetration testing frameworks.
This is one that I kind of go by when I'm dealing with a specific system as I'm trying
to develop an attack or an exploit. I use some different ones when I'm actually, you
know,
dealing with full networks and things like that. But in general you've got four main
phases of it. Open source intelligence, passive recon, active testing and then weaponizing.
So for open source intel we do have a lot of previous research that's already been done
on the simply safe system and I'm going to talk a little bit about that in a few minutes.
I've also got obviously the FCC filings on the device. We've got setup guides. We've
got help forums.
For the passive recon, just in general terms, I like to think of passive recon as something
that I can do that doesn't directly interface or interact or change the environment or at
least not meant to. So you set up the monitor and then you perform regular non-malicious
tasks just looking at seeing the activity and trying to tease out what you can for later
analysis.
Okay. Now when you're ready for active testing you're making controlled changes and looking
for differences. You're observing and comparing responses and then you're sort of building
up some automations to further that process.
Finally, we're coming to weaponizing where we're going to collect and synthesize everything
that we have done over the past three phases. Then we're going to perform our tests where
we're actually testing out our hypotheses about how the system works. We're extending
those tests based on new information or other events that we're in the process of developing.
information that comes in and then we are refining our
knowledge and filling in the gaps that we have. Finally,
we're going to take the tests and the exploits that we've
already mostly written, we're going to automate it to save
time and we're going to optimize it for whatever our
attack scenario is. The final bullet point there, deploy and
exploit, you know, we would do that on a real world penetration
test because this is more of a lab exercise, not so much of a
big deal, not so applicable, so I'd just like to mention it sort
of as a reference. So, taking a look at the system components of
the SimpliSafe system, there are three components that I classify
as user interface components. That is the base station, so this
road cone looking thing up here. There's a keychain remote, well,
the keychain remote, well, the keychain remote, well, the
remnants of it are up here. If anybody wants to see this after
the talk, feel free to come up. And then you have the sensors
that will hopefully send an alarm to the base station for
processing. So, the previous research on this, first research
that I found on it was done by Andrew Zonenberg, I believe
who was with IOactive, sent in February 2016 using a replay attack
by interfacing the SimpliSafe keypad with a microcontroller. So,
sort of taking the SimpliSafe hardware just for the radio circuits
so that there didn't need to be any reverse engineering on that side
of things. And the way I understand it, he was using the packets that
were coming in from that radio hardware, decoding them, and then
replaying and manipulating as necessary. A couple of days later,
Michael Osman, who I believe is actually speaking after me, and I'd
love to get his take on what was found here. So, he exploited the
vulnerability by capturing and decoding packets with SDR and Yardstick
One. That way, you didn't even have to use any SimpliSafe hardware at
all to perform the attacks. So, while that...
that vulnerability and that information was, as far as I have done my
research, well received in the information security community. You know,
if you take a look at some of the user forums and some of the other
feedback, you know, one of the criticisms was that, well, these are
people who are clearly experts in the field. They're on the cutting edge.
You know, would an attacker be able to exploit, you know, these without
advanced degrees in electrical engineering? And, you know, just
philosophically speaking, I think that we as security researchers kind of need
to be on the cutting edge and letting manufacturers know, you know, hey, this
is a problem. So that way, they can design their systems to withstand
conditions that, you know, will occur into the future. So, these days,
kids are being taught in grade school basic programming skills. And those
programming skills are being applied to things like microcontrollers. SDR, I'm
seeing pop up in things like youth library programs. People are learning
about radio. And, you know, it's a great thing. Technology is surrounding us.
And it's not going back the other way. But the fact remains is that the threat
landscape has certainly changed a lot over the years.
The last 10 years. And will continue to change in the future. So, I don't agree with
the assessment that, hey, just because it requires advanced knowledge in the field to be
able to turn, to exploit these attacks, it's not really a flaw. I believe it absolutely is a
flaw. It needs to be fixed. But what I'm going to do in today's talk is demonstrate the
vulnerability which is inherent to the security architecture without requiring either SDR or
hardware modification. I am going to take the SimpliSafe hardware and basically use it against
them. So, one of the components of the system that wasn't directly analyzed in the research that I
found was the keychain remote. Now, the keychain remote goes beyond what you would see for your
car or even, you know, some other home security systems. It actually has a lot of
USB functionality built into it. And what that USB functionality does is it basically presents a
virtual CD-ROM drive to the operating system. And then there's an application user interface on
there that allows the user to make changes to the system. And then it's synchronized back to the
base station by this USB port up here at the top.
So,
that interface is programmed in Shockwave, yeah, Adobe Shockwave. And so, I realized that it might have been a little bit faster to, say, use a Flash decompiler, go that route. But, again, not really a developer, sysadmin, going from things that are quick and easy, working my way down to things that I need to maybe do a little bit more work on.
So,
like you would expect with a keychain remote, it does have the arm and disarm functionality. So, there are a couple of risks when taking a look at this little piece of hardware right here. First thing that came to my mind is loss or theft. So, what happens if somebody gets a hold of this? You know, it's got a full copy of the system's configuration on it. So, when I went through this, I found out that the keychain remote was actually a little bit more expensive than the other ones. And so, I was like, well, that's a little bit more expensive. But, again, not really a developer, sysadmin, going from things that are quick and easy, working my way down to things that I need to maybe do a little bit more work on. So, I realized that it might have been a little bit more expensive. But, again, not really a developer, sysadmin, going from things that I need to maybe do a little bit more work on. So, I realized that it might
be a little bit more expensive. But, again, not really a developer, sysadmin, going from things that are quick and easy, working my way down to things that I need to maybe do a little bit more work on. So, I realized that it might be a little bit more expensive. But, again, not really a developer, sysadmin, going from things that are quick and easy, working my way down to things that I need to maybe do a little bit more work on. So, I realized that it might be a little bit more expensive. But, again, not really a developer, sysadmin, going from things that I need to maybe do a little bit more work on. So, I realized that it might be a little bit more expensive. But, again, not really a developer, sysadmin, going from things that I need to maybe do a little bit more work on. So, I realized that it might be a little bit more expensive. But, again, not really a developer, sysadmin,
nobody will be able to arm or disarm your system, it'll be okay, we'll send you a replacement,
it's all good. But that configuration being on the remote really, really didn't sit well
with me, so I continued to extend and take a look at that component specifically.
So I went out and I bought a SimpliSafe system. I bought one of the basic packages. It comes
with base station, keychain, remote, keypad, four entry sensors, and a motion sensor.
So it's a good cross-section of sensors. It's a reasonable system that you'd expect people to
be able to deploy in a small office, home office environment, or in a normal residential environment.
Doing my open source recon, I did note some interesting things about the FCC filings themselves,
namely that
most
many of the FCC filings go all the way back to November of 2008, so as I said, the threat
landscape has changed significantly in the past ten years, as you would expect it to.
In the defense of SimpliSafe, you know, this hardware is quite a few years old. You know, I think
that the industry as a whole has done a lot of learning since then.
So, kind of following on from that a little bit, I didn't really get too far
into in depth with the internal photos, and looking at the hardware chips and,
you know, looking up individual chips on the devices, because, again, not really my goal.
I wanted to see what we can do with the hardware, this system, as it was on modified.
So, taking a look at tools that I would use to analyze any USB device areエ
I kind of did a little bit of brainstorming here.
We've got ProcMon, which is a former sysinternals tool
before Microsoft bought sysinternals.
Useful for all kinds of operating system level
monitoring of inputs and outputs on the system.
Wireshark has functionality through USBmon.
So that would let me see the traffic
going from the web application interface
back down to the physical device itself.
Python, also always a pen tester's friend,
has a library, PyUSB,
which appears to be a C-types wrapper for libUSB.
Also, you can't forget,
and I do have to credit Google and Stack Exchange
for all of the research that I did on there
as I was trying to learn a little bit more about USB
at a low level and how to interact with it with PyUSB.
I'd like to say,
that you can use your OS of choice here.
Just because I chose to do this research
and development on a Linux box
doesn't mean you couldn't use a Windows box,
doesn't mean you couldn't use a Mac OS device.
The USB keychain remote itself
doesn't actually support Mac OS.
So I think that Windows was the most convenient
for that part of it.
And so I kind of went a hybrid route
between Windows and Linux for it.
eBay.
Again, will become useful for reasons apparent
later on in the talk.
And of course, a little bit of caffeine
on a cold, snowy afternoon.
So taking a look at ProcMon,
which I would figure would be the best place
to look for file activity related to configuration changes,
actually showed lots of activity,
but it didn't show any writes at all.
Not that surprising since there was a CD drive
that was being presented by the USB remote
as you plug it into the system.
So in that regard, that was a good way to confirm
kind of what we're looking for,
but not really useful to us for furthering our access.
After that, what I decided to do
is I decided to take a quick image of the drive
as it was presented to the operating system
using DCF-LDD.
DCF-LDD is basically a,
I don't know if you've heard of DCF-LDD,
but it's basically a very basic
forensic version of the basic DD imaging utility.
So I took a before image
and then I made a couple of changes in the configuration.
I took an after image and then I diffed those images,
did not find any changes at all on them.
So okay, pretty confident nothing is happening
with that presented CD drive.
So after that, I go on to Wireshark
and USBmon.
This is what a typical read access would look like.
And again, I apologize if the text is a little bit small.
What it shows is a SCSI read with an opcode
in the parentheses there of 10.
So again, it's well understood by Wireshark.
It's easily parsed,
not likely to be anything too far out of the ordinary.
What I also found though,
as I was taking a look at the traffic,
was that,
there were some other opcodes
that Wireshark couldn't decode.
And the one interesting one
that I really keyed in on was the opcode F6.
So as I was taking a look at these F6 opcodes,
I did see that the
packet lengths were changing a little bit.
So going through and doing a little bit more analysis,
here's another F6 opcode where a couple of packets down,
you see the URB bulk in,
the length was 576 on that,
as opposed to the previous one,
where the length stayed within the double digits.
Taking a look at that bigger packet,
I start to see some interesting information.
Namely, what I see is I see the ASCII serial numbers
of some of the devices that are in my system.
So, what I have is I have the whole configuration
in that little 576 byte packet,
retrieved and saved in plain text.
As I was taking a look at the packet,
you can see that no authentication methods were used
between the host computer and the keychain,
and the authentication that occurs between the user
and the keychain, where you would ordinarily have to put in
your master pin that you had previously defined
is easily bypassesable,
because in order to check to see if the passcode,
if the pin you put in is correct,
the application which is running on the laptop
needs a copy of the full configuration.
So, the authentication there certainly has some problems.
So, interestingly, I noted that all of the disarmed codes
for the system were in plain text,
and even better than in,
in plain text, they treated the hexadecimal nibbles
as though they were a full character.
So if you took a look at the hex of the packet,
you know, a disarm code of 9999
would actually show up as 9999.
It wasn't even encoded as an integer
where you had to do some decoding
or it wasn't base 64 or anything like that.
So it couldn't get any easier to see the codes.
It contained the serial numbers of all devices on the system
except for the base station.
And that's significant for a couple of reasons
that I'll get into a little bit later.
So the next step is gonna be to break down
the unknown parts of the configuration.
My goal here is to identify as much as I can
about the device types, the different modes and options
for those devices, and also the global settings.
Another key observation is that the configuration
is always a constant.
It's a constant size.
No matter how long the strings are for,
that you put into the UI for the serial numbers
as you're adding new sensors,
the configuration is always a constant 512 bytes.
And that makes diffing a lot easier for us.
We know that we're going one to one.
We don't have to account for changes in address space.
If I make a change, it's gonna change a finite number
of bytes in the configuration.
And so I can tell exactly which bytes
were affected immediately.
It also brings up the prospect of possible buffer overflow
in other parts of the system.
Although that wasn't really what I wanted to go for today,
so I didn't test for it.
Maybe another day.
So this is where we start our analysis
and our making our control changes.
Go through and we make our control changes in the UI.
We compare our data to what we have in the system.
What we previously saw.
And then we just wash, rinse, repeat as much as we can
as fast as we can.
So in order to automate that process a little bit,
because even in a small system like this,
there are quite a few variables in terms of the sensors
and the actual global settings themselves.
I turned to PyUSB.
Python, again, being a fairly robust language.
There's usually libraries out there to do the bulk of what you want to do.
So I wrote a little script to go through
and get all the information that PyUSB can off of a device.
So the device itself is fairly basic.
And in order to start off, you need to know
which device you're actually gonna query.
Simplest way to do that on a Unix command line,
you're gonna do an LS to the USB.
I just happened to redirect that into a file called
USB1.
You plug in the physical key chain remote.
Pipe that output to USB2.
And then a simple diff, USB1, USB2.
Leaves me with the string right there.
So this is just a quick PyUSB script that'll go through.
It will detect if there is a SimpliSafe key chain remote
that is attached to the system.
And it's gonna print everything that it knows
about that device.
If it doesn't find the device, it'll print, well, that's it.
little sad face. So, alright, we know that we can interface with the device as it is
on, on, uh, you know, typical, uh, Unix Linux machine. Um, as noted before in one of the
previous slides, uh, it's a simple device. It only has one configuration, uh, and when
you're talking USB, uh, you kind of have a, uh, uh, hierarchy where at the top level you
have the device, down below that you have the device configuration, below that you have
interfaces, and on an interface you could have, uh, a couple different endpoints. So,
there's only one configuration, uh, there's one interface, and I believe two different
endpoints. Uh, couldn't get much simpler than that. Um, interestingly enough, if
you just start querying some of the other devices that are on your, uh, that are on
your system, uh, or any other random USB gadget you have, um, they will find that
you can find some pretty interesting stuff out about your hardware
you just have sitting around with very little effort.
So here's how we start out.
We actually use PyUSB to connect to the endpoints on the USB drive.
So EPO is the output endpoint.
So that Lambda function there will basically just help PyUSB go through
and query for the first one available.
I believe that you can actually hard code those endpoint numbers as well.
I just happen to use this.
And again, this is code that was borrowed from Stack Exchange,
so it is what it is.
So this one here contains really what's important for the analysis that we're going to be doing.
For the sake of speed and for the sake of...
of being easy, I decided to go the replay attack route
instead of trying to go through and decode those custom opcodes.
I didn't want to risk bricking the device
because that would get expensive eventually.
And also, you know, if you know something works
when you're early in the analysis period,
get what you need to out of it first
and then maybe you can afford to be a little bit more exotic with your attacks.
So I did take the bytes...
from the commands to get the configuration from the USB remote.
I also took the bytes from the request to set the data,
write it back to the remote.
And also, there appears to be a reset packet
that gets sent in order to make sure that, you know,
multiple writes and multiple reads are handled by that interface application.
So I also captured those bytes as well.
Never did get the reset packet,
which is part of the reason why I'm not releasing any code.
So one of those things that I can work on another day.
So you put the blob into the replay
and you set with the EPO.write routine there.
Send the request to get the data.
Then you have to read the data in from the buffer.
What I found is that the timings were sometimes...
a little bit inconsistent when I was trying to access it through PI USB.
So I did write a little try block there,
which will somewhat handle the timeout operations.
And what you get back is you get back the raw config data as a Python list.
So now we're just going through and we're mapping GUI elements
to configuration addresses.
For the globals, what I found is that they put
the global configs in the first part of the packet.
And then you've got the pins, which by the way,
again, it's all the pins plus the duress pin as well.
If somebody were looking to play a really cruel joke,
they could switch the duress pin with the master pin
and bad things would happen.
Again, that's something that really...
emphasizes the need to lock down
all these different interfaces.
You know, it's not just a trivial thing
and actually sort of, you kind of wonder
why the functionality was built into the remote
in the first place, given that somebody's gonna carry
this around everywhere, you could easily lose it.
Personally, I think that this information
would have been better handled by providing an application
that generates the configuration, puts it on a USB stick,
and that way, you know that configuration
is on that USB stick, you can lock it away,
you can keep it wherever you want,
you don't need to carry it around all the time
in order to use why the device was built,
which is as a remote control.
So, after going through all of the different
configuration settings in the GUI,
which include things like alarm volume,
whether or not there are any lights
that are activated at any point,
the alarm
signal duration, so that's the amount of time
that you have to get to the keypad and put in the pin
before the alarm goes off.
It also includes things like whether the voice chime
is on, whether the chime functionality is on,
which dings when, you know, a sensor is activated.
So, all that stuff is now mapped out.
In addition, the different sensors have an option block,
which do different things depending on the sensor as well.
So,
for an entry sensor, you could have a configuration
where the sensor is only active
when the alarm is armed in away mode,
which, for those not familiar with home alarm systems,
generally they can be armed in home away or home at home.
That way you're not,
you're disabling certain sensors
while you're still in your house,
so that way you're not tripping your system
every time you want to go down to the basement,
or every time, you know,
your dog runs by the motion sensor.
So, a little while later, after I go through with,
you know, some automation, some scripting
to identify the addresses, what goes where,
we have a little bit of a better idea
of what serial numbers are matched to which device.
I spat out the data as a Smasky config,
just kind of for reference,
and to, you know, give a little bit of scale
on how big that, you know, scale is going to be.
So, that configuration actually is,
as you can see, I was able to easily parse out the volume,
whether the door chime was active,
and, you know, all the different pins
broken out by number and function.
So, now that we have a significant amount of information
about how the system actually works,
we're gonna ask ourselves,
what in total do we know about the system at this point?
So, we know that adding sensors to the system
only requires a serial number
based on what we've seen from the GUI.
In addition, we know that communications
are susceptible to replay attacks
from the previous work that was done
by Andrew Zonenberg and Michael Osman.
So, what's our hypothesis here?
So, a sensor doesn't likely authenticate the base station
because it's just broadcasting simple packets
out to anybody who will listen.
So, the sensor types and numbers
are contained in the configuration data,
and a sensor is configurable in a separate base station,
a hypothesis here, rather,
is that the sensor can be configured
in a separate base station based on a config
that's stolen from a USB stick.
Also, it's noted in the documentation
that the sensor range is about 100 feet
from the base station,
and given that sensors are often placed
on the perimeter of a protected area,
on the windows, the doors,
it's pretty likely that there's gonna be a lot of noise,
there's gonna be over-penetration out to public areas
or areas that you're not really able
to physically control so much.
So, taking our three sub-hypotheses,
the hypothetical attack that we're gonna work on
is that a stock base station can be configured
with sensor values from a stolen configuration,
and then an arbitrary malicious base station
can receive and interpret those sensor signals.
What's the next step?
It's gonna be to source another base station
and test out our hypothesis.
So, for that, I turned to eBay.
I didn't feel like dropping another couple hundred dollars
on another full system from retail.
I found that I was actually able to obtain
a separate base station with keychain remote
from eBay for about 70 bucks, I think.
So, forgive the electrical tape here.
This is so I don't actually confuse which one was the victim
and which one was the malicious base station.
So, once I obtained that second system,
I was able to configure both systems so that,
alternately, so that they would chime
when one of the entry sensors was tripped.
I started off with the sensor configured just in one,
not the other, set the chime, confirmed,
yeah, I heard the tone.
Then I configured it in both and I set off the sensor
and confirmed it.
That confirmed that I heard the chime
out of both base stations.
So, yes, that confirms our hypothesis.
The sensors are just doing a very basic broadcast out
and any base station in the area can listen to that sensor
and interpret it and integrate it into its own operations.
So, now we're gonna take that hypothesis,
we're gonna extend it and we're gonna refine it even more.
So, what else do we know about the system?
We know that the base station can be configured to read,
data from arbitrary sensors now that we've done that test.
We also know from the documentation
that online monitoring is an optional add-on.
So, what we're gonna do now is we're gonna test to see
if a physically planted device has usable remote
connectivity to pretty much anywhere in the world
via the base station's built-in 2G connection.
We also know that the system will send monitoring alerts.
So, we should be able to build up a pretty robust picture
of how that system is used over time.
So, being a pen tester, this is something that we do
when there is a physical aspect to our engagements.
I'm not gonna go through the details
of how I would go through and what I'd be looking for,
trends in terms of building usage
and things of that nature.
But, you know,
if someone were so inclined
or if this were a penetration test engagement,
you know, we absolutely could do a lot of analysis
and trending and things like that
to determine when, for example,
the house or the protected area would be most likely
unoccupied or other attack scenarios.
So, our next step is to provision online monitoring
for the malicious base station to receive these alerts.
When the sensors are triggered.
So, I set up, I had access to a friendly multi-tenant office,
I'm sorry, an office in a multi-tenant office building.
So, I was able to set up the original retail bot
simply safe system as it would be deployed
in a normal small office sort of environment.
As I did that, I also put the malicious base station down,
in my vehicle in the parking lot.
And what I found was that
I was able to receive alerts that were delivered to me
by email about the comings and goings in that office
even though the base station itself
was on a different physical level.
It was on a parking lot that was outside of the building.
It wasn't even right next to the actual office.
So it was a significant distance away.
I didn't get all of the sensors, which one would expect.
One would hope that the sensor wouldn't penetrate
all the way out that way, but certainly enough
to give me an idea of when the office was occupied.
So now that we know that we have a hypothetical attack
that works, what are we gonna do to automate that attack
and really make it usable in a real world scenario?
So one thing you can do to automate the attack
is to run the data capture script as a service
in the background on your machine.
So that way really the only limiting factor
in the time it takes to do the attack
is the time to undo the cap on the remote
and plug it into a USB port.
Mere seconds.
You can either save that configuration off to a file.
You can Bluetooth it off to another location.
Any means of exfiltration at that point is completely valid.
And what else can we do to optimize it
for a particular attack scenario?
So when you are thinking about these USB keys,
there are a couple of different scenarios that pop to mind.
Lost and stolen is obviously one aspect.
But it doesn't even necessarily have to be fully lost.
I was going for a run at the gym one day
and I just happened to see one of these
sitting on the little key hanger things
that are outside the front of the building.
Why someone would put their keys on one of those
in the first place, being a security professional,
again, is beyond me, but there are people that do it.
And so it got me thinking, you know,
well, people do actually give their keys to people
for short periods of time.
Whether it's a valet or a mechanic
or again, on one of those little boards,
a lot of times people will leave their keys
in the break room at work.
And they might not even necessarily know
that somebody was able to pick up their keys.
I know a number of years ago,
there was, I guess, an interesting talk
about somebody who managed to replicate
a physical key with a 3D printer,
just by taking a picture of it.
So this would kind of be the equivalent of that.
You can actually run the script easily,
very, very easily, on a Raspberry Pi Zero.
And again, for those that might not be familiar
with the Pi Zero, it is a very, very small board,
which is actually about the same size as the key chain.
It's about the same size as the key chain itself.
You can wire that up to a very inexpensive USB power supply.
You can oftentimes get them as swag at conventions
or they're given out for free,
just for promotional material.
So for the cost of five bucks for a Pi Zero,
an extra flash card you have sitting around,
USB OTG cable.
You know, you could have an easily concealable,
a method of actually collecting this data.
So I did actually reach out to SimpliSafe
when I found this vulnerability
to do some coordinated disclosure.
So they had actually been in contact with me
for a couple of months,
and they had released a security advisory today.
It's available as a blog post
up on SimpliSafe's website there,
just provided for anybody who wants to check that out.
Now, I'll tell you a little bit more about this.
I'll tell you a little bit more about this.
I'll tell you a little bit more about this.
Obviously, you know, I think that, you know,
their recommendations, you know,
and my recommendations can disagree a little bit.
Reasonable minds can disagree.
So I'm told that there's actually going to be
a utility that they came out with
that's going to help mitigate this problem as well,
where customers can actually wipe the configuration
off of their keychain remote
while they're not making changes.
So it would work like this.
Basically, you would want to make changes to your system,
you would take your keychain remote,
you would plug it into the base station,
it would write the configuration data to the keychain,
you'd plug it into the system, to the laptop,
make your changes, and then you'd re-sync it
to the base station, and then you'd run this utility
on the laptop again that would reset the data,
wipe it off the keychain.
You know, absolutely, for having hardware
that was first envisioned and deployed almost 10 years ago,
I think that that's a novel way
of mitigating the risk personally.
I think that a lot of users might not want
to go through that trouble.
I think that a lot of users might forget to do that.
I think that having something out there
and acknowledging that, hey, yeah,
there is a configuration on here,
and you do need to take into consideration
more than just your base station,
is a good step.
SimpliSafe also did modify some of their guidance
to say, hey, if you lose a remote,
you should reset your pins just in case.
I recommend not using the USB-enabled remote
just in case you forget to wipe it.
Also, I would recommend if the USB-enabled remote is lost,
you know, obviously, you can change it,
change the pins immediately.
But really, there's no known remedy
to reinitialize the compromised sensor serial numbers.
So, that kind of makes you think about whether or not,
you know, you have to think about
your own risk profile, basically.
A small business is gonna be a different risk profile
to somebody who's using this to protect their home.
So, it might be a good idea to supplement additional security measures.
Things like web cameras that utilize different technologies,
say, Wi-Fi or wired connections,
or additional locks that might also have
notification capabilities as well.
So, again, you know, yeah,
we're pointing out a vulnerability.
It's going to be up to the individual
to determine whether or not this vulnerability
really affects their use case.
Finally, I'd just like to mention,
it's a good idea always to restrict
physical access to the base station.
It's one of the things where, you know,
if you do a little bit of Googling about SimpliSafe,
there are some other YouTube attacks out there
that you can find on YouTube.
I haven't tested them myself.
I'm not gonna vouch for whether or not they actually are real.
But just to be on the safe side,
it is a good idea to just sort of keep this
in a physically safe spot if you can,
if you're gonna continue to use the system.
So, what I've found about the system
is that the vulnerabilities that are inherent
to the architecture of the system
are exploitable in three different ways.
You can use hardware hacking,
you can use SDR and signals analysis,
or you can use the native device
and abuse of the features that are already
built into the system.
When you have a secure product
and when you are going through
and you're inspecting your designs,
you're going through and you're inspecting your designs,
you're doing risk analysis,
it doesn't really matter what the tools are
used to attack it.
It's a strong architecture.
Saying that, you know,
well, it's not really a valid attack
because they used one skill
or they used one particular tool
becomes an irrelevant point
because you're actually getting to meet the problem,
you're fixing the root cause.
So, is the system still useful and effective?
And as I said before,
that really depends on
the individual.
So, an individual who, you know,
is looking at high-risk human threat actors,
so somebody that has a reason
to have a home security system,
and it's an unfortunate reality
that people out there, you know,
have stalkers, they have PFAs against people,
they know that there are threats that have been made,
things of that nature.
I'm not sure that I would recommend this system.
I'm not sure that I would recommend this system
to somebody who knows that there is a high risk
of something happening,
needing to alert the police quickly.
Low and medium risk human threat actors,
I'd say that depends on, you know,
more of the use case of, you know,
are you looking to protect property?
Are you looking to supplement additional controls?
It might still be effective
on defending against normal smash and grab type burglaries.
It might be, you know,
still useful in deterring
there being an incident in the first place.
However, it's kind of hard to measure a negative.
How do you measure something that doesn't happen?
And then there also is the environmental monitoring piece,
the environmental threat actors.
There's no intelligence.
There's no active circumvention of carbon monoxide detector,
you know, smoke detectors and water detectors.
There's no intelligence.
That's not really my area of expertise.
I would leave it to somebody like Underwriters Labs
to test those components.
You know, they know really what the key variables are
and making sure that those systems are effective.
So on a high level, what I would say
the most apparent vulnerability in the architecture itself
is the lack of two-way authentication.
sensor that is broadcasting out to anybody who will listen, and you have a system that
will accept that data without proving integrity or identity, that's really a system that's
not able to do some very key things from an information security perspective. You don't
have confidentiality, you don't have data integrity, and you don't have data authenticity.
When you're building a system like this, you would expect it to have some confidentiality,
you'd expect it to have integrity checks, you'd expect it to have authentication checks.
So two-way authentication, I think, would be the goal for manufacturers of alarm systems,
making sure that you can't just do simple replays, simple spoofs, things of that nature
to get around and cause problems.
Whether it's a two-way authentication or a two-way authentication, you can't just do simple replays, simple spoofs, things of that nature to get around and cause problems, whether it's a two-way authentication,
it be false positives or false negatives. Does anybody have any questions? All right. Well,
thank you very much for coming to the talk today. If you're interested in reaching out,
there's a couple of different ways you can get a hold of me. I am on LinkedIn. I'm not on Twitter,
although my company is. So you can go to Twitter handle at Spirant Security.
Security. You can reach out to me directly at Nick.Dolesky at Spirant.com. You can reach out
to the whole group at SecurityLabs at Spirant.com. And for anything that's more of an enthusiast or
other sort of email, you can reach out to me. Believe it or not, this actually is a valid email
address down there. So did I see a hand over here? And by the way, we do have a couple of shirts. So
if you have some questions, feel free to come up.
Did you find any attributes in the configuration that were very specific to that particular setup
that you had? Can you speak into the microphone? Yeah. Did you find any attributes in your
configuration that were specific to that particular setup? So. Are you unique to that
setup? I'm not. I'm not. I'm not. I'm not. I'm not. I'm not. I'm not.
So a lot of the attributes that I found were pretty common among the other home security systems
I've looked at. You know, it was a pretty bare-bones configuration. But it is a fairly
straightforward embedded system. It's not. No. No. I mean, were most of the parameters very
generic? Or were they particular to that particular setup to recognize each other sensor-wise?
Oh, they were fairly generic. Very generic. Everything was easily
set up with just entering the serial number in the config. So you didn't really have to have a whole lot of
customization. Were you referring to the testing setup or the actual alarm setup?
The actual alarm setup. The actual alarm setup. No. Everything is fairly generic.
Oh, yeah? You know, what I would say is that it wouldn't be interoperable with other systems,
but it's not really a complex system. Okay. Yeah. Thank you. Other questions?
So I gave a TORCON talk in 2015 where I used an MC catcher to basically analyze the communication
between the base station and the actual, like, remote monitoring side. Okay. And it just sends
unencrypted UDP packets. And then on their back end, it's using the base station serial number and
the keypad or sensor serial number to actually trigger those alerts. So did you find anything that
would let you...
Get the base station serial number from the USB keypad? Or anything else?
No. No, I did not. And I think that that would be a key differentiator. And again, the base station
serial number would have been a completely different story if you could find that on the device. No, it
is not on the device configuration. All right. Cool. Are there questions?
All right. Thank you very much, everybody. I appreciate your time.