1
00:00:00,000 --> 00:00:04,580
All right, everybody who wants to break and enter, this is definitely the good place to do it.

2
00:00:05,580 --> 00:00:07,460
Well, I mean, try not to break too much.

3
00:00:07,840 --> 00:00:08,920
We need it to run.

4
00:00:09,100 --> 00:00:09,900
That would be great.

5
00:00:10,840 --> 00:00:13,180
Our next speaker is all ready to go.

6
00:00:13,360 --> 00:00:15,280
This is Nick Delusky.

7
00:00:15,520 --> 00:00:19,900
He is the managing consultant and penetration tester with Spirant.

8
00:00:21,160 --> 00:00:26,460
And more importantly, he got approved because this talk just sounded way too much fun.

9
00:00:26,460 --> 00:00:32,440
Who here knew about the SimpliSafe SDR hacks last year-ish?

10
00:00:32,740 --> 00:00:37,180
Yeah, well, he's apparently got the whole thing just worked out in the funniest possible way.

11
00:00:37,380 --> 00:00:42,640
So fail safe, yet another SimpliSafe attack vector because apparently it wasn't bad enough.

12
00:00:42,880 --> 00:00:44,400
So please welcome Nick.

13
00:00:44,480 --> 00:00:44,840
Thank you.

14
00:00:48,980 --> 00:00:50,340
How's it going, everyone?

15
00:00:51,260 --> 00:00:54,800
I'd like to just start off with a thank you to the Wireless Village

16
00:00:54,800 --> 00:00:56,440
for giving me the opportunity to be here today.

17
00:00:56,460 --> 00:01:03,880
I have to say I'm a bit humbled to be right in between two individuals

18
00:01:03,880 --> 00:01:08,260
who design software-defined radios for a living.

19
00:01:10,120 --> 00:01:19,100
So this talk sort of takes a different tack toward the SimpliSafe vulnerabilities

20
00:01:19,100 --> 00:01:20,440
that were discovered before.

21
00:01:21,080 --> 00:01:23,340
We'll get to a little bit of the history in a little bit.

22
00:01:23,820 --> 00:01:25,420
A little bit about me.

23
00:01:26,460 --> 00:01:29,340
My name is Nick Dolesky, you know, for the last name.

24
00:01:29,620 --> 00:01:33,300
There's only one letter that you don't pronounce, which is not bad for a Polish name.

25
00:01:35,260 --> 00:01:39,560
As I said, I'm a managing consultant for Spirant Security Labs.

26
00:01:40,920 --> 00:01:43,860
My specialization is actually in network pen testing.

27
00:01:44,260 --> 00:01:51,280
And I wanted to sort of do this talk to document a little bit about how I went about, you know,

28
00:01:51,300 --> 00:01:56,280
trying to broaden horizons a little bit and go beyond just,

29
00:01:56,460 --> 00:02:00,880
you know, the network pen test, but also taking a look at the general methodology I used

30
00:02:00,880 --> 00:02:05,540
and sort of how I applied that same methodology to learning some new skills.

31
00:02:06,220 --> 00:02:09,120
I have five plus years of pen testing experience.

32
00:02:09,580 --> 00:02:16,980
Prior to that, I have a little over six years of security analysis and systems admin experience.

33
00:02:17,280 --> 00:02:25,180
So with that being said, there's, you know, obviously the obligatory meme slide here.

34
00:02:25,180 --> 00:02:32,800
You know, everybody at home who asks what I do, you know, my friends think that I'm, you know,

35
00:02:32,800 --> 00:02:36,820
from hackers, my family are convinced that I work for three-letter agencies.

36
00:02:37,200 --> 00:02:43,140
TV producers have a laughable concept of what network penetration testers do.

37
00:02:44,000 --> 00:02:50,860
Just random people on the street think that, you know, absolutely everything that you see

38
00:02:50,860 --> 00:02:52,560
on Mr. Robot is real.

39
00:02:53,680 --> 00:02:55,160
Some days I think that.

40
00:02:55,180 --> 00:03:00,980
You know, all I'm doing is collecting shells, but what I actually do is just drink way too much coffee

41
00:03:00,980 --> 00:03:02,820
and do my job.

42
00:03:04,100 --> 00:03:05,640
So a little bit of fair warning.

43
00:03:05,940 --> 00:03:10,620
In my experience, as you can see, I come from a systems administration background.

44
00:03:11,040 --> 00:03:12,500
I was never a developer.

45
00:03:12,720 --> 00:03:17,300
I learned Python through my experience with other scripting languages.

46
00:03:17,880 --> 00:03:24,260
I'm not going to be releasing full or finalized code today for a couple of reasons.

47
00:03:25,180 --> 00:03:31,840
I will, however, be hitting the highlights of, you know, some of the milestones that I had reached

48
00:03:31,840 --> 00:03:38,400
along the way, talking about some of the libraries I used to create the scripts that I used

49
00:03:38,400 --> 00:03:40,700
and talking about the process.

50
00:03:42,060 --> 00:03:43,640
Finally, I'm a sysadmin.

51
00:03:43,820 --> 00:03:44,920
It's ugly code anyway.

52
00:03:45,120 --> 00:03:50,880
I'm sure that if there are developers in the room, you could do it yourself and do it in a way cleaner way

53
00:03:50,880 --> 00:03:51,360
than I did.

54
00:03:52,780 --> 00:03:54,860
So when we're talking about anything...

55
00:03:55,180 --> 00:03:58,340
You know, that has multiple components that interact with one another,

56
00:03:58,580 --> 00:04:01,440
you know, you're still dealing with some form of a network system.

57
00:04:01,840 --> 00:04:04,880
So the user still has to interact with the system.

58
00:04:05,160 --> 00:04:08,800
The system components all still have to interact with one another.

59
00:04:09,120 --> 00:04:10,860
Now, the way...

60
00:04:10,860 --> 00:04:13,780
The mechanisms for this, not necessarily...

61
00:04:14,820 --> 00:04:20,520
They don't look anything like what we're necessarily used to in the traditional client-server model

62
00:04:20,520 --> 00:04:24,520
with, you know, laptops and enterprise applications.

63
00:04:25,320 --> 00:04:28,580
However, we can still look at them mostly in the same way.

64
00:04:29,120 --> 00:04:35,700
Now, when I am trying to reverse engineer a system, I generally start with the techniques that I'm most familiar with.

65
00:04:36,460 --> 00:04:41,520
And that familiarity means that I know, you know, what those techniques are good at

66
00:04:41,520 --> 00:04:43,140
and also where the blind spots are.

67
00:04:43,420 --> 00:04:49,860
And I kind of start with the most familiar so that I know that I can get those out of the way early.

68
00:04:50,120 --> 00:04:54,040
And then I can, you know, use my time wisely and learn more.

69
00:04:55,180 --> 00:05:01,840
more skills along the way and that's honestly my goal with every project or every research

70
00:05:02,840 --> 00:05:10,720
project that I do. So when we are doing reverse engineering essentially we're performing experimentation

71
00:05:12,260 --> 00:05:18,300
over and over again. We're taking stock of what we can infer based on what we know and

72
00:05:18,300 --> 00:05:25,160
we're also taking a look at how can we apply that knowledge to control the system and once

73
00:05:25,160 --> 00:05:31,060
we have a little bit of control we're going to go in a constant loop to see what else

74
00:05:31,060 --> 00:05:36,020
we can learn with that control and reassess and reevaluate.

75
00:05:38,160 --> 00:05:42,780
So there are a lot of different organizations out there that have penetration testing frameworks.

76
00:05:43,380 --> 00:05:50,000
This is one that I kind of go by when I'm dealing with a specific system as I'm trying

77
00:05:50,000 --> 00:05:54,780
to develop an attack or an exploit. I use some different ones when I'm actually, you

78
00:05:54,780 --> 00:05:54,940
know,

79
00:05:55,160 --> 00:06:01,060
dealing with full networks and things like that. But in general you've got four main

80
00:06:02,700 --> 00:06:08,320
phases of it. Open source intelligence, passive recon, active testing and then weaponizing.

81
00:06:09,340 --> 00:06:15,580
So for open source intel we do have a lot of previous research that's already been done

82
00:06:15,580 --> 00:06:19,780
on the simply safe system and I'm going to talk a little bit about that in a few minutes.

83
00:06:20,240 --> 00:06:25,100
I've also got obviously the FCC filings on the device. We've got setup guides. We've

84
00:06:25,100 --> 00:06:25,720
got help forums.

85
00:06:27,300 --> 00:06:33,460
For the passive recon, just in general terms, I like to think of passive recon as something

86
00:06:33,460 --> 00:06:39,480
that I can do that doesn't directly interface or interact or change the environment or at

87
00:06:39,480 --> 00:06:47,720
least not meant to. So you set up the monitor and then you perform regular non-malicious

88
00:06:47,720 --> 00:06:54,040
tasks just looking at seeing the activity and trying to tease out what you can for later

89
00:06:54,040 --> 00:06:54,580
analysis.

90
00:06:55,100 --> 00:06:59,560
Okay. Now when you're ready for active testing you're making controlled changes and looking

91
00:06:59,560 --> 00:07:03,680
for differences. You're observing and comparing responses and then you're sort of building

92
00:07:03,680 --> 00:07:07,300
up some automations to further that process.

93
00:07:08,260 --> 00:07:12,140
Finally, we're coming to weaponizing where we're going to collect and synthesize everything

94
00:07:12,140 --> 00:07:17,820
that we have done over the past three phases. Then we're going to perform our tests where

