1
00:00:00,000 --> 00:00:09,740
Guys, enjoy. Mmm, breakfast. Alright. Morning DEF CON. Thanks for all coming. Thanks for

2
00:00:09,740 --> 00:00:15,440
having us. This is Badge of Shame. Hey, I'm Dan Pietro. I'm a senior security engineer at

3
00:00:15,440 --> 00:00:21,480
Bishop Fox. Before that I was a long time pen tester here at Bishop Fox. Yeah, hi everyone. I'm

4
00:00:21,480 --> 00:00:25,540
the new speaker here. My name is David Vargas. I'm a senior consultant with the red team at

5
00:00:25,540 --> 00:00:31,000
Bishop Fox. Cool. And we're going to be talking about breaking into secure facilities. So

6
00:00:31,000 --> 00:00:36,540
this actually all came about as a part of a pen test here at Bishop Fox. Breaking into secure

7
00:00:36,540 --> 00:00:41,060
facilities is easily one of the coolest things that we get to do. And if you're already

8
00:00:41,060 --> 00:00:45,820
familiar with like breaking into facilities, there's like an ESP key. We'll kind of get into

9
00:00:45,820 --> 00:00:49,780
this a little bit more as a tool. And we tried using this on a pen test one time. It just

10
00:00:49,780 --> 00:00:53,640
like wasn't working and we were super like curious as to why. It turned out that we had an

11
00:00:53,640 --> 00:00:58,980
OSDP installation. We hadn't actually seen one in the wild at that point. And so like I've

12
00:00:58,980 --> 00:01:03,000
got a background in cryptographic protocols. Figure why not take a look at this thing. And

13
00:01:03,000 --> 00:01:09,080
this presentation is the result of that. Cool. So let's get into it. So one of the other

14
00:01:09,080 --> 00:01:14,440
things you should know about me is that I hate slides. But you can't just get away with not

15
00:01:14,440 --> 00:01:19,760
having slides. So we made some authentic bespoke one off slides. These slides are like

16
00:01:19,760 --> 00:01:23,620
organic. They are allowed to turn fully around in PowerPoint before being used. So you can't

17
00:01:23,640 --> 00:01:28,600
export it. So suppose you're trying to break into a secure facility, right? Let's say some

18
00:01:28,600 --> 00:01:33,700
undisclosed location in Santa Fe, New Mexico. And you like really want to get into this room,

19
00:01:33,800 --> 00:01:38,620
right? It's like very important to you personally. And this room, like a lot of other

20
00:01:38,620 --> 00:01:43,800
rooms, has an RFID badge reader that is protecting the entrance to it. Even if you're not

21
00:01:43,800 --> 00:01:47,740
familiar with physical security, I'm sure you've seen these things, right? You take a badge out,

22
00:01:47,820 --> 00:01:53,620
you sort of beep it to the little thing and it lets you into the room. Cool. So, let's talk a

23
00:01:53,640 --> 00:01:56,800
little bit about this. There's lots of ways of attacking these RFID badge reader systems. Some

24
00:01:56,800 --> 00:02:01,660
of which we've actually pioneered here at Bishop Fox. This is the Tasic RFID thief. This is a

25
00:02:01,660 --> 00:02:07,680
thing that my boss Fran made a while ago. It's basically like a long range RFID reader. So it

26
00:02:07,680 --> 00:02:12,040
can like read badges from about like five, six feet away. We developed this cool little

27
00:02:12,040 --> 00:02:16,720
maneuver where you like put it into a briefcase and walk up to somebody at Starbucks with like

28
00:02:16,720 --> 00:02:21,860
wearing their badge. And you like set it down and then kind of like pull it up and then up onto

29
00:02:21,860 --> 00:02:25,260
your shoulder, like the briefcase. And really what you're doing is you're scanning the person

30
00:02:25,260 --> 00:02:31,060
from like toe to head, like surreptitiously. This was even featured on an episode of Mr. Robot,

31
00:02:31,220 --> 00:02:39,660
actually two I think. And yeah, that's cool. So, the hacking tool my boss Fran made,

32
00:02:39,780 --> 00:02:44,140
but the prop in the show I made, we knew the technical advisor for the show at the time and so

33
00:02:44,140 --> 00:02:48,840
they just needed a little gizmo that says like, no badges detected. Like when you press a

34
00:02:48,840 --> 00:02:51,600
little button. It's just a raspberry pie inside of a plastic case. But that's kind of cool.

35
00:02:52,640 --> 00:02:57,120
So, that's not what we're talking about today. We're going to be going over, let's talk a

36
00:02:57,120 --> 00:02:59,880
little bit about how RFID badge reader systems work in general because this is going to be

37
00:02:59,880 --> 00:03:03,380
pretty important. So on the outside you're going to see three things. You're going to see a

38
00:03:03,380 --> 00:03:09,820
door, a lock and a reader. So the reader you present with a badge. So the badge just, at

39
00:03:09,820 --> 00:03:13,360
least for passive cards, is just basically a number. It's got a number. Sometimes they're

40
00:03:13,360 --> 00:03:18,060
very short too. They're not like big 128 bit numbers or whatever, right? You present the

41
00:03:18,060 --> 00:03:21,700
badge to the reader and you're basically just telling it this number. It says here's my,

42
00:03:21,860 --> 00:03:27,640
badge number, one, two, three, four. Now importantly, the reader does not perform

43
00:03:27,640 --> 00:03:32,440
authentication or authorization in this system. It's not the thing that lets you into the

44
00:03:32,440 --> 00:03:36,920
door. In order to do that, it has to talk to a back end controller. The controller is the

45
00:03:36,920 --> 00:03:41,240
thing that actually like knows who you are and decides whether you're allowed into this door

46
00:03:41,240 --> 00:03:45,740
or not. So the reader then forwards that badge number off to the controller. The controller

47
00:03:45,740 --> 00:03:51,440
then says, yeah, sure, this person's allowed into this door and sends it a little like

48
00:03:51,440 --> 00:03:55,760
signal that says, flash your green light that says that they're allowed in. Now importantly,

49
00:03:55,920 --> 00:04:00,580
again, the reader can't let you in. So it has to have a separate set of wires that is not the

50
00:04:00,580 --> 00:04:05,620
same set of wires that like physically unlocks the door because the reader can't control it.

51
00:04:05,740 --> 00:04:08,500
Because obviously if the reader controlled whether you could get in, you could just like

52
00:04:08,500 --> 00:04:12,000
hack the reader and let you in. It would be super easy. That is not how these things work.

53
00:04:14,900 --> 00:04:19,260
Cool. All right. So let's take a look at how everything actually works in the back end. So

54
00:04:20,060 --> 00:04:21,420
currently it uses something called the back end controller. It's a little bit more complicated.

55
00:04:21,420 --> 00:04:25,260
It's called Wiegand, right? Everything is unencrypted. The card numbers or whatever data

56
00:04:25,260 --> 00:04:31,920
just happens to go across the wire. What that means is we can actually make a small device.

57
00:04:32,240 --> 00:04:36,620
Right now it's, you know, like an ESP key which you put into the reader. Now what happens is

58
00:04:36,620 --> 00:04:43,640
whenever somebody swipes a badge, the ESP key can grab the plain text communication and then we

59
00:04:43,640 --> 00:04:48,540
can clone the card. Right? And now we can also replay it, right? We can make our own cards. We

60
00:04:48,540 --> 00:04:50,480
can do all sorts of things to gain access to that facility.

61
00:04:51,900 --> 00:04:59,360
So that's a problem. And so now comes OSDP. So what's OSDP? OSDP stands for the open

62
00:04:59,360 --> 00:05:06,380
supervised device protocol. And it's meant to replace Wiegand. OSDP is built as an encrypted

63
00:05:06,380 --> 00:05:11,060
protocol, a secure protocol. It has a couple of other benefits over Wiegand like it's over

64
00:05:11,060 --> 00:05:15,880
RS485 which supports multiple readers on the same bus but we'll get to that a little later.

65
00:05:16,220 --> 00:05:20,300
Mainly the big thing was that it's supposed to be encrypted. So the same attack we just talked

66
00:05:20,300 --> 00:05:26,640
about won't work theoretically. So we started reading about it, right? We started looking into,

67
00:05:26,820 --> 00:05:31,040
all right, this sounds interesting. What's up with it? And we came across some very interesting

68
00:05:31,440 --> 00:05:37,380
claims. Mainly that it was unhackable as of 2020. And so, you know, that piqued our interest.

69
00:05:37,460 --> 00:05:41,960
So we were like, all right, let's take a look at this. So we did a couple of things. To start

70
00:05:41,960 --> 00:05:49,840
off we made our own version of an ESP key, a device we dubbed Melon. And so this device just like an

71
00:05:50,300 --> 00:05:57,120
ESP key plugs in between the reader and the controller. We also got our hands. David was

72
00:05:57,120 --> 00:06:06,080
allowed to call it Melon as long as he said it like Gandalf at least one time. So Melon. All

73
00:06:06,080 --> 00:06:13,620
right. And so we got the device and so we got a bunch of readers and we got an Axis A1001

74
00:06:13,620 --> 00:06:18,580
controller. Now everything that we have supports OSDP. So the controller which Dan has over here

75
00:06:18,580 --> 00:06:24,920
supports OSDP. We got it on eBay. We got some HID signal 20 readers. So what we

76
00:06:24,920 --> 00:06:29,260
expected to see was basically encrypted traffic going across the wire. Let's see what we

77
00:06:29,260 --> 00:06:40,200
actually saw. I think the name of the video kind of gives it away, but. Yeah, I did. Here we go.

78
00:06:40,240 --> 00:06:48,560
Cool. Yeah. Not encrypted. So what's going on? It's supposed to be encrypted. It's supposed to be

79
00:06:48,580 --> 00:06:56,080
encrypted. Everything supports OSDP. Let's see what happened. Well, when we kept looking into

80
00:06:56,080 --> 00:07:03,760
it, it turns out OSDP supports but doesn't actually require encryption. OSDP SC, a secure

81
00:07:03,760 --> 00:07:08,920
channel extension added to OSDP is what takes care of the encryption. So what does that mean? It

82
00:07:08,920 --> 00:07:14,760
actually means that OSDP devices that support OSDP both can choose to encrypt or not to encrypt

83
00:07:14,760 --> 00:07:18,560
traffic. And this is going to come playing a role into this a little later on. So let's go to the

84
00:07:18,580 --> 00:07:24,900
next slide. Cool. So let's back up a minute and talk about protocol and RS-485 that is

85
00:07:24,900 --> 00:07:31,340
underneath OSDP since this is going to be kind of important. So RS-485 is the underlying like

86
00:07:31,340 --> 00:07:37,240
physical layer underneath OSDP. It's serial, but it's not that serial. It's the other serial. In

87
00:07:37,240 --> 00:07:43,220
particular, RS-485 is multidrop. So that means you've got a controller and a reader and you want

88
00:07:43,220 --> 00:07:47,920
to hook up additional readers to this controller. You don't have to like have a separate line out to

89
00:07:47,920 --> 00:07:52,120
them. You can hook them all up in like succession like this. You can sort of daisy chain the

90
00:07:52,120 --> 00:07:58,800
readers. And importantly in this scenario, all messages are broadcast. So like this is a

91
00:07:58,800 --> 00:08:04,100
necessity because of just like not the laws of OSDP but just the laws of physics. Like they're

92
00:08:04,100 --> 00:08:07,980
all connected with the same copper wires. And so necessarily if you're going to send a message

93
00:08:07,980 --> 00:08:12,900
to like any of the devices, it's going to send them to all of them. So if reader A wants to

94
00:08:12,900 --> 00:08:17,900
send a message out to the controller, it has to necessarily also send them out to reader A. So

95
00:08:17,920 --> 00:08:24,140
this is not necessarily a vulnerability. It's just like kind of a nice to have. In fact, this is

96
00:08:24,140 --> 00:08:29,000
really useful for installers since you don't need to have a separate wire out to every single

97
00:08:29,000 --> 00:08:33,160
reader in your entire building. You can kind of daisy chain them around. It reduces the wiring.

98
00:08:33,380 --> 00:08:38,340
It makes it actually a lot nicer. This does have a consequence though that if suppose we're

99
00:08:38,340 --> 00:08:43,240
back in our undisclosed location in Santa Fe, New Mexico and there's like you know some guard out

100
00:08:43,240 --> 00:08:47,260
in front of a top secret door. Like this is the door we really want to get into, right? And there's

101
00:08:47,920 --> 00:08:52,460
beards and suspenders. Let's just call him George. That's in front of this room that like is

102
00:08:52,460 --> 00:08:57,500
preventing us from getting in yelling something about Targaryens. There might be a second side

103
00:08:57,500 --> 00:09:02,540
door that is like not especially secret. That like we wouldn't normally care about getting

104
00:09:02,540 --> 00:09:07,240
into. But now you might actually attack this door anyway because it could very well be on the

105
00:09:07,240 --> 00:09:12,400
same bus as the secret door. And so if you could listen and sniff badges on this one, you might

106
00:09:12,400 --> 00:09:16,460
be sniffing badges to like the rest of the building or you know maybe just the door that you

107
00:09:16,460 --> 00:09:17,680
really care about. So.

108
00:09:17,920 --> 00:09:22,780
That's kind of a nice little bonus there for attackers. So if red teamers are trying to do this,

109
00:09:22,920 --> 00:09:29,320
just find any door and it might be the one you care about. Next is around the client server

110
00:09:29,320 --> 00:09:36,120
model of OSDP. This is just kind of a practical thing for the protocol. Which is that in OSDP

111
00:09:36,580 --> 00:09:42,080
there's clients and servers. The controller is the client. All the readers are servers. So what

112
00:09:42,080 --> 00:09:47,900
that means is that readers, if you wanted to send a message, you can't just asynchronously send a message.

113
00:09:47,920 --> 00:09:54,720
It would just get ignored at least. According to the spec it should. And in order to send a

114
00:09:54,720 --> 00:10:00,000
message you have to reply to responses. So what this means is that controllers have to constantly

115
00:10:00,000 --> 00:10:04,980
pull the readers. In practice this like happens like something on the order of like 100 hertz is

116
00:10:04,980 --> 00:10:09,720
pretty typical. Where you see the controller say hey you got anything for me now? No. You got

117
00:10:09,720 --> 00:10:14,180
anything for me now? No. And that's how like when you badge in it knows immediately because it's

118
00:10:14,180 --> 00:10:15,160
like pulling constantly.