95
00:07:17,820 --> 00:07:22,920
we're actually testing out our hypotheses about how the system works. We're extending

96
00:07:23,460 --> 00:07:25,080
those tests based on new information or other events that we're in the process of developing.

97
00:07:25,080 --> 00:07:28,220
information that comes in and then we are refining our

98
00:07:28,220 --> 00:07:31,160
knowledge and filling in the gaps that we have. Finally,

99
00:07:31,400 --> 00:07:37,360
we're going to take the tests and the exploits that we've

100
00:07:37,360 --> 00:07:40,640
already mostly written, we're going to automate it to save

101
00:07:40,640 --> 00:07:44,760
time and we're going to optimize it for whatever our

102
00:07:44,760 --> 00:07:51,480
attack scenario is. The final bullet point there, deploy and

103
00:07:51,480 --> 00:07:54,540
exploit, you know, we would do that on a real world penetration

104
00:07:54,540 --> 00:07:59,340
test because this is more of a lab exercise, not so much of a

105
00:07:59,340 --> 00:08:03,740
big deal, not so applicable, so I'd just like to mention it sort

106
00:08:03,740 --> 00:08:08,260
of as a reference. So, taking a look at the system components of

107
00:08:08,260 --> 00:08:12,300
the SimpliSafe system, there are three components that I classify

108
00:08:12,300 --> 00:08:18,900
as user interface components. That is the base station, so this

109
00:08:19,740 --> 00:08:24,000
road cone looking thing up here. There's a keychain remote, well,

110
00:08:24,140 --> 00:08:24,520
the keychain remote, well, the keychain remote, well, the

111
00:08:24,540 --> 00:08:28,360
remnants of it are up here. If anybody wants to see this after

112
00:08:28,360 --> 00:08:34,020
the talk, feel free to come up. And then you have the sensors

113
00:08:34,020 --> 00:08:40,000
that will hopefully send an alarm to the base station for

114
00:08:40,000 --> 00:08:50,320
processing. So, the previous research on this, first research

115
00:08:50,320 --> 00:08:54,460
that I found on it was done by Andrew Zonenberg, I believe

116
00:08:54,540 --> 00:09:00,820
who was with IOactive, sent in February 2016 using a replay attack

117
00:09:01,280 --> 00:09:06,880
by interfacing the SimpliSafe keypad with a microcontroller. So,

118
00:09:06,980 --> 00:09:11,700
sort of taking the SimpliSafe hardware just for the radio circuits

119
00:09:12,500 --> 00:09:15,560
so that there didn't need to be any reverse engineering on that side

120
00:09:15,560 --> 00:09:20,100
of things. And the way I understand it, he was using the packets that

121
00:09:20,100 --> 00:09:23,700
were coming in from that radio hardware, decoding them, and then

122
00:09:24,680 --> 00:09:28,440
replaying and manipulating as necessary. A couple of days later,

123
00:09:28,500 --> 00:09:34,640
Michael Osman, who I believe is actually speaking after me, and I'd

124
00:09:34,640 --> 00:09:39,960
love to get his take on what was found here. So, he exploited the

125
00:09:39,960 --> 00:09:43,620
vulnerability by capturing and decoding packets with SDR and Yardstick

126
00:09:43,620 --> 00:09:48,060
One. That way, you didn't even have to use any SimpliSafe hardware at

127
00:09:48,060 --> 00:09:53,820
all to perform the attacks. So, while that...

128
00:09:53,820 --> 00:10:00,600
that vulnerability and that information was, as far as I have done my

129
00:10:00,600 --> 00:10:05,020
research, well received in the information security community. You know,

130
00:10:05,020 --> 00:10:07,980
if you take a look at some of the user forums and some of the other

131
00:10:07,980 --> 00:10:13,140
feedback, you know, one of the criticisms was that, well, these are

132
00:10:13,500 --> 00:10:16,540
people who are clearly experts in the field. They're on the cutting edge.

133
00:10:16,720 --> 00:10:23,380
You know, would an attacker be able to exploit, you know, these without

134
00:10:23,380 --> 00:10:28,880
advanced degrees in electrical engineering? And, you know, just

135
00:10:28,880 --> 00:10:36,220
philosophically speaking, I think that we as security researchers kind of need

136
00:10:36,220 --> 00:10:40,540
to be on the cutting edge and letting manufacturers know, you know, hey, this

137
00:10:40,540 --> 00:10:44,160
is a problem. So that way, they can design their systems to withstand

138
00:10:45,160 --> 00:10:51,720
conditions that, you know, will occur into the future. So, these days,

139
00:10:53,740 --> 00:10:59,060
kids are being taught in grade school basic programming skills. And those

140
00:10:59,060 --> 00:11:03,760
programming skills are being applied to things like microcontrollers. SDR, I'm

141
00:11:03,760 --> 00:11:08,020
seeing pop up in things like youth library programs. People are learning

142
00:11:08,020 --> 00:11:13,640
about radio. And, you know, it's a great thing. Technology is surrounding us.

143
00:11:13,760 --> 00:11:19,940
And it's not going back the other way. But the fact remains is that the threat

144
00:11:19,940 --> 00:11:23,360
landscape has certainly changed a lot over the years.

145
00:11:23,380 --> 00:11:28,220
The last 10 years. And will continue to change in the future. So, I don't agree with

146
00:11:28,220 --> 00:11:33,220
the assessment that, hey, just because it requires advanced knowledge in the field to be

147
00:11:33,220 --> 00:11:38,940
able to turn, to exploit these attacks, it's not really a flaw. I believe it absolutely is a

148
00:11:38,940 --> 00:11:45,140
flaw. It needs to be fixed. But what I'm going to do in today's talk is demonstrate the

149
00:11:46,000 --> 00:11:53,180
vulnerability which is inherent to the security architecture without requiring either SDR or

150
00:11:53,380 --> 00:11:59,660
hardware modification. I am going to take the SimpliSafe hardware and basically use it against

151
00:11:59,660 --> 00:12:10,680
them. So, one of the components of the system that wasn't directly analyzed in the research that I

152
00:12:10,680 --> 00:12:17,180
found was the keychain remote. Now, the keychain remote goes beyond what you would see for your

153
00:12:17,180 --> 00:12:23,360
car or even, you know, some other home security systems. It actually has a lot of

154
00:12:23,380 --> 00:12:32,500
USB functionality built into it. And what that USB functionality does is it basically presents a

155
00:12:33,320 --> 00:12:38,400
virtual CD-ROM drive to the operating system. And then there's an application user interface on

156
00:12:38,400 --> 00:12:48,140
there that allows the user to make changes to the system. And then it's synchronized back to the

157
00:12:48,140 --> 00:12:51,760
base station by this USB port up here at the top.

158
00:12:52,500 --> 00:12:52,860
So,

159
00:12:54,460 --> 00:13:22,560
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.

160
00:13:22,860 --> 00:13:23,360
So,

161
00:13:23,380 --> 00:13:53,360
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

162
00:14:07,500 --> 00:14:22,680
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,

163
00:14:22,680 --> 00:14:27,340
nobody will be able to arm or disarm your system, it'll be okay, we'll send you a replacement,

164
00:14:27,980 --> 00:14:35,800
it's all good. But that configuration being on the remote really, really didn't sit well

165
00:14:35,800 --> 00:14:41,840
with me, so I continued to extend and take a look at that component specifically.

166
00:14:45,640 --> 00:14:51,480
So I went out and I bought a SimpliSafe system. I bought one of the basic packages. It comes

167
00:14:51,480 --> 00:14:56,780
with base station, keychain, remote, keypad, four entry sensors, and a motion sensor.

168
00:14:57,120 --> 00:15:04,800
So it's a good cross-section of sensors. It's a reasonable system that you'd expect people to

169
00:15:04,800 --> 00:15:10,900
be able to deploy in a small office, home office environment, or in a normal residential environment.

170
00:15:12,040 --> 00:15:18,680
Doing my open source recon, I did note some interesting things about the FCC filings themselves,

171
00:15:19,360 --> 00:15:20,520
namely that

172
00:15:20,520 --> 00:15:21,000
most

173
00:15:21,480 --> 00:15:29,060
many of the FCC filings go all the way back to November of 2008, so as I said, the threat

174
00:15:29,060 --> 00:15:33,940
landscape has changed significantly in the past ten years, as you would expect it to.

175
00:15:35,540 --> 00:15:45,780
In the defense of SimpliSafe, you know, this hardware is quite a few years old. You know, I think

176
00:15:45,780 --> 00:15:49,160
that the industry as a whole has done a lot of learning since then.

177
00:15:51,780 --> 00:15:57,100
So, kind of following on from that a little bit, I didn't really get too far

178
00:15:57,100 --> 00:16:02,500
into in depth with the internal photos, and looking at the hardware chips and,

179
00:16:03,120 --> 00:16:08,400
you know, looking up individual chips on the devices, because, again, not really my goal.

180
00:16:08,980 --> 00:16:13,880
I wanted to see what we can do with the hardware, this system, as it was on modified.

181
00:16:14,460 --> 00:16:19,140
So, taking a look at tools that I would use to analyze any USB device areエ

182
00:16:19,140 --> 00:16:20,720
I kind of did a little bit of brainstorming here.

183
00:16:20,880 --> 00:16:24,960
We've got ProcMon, which is a former sysinternals tool

184
00:16:24,960 --> 00:16:26,860
before Microsoft bought sysinternals.

185
00:16:27,700 --> 00:16:31,740
Useful for all kinds of operating system level

186
00:16:31,740 --> 00:16:34,620
monitoring of inputs and outputs on the system.