119
00:10:17,980 --> 00:10:25,620
This brings us to protocol WTF number one. Something I like to call what do we pain by the bit now?

120
00:10:27,060 --> 00:10:32,020
So one of the core functions of a cryptographic protocol is to prevent against replay attacks.

121
00:10:32,400 --> 00:10:37,600
So even though it's encrypted, what keeps an attacker from just taking the encrypted packet

122
00:10:37,600 --> 00:10:42,140
that has like our badge numbers when somebody badges in, right? And just replaying that packet.

123
00:10:42,220 --> 00:10:47,900
Just taking it and forwarding it off to the controller when we want to authenticate. So it's a

124
00:10:47,900 --> 00:10:55,240
normally protocols will do this by having your data. Attaching a sequence number to it. So the

125
00:10:55,240 --> 00:11:00,340
sequence number makes sure that every packet is fresh. It's live. So it has to either just be

126
00:11:00,340 --> 00:11:04,760
monotonically increasing from the last one or it's like the number of days like TCP does this by

127
00:11:04,760 --> 00:11:09,360
having like the amount of data increasing the sequence number. There's lots of ways of doing

128
00:11:09,360 --> 00:11:12,920
this. But basically the idea is that the receiver knows what the sequence number should be.

129
00:11:13,000 --> 00:11:17,760
It's going to be different every time. Keeps you from replaying things along with an HBAC that keeps the

130
00:11:17,900 --> 00:11:22,240
attacker from tampering with that data. Because obviously if the attacker could just like modify

131
00:11:22,240 --> 00:11:26,200
the sequence number to be the correct one, then that kind of defeats the whole purpose. So we don't

132
00:11:26,200 --> 00:11:30,900
have time to get into like what an HBAC is. It's a keyed hash. If you're not familiar with the

133
00:11:30,900 --> 00:11:36,280
way to look it up, it's cool. So you might be wondering, alright this sequence number, how

134
00:11:36,280 --> 00:11:41,280
many bits does that need to be? Like maybe like 128 bits? Like that would be cryptographically

135
00:11:41,280 --> 00:11:47,200
strong, right? You can't enumerate that. That would be really good. Maybe 64 bits? Like that's not

136
00:11:47,200 --> 00:11:51,820
bad. That's like the edge of enumeration. Like if you're trying to, you know, brute force

137
00:11:51,820 --> 00:11:55,500
something offline, 64 bits is usually the area where you're like, I don't know if that's

138
00:11:55,500 --> 00:12:02,960
possible anymore. Like 32 bits? Like that's fine maybe I guess. That's not great. How about

139
00:12:03,420 --> 00:12:10,280
two bits? Now I know what you're thinking. Now what you're thinking. Two bits? Those are

140
00:12:10,280 --> 00:12:16,860
rookie numbers. We can get that down. How about one and a half bits? Because OSTP actually

141
00:12:17,200 --> 00:12:23,680
skips zero in their two bit sequence number scheme. So you start with zero, but then

142
00:12:23,680 --> 00:12:27,900
everything going off there just goes one, two, three, one, two, three. So this sequence

143
00:12:27,900 --> 00:12:32,300
number exists, but for the purposes of security, might as well not. In fact, I question

144
00:12:32,300 --> 00:12:40,220
whether it's useful even for non-security purposes. So let's talk about this HMAC. So OSTP

145
00:12:40,220 --> 00:12:46,780
has this system of IV chaining where the HMAC of the previous packet is the IV of the current

146
00:12:47,200 --> 00:12:52,640
packet. By the way, we're running in a CBC mode encryption. I can hear the collective groans

147
00:12:52,640 --> 00:12:56,560
of all the cryptographers in the room. We don't have time to go over it. It's in CBC mode.

148
00:12:56,640 --> 00:13:04,440
Don't question it. So the IVs are sort of chained down the line where every single HMAC is

149
00:13:04,440 --> 00:13:11,280
just going to be the IV of the next packet. So this sort of has the effect of providing

150
00:13:11,280 --> 00:13:16,400
liveness because like the last packet is going to kind of mutate your current one and so that sort

151
00:13:16,400 --> 00:13:22,040
of prevents replay attacks in this kind of like janky sort of set up. But like in practice it

152
00:13:22,040 --> 00:13:26,520
sort of kind of works. We're going to have to come back to that. The problem with the HMAC,

153
00:13:26,600 --> 00:13:33,360
however, is that we just take most of it and throw it in the trash. So the first 32 bits of the

154
00:13:33,360 --> 00:13:41,340
HMAC we keep. And then the last 96 bits we just throw away. The spec even says to reduce the

155
00:13:41,340 --> 00:13:46,380
message size and transmission time overhead, only the first four bytes are sent. So that's a

156
00:13:46,400 --> 00:13:53,000
problem. Like why would you do this? Like you can't just take like the bits and like reduce the

157
00:13:53,000 --> 00:13:58,800
overhead. You know, like those are important bits. Like we needed those bits. You can't just do

158
00:13:58,800 --> 00:14:06,060
this. So if we do some back of the envelope math on like what this might look like. So imagine

159
00:14:06,060 --> 00:14:12,660
you're just sending badge in attempts with like random MACs, right? Like how long would this take

160
00:14:12,660 --> 00:14:16,380
us to enumerate in practice? So that's two to the third. So that's two to the third. That's two to the

161
00:14:16,400 --> 00:14:23,020
thirty one attempts on average. Let's assume that we're running at like 115200 baud, which is

162
00:14:23,020 --> 00:14:28,880
around the top end of what you can see. I think in practice, technically RS45 can run at 10

163
00:14:28,880 --> 00:14:33,100
megabits. In which case, if you find some installation that's running that fast, then like

164
00:14:33,640 --> 00:14:42,780
fuck. But this would be a success after like 35 days. Which is dangerous and sort of scary. Like

165
00:14:42,780 --> 00:14:46,380
if you're a defender. But I think as a red teamer, we're unlikely to run that fast. So we're

166
00:14:46,400 --> 00:14:50,320
going to really exploit this. Like I can imagine like sending David on a pen test. We're like

167
00:14:50,320 --> 00:14:55,180
okay. So we're going to give you a sleeping bag. And you're going to just like hang out in front of

168
00:14:55,180 --> 00:15:01,420
the door for 35 days on average. And at some point during that time, you might be asleep. The

169
00:15:01,420 --> 00:15:05,120
door is going to beep. And you've got to make a mad dash to it. Because it's going to be open

170
00:15:05,120 --> 00:15:12,600
for like three seconds. We have budgets. And I don't think that's going to be within ours. So I

171
00:15:12,600 --> 00:15:16,380
think in practice, this is likely not a thing that you're going to see happen. But it's going to be

172
00:15:16,380 --> 00:15:20,220
something that you're going to see a ton of. Unless the speed changes. Like if you're running

173
00:15:20,220 --> 00:15:26,080
this over a different underlying protocol for some reason that runs at like 10 megabits or like

174
00:15:26,080 --> 00:15:31,360
if for some reason your RS45 installation really is that fast, then this could start getting

175
00:15:31,360 --> 00:15:38,720
really scary. Next is there's a birthday attack in this. Some of you might have already

176
00:15:38,720 --> 00:15:45,880
noticed. So if you just ask the question, like what are the chances that any of these IVs are the

177
00:15:46,380 --> 00:15:52,840
same? On average, with only a 32 bit Mac, you're going to get it at about 77,000 packets on

178
00:15:52,840 --> 00:15:58,200
average. And what that means is if the data is always the same, like if we're in this polling

179
00:15:58,760 --> 00:16:03,460
hack loop, the data is always going to be the same. So our data is just going to loop back

180
00:16:03,460 --> 00:16:09,260
around. So like you can actually observe this happening in practice, too. Which is just like

181
00:16:09,860 --> 00:16:14,580
bizarre and not a good look for a cryptographic protocol. This isn't a vulnerability as far as I

182
00:16:14,580 --> 00:16:18,780
can tell. Because anytime somebody does anything, like if you badge in, it'll perturb the loop

183
00:16:18,780 --> 00:16:23,500
and escape you out of the loop and get you into a new loop. Um, but just like this is not a

184
00:16:23,500 --> 00:16:27,200
thing that a reasonable protocol should be doing. Where you're just like actually sending the

185
00:16:27,200 --> 00:16:32,420
same exact bits, looping back around and reusing IVs is like a thing that has gotten other

186
00:16:32,420 --> 00:16:38,580
protocols into a lot of hot water. Um, so like we should just not be doing this. Um, oh and

187
00:16:38,580 --> 00:16:45,020
then lastly around this is, uh, the key, not key exchange, um, a key derivation for session

188
00:16:45,020 --> 00:16:50,640
keys. So we'll get a bit more into like a key hierarchy that OSTB defines. But the, uh, session

189
00:16:50,640 --> 00:16:55,920
keys, the thing that's like actually used to encrypt data, um, only uses 48 bits of entropy

190
00:16:55,920 --> 00:17:02,200
from the, uh, backend server. So, uh, session keys are derived by having the controller send

191
00:17:02,200 --> 00:17:08,560
the reader a nonce. The, uh, controller then, uh, derives a session key by taking 48 bits of

192
00:17:08,580 --> 00:17:13,900
that nonce, for reasons unknown, um, and then encrypting that with the base key, the higher

193
00:17:13,900 --> 00:17:20,160
level key. Um, and that becomes the session key basically. And maybe somebody in the audience is

194
00:17:20,160 --> 00:17:24,560
cleverer than us and could figure out a way to actually brute force this offline, cause if it

195
00:17:24,560 --> 00:17:29,640
were 48 bits you could. Um, but because it's encrypted by the base key, which the attacker in

196
00:17:29,640 --> 00:17:33,240
this scenario presumably does not know, um, I don't, I couldn't figure out a good way to

197
00:17:33,240 --> 00:17:35,120
enumerate this offline. So.

198
00:17:40,180 --> 00:17:45,000
Cool. All right. So let's actually attack this thing. All right. We have some background. We know

199
00:17:45,000 --> 00:17:50,760
that OSTB supports, uh, both encrypted and unencrypted connections. So we can do something

200
00:17:50,760 --> 00:18:03,140
called a replay attack. Or sorry, a downgrade attack. All right. So let me pause it here,

201
00:18:03,320 --> 00:18:08,080
see, explain what's going on. So on the right hand side, we have our controller.

202
00:18:08,580 --> 00:18:14,240
So we can see that, um, what it's seeing and we can see on the left hand side, um, the, the

203
00:18:14,240 --> 00:18:20,760
communication going between the controller and the reader. So there's a secure channel set up. We

204
00:18:20,760 --> 00:18:25,280
can't see anything, right? Everything's secure. We're gonna swipe in. And there's absolutely

205
00:18:25,280 --> 00:18:30,960
nothing that we can see. Okay. But let's remember that, again, it supports both, right? So

206
00:18:30,960 --> 00:18:37,860
there's sure a way we can mess around with this. So we do it again. This time we try to carry out a

207
00:18:37,860 --> 00:18:45,480
downgrade attack. We try to downgrade. And then we swipe in again. And we can actually see the

208
00:18:45,480 --> 00:18:55,700
card data. Cool. All right. So let's see what we actually did there to make that happen. To decide

209
00:18:55,700 --> 00:18:59,300
if it can establish encryption or not, there's a couple of things that happen first. So the

210
00:18:59,300 --> 00:19:04,320
controller first asks the reader what its capabilities are. And the reader replies, its

211
00:19:04,320 --> 00:19:07,840
capabilities. The capabilities can be a number of variables. So, for example, if you have a

212
00:19:07,860 --> 00:19:11,680
So it is a very interesting thing to us. So it can say, maybe we're talking to a fingerprint

213
00:19:11,680 --> 00:19:15,880
reader, right, or an IRA scanner and it supports biometrics. Maybe we're talking to a

214
00:19:15,880 --> 00:19:21,900
keypad. It's a keypad entry, so the capabilities are the keypad. The one we're interested in here

215
00:19:21,900 --> 00:19:26,480
is communication security. So the communication security bit actually tells the controller

216
00:19:26,480 --> 00:19:33,900
whether or not the reader supports encryption. So let's insert our device in the middle here and

217
00:19:33,900 --> 00:19:37,840
let's wait for that capabilities request. And now, when we think about the information of the

218
00:19:37,860 --> 00:19:42,840
we actually reply, we're going to switch that communication security bit from a one to a zero

219
00:19:43,380 --> 00:19:47,440
and so the controller assumes that there's no encryption set up. It doesn't support

220
00:19:47,440 --> 00:19:54,340
encryption and we can carry on with everything unencrypted. All right. That brings us to

221
00:19:54,340 --> 00:20:01,500
protocol WTF number two. Stop making null ciphers. So Dan explained a little bit about

222
00:20:01,500 --> 00:20:05,940
how what happens when a secure channel is set up. There's basically a four step process in

223
00:20:05,940 --> 00:20:09,400
which the controller and the reader mutually authenticate to each other to make sure that

224
00:20:09,400 --> 00:20:15,680
they each have the same encryption key. Now, as a result of this, when everything works out,

225
00:20:15,800 --> 00:20:21,720
there's four message types that can be sent. SES 15 and 17 which are command from the

226
00:20:21,720 --> 00:20:28,160
controller to the reader or replies 16 and 18 which are, you know, replies from the reader to

227
00:20:28,160 --> 00:20:35,920
the controller. If you read the spec, SES 15 and 16 say that the controller and the reader

228
00:20:35,940 --> 00:20:42,600
even though there's a MAC applied, the data is still unencrypted. Which is wild, right? We're

229
00:20:42,600 --> 00:20:48,620
supposed to be having a secure channel set up with encryption, but yet the data fields are

230
00:20:48,620 --> 00:20:53,020
unencrypted. So that means that in a fully secured session, there is a possibility that the data

231
00:20:53,020 --> 00:20:56,920
is just going to go over the wire. Now, it has a MAC applied to it, so we can't just replay it.

232
00:20:57,620 --> 00:21:01,940
But, you know, we can still just in the case of car data, watch it, clone it and just

233
00:21:01,940 --> 00:21:03,300
authenticate to the readers.

234
00:21:05,940 --> 00:21:11,240
Now, to be fair, the spec does say that those message types are not meant to be used with any

235
00:21:11,240 --> 00:21:21,220
sort of data, but then why have them in the first place, right? All right. This moves us to