187
00:16:35,340 --> 00:16:38,020
Wireshark has functionality through USBmon.

188
00:16:39,080 --> 00:16:41,200
So that would let me see the traffic

189
00:16:41,200 --> 00:16:46,280
going from the web application interface

190
00:16:46,280 --> 00:16:48,840
back down to the physical device itself.

191
00:16:49,980 --> 00:16:53,160
Python, also always a pen tester's friend,

192
00:16:53,860 --> 00:16:55,920
has a library, PyUSB,

193
00:16:56,060 --> 00:17:00,700
which appears to be a C-types wrapper for libUSB.

194
00:17:01,620 --> 00:17:02,800
Also, you can't forget,

195
00:17:03,000 --> 00:17:05,540
and I do have to credit Google and Stack Exchange

196
00:17:05,540 --> 00:17:10,100
for all of the research that I did on there

197
00:17:10,100 --> 00:17:13,200
as I was trying to learn a little bit more about USB

198
00:17:13,200 --> 00:17:17,180
at a low level and how to interact with it with PyUSB.

199
00:17:18,240 --> 00:17:19,120
I'd like to say,

200
00:17:19,120 --> 00:17:20,880
that you can use your OS of choice here.

201
00:17:21,200 --> 00:17:24,140
Just because I chose to do this research

202
00:17:24,140 --> 00:17:25,740
and development on a Linux box

203
00:17:25,740 --> 00:17:27,840
doesn't mean you couldn't use a Windows box,

204
00:17:28,020 --> 00:17:31,660
doesn't mean you couldn't use a Mac OS device.

205
00:17:32,300 --> 00:17:34,360
The USB keychain remote itself

206
00:17:34,360 --> 00:17:36,040
doesn't actually support Mac OS.

207
00:17:37,080 --> 00:17:41,080
So I think that Windows was the most convenient

208
00:17:41,080 --> 00:17:41,980
for that part of it.

209
00:17:42,220 --> 00:17:45,380
And so I kind of went a hybrid route

210
00:17:45,380 --> 00:17:47,240
between Windows and Linux for it.

211
00:17:47,980 --> 00:17:48,500
eBay.

212
00:17:49,120 --> 00:17:53,800
Again, will become useful for reasons apparent

213
00:17:53,800 --> 00:17:54,720
later on in the talk.

214
00:17:55,260 --> 00:17:57,760
And of course, a little bit of caffeine

215
00:17:57,760 --> 00:17:58,920
on a cold, snowy afternoon.

216
00:18:00,380 --> 00:18:02,020
So taking a look at ProcMon,

217
00:18:02,140 --> 00:18:04,460
which I would figure would be the best place

218
00:18:04,460 --> 00:18:08,360
to look for file activity related to configuration changes,

219
00:18:10,700 --> 00:18:12,300
actually showed lots of activity,

220
00:18:12,500 --> 00:18:14,040
but it didn't show any writes at all.

221
00:18:14,980 --> 00:18:18,620
Not that surprising since there was a CD drive

222
00:18:18,620 --> 00:18:23,080
that was being presented by the USB remote

223
00:18:23,080 --> 00:18:25,640
as you plug it into the system.

224
00:18:26,240 --> 00:18:30,040
So in that regard, that was a good way to confirm

225
00:18:30,040 --> 00:18:31,200
kind of what we're looking for,

226
00:18:31,340 --> 00:18:36,440
but not really useful to us for furthering our access.

227
00:18:36,940 --> 00:18:38,800
After that, what I decided to do

228
00:18:38,800 --> 00:18:41,980
is I decided to take a quick image of the drive

229
00:18:41,980 --> 00:18:43,860
as it was presented to the operating system

230
00:18:43,860 --> 00:18:45,760
using DCF-LDD.

231
00:18:46,420 --> 00:18:48,260
DCF-LDD is basically a,

232
00:18:48,620 --> 00:18:49,180
I don't know if you've heard of DCF-LDD,

233
00:18:49,180 --> 00:18:49,700
but it's basically a very basic

234
00:18:49,700 --> 00:18:53,820
forensic version of the basic DD imaging utility.

235
00:18:55,080 --> 00:18:58,060
So I took a before image

236
00:18:58,060 --> 00:19:00,960
and then I made a couple of changes in the configuration.

237
00:19:01,260 --> 00:19:04,480
I took an after image and then I diffed those images,

238
00:19:04,740 --> 00:19:07,300
did not find any changes at all on them.

239
00:19:07,400 --> 00:19:09,860
So okay, pretty confident nothing is happening

240
00:19:09,860 --> 00:19:11,600
with that presented CD drive.

241
00:19:12,560 --> 00:19:14,940
So after that, I go on to Wireshark

242
00:19:14,940 --> 00:19:16,360
and USBmon.

243
00:19:18,620 --> 00:19:21,500
This is what a typical read access would look like.

244
00:19:21,600 --> 00:19:25,020
And again, I apologize if the text is a little bit small.

245
00:19:25,820 --> 00:19:29,800
What it shows is a SCSI read with an opcode

246
00:19:29,800 --> 00:19:32,900
in the parentheses there of 10.

247
00:19:33,320 --> 00:19:36,920
So again, it's well understood by Wireshark.

248
00:19:37,060 --> 00:19:38,140
It's easily parsed,

249
00:19:38,160 --> 00:19:42,360
not likely to be anything too far out of the ordinary.

250
00:19:43,600 --> 00:19:45,680
What I also found though,

251
00:19:45,720 --> 00:19:47,380
as I was taking a look at the traffic,

252
00:19:47,580 --> 00:19:48,600
was that,

253
00:19:48,620 --> 00:19:50,280
there were some other opcodes

254
00:19:50,280 --> 00:19:52,380
that Wireshark couldn't decode.

255
00:19:52,640 --> 00:19:54,960
And the one interesting one

256
00:19:56,070 --> 00:19:59,420
that I really keyed in on was the opcode F6.

257
00:20:01,070 --> 00:20:05,340
So as I was taking a look at these F6 opcodes,

258
00:20:05,830 --> 00:20:07,460
I did see that the

259
00:20:10,050 --> 00:20:12,380
packet lengths were changing a little bit.

260
00:20:13,050 --> 00:20:18,020
So going through and doing a little bit more analysis,

261
00:20:18,020 --> 00:20:23,740
here's another F6 opcode where a couple of packets down,

262
00:20:23,840 --> 00:20:25,280
you see the URB bulk in,

263
00:20:25,480 --> 00:20:29,120
the length was 576 on that,

264
00:20:29,240 --> 00:20:30,740
as opposed to the previous one,

265
00:20:30,920 --> 00:20:33,700
where the length stayed within the double digits.

266
00:20:35,020 --> 00:20:36,680
Taking a look at that bigger packet,

267
00:20:37,270 --> 00:20:39,980
I start to see some interesting information.

268
00:20:40,900 --> 00:20:45,040
Namely, what I see is I see the ASCII serial numbers

269
00:20:45,470 --> 00:20:47,500
of some of the devices that are in my system.

270
00:20:50,760 --> 00:20:53,780
So, what I have is I have the whole configuration

271
00:20:54,040 --> 00:20:57,140
in that little 576 byte packet,

272
00:20:58,200 --> 00:20:59,960
retrieved and saved in plain text.

273
00:21:00,880 --> 00:21:02,420
As I was taking a look at the packet,

274
00:21:03,020 --> 00:21:07,880
you can see that no authentication methods were used

275
00:21:07,880 --> 00:21:09,420
between the host computer and the keychain,

276
00:21:09,660 --> 00:21:14,920
and the authentication that occurs between the user

277
00:21:14,920 --> 00:21:17,800
and the keychain, where you would ordinarily have to put in

278
00:21:17,800 --> 00:21:20,280
your master pin that you had previously defined

279
00:21:20,920 --> 00:21:22,680
is easily bypassesable,

280
00:21:22,760 --> 00:21:25,200
because in order to check to see if the passcode,

281
00:21:25,260 --> 00:21:26,540
if the pin you put in is correct,

282
00:21:27,680 --> 00:21:30,920
the application which is running on the laptop

283
00:21:30,920 --> 00:21:32,900
needs a copy of the full configuration.

284
00:21:34,260 --> 00:21:38,240
So, the authentication there certainly has some problems.

285
00:21:38,780 --> 00:21:43,020
So, interestingly, I noted that all of the disarmed codes

286
00:21:43,020 --> 00:21:45,900
for the system were in plain text,

287
00:21:46,080 --> 00:21:47,520
and even better than in,

288
00:21:47,520 --> 00:21:53,780
in plain text, they treated the hexadecimal nibbles

289
00:21:53,780 --> 00:21:55,680
as though they were a full character.

290
00:21:56,000 --> 00:21:58,960
So if you took a look at the hex of the packet,

291
00:21:59,980 --> 00:22:02,240
you know, a disarm code of 9999

292
00:22:02,240 --> 00:22:04,640
would actually show up as 9999.

293
00:22:05,260 --> 00:22:07,100
It wasn't even encoded as an integer

294
00:22:07,100 --> 00:22:09,200
where you had to do some decoding

295
00:22:09,200 --> 00:22:13,520
or it wasn't base 64 or anything like that.

296
00:22:13,780 --> 00:22:16,080
So it couldn't get any easier to see the codes.

297
00:22:17,520 --> 00:22:19,620
It contained the serial numbers of all devices on the system

298
00:22:19,620 --> 00:22:20,880
except for the base station.

299
00:22:21,280 --> 00:22:24,900
And that's significant for a couple of reasons

300
00:22:24,900 --> 00:22:26,200
that I'll get into a little bit later.

301
00:22:27,640 --> 00:22:31,960
So the next step is gonna be to break down

302
00:22:31,960 --> 00:22:33,780
the unknown parts of the configuration.

303
00:22:34,320 --> 00:22:36,900
My goal here is to identify as much as I can

304
00:22:36,900 --> 00:22:40,480
about the device types, the different modes and options

305
00:22:40,480 --> 00:22:43,520
for those devices, and also the global settings.

306
00:22:43,960 --> 00:22:46,160
Another key observation is that the configuration

307
00:22:46,160 --> 00:22:47,460
is always a constant.

308
00:22:47,520 --> 00:22:47,840
It's a constant size.

309
00:22:48,160 --> 00:22:53,100
No matter how long the strings are for,

310
00:22:53,640 --> 00:22:58,000
that you put into the UI for the serial numbers

311
00:22:58,000 --> 00:22:59,140
as you're adding new sensors,

312
00:22:59,500 --> 00:23:03,580
the configuration is always a constant 512 bytes.

313
00:23:04,200 --> 00:23:06,720
And that makes diffing a lot easier for us.

314
00:23:06,920 --> 00:23:09,460
We know that we're going one to one.

315
00:23:09,580 --> 00:23:13,040
We don't have to account for changes in address space.

316
00:23:13,380 --> 00:23:16,580
If I make a change, it's gonna change a finite number

317
00:23:16,580 --> 00:23:17,500
of bytes in the configuration.

318
00:23:17,500 --> 00:23:21,400
And so I can tell exactly which bytes

319
00:23:21,400 --> 00:23:22,740
were affected immediately.

320
00:23:24,140 --> 00:23:28,260
It also brings up the prospect of possible buffer overflow

321
00:23:28,540 --> 00:23:29,980
in other parts of the system.

322
00:23:30,300 --> 00:23:33,040
Although that wasn't really what I wanted to go for today,

323
00:23:33,200 --> 00:23:34,420
so I didn't test for it.

324
00:23:34,880 --> 00:23:35,780
Maybe another day.

325
00:23:36,360 --> 00:23:39,140
So this is where we start our analysis

326
00:23:39,140 --> 00:23:40,740
and our making our control changes.

327
00:23:41,120 --> 00:23:44,400
Go through and we make our control changes in the UI.

328
00:23:44,980 --> 00:23:47,480
We compare our data to what we have in the system.

329
00:23:47,480 --> 00:23:48,560
What we previously saw.

330
00:23:48,760 --> 00:23:51,760
And then we just wash, rinse, repeat as much as we can

331
00:23:51,760 --> 00:23:52,540
as fast as we can.

332
00:23:53,900 --> 00:23:56,660
So in order to automate that process a little bit,

333
00:23:56,820 --> 00:23:59,640
because even in a small system like this,

334
00:23:59,740 --> 00:24:03,800
there are quite a few variables in terms of the sensors

335
00:24:03,800 --> 00:24:06,160
and the actual global settings themselves.

336
00:24:07,540 --> 00:24:09,220
I turned to PyUSB.

337
00:24:10,160 --> 00:24:13,380
Python, again, being a fairly robust language.

338
00:24:13,600 --> 00:24:17,460
There's usually libraries out there to do the bulk of what you want to do.

339
00:24:17,460 --> 00:24:22,060
So I wrote a little script to go through

340
00:24:22,060 --> 00:24:27,220
and get all the information that PyUSB can off of a device.

341
00:24:29,640 --> 00:24:33,180
So the device itself is fairly basic.

342
00:24:34,660 --> 00:24:37,560
And in order to start off, you need to know

343
00:24:37,560 --> 00:24:39,060
which device you're actually gonna query.

344
00:24:39,740 --> 00:24:42,280
Simplest way to do that on a Unix command line,

345
00:24:43,020 --> 00:24:44,920
you're gonna do an LS to the USB.

346
00:24:45,220 --> 00:24:47,400
I just happened to redirect that into a file called

347
00:24:47,460 --> 00:24:48,140
USB1.

348
00:24:48,240 --> 00:24:50,280
You plug in the physical key chain remote.

349
00:24:51,940 --> 00:24:53,760
Pipe that output to USB2.

350
00:24:53,840 --> 00:24:55,980
And then a simple diff, USB1, USB2.

351
00:24:56,420 --> 00:24:58,700
Leaves me with the string right there.

352
00:25:02,580 --> 00:25:06,440
So this is just a quick PyUSB script that'll go through.

353
00:25:06,700 --> 00:25:10,340
It will detect if there is a SimpliSafe key chain remote

354
00:25:10,340 --> 00:25:12,480
that is attached to the system.

355
00:25:12,680 --> 00:25:14,440
And it's gonna print everything that it knows

356
00:25:14,440 --> 00:25:15,200
about that device.

357
00:25:15,500 --> 00:25:17,440
If it doesn't find the device, it'll print, well, that's it.

358
00:25:17,440 --> 00:25:25,500
little sad face. So, alright, we know that we can interface with the device as it is

359
00:25:25,500 --> 00:25:31,960
on, on, uh, you know, typical, uh, Unix Linux machine. Um, as noted before in one of the

360
00:25:31,960 --> 00:25:37,080
previous slides, uh, it's a simple device. It only has one configuration, uh, and when

361
00:25:37,080 --> 00:25:42,960
you're talking USB, uh, you kind of have a, uh, uh, hierarchy where at the top level you

362
00:25:42,960 --> 00:25:47,500
have the device, down below that you have the device configuration, below that you have

363
00:25:47,500 --> 00:25:52,440
interfaces, and on an interface you could have, uh, a couple different endpoints. So,

364
00:25:53,180 --> 00:25:58,620
there's only one configuration, uh, there's one interface, and I believe two different

365
00:25:58,620 --> 00:26:03,900
endpoints. Uh, couldn't get much simpler than that. Um, interestingly enough, if

366
00:26:03,900 --> 00:26:09,020
you just start querying some of the other devices that are on your, uh, that are on

367
00:26:09,020 --> 00:26:12,940
your system, uh, or any other random USB gadget you have, um, they will find that

368
00:26:12,940 --> 00:26:17,380
you can find some pretty interesting stuff out about your hardware

369
00:26:17,380 --> 00:26:19,360
you just have sitting around with very little effort.

370
00:26:20,560 --> 00:26:22,300
So here's how we start out.

371
00:26:22,400 --> 00:26:27,860
We actually use PyUSB to connect to the endpoints on the USB drive.

372
00:26:28,320 --> 00:26:31,220
So EPO is the output endpoint.

373
00:26:32,160 --> 00:26:37,360
So that Lambda function there will basically just help PyUSB go through

374
00:26:37,360 --> 00:26:38,860
and query for the first one available.

375
00:26:38,860 --> 00:26:45,540
I believe that you can actually hard code those endpoint numbers as well.

376
00:26:45,900 --> 00:26:47,340
I just happen to use this.

377
00:26:47,540 --> 00:26:51,580
And again, this is code that was borrowed from Stack Exchange,

378
00:26:51,880 --> 00:26:54,380
so it is what it is.

379
00:26:57,540 --> 00:27:03,300
So this one here contains really what's important for the analysis that we're going to be doing.

380
00:27:05,860 --> 00:27:08,460
For the sake of speed and for the sake of...

381
00:27:08,860 --> 00:27:11,980
of being easy, I decided to go the replay attack route

382
00:27:11,980 --> 00:27:17,220
instead of trying to go through and decode those custom opcodes.

383
00:27:17,560 --> 00:27:19,840
I didn't want to risk bricking the device

384
00:27:19,840 --> 00:27:22,160
because that would get expensive eventually.

385
00:27:23,040 --> 00:27:25,320
And also, you know, if you know something works

386
00:27:25,320 --> 00:27:27,340
when you're early in the analysis period,

387
00:27:27,660 --> 00:27:29,480
get what you need to out of it first

388
00:27:29,480 --> 00:27:33,220
and then maybe you can afford to be a little bit more exotic with your attacks.

389
00:27:34,520 --> 00:27:38,840
So I did take the bytes...

390
00:27:38,860 --> 00:27:44,400
from the commands to get the configuration from the USB remote.

391
00:27:44,640 --> 00:27:48,380
I also took the bytes from the request to set the data,

392
00:27:48,460 --> 00:27:49,500
write it back to the remote.

393
00:27:50,060 --> 00:27:52,880
And also, there appears to be a reset packet

394
00:27:53,960 --> 00:27:57,860
that gets sent in order to make sure that, you know,

395
00:27:57,880 --> 00:28:01,840
multiple writes and multiple reads are handled by that interface application.

396
00:28:03,780 --> 00:28:06,440
So I also captured those bytes as well.

397
00:28:07,040 --> 00:28:08,780
Never did get the reset packet,

398
00:28:08,780 --> 00:28:11,460
which is part of the reason why I'm not releasing any code.

399
00:28:13,960 --> 00:28:17,720
So one of those things that I can work on another day.

400
00:28:18,060 --> 00:28:21,500
So you put the blob into the replay

401
00:28:21,500 --> 00:28:28,160
and you set with the EPO.write routine there.

402
00:28:29,620 --> 00:28:31,180
Send the request to get the data.

403
00:28:31,340 --> 00:28:33,520
Then you have to read the data in from the buffer.

404
00:28:34,340 --> 00:28:37,620
What I found is that the timings were sometimes...

405
00:28:38,780 --> 00:28:42,340
a little bit inconsistent when I was trying to access it through PI USB.

406
00:28:42,680 --> 00:28:46,920
So I did write a little try block there,