236
00:21:21,220 --> 00:21:27,100
demo number three, something we like to call the install mode attack. Ominous sounding.

237
00:21:30,800 --> 00:21:34,680
It's going to already play. Okay. Cool. So what you're going to see here on the right is the

238
00:21:34,680 --> 00:21:39,540
controller that is going to be running in a terminal. This is an intentionally vulnerable

239
00:21:40,100 --> 00:21:44,640
controller software that we wrote that's basically just a lib OSDP sample code, basically,

240
00:21:44,640 --> 00:21:49,240
actually. And on the left is an attack script that we're writing. They're going to be

241
00:21:49,240 --> 00:21:53,380
performing something we call the install mode attack. So we're going to run this with just a

242
00:21:53,380 --> 00:22:00,020
dash dash install flag, run up our server. And this time, we don't just capture a badge number,

243
00:22:00,160 --> 00:22:04,660
we actually steal the encryption key right out from underneath the server. So this is just a

244
00:22:04,660 --> 00:22:13,080
So, how the heck does that work? Let's talk about it. So, OSTP has something a bit like the

245
00:22:13,080 --> 00:22:19,460
SSH security model, which is like a one-time insecure setup. This is not by itself in a

246
00:22:19,460 --> 00:22:25,280
vacuum a bad thing. We don't care about, we don't mind SSH's security model so much. The

247
00:22:25,280 --> 00:22:31,320
problem is that this has to actually be a one-time insecure setup. Like if somebody told you

248
00:22:31,320 --> 00:22:35,040
they found a way of hacking SSH and all you have to do is man the middle of the initial

249
00:22:35,040 --> 00:22:39,200
connection and be like, yeah, that's kind of built into the model. That's not clever or

250
00:22:39,200 --> 00:22:45,300
anything. The problem is when this turns out to not be so one-time. So, controllers and

251
00:22:45,300 --> 00:22:52,960
readers in OSTP have this kind of quasi-official install mode that is specified in the spec, but

252
00:22:52,960 --> 00:22:57,700
it's exact semantics aren't exactly laid out, like when are you supposed to do things and

253
00:22:57,700 --> 00:23:01,300
how are you supposed to behave. A lot of that is just sort of left up to the

254
00:23:01,320 --> 00:23:07,940
individual implementers. So, in this install mode, as the name suggests, this is not the

255
00:23:07,940 --> 00:23:13,280
exact packets, but the reader is able to ask it like, hey, what's the encryption key? I'm

256
00:23:13,280 --> 00:23:17,100
just trying to get set up here. And the controller just goes, here you go, here's the

257
00:23:17,100 --> 00:23:24,520
key. Because like that's what the install mode is supposed to do. The problem happens when

258
00:23:24,520 --> 00:23:30,960
this install mode persists. If it happens to last more than just this like short ephemeral moment

259
00:23:30,960 --> 00:23:36,800
when you're initially installing a reader. So, if you happen to have a controller that is just

260
00:23:36,800 --> 00:23:42,540
like hanging out in install mode persistently, then an attacker can just show up on the bus, ask

261
00:23:42,540 --> 00:23:47,400
the controller, hey, what's the encryption key? I'm a reader. And it will just respond to you

262
00:23:47,400 --> 00:23:56,860
and say, here's the key. And the keys in this case are unique per reader controller pair. But

263
00:23:56,860 --> 00:24:00,940
that ID is just a public ID. In fact, it's usually written on the reader controller. So, it's

264
00:24:00,940 --> 00:24:05,960
written on the back of the reader itself. So, like you could just lie about your ID and get the

265
00:24:05,960 --> 00:24:14,040
key for any reader on the building. So, this brings us to this point of like where exactly do

266
00:24:14,040 --> 00:24:18,820
these vulnerabilities lie? So, we've been kind of picking on the protocol and I think there's a

267
00:24:18,820 --> 00:24:24,200
fair number of things to pick about the protocol. But like there's lots of other places depending

268
00:24:24,200 --> 00:24:30,100
on how you want to kind of squint and look at it that the vulnerabilities could exist on. So, you

269
00:24:30,100 --> 00:24:34,460
could think of this as a library bug, some of these. Like whatever the library does is probably

270
00:24:34,460 --> 00:24:38,480
what's going to be out there in practice, right? Like who is going to go out and roll their own

271
00:24:38,480 --> 00:24:44,460
library just for this? So, like you could argue that like the behavior of the popular

272
00:24:44,460 --> 00:24:48,560
libraries is the thing that needs to change here. That's where the fault really lies. You could

273
00:24:48,560 --> 00:24:53,220
argue that this is a configuration problem. A lot of these vulnerabilities can be fixed in

274
00:24:53,220 --> 00:24:59,020
configurations. Like you should configure your controllers to not sit around persistently in install

275
00:24:59,020 --> 00:25:04,960
mode. And maybe that's not crazy. You could argue that it's a documentation problem. That

276
00:25:04,960 --> 00:25:10,300
like the exact behaviors of how these things are supposed to work is like maybe not documented

277
00:25:10,300 --> 00:25:14,400
well or maybe it is but nobody knows where that's at. And so, like maybe better documentation

278
00:25:14,400 --> 00:25:18,900
could get us out of this problem. You could argue that this is an implementation bug. That the

279
00:25:18,900 --> 00:25:25,000
individual like implementers of the controller hardware are responsible for setting these

280
00:25:25,000 --> 00:25:28,840
things up properly and what admin is going to go out and tinker with the settings of the fine

281
00:25:28,840 --> 00:25:33,020
grain level. Like whatever is out there in implementation is probably what's going to be out

282
00:25:33,020 --> 00:25:38,740
there in practice. You could also argue that this is a marketing problem. That a lot of devices

283
00:25:39,210 --> 00:25:46,020
such as our AXA 1001 just say that they support OSDP but that's not like a legally defensible

284
00:25:46,020 --> 00:25:53,320
like term. Whereas there's actually an OSDP verified like program where you can put your

285
00:25:53,320 --> 00:25:58,260
hardware into the people that make the specification and they can like certify it as not like

286
00:25:58,260 --> 00:26:03,360
secure in some abstract sense but at least that it like does the protocol and does all of the

287
00:26:03,360 --> 00:26:10,960
protocol like the encryption parts. Where like you might just have an entire OSDP set up at home.

288
00:26:11,180 --> 00:26:16,940
Probably not at home. At your office. And think like I'm all secure. Like I bought all this

289
00:26:16,940 --> 00:26:20,380
stuff. I spent a whole bunch of money upgrading it. And you could very well go back to your

290
00:26:20,380 --> 00:26:24,940
office and discover that none of it is encrypted. It's all just plain text. And that's not

291
00:26:24,940 --> 00:26:28,240
great. And that's also partly a marketing problem. So, it's pretty much the same thing. It's not

292
00:26:28,240 --> 00:26:33,200
pretty easy to see how these vulnerabilities could just pass by people. Because no matter who

293
00:26:33,200 --> 00:26:37,320
you are in this setup, there's always somebody else you could possibly blame and think like,

294
00:26:37,400 --> 00:26:40,460
well, it's not really my problem. It's whoever is going to configure the stupid thing.

295
00:26:44,920 --> 00:26:49,980
Okay. Let's step it up a bit. Let's look at what happens in when everything is set up

296
00:26:49,980 --> 00:26:56,500
properly, right? And how the secure channel is supposed to work. So, this is protocol