407
00:28:47,080 --> 00:28:52,000
which will somewhat handle the timeout operations.

408
00:28:53,750 --> 00:28:57,720
And what you get back is you get back the raw config data as a Python list.

409
00:28:59,700 --> 00:29:03,000
So now we're just going through and we're mapping GUI elements

410
00:29:03,000 --> 00:29:04,260
to configuration addresses.

411
00:29:05,020 --> 00:29:08,280
For the globals, what I found is that they put

412
00:29:08,280 --> 00:29:13,700
the global configs in the first part of the packet.

413
00:29:13,880 --> 00:29:17,420
And then you've got the pins, which by the way,

414
00:29:17,420 --> 00:29:20,820
again, it's all the pins plus the duress pin as well.

415
00:29:21,470 --> 00:29:25,780
If somebody were looking to play a really cruel joke,

416
00:29:26,380 --> 00:29:31,400
they could switch the duress pin with the master pin

417
00:29:31,400 --> 00:29:33,480
and bad things would happen.

418
00:29:34,020 --> 00:29:37,080
Again, that's something that really...

419
00:29:38,280 --> 00:29:40,040
emphasizes the need to lock down

420
00:29:40,040 --> 00:29:41,500
all these different interfaces.

421
00:29:42,500 --> 00:29:45,740
You know, it's not just a trivial thing

422
00:29:45,740 --> 00:29:48,560
and actually sort of, you kind of wonder

423
00:29:48,560 --> 00:29:51,680
why the functionality was built into the remote

424
00:29:51,680 --> 00:29:54,240
in the first place, given that somebody's gonna carry

425
00:29:54,240 --> 00:29:56,660
this around everywhere, you could easily lose it.

426
00:29:57,120 --> 00:29:58,960
Personally, I think that this information

427
00:29:58,960 --> 00:30:02,360
would have been better handled by providing an application

428
00:30:02,360 --> 00:30:06,540
that generates the configuration, puts it on a USB stick,

429
00:30:06,540 --> 00:30:09,020
and that way, you know that configuration

430
00:30:09,020 --> 00:30:11,320
is on that USB stick, you can lock it away,

431
00:30:11,480 --> 00:30:12,480
you can keep it wherever you want,

432
00:30:12,540 --> 00:30:13,960
you don't need to carry it around all the time

433
00:30:13,960 --> 00:30:17,560
in order to use why the device was built,

434
00:30:17,680 --> 00:30:18,680
which is as a remote control.

435
00:30:19,580 --> 00:30:22,480
So, after going through all of the different

436
00:30:23,920 --> 00:30:25,740
configuration settings in the GUI,

437
00:30:25,780 --> 00:30:28,900
which include things like alarm volume,

438
00:30:29,600 --> 00:30:31,840
whether or not there are any lights

439
00:30:31,840 --> 00:30:33,940
that are activated at any point,

440
00:30:35,000 --> 00:30:35,800
the alarm

441
00:30:36,860 --> 00:30:39,080
signal duration, so that's the amount of time

442
00:30:39,080 --> 00:30:42,060
that you have to get to the keypad and put in the pin

443
00:30:42,060 --> 00:30:44,020
before the alarm goes off.

444
00:30:45,700 --> 00:30:48,860
It also includes things like whether the voice chime

445
00:30:48,860 --> 00:30:51,140
is on, whether the chime functionality is on,

446
00:30:51,240 --> 00:30:55,380
which dings when, you know, a sensor is activated.

447
00:30:55,820 --> 00:30:57,880
So, all that stuff is now mapped out.

448
00:30:58,140 --> 00:31:01,600
In addition, the different sensors have an option block,

449
00:31:01,900 --> 00:31:04,500
which do different things depending on the sensor as well.

450
00:31:05,400 --> 00:31:05,880
So,

451
00:31:06,540 --> 00:31:09,880
for an entry sensor, you could have a configuration

452
00:31:09,880 --> 00:31:12,760
where the sensor is only active

453
00:31:13,900 --> 00:31:17,940
when the alarm is armed in away mode,

454
00:31:18,140 --> 00:31:20,540
which, for those not familiar with home alarm systems,

455
00:31:20,820 --> 00:31:24,760
generally they can be armed in home away or home at home.

456
00:31:25,000 --> 00:31:26,060
That way you're not,

457
00:31:27,740 --> 00:31:29,520
you're disabling certain sensors

458
00:31:29,520 --> 00:31:31,060
while you're still in your house,

459
00:31:31,120 --> 00:31:33,140
so that way you're not tripping your system

460
00:31:33,140 --> 00:31:34,640
every time you want to go down to the basement,

461
00:31:34,860 --> 00:31:36,140
or every time, you know,

462
00:31:36,140 --> 00:31:38,220
your dog runs by the motion sensor.

463
00:31:39,360 --> 00:31:44,500
So, a little while later, after I go through with,

464
00:31:44,600 --> 00:31:46,660
you know, some automation, some scripting

465
00:31:46,660 --> 00:31:49,060
to identify the addresses, what goes where,

466
00:31:50,080 --> 00:31:52,020
we have a little bit of a better idea

467
00:31:52,020 --> 00:31:55,880
of what serial numbers are matched to which device.

468
00:31:56,400 --> 00:31:59,600
I spat out the data as a Smasky config,

469
00:32:00,180 --> 00:32:01,680
just kind of for reference,

470
00:32:01,820 --> 00:32:05,020
and to, you know, give a little bit of scale

471
00:32:05,020 --> 00:32:06,120
on how big that, you know, scale is going to be.

472
00:32:06,120 --> 00:32:08,100
So, that configuration actually is,

473
00:32:08,240 --> 00:32:11,120
as you can see, I was able to easily parse out the volume,

474
00:32:12,060 --> 00:32:13,600
whether the door chime was active,

475
00:32:14,660 --> 00:32:16,640
and, you know, all the different pins

476
00:32:16,640 --> 00:32:18,900
broken out by number and function.

477
00:32:20,460 --> 00:32:22,600
So, now that we have a significant amount of information

478
00:32:22,600 --> 00:32:24,240
about how the system actually works,

479
00:32:24,620 --> 00:32:25,720
we're gonna ask ourselves,

480
00:32:25,960 --> 00:32:28,620
what in total do we know about the system at this point?

481
00:32:28,920 --> 00:32:31,420
So, we know that adding sensors to the system

482
00:32:31,420 --> 00:32:32,700
only requires a serial number

483
00:32:32,700 --> 00:32:35,580
based on what we've seen from the GUI.

484
00:32:36,260 --> 00:32:38,240
In addition, we know that communications

485
00:32:38,240 --> 00:32:39,880
are susceptible to replay attacks

486
00:32:39,880 --> 00:32:41,580
from the previous work that was done

487
00:32:41,580 --> 00:32:46,460
by Andrew Zonenberg and Michael Osman.

488
00:32:46,760 --> 00:32:48,840
So, what's our hypothesis here?

489
00:32:49,540 --> 00:32:52,200
So, a sensor doesn't likely authenticate the base station

490
00:32:52,200 --> 00:32:55,220
because it's just broadcasting simple packets

491
00:32:55,810 --> 00:32:57,140
out to anybody who will listen.

492
00:32:57,540 --> 00:32:59,660
So, the sensor types and numbers

493
00:32:59,660 --> 00:33:01,160
are contained in the configuration data,

494
00:33:01,710 --> 00:33:06,100
and a sensor is configurable in a separate base station,

495
00:33:06,100 --> 00:33:09,040
a hypothesis here, rather,

496
00:33:09,100 --> 00:33:10,420
is that the sensor can be configured

497
00:33:10,420 --> 00:33:12,280
in a separate base station based on a config

498
00:33:12,280 --> 00:33:15,540
that's stolen from a USB stick.

499
00:33:17,780 --> 00:33:20,300
Also, it's noted in the documentation

500
00:33:20,810 --> 00:33:23,240
that the sensor range is about 100 feet

501
00:33:24,290 --> 00:33:25,240
from the base station,

502
00:33:25,850 --> 00:33:28,940
and given that sensors are often placed

503
00:33:28,940 --> 00:33:31,260
on the perimeter of a protected area,

504
00:33:31,340 --> 00:33:32,460
on the windows, the doors,

505
00:33:33,660 --> 00:33:36,080
it's pretty likely that there's gonna be a lot of noise,

506
00:33:36,080 --> 00:33:38,820
there's gonna be over-penetration out to public areas

507
00:33:38,820 --> 00:33:40,480
or areas that you're not really able

508
00:33:40,480 --> 00:33:42,000
to physically control so much.

509
00:33:42,580 --> 00:33:47,240
So, taking our three sub-hypotheses,

510
00:33:47,320 --> 00:33:50,140
the hypothetical attack that we're gonna work on

511
00:33:50,140 --> 00:33:53,620
is that a stock base station can be configured

512
00:33:53,620 --> 00:33:56,700
with sensor values from a stolen configuration,

513
00:33:58,020 --> 00:34:01,080
and then an arbitrary malicious base station

514
00:34:01,480 --> 00:34:03,520
can receive and interpret those sensor signals.

515
00:34:03,960 --> 00:34:05,120
What's the next step?

516
00:34:05,120 --> 00:34:07,160
It's gonna be to source another base station

517
00:34:07,160 --> 00:34:08,980
and test out our hypothesis.

518
00:34:09,500 --> 00:34:11,980
So, for that, I turned to eBay.

519
00:34:12,260 --> 00:34:15,600
I didn't feel like dropping another couple hundred dollars

520
00:34:15,600 --> 00:34:17,140
on another full system from retail.

521
00:34:17,440 --> 00:34:20,580
I found that I was actually able to obtain

522
00:34:21,120 --> 00:34:24,580
a separate base station with keychain remote

523
00:34:25,280 --> 00:34:28,260
from eBay for about 70 bucks, I think.

524
00:34:29,020 --> 00:34:30,860
So, forgive the electrical tape here.

525
00:34:30,940 --> 00:34:33,400
This is so I don't actually confuse which one was the victim

526
00:34:33,400 --> 00:34:35,100
and which one was the malicious base station.

527
00:34:35,100 --> 00:34:40,360
So, once I obtained that second system,

528
00:34:40,460 --> 00:34:42,840
I was able to configure both systems so that,

529
00:34:43,460 --> 00:34:45,780
alternately, so that they would chime

530
00:34:46,100 --> 00:34:48,280
when one of the entry sensors was tripped.

531
00:34:48,540 --> 00:34:53,340
I started off with the sensor configured just in one,

532
00:34:53,500 --> 00:34:55,880
not the other, set the chime, confirmed,

533
00:34:56,060 --> 00:34:56,820
yeah, I heard the tone.

534
00:34:57,040 --> 00:35:03,440
Then I configured it in both and I set off the sensor

535
00:35:03,880 --> 00:35:05,080
and confirmed it.

536
00:35:05,100 --> 00:35:05,840
That confirmed that I heard the chime

537
00:35:05,840 --> 00:35:07,000
out of both base stations.

538
00:35:07,220 --> 00:35:09,040
So, yes, that confirms our hypothesis.

539
00:35:09,460 --> 00:35:13,240
The sensors are just doing a very basic broadcast out

540
00:35:13,240 --> 00:35:18,660
and any base station in the area can listen to that sensor

541
00:35:19,250 --> 00:35:21,800
and interpret it and integrate it into its own operations.

542
00:35:23,780 --> 00:35:25,840
So, now we're gonna take that hypothesis,

543
00:35:26,240 --> 00:35:28,660
we're gonna extend it and we're gonna refine it even more.

544
00:35:28,920 --> 00:35:30,740
So, what else do we know about the system?

545
00:35:31,040 --> 00:35:34,540
We know that the base station can be configured to read,

546
00:35:35,100 --> 00:35:37,880
data from arbitrary sensors now that we've done that test.

547
00:35:38,120 --> 00:35:40,460
We also know from the documentation

548
00:35:40,460 --> 00:35:43,440
that online monitoring is an optional add-on.

549
00:35:43,760 --> 00:35:48,640
So, what we're gonna do now is we're gonna test to see

550
00:35:48,640 --> 00:35:52,260
if a physically planted device has usable remote

551
00:35:52,260 --> 00:35:56,440
connectivity to pretty much anywhere in the world

552
00:35:56,440 --> 00:35:59,400
via the base station's built-in 2G connection.

553
00:36:00,660 --> 00:36:04,100
We also know that the system will send monitoring alerts.

554
00:36:05,420 --> 00:36:09,460
So, we should be able to build up a pretty robust picture

555
00:36:09,460 --> 00:36:12,380
of how that system is used over time.

556
00:36:12,940 --> 00:36:17,520
So, being a pen tester, this is something that we do

557
00:36:18,160 --> 00:36:22,000
when there is a physical aspect to our engagements.

558
00:36:22,380 --> 00:36:24,180
I'm not gonna go through the details

559
00:36:24,180 --> 00:36:29,000
of how I would go through and what I'd be looking for,

560
00:36:29,060 --> 00:36:30,580
trends in terms of building usage

561
00:36:30,580 --> 00:36:32,920
and things of that nature.

562
00:36:33,060 --> 00:36:34,680
But, you know,

563
00:36:34,680 --> 00:36:36,100
if someone were so inclined

564
00:36:36,100 --> 00:36:38,700
or if this were a penetration test engagement,

565
00:36:39,080 --> 00:36:42,380
you know, we absolutely could do a lot of analysis

566
00:36:42,380 --> 00:36:44,560
and trending and things like that

567
00:36:45,760 --> 00:36:48,260
to determine when, for example,

568
00:36:49,080 --> 00:36:52,260
the house or the protected area would be most likely

569
00:36:52,260 --> 00:36:54,240
unoccupied or other attack scenarios.

570
00:36:55,980 --> 00:36:59,420
So, our next step is to provision online monitoring

571
00:36:59,420 --> 00:37:04,520
for the malicious base station to receive these alerts.

572
00:37:04,680 --> 00:37:06,380
When the sensors are triggered.

573
00:37:06,600 --> 00:37:13,660
So, I set up, I had access to a friendly multi-tenant office,

574
00:37:14,820 --> 00:37:18,020
I'm sorry, an office in a multi-tenant office building.

575
00:37:18,920 --> 00:37:23,240
So, I was able to set up the original retail bot

576
00:37:23,240 --> 00:37:25,420
simply safe system as it would be deployed

577
00:37:25,420 --> 00:37:28,320
in a normal small office sort of environment.

578
00:37:29,220 --> 00:37:33,840
As I did that, I also put the malicious base station down,

579
00:37:33,840 --> 00:37:35,560
in my vehicle in the parking lot.

580
00:37:35,860 --> 00:37:38,520
And what I found was that

581
00:37:40,420 --> 00:37:43,920
I was able to receive alerts that were delivered to me

582
00:37:43,920 --> 00:37:48,020
by email about the comings and goings in that office

583
00:37:48,020 --> 00:37:49,940
even though the base station itself

584
00:37:49,940 --> 00:37:53,440
was on a different physical level.

585
00:37:53,600 --> 00:37:57,940
It was on a parking lot that was outside of the building.

586
00:37:58,040 --> 00:38:00,780
It wasn't even right next to the actual office.

587
00:38:01,600 --> 00:38:04,500
So it was a significant distance away.

588
00:38:05,100 --> 00:38:08,360
I didn't get all of the sensors, which one would expect.

589
00:38:09,280 --> 00:38:12,100
One would hope that the sensor wouldn't penetrate

590
00:38:12,100 --> 00:38:15,160
all the way out that way, but certainly enough

591
00:38:15,160 --> 00:38:19,840
to give me an idea of when the office was occupied.

592
00:38:23,200 --> 00:38:26,540
So now that we know that we have a hypothetical attack

593
00:38:26,540 --> 00:38:31,200
that works, what are we gonna do to automate that attack

594
00:38:31,200 --> 00:38:35,480
and really make it usable in a real world scenario?

595
00:38:36,060 --> 00:38:39,160
So one thing you can do to automate the attack

596
00:38:39,680 --> 00:38:43,440
is to run the data capture script as a service

597
00:38:43,440 --> 00:38:44,760
in the background on your machine.

598
00:38:45,040 --> 00:38:49,400
So that way really the only limiting factor

599
00:38:49,400 --> 00:38:50,900
in the time it takes to do the attack

600
00:38:51,300 --> 00:38:53,180
is the time to undo the cap on the remote

601
00:38:53,180 --> 00:38:55,520
and plug it into a USB port.

602
00:38:55,520 --> 00:38:56,920
Mere seconds.

603
00:38:57,020 --> 00:38:59,820
You can either save that configuration off to a file.

604
00:39:00,120 --> 00:39:03,180
You can Bluetooth it off to another location.

605
00:39:04,880 --> 00:39:09,320
Any means of exfiltration at that point is completely valid.

606
00:39:09,740 --> 00:39:11,880
And what else can we do to optimize it

607
00:39:11,880 --> 00:39:13,240
for a particular attack scenario?

608
00:39:13,900 --> 00:39:18,700
So when you are thinking about these USB keys,

609
00:39:19,020 --> 00:39:21,900
there are a couple of different scenarios that pop to mind.

610
00:39:22,860 --> 00:39:25,440
Lost and stolen is obviously one aspect.

611
00:39:25,520 --> 00:39:30,340
But it doesn't even necessarily have to be fully lost.

612
00:39:30,980 --> 00:39:34,980
I was going for a run at the gym one day

613
00:39:34,980 --> 00:39:36,980
and I just happened to see one of these

614
00:39:36,980 --> 00:39:38,920
sitting on the little key hanger things

615
00:39:38,920 --> 00:39:41,840
that are outside the front of the building.

616
00:39:43,580 --> 00:39:46,580
Why someone would put their keys on one of those

617
00:39:46,580 --> 00:39:48,860
in the first place, being a security professional,

618
00:39:49,100 --> 00:39:52,620
again, is beyond me, but there are people that do it.

619
00:39:52,620 --> 00:39:58,600
And so it got me thinking, you know,

620
00:40:00,100 --> 00:40:03,220
well, people do actually give their keys to people

621
00:40:03,220 --> 00:40:04,600
for short periods of time.

622
00:40:04,660 --> 00:40:07,440
Whether it's a valet or a mechanic

623
00:40:07,440 --> 00:40:10,060
or again, on one of those little boards,

624
00:40:10,340 --> 00:40:12,520
a lot of times people will leave their keys

625
00:40:12,520 --> 00:40:13,800
in the break room at work.

626
00:40:15,120 --> 00:40:17,640
And they might not even necessarily know

627
00:40:17,640 --> 00:40:19,540
that somebody was able to pick up their keys.

628
00:40:20,140 --> 00:40:22,140
I know a number of years ago,

629
00:40:22,140 --> 00:40:25,320
there was, I guess, an interesting talk

630
00:40:25,320 --> 00:40:26,820
about somebody who managed to replicate