297
00:26:56,500 --> 00:26:57,620
what the fuck number three.

298
00:26:58,760 --> 00:27:07,300
Oops. Okay. So, this is what we expected of message 17 and 18. We expected to see the

299
00:27:07,300 --> 00:27:12,160
header in plain text and then the command bytes and the data encrypted. But this is what we

300
00:27:12,160 --> 00:27:19,620
actually see. So, the only thing that's encrypted in a fully secure channel set up is the data.

301
00:27:19,820 --> 00:27:25,300
Now, why does it matter? Why is the command byte important? Well, the command byte is what

302
00:27:25,300 --> 00:27:28,220
tells us what the message type is. It tells us what the message type is. It tells us what the

303
00:27:28,220 --> 00:27:34,600
command was, what the reply is. So, we know what kind of data it is in that packet. Some of

304
00:27:34,600 --> 00:27:40,960
the interesting ones we want to look at are the OSDP raw. All right. This one contains raw card

305
00:27:40,960 --> 00:27:43,960
data. So, we see it going over the wire. We might want to look at that packet a little more.

306
00:27:44,780 --> 00:27:51,720
There's the FMT packet which has formatted card data. The keypad is self-explanatory. The

307
00:27:51,720 --> 00:27:56,600
bioreader, I keep going back to the bioreader ones because they're just very interesting to me. I

308
00:27:56,600 --> 00:27:58,200
haven't had a chance to poke at them. Because they have like one of theографical commands and so

309
00:27:58,200 --> 00:28:04,540
hoping that's the next step here. Okay. And then there's the OSDP keyset message. So the

310
00:28:04,540 --> 00:28:09,100
keyset message is the command from the controller to the reader where the session base key is

311
00:28:09,100 --> 00:28:14,660
delivered. And basically then the encryption key for every message is derived from the

312
00:28:14,660 --> 00:28:18,500
session base key. So we can get our hands on that base key, we can compromise the

313
00:28:18,500 --> 00:28:28,180
communications. Which brings us to the next demo. The weak keys attack. Okay. So

314
00:28:31,540 --> 00:28:37,120
once again, we have the controller and our attack script here. And we're testing for weak

315
00:28:37,120 --> 00:28:45,260
keys. And we just found a weak key. So we find the weak key, we can decrypt the packets now. And

316
00:28:45,260 --> 00:28:51,820
we can intercept that keyset message. Cool. So what happened? First off, before I dive in, this

317
00:28:51,820 --> 00:28:55,660
is not a protocol specific issue. This is something of an implementation issue that we've

318
00:28:55,660 --> 00:28:58,180
observed with a lot of open source libraries. And it's not a protocol specific issue. This is

319
00:29:01,500 --> 00:29:02,400
a type of code we've been using for a while. And I think that's what we

320
00:29:02,400 --> 00:29:09,620
started with. We think a lot of the、 i guess the code for it. Okay. So there is a hierarchy of keys

321
00:29:09,620 --> 00:29:13,840
here. There's a master key which lives in the controller. The master key never leaves the

322
00:29:13,840 --> 00:29:17,940
controller, but it is used to derive the session base key, which is the one we just spoke about.

323
00:29:18,620 --> 00:29:28,160
And then there's the encryption key for all the actual messages, which is derived from the base key. Now, in the newer implementations of OSDP, this pack actually is a key that, I guess,'s removed

324
00:29:28,180 --> 00:29:34,180
it takes out the master key and it recommends eliminating it and instead somehow generating

325
00:29:35,100 --> 00:29:39,580
and delivering the session basically. Now it doesn't say how to do that. So we've seen things

326
00:29:39,580 --> 00:29:47,000
like this. We've actually seen hard coded simple keys for the SCBK. And again this isn't

327
00:29:47,000 --> 00:29:51,940
just one library we've seen a number of these. So what does that mean from our attacking

328
00:29:51,940 --> 00:29:56,200
perspective? Now we're not going to say we're going to brute force the whole 128 bit

329
00:29:56,200 --> 00:30:02,880
space. That'd be silly. But what we can do is try say about a thousand weak keys, right? We can

330
00:30:02,880 --> 00:30:07,900
try repeating characters, we can try increasing and decreasing characters and so on. If we

331
00:30:07,900 --> 00:30:11,740
manage to actually find a reader that's using these hard coded keys then we can recover the

332
00:30:11,740 --> 00:30:18,640
encryption key and compromise that session. All right. This brings us to protocol WTF

333
00:30:18,640 --> 00:30:24,700
number four. Encryption is not magic fairy dust which was also the very nearly the title of

334
00:30:24,700 --> 00:30:26,180
this entire topic. Uh, it's not magic fairy dust. Uh, it's not magic fairy dust. Uh, it's

335
00:30:26,180 --> 00:30:31,060
the another possible alternate title was just because you did it on purpose doesn't mean it's

336
00:30:31,060 --> 00:30:38,180
not a vulnerability. Um, so let's go back to this. Uh, some bold marketing claims about things

337
00:30:38,180 --> 00:30:42,520
being unhackable. Um, while we can all get a good laugh out of this. Um, one thing that it

338
00:30:42,520 --> 00:30:48,180
said was true which is that it does in fact use 128 bit AES encryption. That is in fact true. So

339
00:30:48,600 --> 00:30:54,740
good on them. Um, the problem however is that we only use AES. As in there's no asymmetric

340
00:30:54,740 --> 00:31:00,220
cryptography at all in the spec whatsoever. So naturally cryptographers amongst you are

341
00:31:00,220 --> 00:31:05,660
wondering so how do we do key exchange exactly then, right? So if there's no cryptography then

342
00:31:05,660 --> 00:31:11,320
like how, how do, how do the reader and the controller exchange keys? Ah, dear listener, this

343
00:31:11,320 --> 00:31:16,880
is maybe easier than you think. You just send the key. Um, no, okay, okay, okay. We

344
00:31:16,880 --> 00:31:23,700
can't just send the key unencrypted, right? That would be insecure. So we encrypt the key. But,

345
00:31:25,280 --> 00:31:29,160
cryptographers amongst you are scratching their heads right now. With what do we encrypt the

346
00:31:29,160 --> 00:31:35,640
key? If we are trying to send the key. Ah, that's a good question. We use the SCBKD which is

347
00:31:35,640 --> 00:31:43,400
the secure channel base key default. Default meaning that's it. That's the key. It's just the

348
00:31:43,400 --> 00:31:50,600
ASCII numbers zero to half, um, in hex. Like this is not how encryption works. Like you

349
00:31:50,600 --> 00:31:54,720
can't just like sprinkle some like crypto on something and say like, where are you going? You

350
00:31:54,740 --> 00:32:00,260
we encrypted it, boss. There's no point in this whatsoever. It's just like a really fancy

351
00:32:00,260 --> 00:32:05,900
encoding mechanism that only serves to give you a false sense of security and thinking,

352
00:32:05,980 --> 00:32:10,060
like, I don't know, the thing says it's encrypted right now and I can't read it, so I guess

353
00:32:10,060 --> 00:32:16,720
it's good, right? Like, this is not the air bug rules of cryptography where, like, you

354
00:32:16,720 --> 00:32:20,540
can't just, like, there's nothing in the rules that says a default key can't be an