631
00:40:26,820 --> 00:40:30,460
a physical key with a 3D printer,

632
00:40:30,940 --> 00:40:32,660
just by taking a picture of it.

633
00:40:32,920 --> 00:40:35,460
So this would kind of be the equivalent of that.

634
00:40:36,080 --> 00:40:40,140
You can actually run the script easily,

635
00:40:40,400 --> 00:40:43,480
very, very easily, on a Raspberry Pi Zero.

636
00:40:43,860 --> 00:40:45,760
And again, for those that might not be familiar

637
00:40:45,760 --> 00:40:48,780
with the Pi Zero, it is a very, very small board,

638
00:40:48,940 --> 00:40:51,900
which is actually about the same size as the key chain.

639
00:40:51,900 --> 00:40:52,120
It's about the same size as the key chain itself.

640
00:40:52,680 --> 00:40:58,060
You can wire that up to a very inexpensive USB power supply.

641
00:40:59,040 --> 00:41:04,740
You can oftentimes get them as swag at conventions

642
00:41:04,740 --> 00:41:08,080
or they're given out for free,

643
00:41:08,100 --> 00:41:09,440
just for promotional material.

644
00:41:09,820 --> 00:41:13,620
So for the cost of five bucks for a Pi Zero,

645
00:41:14,240 --> 00:41:16,700
an extra flash card you have sitting around,

646
00:41:16,880 --> 00:41:18,260
USB OTG cable.

647
00:41:18,900 --> 00:41:21,320
You know, you could have an easily concealable,

648
00:41:21,320 --> 00:41:23,820
a method of actually collecting this data.

649
00:41:25,320 --> 00:41:28,280
So I did actually reach out to SimpliSafe

650
00:41:28,280 --> 00:41:30,800
when I found this vulnerability

651
00:41:30,800 --> 00:41:32,860
to do some coordinated disclosure.

652
00:41:33,260 --> 00:41:37,620
So they had actually been in contact with me

653
00:41:37,620 --> 00:41:38,380
for a couple of months,

654
00:41:38,480 --> 00:41:41,180
and they had released a security advisory today.

655
00:41:42,160 --> 00:41:44,320
It's available as a blog post

656
00:41:44,320 --> 00:41:46,100
up on SimpliSafe's website there,

657
00:41:46,940 --> 00:41:49,500
just provided for anybody who wants to check that out.

658
00:41:49,780 --> 00:41:50,680
Now, I'll tell you a little bit more about this.

659
00:41:50,680 --> 00:41:50,700
I'll tell you a little bit more about this.

660
00:41:50,700 --> 00:41:50,860
I'll tell you a little bit more about this.

661
00:41:51,320 --> 00:41:53,220
Obviously, you know, I think that, you know,

662
00:41:53,220 --> 00:41:55,480
their recommendations, you know,

663
00:41:55,480 --> 00:41:57,860
and my recommendations can disagree a little bit.

664
00:41:57,900 --> 00:41:58,920
Reasonable minds can disagree.

665
00:42:01,760 --> 00:42:04,060
So I'm told that there's actually going to be

666
00:42:04,060 --> 00:42:05,760
a utility that they came out with

667
00:42:05,760 --> 00:42:07,820
that's going to help mitigate this problem as well,

668
00:42:08,520 --> 00:42:11,360
where customers can actually wipe the configuration

669
00:42:12,100 --> 00:42:14,260
off of their keychain remote

670
00:42:14,260 --> 00:42:15,800
while they're not making changes.

671
00:42:16,180 --> 00:42:17,800
So it would work like this.

672
00:42:17,900 --> 00:42:20,880
Basically, you would want to make changes to your system,

673
00:42:20,880 --> 00:42:22,480
you would take your keychain remote,

674
00:42:22,620 --> 00:42:23,860
you would plug it into the base station,

675
00:42:24,530 --> 00:42:29,160
it would write the configuration data to the keychain,

676
00:42:29,910 --> 00:42:32,540
you'd plug it into the system, to the laptop,

677
00:42:32,840 --> 00:42:36,760
make your changes, and then you'd re-sync it

678
00:42:36,760 --> 00:42:39,520
to the base station, and then you'd run this utility

679
00:42:39,520 --> 00:42:42,200
on the laptop again that would reset the data,

680
00:42:42,320 --> 00:42:43,220
wipe it off the keychain.

681
00:42:43,880 --> 00:42:46,680
You know, absolutely, for having hardware

682
00:42:46,680 --> 00:42:50,740
that was first envisioned and deployed almost 10 years ago,

683
00:42:50,740 --> 00:42:54,300
I think that that's a novel way

684
00:42:54,300 --> 00:42:57,900
of mitigating the risk personally.

685
00:42:58,460 --> 00:43:02,060
I think that a lot of users might not want

686
00:43:02,060 --> 00:43:03,040
to go through that trouble.

687
00:43:03,520 --> 00:43:06,780
I think that a lot of users might forget to do that.

688
00:43:08,420 --> 00:43:11,180
I think that having something out there

689
00:43:11,600 --> 00:43:13,400
and acknowledging that, hey, yeah,

690
00:43:13,460 --> 00:43:15,160
there is a configuration on here,

691
00:43:15,260 --> 00:43:18,320
and you do need to take into consideration

692
00:43:18,320 --> 00:43:20,640
more than just your base station,

693
00:43:20,640 --> 00:43:22,440
is a good step.

694
00:43:23,060 --> 00:43:26,720
SimpliSafe also did modify some of their guidance

695
00:43:26,720 --> 00:43:29,220
to say, hey, if you lose a remote,

696
00:43:29,420 --> 00:43:32,300
you should reset your pins just in case.

697
00:43:33,440 --> 00:43:36,960
I recommend not using the USB-enabled remote

698
00:43:36,960 --> 00:43:38,980
just in case you forget to wipe it.

699
00:43:39,680 --> 00:43:47,280
Also, I would recommend if the USB-enabled remote is lost,

700
00:43:47,760 --> 00:43:50,620
you know, obviously, you can change it,

701
00:43:50,620 --> 00:43:51,440
change the pins immediately.

702
00:43:53,120 --> 00:43:55,700
But really, there's no known remedy

703
00:43:55,700 --> 00:43:58,560
to reinitialize the compromised sensor serial numbers.

704
00:43:59,100 --> 00:44:03,760
So, that kind of makes you think about whether or not,

705
00:44:05,040 --> 00:44:07,500
you know, you have to think about

706
00:44:07,500 --> 00:44:08,740
your own risk profile, basically.

707
00:44:09,020 --> 00:44:12,940
A small business is gonna be a different risk profile

708
00:44:12,940 --> 00:44:14,740
to somebody who's using this to protect their home.

709
00:44:16,620 --> 00:44:20,540
So, it might be a good idea to supplement additional security measures.

710
00:44:20,540 --> 00:44:25,760
Things like web cameras that utilize different technologies,

711
00:44:25,940 --> 00:44:28,020
say, Wi-Fi or wired connections,

712
00:44:28,880 --> 00:44:31,940
or additional locks that might also have

713
00:44:31,940 --> 00:44:34,960
notification capabilities as well.

714
00:44:35,340 --> 00:44:37,800
So, again, you know, yeah,

715
00:44:37,860 --> 00:44:38,720
we're pointing out a vulnerability.

716
00:44:39,780 --> 00:44:41,920
It's going to be up to the individual

717
00:44:41,920 --> 00:44:44,740
to determine whether or not this vulnerability

718
00:44:44,740 --> 00:44:46,260
really affects their use case.

719
00:44:46,760 --> 00:44:48,180
Finally, I'd just like to mention,

720
00:44:48,320 --> 00:44:50,080
it's a good idea always to restrict

721
00:44:50,080 --> 00:44:51,740
physical access to the base station.

722
00:44:52,640 --> 00:44:56,260
It's one of the things where, you know,

723
00:44:56,280 --> 00:44:58,360
if you do a little bit of Googling about SimpliSafe,

724
00:44:58,520 --> 00:45:01,540
there are some other YouTube attacks out there

725
00:45:02,100 --> 00:45:03,380
that you can find on YouTube.

726
00:45:03,680 --> 00:45:05,060
I haven't tested them myself.

727
00:45:05,300 --> 00:45:07,720
I'm not gonna vouch for whether or not they actually are real.

728
00:45:08,200 --> 00:45:09,720
But just to be on the safe side,

729
00:45:10,240 --> 00:45:13,220
it is a good idea to just sort of keep this

730
00:45:14,060 --> 00:45:16,600
in a physically safe spot if you can,

731
00:45:17,080 --> 00:45:18,880
if you're gonna continue to use the system.

732
00:45:21,280 --> 00:45:23,440
So, what I've found about the system

733
00:45:23,440 --> 00:45:28,440
is that the vulnerabilities that are inherent

734
00:45:28,440 --> 00:45:30,060
to the architecture of the system

735
00:45:30,540 --> 00:45:32,280
are exploitable in three different ways.

736
00:45:32,740 --> 00:45:34,620
You can use hardware hacking,

737
00:45:34,860 --> 00:45:36,840
you can use SDR and signals analysis,

738
00:45:37,420 --> 00:45:39,000
or you can use the native device

739
00:45:39,520 --> 00:45:41,360
and abuse of the features that are already

740
00:45:41,360 --> 00:45:42,340
built into the system.

741
00:45:42,980 --> 00:45:44,480
When you have a secure product

742
00:45:44,480 --> 00:45:47,660
and when you are going through

743
00:45:47,660 --> 00:45:49,840
and you're inspecting your designs,

744
00:45:49,880 --> 00:45:50,060
you're going through and you're inspecting your designs,