355
00:32:20,540 --> 00:32:29,640
encryption key. Cool. Okay. So this brings us to our final demo, and actually my

356
00:32:29,640 --> 00:32:42,560
favorite one, because just what it actually means. Cool. So, again, we're attacking the

357
00:32:42,560 --> 00:32:49,620
controller, and we managed to capture the encryption key. So how do we capture the

358
00:32:49,620 --> 00:32:50,040
encryption key?

359
00:32:51,500 --> 00:32:56,320
Up to this point, a lot of what we've discussed can be attributed to misconfigurations, right?

360
00:32:56,460 --> 00:33:01,980
Not so much, like, other than the WTFs, a lot of it is the reader being left in install

361
00:33:01,980 --> 00:33:07,640
mode or supporting both secure channel and unencrypted traffic. So what happens if best

362
00:33:07,640 --> 00:33:12,260
practices are followed? First of all, I think a lot of us know that best practices usually

363
00:33:12,260 --> 00:33:17,300
aren't followed. But let me walk you through a scenario of how we would attack a completely

364
00:33:17,980 --> 00:33:18,840
secure setup.

365
00:33:19,520 --> 00:33:20,140
Number one.

366
00:33:20,140 --> 00:33:27,220
We insert our listening device. Number two, we need to break a reader. Number three, we need to wait

367
00:33:27,220 --> 00:33:33,260
for IT to replace that reader. And number four, we capture the key set command. So this is how it

368
00:33:33,260 --> 00:33:37,900
actually works. So let's say we show up on a site where we want to break in, right? We have the

369
00:33:37,900 --> 00:33:42,020
top secret door we want to gain access to, and we have maybe a side door that's not so well

370
00:33:42,020 --> 00:33:46,900
guarded. Everything is set up correctly. There's no possibility for downgrade attack. Everything is

371
00:33:46,900 --> 00:33:48,080
encrypted with a session-based key.

372
00:33:49,500 --> 00:33:55,380
Well, we're still going to go and insert our listening device behind the not so very secret door.

373
00:33:55,480 --> 00:34:03,460
Again, let's remember that OSDP on RS485 supports multiple readers. So that's kind of a that's

374
00:34:03,460 --> 00:34:08,120
what's going to make the attack practical for us. I'm going to go ahead and insert it on that same

375
00:34:08,120 --> 00:34:13,440
bus somewhere where that's not well guarded. Now, we need to break the reader we're interested

376
00:34:13,440 --> 00:34:18,060
in. How we do that, it's up to you. So you can either use an NDP or you can use the NDP. So we're

377
00:34:18,080 --> 00:34:22,320
going to go to the NFC app on your phone, go up to the reader and mess around with its settings,

378
00:34:22,360 --> 00:34:27,540
which is actually something you can do with a lot of readers we tested. Or you can literally go up

379
00:34:27,540 --> 00:34:32,200
and rip the reader off the wall. Doesn't matter how you do it. You just need to break it. Now,

380
00:34:32,220 --> 00:34:36,940
what's going to happen? Well, they're going to need to replace that reader or they're going to

381
00:34:36,940 --> 00:34:42,100
need to repair it. And so they need to deliver that key to that reader, right, to set up the

382
00:34:42,100 --> 00:34:48,060
secure channel encryption. Well, if we're on the bus listening to everything, we're going to need to

383
00:34:48,060 --> 00:34:51,460
do that. We know that that key set message is going to be delivered with the default base key,

384
00:34:51,540 --> 00:34:56,200
which means we're going to be in a position where we can capture it when the reader is being set

385
00:34:56,200 --> 00:35:01,800
up. Which means after everything is set up, we now have the session base key and we can decrypt

386
00:35:01,800 --> 00:35:09,540
all the traffic going to the top secret door. Cool. All right. So what do we do? How do I

387
00:35:10,060 --> 00:35:15,600
defend? Let's look at what we can do from the blue team side. First, check your configuration. So

388
00:35:18,060 --> 00:35:22,640
we have the default base key, which is actually enforced. We need to make sure that there is no

389
00:35:22,640 --> 00:35:28,500
possibility that we can downgrade that. So the readers that support encryption, sorry, the

390
00:35:28,500 --> 00:35:33,800
controllers that support encryption usually have an option that just does not allow it to be for

391
00:35:33,800 --> 00:35:39,400
communications to carry on unencrypted. And disable the install mode. Now, something that Dan

392
00:35:39,400 --> 00:35:45,740
failed to mention is, when we were doing the testing for this, we actually tested this on a

393
00:35:45,740 --> 00:35:48,040
production site where the install mode was in this case. So we are going to have to place that in a

394
00:35:48,060 --> 00:35:53,420
left on. So it's not, you know, it's not a theoretical misconfiguration. We've actually

395
00:35:53,420 --> 00:35:57,220
seen that in production. So whenever it's set up, make sure to disable the install mode.

396
00:36:01,120 --> 00:36:05,980
So this is a recommendation that I'm going to give to you that you are definitely not going

397
00:36:05,980 --> 00:36:11,840
to do. But I'm going to say it anyway. So to never configure a reader in production,

398
00:36:12,080 --> 00:36:16,520
meaning this is basically a way of inventing your own out of band key exchange mechanism.

399
00:36:16,520 --> 00:36:23,720
So rather than ever using the production wires as in like the reader on the wall using the wires

400
00:36:23,720 --> 00:36:30,100
that are in your building, since the entire point of putting encryption on this thing is

401
00:36:30,100 --> 00:36:34,880
assuming that those wires are compromised, there could be somebody listening, that like doing

402
00:36:34,880 --> 00:36:40,020
an insecure key exchange over that mechanism is just hazardous. So what you could do is if you

403
00:36:40,020 --> 00:36:45,400
need to install a reader, to take the reader off the wall, walk it over to the controller with

404
00:36:45,400 --> 00:36:51,620
your feet, plug it into the controller with like a two-foot wire that you're reasonably sure has

405
00:36:51,620 --> 00:36:57,200
no listening device on it, do the key configuration there. Do the key exchange there. Take the

406
00:36:57,200 --> 00:37:03,140
reader, walk it back to the door with your feet, and then put it back onto the wall. You have to

407
00:37:03,140 --> 00:37:07,480
do this every single time a reader has any kind of an error or needs to be reconfigured or

408
00:37:07,480 --> 00:37:13,120
replaced. For a significantly large building, this is going to be utterly untenable. But

409
00:37:13,760 --> 00:37:15,380
nonetheless, this is a thing you could do. This is a thing you could do. This is a thing you could

410
00:37:15,400 --> 00:37:21,080
do. That way, any time the key exchange happens, it's never done over the production wires where

411
00:37:21,080 --> 00:37:25,860
somebody is actually listening. So if you're like extremely paranoid and this is a thing you want

412
00:37:25,860 --> 00:37:32,540
to do, then go ahead. It sort of defeats the purpose of like having this whole system, but it's

413
00:37:32,540 --> 00:37:39,080
a thing that you could do. Never ignore tamper alarms. Modern readers have a little button on

414
00:37:39,080 --> 00:37:43,300
the back of them. That is like a tamper alarm. And in practice, when you are a red teamer and

415
00:37:43,300 --> 00:37:45,380
you're going to be performing this attack, you're likely to do a tamper alarm. You're likely to do a

416
00:37:45,400 --> 00:37:50,720
tamper alarm. It's literally just like a button that when you have the reader against the wall,

417
00:37:50,820 --> 00:37:55,500
it's pressed in. And then when you like unscrew it with a Phillips head screwdriver to access the

418
00:37:55,500 --> 00:38:00,140
wires behind it, it un-presses that button and then sends a little signal out to the controller

419
00:38:00,140 --> 00:38:06,500
that says, I've been tampered with. And like what happens on the controller is kind of up to you as

420
00:38:06,500 --> 00:38:11,400
a blue team. Maybe that just goes and gets into a log somewhere that somebody will notice in

421
00:38:11,400 --> 00:38:15,380
several months. Don't let that happen. There's often, you know, there's a lot of things that

422
00:38:15,400 --> 00:38:19,020
happen. Often other mitigating physical controls around these sorts of doors, especially in

423
00:38:19,020 --> 00:38:24,220
physical security systems for high secure facilities. So like maybe take a tamper alarm and

424
00:38:24,220 --> 00:38:28,360
like start recording with the camera when that happens or something if there's a camera there.

425
00:38:28,520 --> 00:38:32,560
Like whatever you do, don't ignore these things because if you're being attacked for real,

426
00:38:32,720 --> 00:38:41,160
you're likely to get one of these things. It is probably possible to like tamper or to get

427
00:38:41,160 --> 00:38:45,080
access to the wires behind a reader without triggering a tamper alarm, but that's like a whole

428
00:38:45,400 --> 00:38:48,760
tougher thing that we didn't bother getting into because it's sort of its own rabbit hole.

429
00:38:49,280 --> 00:38:53,120
Maybe there's a clever little like device you could use to like insert behind it and press the

430
00:38:53,120 --> 00:39:00,420
button in and then pull it out. I don't know. That's not me. Buy OSDB verified devices. So if

431
00:39:00,420 --> 00:39:05,440
you're a blue teamer or if you're setting up badge control systems for your work, look for this

432
00:39:05,440 --> 00:39:10,600
little like check box thing. Don't just buy some random box off the Internet that says it

433
00:39:10,600 --> 00:39:15,320
supports OSDB because it might just like not even support encryption. Like we literally bought,

434
00:39:15,400 --> 00:39:21,060
bought a device on eBay for like $300 because we wanted to test OSDB encryption and it turned

435
00:39:21,060 --> 00:39:28,160
out to not support encryption. So I made that mistake and I bet you could, too. And then lastly,

436
00:39:28,300 --> 00:39:33,260
don't trust things just because it's encrypted. Cryptographic protocols are really hard and

437
00:39:33,260 --> 00:39:37,640
security is hard. And just because it has encryption on it doesn't make it like secure

438
00:39:37,640 --> 00:39:42,040
magically. And then that is all. Thanks a lot.

439
00:39:48,500 --> 00:39:53,600
I think that we have time for some questions. There is a microphone right in the

440
00:39:53,600 --> 00:39:57,380
middle here. If you'd like to ask a question, you can go up to the microphone there.

441
00:39:57,500 --> 00:40:03,560
Alternatively, you can just shout really loud. And I could probably hear you if you do that. If

442
00:40:03,560 --> 00:40:11,680
not, then we'll just be kind of milling about here. And then how am I splicing 485? Oh, yeah.

443
00:40:11,740 --> 00:40:15,380
You can basically just punch into it. So it's a differential for the question. I'll give you a

444
00:40:15,380 --> 00:40:21,000
couple of questions. Repeat the question. How are we interfacing with the RS-485 from a physical

445
00:40:21,000 --> 00:40:26,120
perspective? And you can just tap into it, basically, so it's a differential signal. And

446
00:40:26,120 --> 00:40:31,560
because it's multi-drop, it's meant to be used in that kind of configuration, basically. So,

447
00:40:31,580 --> 00:40:37,500
yeah, you can just kind of tap into it. Also, for our device, I'm tapping into the power line as

448
00:40:37,500 --> 00:40:42,820
well just to get power from it. So you get the data lines, it's a differential signal, so you get

449
00:40:42,820 --> 00:40:44,280
like power in, power out.

450
00:40:44,720 --> 00:40:45,360
So, yeah.

451
00:40:45,380 --> 00:40:50,120
Data and then negative data. And then you'll also have power lines. In theory, you could use a

452
00:40:50,120 --> 00:40:54,420
battery, but we figured it was just going to be easier to tap into the power lines as well. So,

453
00:40:54,540 --> 00:41:02,660
yeah. Yes, all of our, the tools are on our GitHub. It's GitHub.com slash Bishop Fox. You'll

454
00:41:02,660 --> 00:41:07,020
find all the code there. We have the hardware schematics for the hardware itself, as well as

455
00:41:07,020 --> 00:41:14,640
some code. Oh, yeah. We actually have a bunch of PCBs to give away. We have a hundred, like,

456
00:41:14,640 --> 00:41:20,060
melon PCBs if you want to nag one. It doesn't have the rest of the components on them, so you'll have to do

457
00:41:20,060 --> 00:41:25,080
some soldering. But, yeah, we've got some PCBs if you want to get one. We have to bug this guy. He's

458
00:41:25,080 --> 00:41:30,200
got them. Yes, question? People are going for the shouting option more than I thought they were

459
00:41:30,200 --> 00:41:39,920
going to. You have to shout. Yes. So, the spec is open. In fact, it's so open that anyone can

460
00:41:39,920 --> 00:41:44,620
purchase it for $200 online. That is the only official way to do it. So, yeah, we've got a bunch of

461
00:41:44,620 --> 00:41:48,140
things. So, yeah, that's the only way of getting access to it. So, one of the things you mentioned

462
00:41:48,140 --> 00:41:53,500
about parsing a packet and resetting parts of it. Yeah. How would you actually do that if it was

463
00:41:53,500 --> 00:42:00,920
sitting on the bus? Yeah. So, the question for those listening is, like, in one of the attacks,

464
00:42:01,100 --> 00:42:04,840
the downgrade attack, we're going to modify the capabilities packet. Like, how are we doing that

465
00:42:04,840 --> 00:42:09,240
if we're just passively tapping? For that attack, we're just not for the hardware device. We have,

466
00:42:09,280 --> 00:42:13,680
kind of, like, two versions of the code. There's one that's Python that's, like, meant to run on a

467
00:42:13,680 --> 00:42:18,700
laptop with big RS-485 adapters in the middle. And then for the initial version of our hardware

468
00:42:18,700 --> 00:42:22,020
device that's, like, miniaturized down into, like, a one inch by one inch thing, we decided to just

469
00:42:22,020 --> 00:42:26,160
make it a passive tap. So, we're not doing the man in the middle attacks. And that would be one

470
00:42:26,160 --> 00:42:29,980
of them. So, yeah, that one, the install mode attack is not part of the hardware one at this

471
00:42:29,980 --> 00:42:34,040
point. Maybe we'll make a separate one that has, like, a proper man in the middle. But you'd have

472
00:42:34,040 --> 00:42:39,540
to, like, snip the wire and then get it in the middle and then, like, I don't know. That seems

473
00:42:39,540 --> 00:42:43,660
like a lot for red teaming. So, we would just have avoided it. So, yeah. So, yeah. So, yeah. So,

474
00:42:44,200 --> 00:42:45,180
cool. Thanks. Yeah.