745
00:45:50,080 --> 00:45:51,440
you're doing risk analysis,

746
00:45:52,060 --> 00:45:55,840
it doesn't really matter what the tools are

747
00:45:56,280 --> 00:45:57,400
used to attack it.

748
00:45:57,480 --> 00:45:59,080
It's a strong architecture.

749
00:46:00,140 --> 00:46:01,500
Saying that, you know,

750
00:46:01,620 --> 00:46:03,300
well, it's not really a valid attack

751
00:46:03,300 --> 00:46:04,840
because they used one skill

752
00:46:04,840 --> 00:46:07,280
or they used one particular tool

753
00:46:07,880 --> 00:46:09,180
becomes an irrelevant point

754
00:46:09,180 --> 00:46:11,060
because you're actually getting to meet the problem,

755
00:46:11,240 --> 00:46:12,260
you're fixing the root cause.

756
00:46:12,760 --> 00:46:16,920
So, is the system still useful and effective?

757
00:46:17,400 --> 00:46:19,000
And as I said before,

758
00:46:19,040 --> 00:46:19,860
that really depends on

759
00:46:19,860 --> 00:46:20,280
the individual.

760
00:46:20,620 --> 00:46:24,580
So, an individual who, you know,

761
00:46:24,580 --> 00:46:27,680
is looking at high-risk human threat actors,

762
00:46:27,760 --> 00:46:30,820
so somebody that has a reason

763
00:46:30,820 --> 00:46:33,480
to have a home security system,

764
00:46:34,160 --> 00:46:36,160
and it's an unfortunate reality

765
00:46:36,160 --> 00:46:38,720
that people out there, you know,

766
00:46:38,720 --> 00:46:40,880
have stalkers, they have PFAs against people,

767
00:46:41,080 --> 00:46:43,880
they know that there are threats that have been made,

768
00:46:44,330 --> 00:46:45,260
things of that nature.

769
00:46:46,000 --> 00:46:49,680
I'm not sure that I would recommend this system.

770
00:46:49,680 --> 00:46:49,840
I'm not sure that I would recommend this system

771
00:46:49,840 --> 00:46:54,380
to somebody who knows that there is a high risk

772
00:46:54,380 --> 00:46:55,660
of something happening,

773
00:46:56,260 --> 00:46:57,960
needing to alert the police quickly.

774
00:46:58,580 --> 00:47:01,320
Low and medium risk human threat actors,

775
00:47:01,540 --> 00:47:04,920
I'd say that depends on, you know,

776
00:47:04,920 --> 00:47:06,940
more of the use case of, you know,

777
00:47:06,940 --> 00:47:08,260
are you looking to protect property?

778
00:47:08,500 --> 00:47:10,640
Are you looking to supplement additional controls?

779
00:47:11,220 --> 00:47:12,580
It might still be effective

780
00:47:12,580 --> 00:47:17,680
on defending against normal smash and grab type burglaries.

781
00:47:18,060 --> 00:47:19,660
It might be, you know,

782
00:47:19,680 --> 00:47:23,040
still useful in deterring

783
00:47:24,840 --> 00:47:27,980
there being an incident in the first place.

784
00:47:28,500 --> 00:47:30,700
However, it's kind of hard to measure a negative.

785
00:47:30,840 --> 00:47:32,960
How do you measure something that doesn't happen?

786
00:47:33,700 --> 00:47:37,020
And then there also is the environmental monitoring piece,

787
00:47:37,200 --> 00:47:38,420
the environmental threat actors.

788
00:47:38,660 --> 00:47:39,800
There's no intelligence.

789
00:47:39,840 --> 00:47:43,700
There's no active circumvention of carbon monoxide detector,

790
00:47:44,560 --> 00:47:48,480
you know, smoke detectors and water detectors.

791
00:47:48,940 --> 00:47:49,660
There's no intelligence.

792
00:47:49,660 --> 00:47:51,240
That's not really my area of expertise.

793
00:47:51,480 --> 00:47:53,500
I would leave it to somebody like Underwriters Labs

794
00:47:53,500 --> 00:47:54,540
to test those components.

795
00:47:55,280 --> 00:48:00,580
You know, they know really what the key variables are

796
00:48:00,580 --> 00:48:03,240
and making sure that those systems are effective.

797
00:48:05,000 --> 00:48:06,960
So on a high level, what I would say

798
00:48:06,960 --> 00:48:13,560
the most apparent vulnerability in the architecture itself

799
00:48:13,560 --> 00:48:16,280
is the lack of two-way authentication.

800
00:48:19,660 --> 00:48:25,020
sensor that is broadcasting out to anybody who will listen, and you have a system that

801
00:48:25,020 --> 00:48:34,000
will accept that data without proving integrity or identity, that's really a system that's

802
00:48:34,000 --> 00:48:41,160
not able to do some very key things from an information security perspective. You don't

803
00:48:41,160 --> 00:48:46,000
have confidentiality, you don't have data integrity, and you don't have data authenticity.

804
00:48:47,340 --> 00:48:52,980
When you're building a system like this, you would expect it to have some confidentiality,

805
00:48:53,080 --> 00:48:57,500
you'd expect it to have integrity checks, you'd expect it to have authentication checks.

806
00:48:59,440 --> 00:49:06,820
So two-way authentication, I think, would be the goal for manufacturers of alarm systems,

807
00:49:07,180 --> 00:49:12,720
making sure that you can't just do simple replays, simple spoofs, things of that nature

808
00:49:12,720 --> 00:49:14,980
to get around and cause problems.

809
00:49:15,220 --> 00:49:15,980
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,

810
00:49:15,980 --> 00:49:25,700
it be false positives or false negatives. Does anybody have any questions? All right. Well,

811
00:49:25,720 --> 00:49:30,280
thank you very much for coming to the talk today. If you're interested in reaching out,

812
00:49:30,440 --> 00:49:34,440
there's a couple of different ways you can get a hold of me. I am on LinkedIn. I'm not on Twitter,

813
00:49:34,560 --> 00:49:39,040
although my company is. So you can go to Twitter handle at Spirant Security.

814
00:49:39,040 --> 00:49:46,200
Security. You can reach out to me directly at Nick.Dolesky at Spirant.com. You can reach out

815
00:49:46,200 --> 00:49:55,540
to the whole group at SecurityLabs at Spirant.com. And for anything that's more of an enthusiast or

816
00:49:55,540 --> 00:50:00,920
other sort of email, you can reach out to me. Believe it or not, this actually is a valid email

817
00:50:00,920 --> 00:50:05,960
address down there. So did I see a hand over here? And by the way, we do have a couple of shirts. So

818
00:50:05,960 --> 00:50:08,960
if you have some questions, feel free to come up.

819
00:50:15,900 --> 00:50:22,680
Did you find any attributes in the configuration that were very specific to that particular setup

820
00:50:22,680 --> 00:50:33,180
that you had? Can you speak into the microphone? Yeah. Did you find any attributes in your

821
00:50:33,180 --> 00:50:38,820
configuration that were specific to that particular setup? So. Are you unique to that

822
00:50:38,820 --> 00:50:39,020
setup? I'm not. I'm not. I'm not. I'm not. I'm not. I'm not. I'm not.

823
00:50:39,040 --> 00:50:44,000
So a lot of the attributes that I found were pretty common among the other home security systems

824
00:50:44,000 --> 00:50:51,560
I've looked at. You know, it was a pretty bare-bones configuration. But it is a fairly

825
00:50:51,560 --> 00:50:58,340
straightforward embedded system. It's not. No. No. I mean, were most of the parameters very

826
00:50:58,340 --> 00:51:03,520
generic? Or were they particular to that particular setup to recognize each other sensor-wise?

827
00:51:03,820 --> 00:51:08,560
Oh, they were fairly generic. Very generic. Everything was easily

828
00:51:09,040 --> 00:51:14,760
set up with just entering the serial number in the config. So you didn't really have to have a whole lot of

829
00:51:17,880 --> 00:51:22,040
customization. Were you referring to the testing setup or the actual alarm setup?

830
00:51:22,420 --> 00:51:26,560
The actual alarm setup. The actual alarm setup. No. Everything is fairly generic.

831
00:51:26,760 --> 00:51:32,320
Oh, yeah? You know, what I would say is that it wouldn't be interoperable with other systems,

832
00:51:32,480 --> 00:51:37,720
but it's not really a complex system. Okay. Yeah. Thank you. Other questions?

833
00:51:39,140 --> 00:51:46,600
So I gave a TORCON talk in 2015 where I used an MC catcher to basically analyze the communication

834
00:51:46,600 --> 00:51:52,900
between the base station and the actual, like, remote monitoring side. Okay. And it just sends

835
00:51:52,900 --> 00:51:59,240
unencrypted UDP packets. And then on their back end, it's using the base station serial number and

836
00:51:59,240 --> 00:52:06,460
the keypad or sensor serial number to actually trigger those alerts. So did you find anything that

837
00:52:06,460 --> 00:52:07,220
would let you...

838
00:52:07,720 --> 00:52:13,080
Get the base station serial number from the USB keypad? Or anything else?

839
00:52:13,280 --> 00:52:22,240
No. No, I did not. And I think that that would be a key differentiator. And again, the base station

840
00:52:22,240 --> 00:52:29,880
serial number would have been a completely different story if you could find that on the device. No, it

841
00:52:29,880 --> 00:52:35,580
is not on the device configuration. All right. Cool. Are there questions?

842
00:52:41,640 --> 00:52:45,280
All right. Thank you very much, everybody. I appreciate your time.