1 00:00:02,100 --> 00:00:06,140 Thanks for coming out. This is our talk, Unlocking Doors from Half a Continent Away. 2 00:00:06,740 --> 00:00:19,120 I hope you have some fun. My name is Trevor Stavato. I'm the founder of a small cybersecurity company up in Canada called Loudmouth Security. 3 00:00:19,620 --> 00:00:26,060 I've been doing offensive stuff for, I think, I counted about 15 years now, but I just stopped counting and put 12 plus in the slides. 4 00:00:26,060 --> 00:00:36,480 My biggest personal or professional achievement, it was winning a DEF CON Black Badge back at DEF CON 26. Thank you. 5 00:00:40,300 --> 00:00:47,740 Hi, my name is Sam Haskins. I'm a hacker working for Loudmouth Security. 6 00:00:48,420 --> 00:00:54,360 I'm also a current computer science student at Carleton University up in Ottawa in the computer and internet security stream. 7 00:00:54,680 --> 00:00:56,040 I've been hacking things for a long time. 8 00:00:56,060 --> 00:00:57,960 I've been hacking since I was 12, at least. 9 00:00:58,240 --> 00:01:01,880 I have two CVEs from ages 16 and 19. That was just last year. 10 00:01:02,500 --> 00:01:06,100 This is my second year at DEF CON, and I'm really excited and happy to be here. 11 00:01:06,200 --> 00:01:07,100 I'm just a little bit scared. 12 00:01:14,280 --> 00:01:17,280 All right, so we're going to be talking about physical access systems. 13 00:01:17,440 --> 00:01:22,100 So just to give you a quick background of all the components, you have a card that has the credential on it. 14 00:01:22,360 --> 00:01:24,900 The reader that's going to read that credential off the card. 15 00:01:24,900 --> 00:01:31,940 Send that information back to a back-end access controller that will validate that credential, make sure it's valid for the door it's trying to open. 16 00:01:32,220 --> 00:01:36,860 If it is, it'll send a signal to the lock, opens the door, opens Sesame, you're golden. 17 00:01:38,160 --> 00:01:42,180 We're going to be focusing mostly, well, entirely on the card to reader interactions. 18 00:01:43,160 --> 00:01:48,520 And in that space, there's quite a few technologies that have been a part of this. 19 00:01:48,600 --> 00:01:54,260 And we'll go through some of them just for history's sake, but our attack is going to be on some of the newest technologies. 20 00:01:54,260 --> 00:01:56,180 My Fair Deathfire and CEOS. 21 00:01:59,340 --> 00:02:07,080 So the purpose of physical access, what it's trying to do is it's trying to validate that there's a physical presence of a credential at a specific time. 22 00:02:07,180 --> 00:02:08,620 So that's what the reader is trying to do. 23 00:02:09,700 --> 00:02:15,440 And so because of that, there's some ways that we have come up with, people have come up to attack it. 24 00:02:15,960 --> 00:02:18,920 The first one is the most basic card cloning attack. 25 00:02:19,040 --> 00:02:23,760 If you can see a card, capture the data off of it, write that to a new card. 26 00:02:24,260 --> 00:02:25,240 Present that to a reader. 27 00:02:25,400 --> 00:02:27,660 It has no idea that it's a different card. 28 00:02:27,800 --> 00:02:31,400 So you have a duplicate and you can authenticate as the original card. 29 00:02:32,220 --> 00:02:35,440 A kind of offshoot of that one is a downgrade attack. 30 00:02:35,800 --> 00:02:41,520 So if you have a technology that can't be cloned, but you can read it with a standard reader, 31 00:02:41,920 --> 00:02:47,880 you can take the data that it's trying to send to the back end and code that on a lower frequency or lower security card. 32 00:02:48,120 --> 00:02:52,440 And if the reader will accept both, then you've duplicated the card just as effectively. 33 00:02:54,960 --> 00:02:59,080 The other category that I don't see very much in the physical security space, 34 00:02:59,280 --> 00:03:02,060 but we just put it in for posterity, is the replay attack. 35 00:03:02,300 --> 00:03:07,060 So if you can capture a sequence of messages between a card and a reader and then replay that, 36 00:03:07,180 --> 00:03:10,460 you may be able to trick a reader into thinking that there is a credential there at that time. 37 00:03:11,920 --> 00:03:17,780 And then the final one, the one that we're going to be talking most about and doing the demos of today, is the relay attack. 38 00:03:18,180 --> 00:03:22,460 And you might be familiar with this in the space of car thefts, 39 00:03:22,460 --> 00:03:28,880 where people are putting readers up next to your door and trying to relay the signal from your key fobs to your car. 40 00:03:29,300 --> 00:03:33,260 The same kind of thing that we're doing with RFID cards. 41 00:03:33,380 --> 00:03:40,280 We're going to try to relay an RFID card over a very long distance and just show you how that can be done. 42 00:03:41,800 --> 00:03:47,440 So to give you some context about how we got started down this path of research, 43 00:03:48,300 --> 00:03:52,020 it's good to know what the history of access control technologies are 44 00:03:52,020 --> 00:03:55,680 and what the flaws were that kind of led them to where they are today. 45 00:03:56,840 --> 00:04:02,120 So one of the original technologies, the HID Prox, a very simplistic technology. 46 00:04:03,260 --> 00:04:06,120 Once the card got energized, it broadcasts its ID. 47 00:04:06,300 --> 00:04:07,940 Anybody around can listen to it. 48 00:04:08,280 --> 00:04:10,580 Super insecure. There's no encryption on it. 49 00:04:11,160 --> 00:04:14,060 You can buy a reader from Amazon for very cheap. 50 00:04:15,300 --> 00:04:18,340 Fun fact, my very first DEF CON was DEF CON 21. 51 00:04:18,680 --> 00:04:22,000 I went to go see the Bishop Fox talk on the task force. 52 00:04:22,020 --> 00:04:25,080 He was a classic RFID thief where he took a garage door reader, 53 00:04:25,240 --> 00:04:27,200 it was a high-powered garage door reader, 54 00:04:27,400 --> 00:04:32,020 and basically tagged onto the data line so he could record the card data. 55 00:04:32,220 --> 00:04:36,360 But that extended his read range from a couple of inches to a couple of feet. 56 00:04:36,560 --> 00:04:39,280 And he would walk around with that in a briefcase and collect cards. 57 00:04:39,720 --> 00:04:40,780 It's a pretty fun talk. 58 00:04:41,000 --> 00:04:43,400 I still have the piece that I got from it, 59 00:04:43,440 --> 00:04:48,360 and it kind of inspired some of the stuff that moved me forward into this talk. 60 00:04:50,360 --> 00:04:51,560 So HID realized, 61 00:04:52,020 --> 00:04:53,220 that wasn't a good idea. 62 00:04:53,320 --> 00:04:55,940 So they came up with another version called the HID iClass. 63 00:04:56,620 --> 00:04:59,500 And it was designed to protect card cloning replays. 64 00:04:59,520 --> 00:05:03,880 The way they did that was they had a key between the card and the reader, 65 00:05:03,960 --> 00:05:06,140 a shared key that only they knew. 66 00:05:08,380 --> 00:05:11,740 HID created one shared key between the card and reader 67 00:05:11,740 --> 00:05:13,460 for most of the systems that they released. 68 00:05:14,140 --> 00:05:15,960 If you wanted to have a special key, 69 00:05:16,180 --> 00:05:18,520 you had to ask HID to create a new one for you, 70 00:05:18,560 --> 00:05:20,120 and they called that the Elite Key System. 71 00:05:20,280 --> 00:05:21,900 So only your readers, 72 00:05:22,020 --> 00:05:22,700 and your cards, 73 00:05:22,800 --> 00:05:23,820 would use that shared key. 74 00:05:24,280 --> 00:05:27,460 And it was done through a proprietary cipher that they created, 75 00:05:28,060 --> 00:05:30,680 which was then reverse engineered by some researchers. 76 00:05:31,000 --> 00:05:33,420 And they came up with a key recovery attack, 77 00:05:33,680 --> 00:05:37,360 where you can recover the keys of any, 78 00:05:37,440 --> 00:05:38,260 not just the standard, 79 00:05:38,380 --> 00:05:39,660 but even the elite keyed readers. 80 00:05:39,980 --> 00:05:43,960 So now it's trivially simple 81 00:05:43,960 --> 00:05:48,260 to create a copy of an iClass card using things like the Proxmark. 82 00:05:51,000 --> 00:05:55,360 Another kind of entry in the mid-range RFID is the Mifare Classic. 83 00:05:55,620 --> 00:05:58,120 So we don't see this very often used in access control, 84 00:05:58,360 --> 00:06:01,440 but it's kind of the precursor to the Desfire EV1 85 00:06:01,440 --> 00:06:03,240 that sometimes does get into access control. 86 00:06:03,400 --> 00:06:05,580 So we thought we'd throw it in as well. 87 00:06:07,240 --> 00:06:08,800 It uses a different mechanism. 88 00:06:08,900 --> 00:06:10,480 It has keys for each sector, 89 00:06:10,600 --> 00:06:13,820 and you can have two keys that you can define as a read or a write key. 90 00:06:14,200 --> 00:06:17,200 But again, they used a proprietary algorithm for that crypto. 91 00:06:17,200 --> 00:06:19,580 And again, it was reverse engineered by a team of researchers. 92 00:06:20,660 --> 00:06:24,580 So very easy to copy and clone Mifare Classic cards. 93 00:06:26,580 --> 00:06:29,840 I think this is about the point where both HID and NXP, 94 00:06:29,920 --> 00:06:30,860 who make the Mifare cards, 95 00:06:31,160 --> 00:06:34,520 kind of realized that maybe making proprietary crypto 96 00:06:34,520 --> 00:06:35,700 was not a good idea. 97 00:06:36,400 --> 00:06:40,160 And you can see that in a lot of their marketing about the new technology. 98 00:06:40,380 --> 00:06:42,460 So the new one for HID is CIOS. 99 00:06:43,900 --> 00:06:44,780 And Mifare... 100 00:06:45,740 --> 00:06:47,180 NXP came out with the Mifare Deck. 101 00:06:47,200 --> 00:06:47,400 It's called Desfire. 102 00:06:47,640 --> 00:06:50,280 And there's a couple of variants of that, EV1, 2, and 3. 103 00:06:50,800 --> 00:06:54,180 And so they all use industry standard ciphers. 104 00:06:54,420 --> 00:06:59,200 And the worthwhile thing to note is that EV1 came out in 2006. 105 00:06:59,600 --> 00:07:05,460 So 17 years since EV1 came out in CIOS after that in 2012, 106 00:07:06,180 --> 00:07:10,560 there's been no public techniques disclosed to clone a CIOS card. 107 00:07:11,920 --> 00:07:15,420 The only attack that is currently known... 108 00:07:15,420 --> 00:07:17,800 Well, before what we're going to show today, I guess, 109 00:07:17,900 --> 00:07:18,980 is the downgrade attack. 110 00:07:19,640 --> 00:07:25,040 So if you have a CIOS reader that has a standard key set 111 00:07:25,040 --> 00:07:26,640 and your card is in the standard key set, 112 00:07:26,820 --> 00:07:29,220 you could read the data off the back end, 113 00:07:29,980 --> 00:07:33,120 program that onto a low frequency or a lower security card, 114 00:07:33,280 --> 00:07:34,860 and create a duplicate that way. 115 00:07:35,380 --> 00:07:39,200 But that can be easily defeated by using elite keyed systems, 116 00:07:39,500 --> 00:07:42,320 because then you would have to have a reader that has that same elite key. 117 00:07:42,880 --> 00:07:44,860 So if you're targeting a facility, 118 00:07:44,860 --> 00:07:46,760 you'd have to go and rip that reader off the wall, 119 00:07:46,880 --> 00:07:48,260 and I'm pretty sure they're going to notice that. 120 00:07:49,340 --> 00:07:52,860 Or the other thing they can do is they can configure their readers 121 00:07:52,860 --> 00:07:56,560 to only accept the CIOS or DESFIRE cards. 122 00:07:56,840 --> 00:07:59,280 So if you clone it to a low frequency or lower security card, 123 00:07:59,420 --> 00:08:01,640 it's useless because the reader won't accept it. 124 00:08:02,640 --> 00:08:05,960 Now you might come into situations where they have different configurations 125 00:08:05,960 --> 00:08:06,820 around the building. 126 00:08:07,000 --> 00:08:10,180 In a loading bay they might use a dual frequency reader, 127 00:08:10,360 --> 00:08:14,540 but most often the secured, protected areas of a high security building 128 00:08:14,860 --> 00:08:21,120 are going to be protected by elite keyed CIOS or high frequency only cards. 129 00:08:21,940 --> 00:08:24,200 And that was actually the scenario that we faced 130 00:08:24,200 --> 00:08:25,400 when we were doing a red team engagement. 131 00:08:25,740 --> 00:08:27,840 So that's what led to the motivation. 132 00:08:27,980 --> 00:08:32,740 If we can't break the crypto, we go for a relay attack instead. 133 00:08:32,920 --> 00:08:35,400 And I'm going to pass it to Sam to talk about how we did that. 134 00:08:37,200 --> 00:08:37,820 Thank you. 135 00:08:38,560 --> 00:08:42,300 So first I'm just going to talk a bit about the relay attack scenario, 136 00:08:42,640 --> 00:08:44,760 so what this would look like from an attacker deployment. 137 00:08:44,860 --> 00:08:48,300 So basically you're going to send one of your guys to stand 138 00:08:48,300 --> 00:08:51,480 besides a legitimate employee of the place you're trying to access 139 00:08:51,480 --> 00:08:54,120 on public transit or some other environment like that, 140 00:08:54,240 --> 00:08:57,160 and then they can hold a Proxmark fairly close to the guy's pass. 141 00:08:57,500 --> 00:09:00,040 Then you send one of your other guys right up to the door 142 00:09:00,040 --> 00:09:03,240 and just badge in, and you need some way of communicating 143 00:09:03,240 --> 00:09:04,340 between the two Proxmarks. 144 00:09:04,780 --> 00:09:07,620 We use the internet as a backbone, which is super convenient 145 00:09:07,620 --> 00:09:10,940 because it's available everywhere with cell networks and stuff, 146 00:09:11,060 --> 00:09:12,780 but it theoretically could be anything there. 147 00:09:14,680 --> 00:09:18,040 So here's the architecture of our original attack here. 148 00:09:19,340 --> 00:09:22,600 The first version used laptops instead of mobile devices. 149 00:09:22,760 --> 00:09:23,740 We've since migrated to that. 150 00:09:24,360 --> 00:09:27,360 But as you can see, we have the real card and then two Proxmarks 151 00:09:27,360 --> 00:09:29,360 acting as a fake reader and a fake card. 152 00:09:29,740 --> 00:09:32,100 And then if you follow that green line there, 153 00:09:32,240 --> 00:09:36,260 messages go from the real reader all the way to the real card, 154 00:09:36,420 --> 00:09:38,120 and then responses go all the way back. 155 00:09:38,300 --> 00:09:41,080 You repeat that about 10 or 12 times or whatever, 156 00:09:41,220 --> 00:09:42,100 and then the door opens. 157 00:09:43,900 --> 00:09:47,920 And even this original attack did use, over the internet, 158 00:09:48,060 --> 00:09:50,560 we had a web socket connection between the two laptops. 159 00:09:51,140 --> 00:09:53,180 And in this original attack, we also used Bluetooth 160 00:09:53,180 --> 00:09:57,520 between the laptop and the Proxmark 161 00:09:57,520 --> 00:10:00,020 just to get them a bit further apart and not have to run wires. 162 00:10:02,040 --> 00:10:04,900 So because all of the messages are generated by a real card 163 00:10:04,900 --> 00:10:07,900 and a real reader, the contents are guaranteed to be correct. 164 00:10:08,100 --> 00:10:10,500 If they weren't, the system wouldn't work in the first place, 165 00:10:10,540 --> 00:10:12,280 and the legitimate cards would not open the doors. 166 00:10:12,780 --> 00:10:15,040 So the only way that readers could detect our attacks 167 00:10:15,530 --> 00:10:16,980 is by detecting timing variations. 168 00:10:17,460 --> 00:10:20,260 And that's because the round trip time of request response 169 00:10:20,260 --> 00:10:23,140 over about an inch between the legitimate scenario 170 00:10:23,140 --> 00:10:26,520 versus Ottawa to Vegas is significantly shorter. 171 00:10:26,780 --> 00:10:28,120 So we were investigating, 172 00:10:28,340 --> 00:10:31,260 can we make the reader's support longer than normal timings? 173 00:10:32,260 --> 00:10:33,820 And it turns out that we can. 174 00:10:34,040 --> 00:10:35,240 There's a few mechanisms. 175 00:10:37,360 --> 00:10:40,720 So all of the high frequency cards that we've discussed so far, 176 00:10:40,720 --> 00:10:43,300 so the 13.56 megahertz ones, 177 00:10:43,500 --> 00:10:47,040 are based on ISO 14443 TAC4 type A, 178 00:10:47,160 --> 00:10:50,100 or just 14A since that's a lot of letter soup. 179 00:10:50,620 --> 00:10:54,280 And most access controls would be based on the standard. 180 00:10:54,540 --> 00:10:57,340 There's a few that aren't, but most of them are. 181 00:10:57,600 --> 00:11:01,140 And this is analogous to how HTTP is built on top of TCP. 182 00:11:01,540 --> 00:11:06,180 This provides a messaging layer that the application-specific data would travel over. 183 00:11:06,800 --> 00:11:08,940 But before any application layer data, 184 00:11:08,940 --> 00:11:11,260 so the CS protocol or the DSR protocol, 185 00:11:11,480 --> 00:11:12,540 before any of that happens, 186 00:11:12,820 --> 00:11:15,180 the card and the reader must exchange parameters 187 00:11:15,180 --> 00:11:17,120 in what we call the 14A handshake. 188 00:11:17,580 --> 00:11:21,020 And this is both documented very nicely, it's an ISO standard, 189 00:11:21,240 --> 00:11:24,280 but it's also not encrypted or authenticated at all. 190 00:11:24,560 --> 00:11:26,560 There's a 16-bit CRC on some parts, 191 00:11:26,620 --> 00:11:27,800 but the details of that are public, 192 00:11:27,960 --> 00:11:29,000 so we can't mess with that. 193 00:11:29,220 --> 00:11:30,220 So let's have a quick look. 194 00:11:31,560 --> 00:11:34,880 So this diagram here shows a real handshake 195 00:11:34,880 --> 00:11:38,520 that we captured between a real CS card and a real reader. 196 00:11:39,160 --> 00:11:41,080 You don't have to understand most of it, 197 00:11:41,100 --> 00:11:42,260 the spec is about 100 pages, 198 00:11:42,540 --> 00:11:44,440 but there are a few parts I'd like to highlight here. 199 00:11:45,060 --> 00:11:46,820 So the first message I'd like to highlight 200 00:11:46,820 --> 00:11:48,900 is this UID CLN message. 201 00:11:50,140 --> 00:11:52,620 Now, the standard actually has a mechanism 202 00:11:52,620 --> 00:11:56,020 for the card to give a UID to the reader. 203 00:11:57,360 --> 00:12:00,540 CS doesn't use this because it's completely unauthenticated, 204 00:12:00,660 --> 00:12:01,760 as said earlier, 205 00:12:02,500 --> 00:12:03,920 but other mechanisms do. 206 00:12:04,080 --> 00:12:06,780 But CS actually just provides a random value each time, 207 00:12:06,920 --> 00:12:08,820 so you can't even use this with readers 208 00:12:08,940 --> 00:12:09,820 who don't support the CS protocol, 209 00:12:10,060 --> 00:12:11,440 just by falling back to that number. 210 00:12:11,900 --> 00:12:13,300 And then the other thing I'd like to highlight 211 00:12:13,300 --> 00:12:15,040 is that ATS message there, 212 00:12:15,200 --> 00:12:16,740 and specifically that blue byte, 213 00:12:16,920 --> 00:12:18,580 which is interface byte TB1. 214 00:12:20,160 --> 00:12:21,480 ATS here is answer select, 215 00:12:21,680 --> 00:12:23,560 with our ATS being request answer select. 216 00:12:23,960 --> 00:12:25,460 And the important bit of TB1 there 217 00:12:25,460 --> 00:12:27,340 is the frame waiting time integer, 218 00:12:27,500 --> 00:12:29,200 which is coded in the high nibble. 219 00:12:29,500 --> 00:12:31,360 And that's the frame waiting time, 220 00:12:31,560 --> 00:12:33,380 and I'll explain what that is in just a second, 221 00:12:33,500 --> 00:12:35,300 in accordance with that little equation there. 222 00:12:36,820 --> 00:12:38,840 And the FWT tells the reader 223 00:12:38,940 --> 00:12:40,480 how long to wait between frames. 224 00:12:40,760 --> 00:12:42,640 So after the reader sends a request, 225 00:12:42,960 --> 00:12:44,960 it will wait that amount of time 226 00:12:44,960 --> 00:12:47,640 before expecting a response from the card, 227 00:12:47,880 --> 00:12:49,820 and if it doesn't receive one at that point, 228 00:12:49,960 --> 00:12:51,200 it will usually restart 229 00:12:51,200 --> 00:12:52,400 the entire authentication attempt 230 00:12:52,400 --> 00:12:53,060 from the beginning. 231 00:12:54,880 --> 00:12:56,400 However, this is unauthenticated, 232 00:12:56,580 --> 00:12:57,540 it's sent by the card, 233 00:12:57,680 --> 00:12:58,740 which we are pretending to be, 234 00:12:58,920 --> 00:13:00,360 and we can mess with it. 235 00:13:00,840 --> 00:13:03,180 And if you notice at just the end of that equation there, 236 00:13:03,240 --> 00:13:04,520 there's that exponential term, 237 00:13:05,120 --> 00:13:06,500 we can make that go pretty high. 238 00:13:08,940 --> 00:13:11,200 So after the 14a handshake is complete, 239 00:13:11,380 --> 00:13:13,080 it goes into the CS protocol, 240 00:13:13,920 --> 00:13:15,880 which is a bunch of random bytes, 241 00:13:16,060 --> 00:13:17,460 and I have no idea what they mean, 242 00:13:18,800 --> 00:13:19,880 but who cares, 243 00:13:20,060 --> 00:13:20,780 because 244 00:13:22,460 --> 00:13:24,160 these are generated by a real card 245 00:13:24,160 --> 00:13:25,320 and a real reader, 246 00:13:25,480 --> 00:13:26,260 we know they're right, 247 00:13:26,380 --> 00:13:28,120 we just need to get them from point A to point B. 248 00:13:30,640 --> 00:13:31,120 Yes. 249 00:13:31,480 --> 00:13:34,140 A lot of the messages in the 14a handshake 250 00:13:34,140 --> 00:13:36,580 are sent before that ATS message, 251 00:13:36,800 --> 00:13:38,720 so the modified frame waiting time 252 00:13:38,720 --> 00:13:39,460 won't apply yet, 253 00:13:39,660 --> 00:13:41,300 and therefore we can't relay them. 254 00:13:41,520 --> 00:13:43,880 The latency over any internet connection, 255 00:13:44,560 --> 00:13:46,400 even basic ethernet, will be far too long. 256 00:13:46,660 --> 00:13:48,540 It's messed up by print statements, in fact. 257 00:13:48,780 --> 00:13:51,100 So that initial 14a handshake 258 00:13:51,100 --> 00:13:52,000 does have to be handled 259 00:13:52,000 --> 00:13:53,280 on the prox marks themselves, 260 00:13:54,020 --> 00:13:56,280 but thankfully it can really just be 261 00:13:56,280 --> 00:13:57,600 hard-coded for the most part. 262 00:13:57,980 --> 00:13:59,260 It doesn't really vary, 263 00:13:59,340 --> 00:14:01,080 but we'll get into a few more details on that later. 264 00:14:03,700 --> 00:14:06,060 And as for how long we can get the reader 265 00:14:06,060 --> 00:14:07,120 to wait between frames, 266 00:14:08,720 --> 00:14:10,700 the FWI to its highest value of 14, 267 00:14:10,940 --> 00:14:11,900 we can make it wait 268 00:14:11,900 --> 00:14:13,980 4,949 milliseconds, 269 00:14:14,340 --> 00:14:16,040 which is almost 5 seconds. 270 00:14:16,400 --> 00:14:18,180 I'm not sure why that's supported by the standard, 271 00:14:18,340 --> 00:14:20,800 because I don't see a real use case, 272 00:14:21,480 --> 00:14:21,940 but 273 00:14:22,570 --> 00:14:23,960 it's very convenient for us. 274 00:14:24,880 --> 00:14:26,240 There is another technique 275 00:14:26,240 --> 00:14:28,740 in the 14a standard that we can use 276 00:14:28,740 --> 00:14:30,280 to bypass the RAM trip time check, 277 00:14:31,020 --> 00:14:32,760 which is waiting time extensions, 278 00:14:33,980 --> 00:14:34,900 and that's 279 00:14:34,900 --> 00:14:36,500 a mechanism that applies 280 00:14:36,500 --> 00:14:37,540 to just the next message, 281 00:14:38,720 --> 00:14:39,380 or subsequent messages. 282 00:14:39,700 --> 00:14:41,660 But it can also be repeated, which is nice. 283 00:14:41,880 --> 00:14:44,560 So theoretically, if you keep the fake card 284 00:14:44,560 --> 00:14:46,520 by the reader for 20 minutes 285 00:14:46,520 --> 00:14:48,020 and it just keeps sending these, 286 00:14:48,240 --> 00:14:49,940 you could have 20 minutes of time. 287 00:14:50,720 --> 00:14:51,680 But in practice, 288 00:14:51,920 --> 00:14:53,680 at least with the readers that we tested, 289 00:14:53,820 --> 00:14:54,740 we found it was less reliable, 290 00:14:55,080 --> 00:14:57,740 so we're mostly relying on modifying the FWT. 291 00:14:58,440 --> 00:15:00,280 I think a big problem with the WTX 292 00:15:00,280 --> 00:15:01,860 is it does need to be sent for each message, 293 00:15:02,340 --> 00:15:04,120 so if it's missed once, 294 00:15:04,340 --> 00:15:06,160 the entire authentication attempt fails. 295 00:15:08,720 --> 00:15:09,820 So our original design 296 00:15:09,820 --> 00:15:12,140 was implemented as an extension 297 00:15:12,560 --> 00:15:14,480 to the already existing and 298 00:15:14,480 --> 00:15:16,380 open-source HFVBLAE 299 00:15:16,380 --> 00:15:17,340 Proxmark Standalone Mode, 300 00:15:17,460 --> 00:15:19,940 which was originally written by Salvador Mendoza. 301 00:15:20,740 --> 00:15:22,620 That was to relay credit cards, actually, 302 00:15:22,660 --> 00:15:23,300 which was pretty cool. 303 00:15:23,600 --> 00:15:25,380 And we made some changes to allow 304 00:15:25,380 --> 00:15:28,120 protocol, or really any protocol, 305 00:15:28,280 --> 00:15:29,620 instead of just credit cards, 306 00:15:29,740 --> 00:15:32,020 and also adding the long-range 307 00:15:32,020 --> 00:15:34,040 internet component, instead of just over 308 00:15:34,040 --> 00:15:35,280 Bluetooth like it was originally. 309 00:15:36,120 --> 00:15:38,580 And this original design was strongly 310 00:15:38,720 --> 00:15:40,240 coupled with the BlueShark 311 00:15:40,240 --> 00:15:42,400 Bluetooth add-on. Messages were 312 00:15:42,400 --> 00:15:43,620 conveyed from Proxmark to the laptop, 313 00:15:43,740 --> 00:15:44,700 and then sent over IP. 314 00:15:45,380 --> 00:15:47,500 We did have a lot of success with this design. 315 00:15:47,840 --> 00:15:50,240 The big highlight being unlocking a door in 316 00:15:50,240 --> 00:15:51,940 Ottawa with a card in Florida. 317 00:15:52,780 --> 00:15:54,420 Because my colleague over here has 318 00:15:54,420 --> 00:15:55,520 a vacation home in Florida, 319 00:15:55,700 --> 00:15:58,080 so we sent him down with a card 320 00:15:58,080 --> 00:15:59,600 and just tried that out, and 321 00:15:59,600 --> 00:16:01,240 it worked after a few tries. 322 00:16:01,720 --> 00:16:04,380 There were, however, some fairly major 323 00:16:04,380 --> 00:16:06,520 reliability issues in this original design. 324 00:16:08,720 --> 00:16:10,480 So the BlueShark add-on does come with 325 00:16:10,480 --> 00:16:12,160 an integrated rechargeable battery, 326 00:16:12,300 --> 00:16:14,840 and we did like that design at first, 327 00:16:14,980 --> 00:16:16,400 because it's a lot more convenient 328 00:16:16,400 --> 00:16:18,360 for real deployments, 329 00:16:18,480 --> 00:16:20,600 like actually standing beside someone on the bus 330 00:16:20,600 --> 00:16:22,080 and trying to relay their card, 331 00:16:22,200 --> 00:16:23,640 than running a cable up their sleeve. 332 00:16:23,780 --> 00:16:25,220 You get to put it a bit further away, 333 00:16:25,360 --> 00:16:26,740 you don't have that whole cable to deal with. 334 00:16:28,060 --> 00:16:30,000 But the ability of the Proxmark 335 00:16:30,000 --> 00:16:31,140 that's pretending to be a reader 336 00:16:31,140 --> 00:16:33,640 to read the card, which is its job, 337 00:16:33,780 --> 00:16:35,980 is very dependent on the battery level. 338 00:16:36,800 --> 00:16:37,960 If it's too high, 339 00:16:38,720 --> 00:16:38,940 we get bad reads. 340 00:16:39,400 --> 00:16:40,380 If it's too low, 341 00:16:40,480 --> 00:16:41,840 we also get bad reads. 342 00:16:42,360 --> 00:16:44,700 We're not entirely sure why that happens. 343 00:16:45,080 --> 00:16:47,920 We think it's related to the voltage level 344 00:16:47,920 --> 00:16:49,000 being output by the battery, 345 00:16:49,120 --> 00:16:50,640 but we're not 100% sure on that. 346 00:16:51,620 --> 00:16:53,040 It did prove very frustrating. 347 00:16:53,840 --> 00:16:55,040 While we were developing this, 348 00:16:55,080 --> 00:16:56,240 we developed little rules of thumb, 349 00:16:56,360 --> 00:16:58,080 like when it starts failing, 350 00:16:58,280 --> 00:17:00,220 plug it in for 12 minutes and try again. 351 00:17:01,740 --> 00:17:03,300 And that kind of worked, 352 00:17:03,420 --> 00:17:04,840 but it wasn't very nice. 353 00:17:07,320 --> 00:17:08,340 The other problem 354 00:17:08,720 --> 00:17:08,840 was the latency. 355 00:17:09,580 --> 00:17:11,380 We can make the reader accept 356 00:17:11,380 --> 00:17:12,860 ridiculous amounts of latency, 357 00:17:13,460 --> 00:17:14,880 but on the card side, 358 00:17:15,400 --> 00:17:17,540 real cards are designed under the assumption 359 00:17:17,540 --> 00:17:19,660 that the reader will respond 360 00:17:19,660 --> 00:17:21,840 within at most a few milliseconds, 361 00:17:22,140 --> 00:17:23,640 and typically much faster. 362 00:17:24,340 --> 00:17:26,460 We blow that assumption out of the water 363 00:17:26,460 --> 00:17:28,220 by several orders of magnitude 364 00:17:28,220 --> 00:17:30,060 when we're doing this over longer ranges. 365 00:17:30,540 --> 00:17:32,240 We find that the card sometimes 366 00:17:32,960 --> 00:17:34,680 forgets that it's supposed to be 367 00:17:34,680 --> 00:17:36,280 in the middle of an authentication attempt. 368 00:17:37,140 --> 00:17:38,620 This happens increasingly 369 00:17:38,720 --> 00:17:40,460 often as the latency increases. 370 00:17:40,800 --> 00:17:43,080 This isn't necessarily a deal-breaker 371 00:17:43,080 --> 00:17:44,140 by itself, 372 00:17:44,360 --> 00:17:46,100 because it just means you need to retry 373 00:17:46,100 --> 00:17:46,580 from the beginning. 374 00:17:46,820 --> 00:17:48,800 So if your guy's still standing beside the guy 375 00:17:48,800 --> 00:17:50,600 in public transit, you're good to go. 376 00:17:50,720 --> 00:17:52,000 But maybe it's a little suspicious 377 00:17:52,000 --> 00:17:53,940 if you're standing beside a reader 378 00:17:53,940 --> 00:17:56,100 for two minutes waiting for the door to open. 379 00:17:56,960 --> 00:17:57,680 Not the best. 380 00:17:58,460 --> 00:18:01,120 And different cards could be more resilient to this. 381 00:18:01,540 --> 00:18:03,100 Most of our observations here 382 00:18:03,100 --> 00:18:05,120 were with CIOS cards in particular. 383 00:18:05,800 --> 00:18:07,220 We actually only tested 384 00:18:08,720 --> 00:18:09,700 this one time earlier today 385 00:18:09,700 --> 00:18:11,160 before we went to sleep. 386 00:18:11,320 --> 00:18:12,580 It was hard to source a card. 387 00:18:14,200 --> 00:18:16,300 So between that and the battery issues, 388 00:18:16,560 --> 00:18:18,520 the initial design was not reliable. 389 00:18:19,300 --> 00:18:20,380 It was usable, 390 00:18:20,520 --> 00:18:22,160 not really reliable, but usable 391 00:18:22,480 --> 00:18:24,380 within the same city, and even then 392 00:18:24,380 --> 00:18:26,100 I'd say this was a practical attack 393 00:18:26,100 --> 00:18:28,280 that higher security, higher value 394 00:18:28,280 --> 00:18:31,160 facilities would be more concerned about. 395 00:18:31,320 --> 00:18:32,880 But it was much harder 396 00:18:32,880 --> 00:18:34,400 to make it work over longer distances. 397 00:18:35,320 --> 00:18:36,680 And even in the same city 398 00:18:36,680 --> 00:18:37,600 it wasn't perfectly reliable. 399 00:18:38,720 --> 00:18:39,840 So our revised design, 400 00:18:40,020 --> 00:18:42,160 we incorporated quite a few changes. 401 00:18:42,860 --> 00:18:44,560 So first off, we swapped laptops 402 00:18:44,560 --> 00:18:45,120 with phones. 403 00:18:45,540 --> 00:18:47,340 Laptop on your backpack is fine, 404 00:18:47,580 --> 00:18:49,080 but phone in your pocket is even better. 405 00:18:49,860 --> 00:18:51,260 And then more importantly, 406 00:18:51,440 --> 00:18:53,520 we swapped that little Bluetooth link there 407 00:18:53,520 --> 00:18:54,900 with a serial link. 408 00:18:55,240 --> 00:18:57,740 And we're also powering the Proxmark 409 00:18:57,740 --> 00:18:59,120 from the phone over that serial link. 410 00:18:59,300 --> 00:19:00,440 So we knocked out the battery, 411 00:19:00,540 --> 00:19:01,780 and we knocked out Bluetooth. 412 00:19:02,560 --> 00:19:05,020 Bluetooth was nice, but Bluetooth Classic 413 00:19:05,020 --> 00:19:06,200 is a horrible protocol, 414 00:19:06,340 --> 00:19:08,600 and 50 milliseconds of latency 415 00:19:08,600 --> 00:19:11,240 on each side, 100 milliseconds total, 416 00:19:11,420 --> 00:19:12,840 when Florida to Ottawa is only 417 00:19:12,840 --> 00:19:14,040 a 99 millisecond ping. 418 00:19:14,180 --> 00:19:15,720 That's almost doubling it, 419 00:19:15,860 --> 00:19:17,760 and we didn't really want to eat that, 420 00:19:17,920 --> 00:19:20,320 and getting rid of that really did 421 00:19:20,320 --> 00:19:21,500 increase our reliability. 422 00:19:23,100 --> 00:19:24,580 Additionally, just to operate it over 423 00:19:24,580 --> 00:19:26,860 a cell network, where phones will not have 424 00:19:26,860 --> 00:19:28,840 public IPs, instead of them connecting 425 00:19:28,840 --> 00:19:30,620 directly to each other via WebSocket, 426 00:19:30,740 --> 00:19:32,700 we have a little relay server 427 00:19:33,580 --> 00:19:34,540 just hosted 428 00:19:35,020 --> 00:19:36,520 in DigitalOcean in between them. 429 00:19:38,640 --> 00:19:41,060 So the software in our revised design 430 00:19:41,060 --> 00:19:42,420 is called HFCardHopper. 431 00:19:42,680 --> 00:19:44,260 It's a new standalone module 432 00:19:44,260 --> 00:19:46,700 for Iceman's Proxmark 3 firmware. 433 00:19:46,940 --> 00:19:48,820 We will be releasing it later this week, 434 00:19:48,940 --> 00:19:50,980 whenever I get around to doing a pull request. 435 00:19:51,900 --> 00:19:52,820 It's inspired 436 00:19:52,820 --> 00:19:54,920 by Salvador Mendoza's HF Replay, 437 00:19:55,020 --> 00:19:55,960 the original design, 438 00:19:56,220 --> 00:19:58,000 but doesn't share any code. 439 00:19:58,340 --> 00:20:00,100 And it has the code to trick readers 440 00:20:00,100 --> 00:20:02,240 into using a longer frame rating time. 441 00:20:03,160 --> 00:20:04,720 It can relay any ISO 442 00:20:05,020 --> 00:20:06,540 on 4443A... 443 00:20:07,560 --> 00:20:08,760 14A-based protocol. 444 00:20:09,300 --> 00:20:10,920 And it actually has support 445 00:20:10,920 --> 00:20:12,720 for relaying that 446 00:20:12,720 --> 00:20:14,580 initial UID and the ATS. 447 00:20:15,040 --> 00:20:16,880 That doesn't matter so much for CIOS, 448 00:20:16,960 --> 00:20:18,760 because the UID is random each time, 449 00:20:18,880 --> 00:20:20,720 but for Deskfire, that UID 450 00:20:20,720 --> 00:20:22,720 actually contributes material 451 00:20:22,720 --> 00:20:24,860 to later cryptographic operations. 452 00:20:25,120 --> 00:20:27,200 So to get it to match up on both sides, 453 00:20:27,300 --> 00:20:28,120 you do need to get that right. 454 00:20:28,500 --> 00:20:30,640 Now because that's sent over the ATS, 455 00:20:30,860 --> 00:20:32,960 we can't actually relay that in real time, 456 00:20:33,080 --> 00:20:35,000 because the modified frame rating time 457 00:20:35,020 --> 00:20:35,520 won't apply. 458 00:20:36,580 --> 00:20:37,940 But it doesn't actually change. 459 00:20:38,760 --> 00:20:40,280 When it matters, it doesn't change. 460 00:20:40,780 --> 00:20:43,180 So Deskfire cards always give the same UID. 461 00:20:43,420 --> 00:20:44,460 So if you just read it once, 462 00:20:44,520 --> 00:20:45,560 then transmit it, 463 00:20:45,720 --> 00:20:47,420 then the Proxmark can set itself up 464 00:20:47,420 --> 00:20:49,100 to emulate that specific card. 465 00:20:49,500 --> 00:20:51,300 And that doesn't have to happen in real time, 466 00:20:51,440 --> 00:20:51,920 which is nice. 467 00:20:52,460 --> 00:20:53,500 And it works with BlueShark, 468 00:20:54,240 --> 00:20:55,940 and our custom hardware, 469 00:20:56,100 --> 00:20:57,100 which handles that serial link, 470 00:20:57,240 --> 00:20:59,120 which my colleague Trevor will talk to you about. 471 00:21:02,400 --> 00:21:03,940 Yeah, so as Sam mentioned, 472 00:21:05,020 --> 00:21:06,340 we wanted to swap out the Bluetooth module 473 00:21:06,900 --> 00:21:08,140 mainly because of the latency issues. 474 00:21:08,400 --> 00:21:09,680 So we came up with another 475 00:21:10,480 --> 00:21:11,500 module that is 476 00:21:13,760 --> 00:21:15,880 USB to UART bridge, basically. 477 00:21:16,080 --> 00:21:17,080 If you're familiar with things 478 00:21:17,080 --> 00:21:17,760 like the Shikra, 479 00:21:18,400 --> 00:21:20,460 it uses the FT232 chip 480 00:21:20,460 --> 00:21:21,240 that's in the Shikra. 481 00:21:21,780 --> 00:21:23,340 We just modified the design 482 00:21:23,340 --> 00:21:24,560 to have a USB-C, 483 00:21:24,780 --> 00:21:26,400 which is much more convenient 484 00:21:26,400 --> 00:21:27,640 for connecting to modern phones, 485 00:21:27,860 --> 00:21:30,380 and then a ribbon cable 486 00:21:30,380 --> 00:21:32,300 for connecting to the Proxmark. 487 00:21:35,020 --> 00:21:35,180 So we used a ribbon cable 488 00:21:35,180 --> 00:21:36,440 to connect to that interface 489 00:21:36,440 --> 00:21:37,780 on the Proxmark for a couple reasons. 490 00:21:38,180 --> 00:21:40,220 A, we think it's a little bit faster. 491 00:21:41,460 --> 00:21:43,160 We're directly connecting to the Proxmark 492 00:21:43,160 --> 00:21:44,300 over USART, whereas 493 00:21:44,880 --> 00:21:46,480 if you're connecting to the USB 494 00:21:46,480 --> 00:21:47,760 on the side of the Proxmark, 495 00:21:47,920 --> 00:21:49,580 that's actually an emulated modem, 496 00:21:49,600 --> 00:21:50,920 so that would add a little bit of latency. 497 00:21:51,580 --> 00:21:54,820 But also, this makes it completely interchangeable 498 00:21:54,820 --> 00:21:56,700 with the BlueShark add-on. 499 00:21:56,820 --> 00:21:58,300 So if you wanted to use the BlueShark 500 00:21:58,300 --> 00:21:59,660 for wire-free, 501 00:21:59,860 --> 00:22:03,020 our emulator, the standalone mode, 502 00:22:05,020 --> 00:22:06,040 you can connect in with this interchangeably. 503 00:22:06,720 --> 00:22:08,400 We did have one little hiccup 504 00:22:08,400 --> 00:22:10,360 when creating these 505 00:22:10,360 --> 00:22:11,600 and ordering these for DEF CON. 506 00:22:12,180 --> 00:22:14,420 It turns out that just casually mentioning 507 00:22:14,420 --> 00:22:15,940 that you need a 14-pin, 508 00:22:16,020 --> 00:22:17,700 0.5 millimeter spaced 509 00:22:18,360 --> 00:22:19,520 ribbon cable adapter 510 00:22:19,520 --> 00:22:21,040 is not enough to make sure 511 00:22:21,040 --> 00:22:22,120 it actually gets ordered properly. 512 00:22:22,780 --> 00:22:24,560 So, you know, lessons learned. 513 00:22:24,960 --> 00:22:27,060 We managed to get it reordered, 514 00:22:27,080 --> 00:22:31,100 rebuilt, props to one of my colleagues 515 00:22:31,100 --> 00:22:32,640 who actually disassembled 516 00:22:32,640 --> 00:22:34,220 half a dozen of these 517 00:22:35,020 --> 00:22:36,380 and if you see one of these, 518 00:22:36,460 --> 00:22:37,880 if you come up, I'll show you. 519 00:22:37,940 --> 00:22:39,900 There's a lot of tiny little components in here. 520 00:22:40,360 --> 00:22:42,520 He took every single component off 521 00:22:42,520 --> 00:22:44,200 and resoldered it onto a new board 522 00:22:44,200 --> 00:22:45,720 with the right pin header. 523 00:22:45,980 --> 00:22:48,120 And that's the board that's being used in Ottawa 524 00:22:48,120 --> 00:22:50,100 right now for the other side of this demo. 525 00:22:50,660 --> 00:22:51,920 So, appreciate that. 526 00:22:52,120 --> 00:22:53,460 That was a lot of hard work, I know. 527 00:22:56,180 --> 00:22:57,660 And then the other thing we added 528 00:22:57,660 --> 00:22:59,340 is a custom Android app. 529 00:22:59,560 --> 00:23:02,380 So, to make it easy to interface 530 00:23:02,380 --> 00:23:04,000 with the Proxmark, 531 00:23:05,020 --> 00:23:06,160 we have an Android app that will bridge 532 00:23:06,160 --> 00:23:07,880 the communication between the FTDI 533 00:23:07,880 --> 00:23:09,440 and therefore the Proxmark 534 00:23:09,440 --> 00:23:10,500 and the relay server. 535 00:23:11,580 --> 00:23:14,060 And it supports card or reader modes. 536 00:23:14,220 --> 00:23:15,060 You can alternate it. 537 00:23:15,100 --> 00:23:17,080 And it supports COS and Desfire cards. 538 00:23:17,360 --> 00:23:19,380 And you can adjust the frame rating values 539 00:23:19,380 --> 00:23:20,580 for your specific target. 540 00:23:21,880 --> 00:23:24,000 And it also will handle hardware resets 541 00:23:24,000 --> 00:23:25,800 because we came across a lot of those. 542 00:23:25,900 --> 00:23:27,440 We needed to build that in to be able to 543 00:23:27,440 --> 00:23:29,220 quickly reset and start over again. 544 00:23:29,380 --> 00:23:32,440 So, it's quite easy to start over 545 00:23:32,920 --> 00:23:33,600 with that. 546 00:23:35,020 --> 00:23:36,220 Today it is my first Android app. 547 00:23:36,340 --> 00:23:37,280 I've never done this before. 548 00:23:37,420 --> 00:23:38,940 And we kind of just went function over style. 549 00:23:39,180 --> 00:23:41,160 I know it's pretty ugly, but it works. 550 00:23:44,580 --> 00:23:46,280 Alright, so let's go over some of the results 551 00:23:46,280 --> 00:23:47,560 before we get into the demo. 552 00:23:47,740 --> 00:23:49,700 So, we've tested this on a variety of 553 00:23:49,700 --> 00:23:51,300 different HID readers. 554 00:23:51,620 --> 00:23:53,660 So, the first couple are 555 00:23:54,580 --> 00:23:55,460 older generation 556 00:23:56,600 --> 00:23:57,960 HID multi-class readers. 557 00:23:58,140 --> 00:23:59,880 The RP40 and RPK40. 558 00:24:00,220 --> 00:24:01,720 A couple of different models. 559 00:24:01,920 --> 00:24:04,480 But these are ones that will accept 560 00:24:05,020 --> 00:24:06,700 low frequency and high frequency cards. 561 00:24:07,000 --> 00:24:08,340 So, there is 562 00:24:08,830 --> 00:24:10,860 some requirement for them 563 00:24:10,860 --> 00:24:12,400 to adjust the frame rating time because 564 00:24:12,770 --> 00:24:14,000 older cards are a bit slower. 565 00:24:14,320 --> 00:24:16,620 So, it makes sense that adjusting them 566 00:24:16,620 --> 00:24:19,060 was a successful attack. 567 00:24:19,700 --> 00:24:20,860 But the one that was 568 00:24:20,860 --> 00:24:22,320 a little more surprising was 569 00:24:22,320 --> 00:24:24,020 the Signal readers from HID. 570 00:24:24,120 --> 00:24:27,060 Which are their latest and greatest readers. 571 00:24:27,400 --> 00:24:29,160 And there's three variants of them. 572 00:24:29,320 --> 00:24:31,020 00, 0102. 573 00:24:31,880 --> 00:24:32,720 And that just 574 00:24:32,720 --> 00:24:34,360 the difference in those is the 575 00:24:35,020 --> 00:24:35,700 protocols that it supports. 576 00:24:35,920 --> 00:24:37,700 So, 01 is kind of like your multi-class. 577 00:24:37,960 --> 00:24:40,160 It will support the low frequency and high frequency. 578 00:24:42,820 --> 00:24:43,840 Sorry, that's the 00. 579 00:24:44,020 --> 00:24:46,080 The 01, I think, is the 580 00:24:46,740 --> 00:24:48,580 only CEOS protocol. 581 00:24:48,920 --> 00:24:50,140 CEOS and Desfire. 582 00:24:50,340 --> 00:24:51,340 And then 02 is 583 00:24:52,060 --> 00:24:53,480 CEOS, Desfire, and smartphones. 584 00:24:55,360 --> 00:24:56,840 So, that one's the one that 585 00:24:56,840 --> 00:24:58,100 to me is surprising that 586 00:24:58,100 --> 00:25:00,440 the frame rating time attack works on because 587 00:25:01,060 --> 00:25:02,640 especially for the 01 and 02 588 00:25:02,640 --> 00:25:04,740 they're only talking to high frequency cards. 589 00:25:05,020 --> 00:25:07,420 That are fast, quick responding cards. 590 00:25:07,600 --> 00:25:08,860 There's really no need for them 591 00:25:08,860 --> 00:25:09,200 to have 592 00:25:10,860 --> 00:25:11,940 to accept 593 00:25:11,940 --> 00:25:13,620 an increased waiting time. 594 00:25:15,420 --> 00:25:17,000 In terms of the card technologies 595 00:25:17,000 --> 00:25:19,040 most of our research was focused 596 00:25:19,040 --> 00:25:20,420 on CEOS because as I said 597 00:25:20,420 --> 00:25:22,900 this was motivated by a specific engagement 598 00:25:22,900 --> 00:25:24,280 we were trying to get into a building. 599 00:25:24,660 --> 00:25:26,300 But we have since 600 00:25:26,300 --> 00:25:29,320 as of last night at 1am in the morning 601 00:25:29,320 --> 00:25:31,300 acquired an EV1 card 602 00:25:31,300 --> 00:25:33,080 and compatible reader 603 00:25:33,080 --> 00:25:34,920 and were able to test and it does work 604 00:25:35,020 --> 00:25:36,260 for EV1 cards as well. 605 00:25:37,340 --> 00:25:38,900 The other ones that we haven't 606 00:25:38,900 --> 00:25:40,640 tested with and we want to 607 00:25:40,640 --> 00:25:42,800 are the EV2 and EV3. 608 00:25:43,580 --> 00:25:44,980 The problem with that is 609 00:25:44,980 --> 00:25:46,980 EV cards 610 00:25:46,980 --> 00:25:48,620 are not super common in 611 00:25:48,620 --> 00:25:49,900 HID access control systems. 612 00:25:50,380 --> 00:25:52,760 And so getting an EV1 card 613 00:25:52,760 --> 00:25:54,200 or an EV2 card that is 614 00:25:54,760 --> 00:25:56,540 programmed with an HID 615 00:25:56,540 --> 00:25:58,880 secure identity object, which is the object 616 00:25:58,880 --> 00:26:00,180 that they write in the card 617 00:26:00,180 --> 00:26:02,380 for the reader to unpack 618 00:26:02,380 --> 00:26:04,560 and pull the identification out of 619 00:26:05,020 --> 00:26:07,280 so to get a card coded for that 620 00:26:07,280 --> 00:26:09,080 is quite challenging 621 00:26:09,080 --> 00:26:09,900 and quite expensive. 622 00:26:10,080 --> 00:26:11,960 So we haven't come across those cards yet. 623 00:26:13,300 --> 00:26:15,020 But the interesting thing about those 624 00:26:15,020 --> 00:26:16,760 is that NXP does have a patent 625 00:26:16,760 --> 00:26:17,600 for 626 00:26:18,520 --> 00:26:20,260 being able to do the proximity check 627 00:26:20,260 --> 00:26:21,240 for communication devices. 628 00:26:21,680 --> 00:26:24,500 So based on that, these two technologies 629 00:26:24,500 --> 00:26:26,460 should be immune to our relay attack 630 00:26:26,460 --> 00:26:28,060 because they should be able to detect 631 00:26:28,060 --> 00:26:30,580 the proximity of the card 632 00:26:30,580 --> 00:26:32,500 but it's something we would like to verify 633 00:26:32,500 --> 00:26:33,960 and try for ourselves. 634 00:26:36,140 --> 00:26:37,420 In terms of distances, 635 00:26:37,760 --> 00:26:39,340 we started out in our lab 636 00:26:39,340 --> 00:26:40,920 across the room 12 feet. 637 00:26:42,080 --> 00:26:43,800 One of us took the readers home 638 00:26:43,800 --> 00:26:45,740 went back from our house 639 00:26:45,740 --> 00:26:46,580 to the office 640 00:26:46,580 --> 00:26:47,480 tried that 641 00:26:47,480 --> 00:26:49,880 and then as Sam mentioned 642 00:26:49,880 --> 00:26:51,140 when I went down to Florida 643 00:26:51,140 --> 00:26:52,720 I took the card with me 644 00:26:52,720 --> 00:26:54,520 we relayed it from Florida back to Ottawa 645 00:26:54,520 --> 00:26:57,720 which is about 1400 miles of distance 646 00:26:57,720 --> 00:26:58,360 that we're going across. 647 00:26:59,160 --> 00:27:01,820 And then earlier today in the green room 648 00:27:01,820 --> 00:27:03,840 we finally got a successful test of doing 649 00:27:05,020 --> 00:27:06,380 and I say finally got a successful 650 00:27:06,380 --> 00:27:07,560 we just didn't have an opportunity 651 00:27:07,560 --> 00:27:10,280 because production issues on the card hoppers 652 00:27:10,780 --> 00:27:12,700 it actually worked quite smoothly, quite well 653 00:27:12,700 --> 00:27:16,740 so that's about 2400 miles now we've gone. 654 00:27:19,000 --> 00:27:20,380 Can we do it on stage? 655 00:27:20,660 --> 00:27:21,680 Is that possible? 656 00:27:29,380 --> 00:27:30,840 So I better text 657 00:27:30,840 --> 00:27:32,620 my colleague on the other side 658 00:27:32,620 --> 00:27:34,260 who's waiting for us to say 659 00:27:35,200 --> 00:27:35,920 we're ready. 660 00:27:37,180 --> 00:27:38,600 So I'll tell them to join now. 661 00:27:39,580 --> 00:27:41,320 We also would like to test this further 662 00:27:41,320 --> 00:27:42,800 so if there are people here 663 00:27:42,800 --> 00:27:44,540 that are interested in collaborating with us 664 00:27:44,540 --> 00:27:46,500 if you live far away, Brazil 665 00:27:46,920 --> 00:27:47,780 or other places 666 00:27:47,780 --> 00:27:50,580 we can try this out 667 00:27:50,580 --> 00:27:52,260 and see how far we can push this distance 668 00:27:52,260 --> 00:27:53,800 come chat with us afterwards. 669 00:27:56,180 --> 00:27:57,020 Alright, so 670 00:27:57,020 --> 00:27:58,440 we are good to go 671 00:27:58,980 --> 00:28:00,340 they're already on their side 672 00:28:02,600 --> 00:28:03,520 let's jump on 673 00:28:14,200 --> 00:28:15,040 Hello! 674 00:28:15,220 --> 00:28:15,960 Hello! 675 00:28:16,960 --> 00:28:18,320 I don't think 676 00:28:18,320 --> 00:28:19,700 the sound is working 677 00:28:22,180 --> 00:28:24,340 Welcome Noon and Liz 678 00:28:24,340 --> 00:28:25,460 to DEFCON 679 00:28:25,460 --> 00:28:27,620 Everyone say hello 680 00:28:35,020 --> 00:28:36,720 Alright, so Liz is just going to demonstrate 681 00:28:36,720 --> 00:28:38,320 right now that she can't get into the door 682 00:28:38,320 --> 00:28:38,760 it's locked 683 00:28:38,760 --> 00:28:42,740 and just presenting the reader 684 00:28:42,740 --> 00:28:44,700 that she has to the door is not going to work 685 00:28:44,700 --> 00:28:46,620 because we're not relaying the card at this point 686 00:28:46,620 --> 00:28:48,080 so if she puts it up against the door 687 00:28:49,780 --> 00:28:50,580 if you put the 688 00:28:50,580 --> 00:28:51,920 thing up against the reader 689 00:28:51,920 --> 00:28:54,580 it doesn't work 690 00:28:55,300 --> 00:28:56,840 because we need to relay the card 691 00:28:58,160 --> 00:28:59,280 Alright, you ready to go Sam? 692 00:29:00,920 --> 00:29:02,340 Liz, you ready to go? 693 00:29:02,400 --> 00:29:03,420 Give me a thumbs up when you're ready. 694 00:29:05,020 --> 00:29:05,320 Give me a thumbs up 695 00:29:06,360 --> 00:29:06,940 Let's see 696 00:29:16,340 --> 00:29:18,660 I think we need to do a reset on her side 697 00:29:18,660 --> 00:29:19,420 one sec, sorry 698 00:29:21,620 --> 00:29:22,600 This is what happens 699 00:29:22,600 --> 00:29:23,500 when we do it live, right? 700 00:29:29,040 --> 00:29:30,220 She's working with the 701 00:29:30,220 --> 00:29:32,620 pre-production version 702 00:29:32,620 --> 00:29:34,340 the one that my colleague 703 00:29:35,020 --> 00:29:35,420 put together by hand 704 00:29:35,420 --> 00:29:37,260 so it's not the most 705 00:29:38,100 --> 00:29:39,400 production ready system 706 00:29:45,200 --> 00:29:46,560 We'll give her another second here 707 00:29:51,220 --> 00:29:52,380 Alright, she's good to go 708 00:29:52,850 --> 00:29:53,500 We're good to go 709 00:29:54,140 --> 00:29:55,120 Alright, go for it Sam 710 00:30:01,920 --> 00:30:03,180 Put it closer to the reader 711 00:30:07,700 --> 00:30:08,060 Yep 712 00:30:09,820 --> 00:30:11,100 Alright, we're going to try it 713 00:30:11,100 --> 00:30:11,780 one more time 714 00:30:13,540 --> 00:30:14,660 If not, we'll switch 715 00:30:15,640 --> 00:30:16,620 Just pull back Liz 716 00:30:16,620 --> 00:30:18,500 and cancel, we'll try again 717 00:30:24,740 --> 00:30:26,320 Give me a thumbs up when you're ready to go 718 00:30:28,020 --> 00:30:28,940 If this doesn't work 719 00:30:28,940 --> 00:30:30,820 we'll switch to the video of us doing it previously 720 00:30:30,820 --> 00:30:32,740 in the green room, just to prove 721 00:30:33,180 --> 00:30:35,400 Okay, I think she's good 722 00:30:39,700 --> 00:30:41,020 And it's not working 723 00:30:43,340 --> 00:30:44,700 Alright, well I guess that's 724 00:30:44,700 --> 00:30:46,380 where we're going to jump to video 725 00:30:47,840 --> 00:30:49,520 Demo gods prove too much for us 726 00:30:50,560 --> 00:30:51,580 Thanks anyway, Liz 727 00:30:52,000 --> 00:30:52,860 Noon, thank you 728 00:30:59,040 --> 00:31:00,880 Alright, so we kind of planned for this 729 00:31:00,880 --> 00:31:02,720 so that's fine. So this is the 730 00:31:02,740 --> 00:31:04,140 this is what it should have looked like 731 00:31:06,520 --> 00:31:06,960 So 732 00:31:07,940 --> 00:31:09,400 when she puts it up to the reader 733 00:31:09,400 --> 00:31:10,820 it does take some time 734 00:31:10,820 --> 00:31:12,240 because we're relaying these messages 735 00:31:12,240 --> 00:31:14,020 one at a time over the internet 736 00:31:14,020 --> 00:31:16,240 so it's not as quick as normally 737 00:31:16,240 --> 00:31:18,080 when you push it up against the reader 738 00:31:18,620 --> 00:31:20,180 but after a certain amount of time 739 00:31:22,760 --> 00:31:24,880 it does work, and she can open the door 740 00:31:33,380 --> 00:31:34,820 So on the phone side 741 00:31:34,820 --> 00:31:36,180 this is what you would have seen 742 00:31:36,720 --> 00:31:38,020 if you were looking at the phone 743 00:31:39,200 --> 00:31:41,220 So we connect the card hopper 744 00:31:41,220 --> 00:31:42,860 Card hopper is the term 745 00:31:42,860 --> 00:31:43,960 we're giving this board 746 00:31:44,580 --> 00:31:46,420 We connect it to the phone 747 00:31:47,000 --> 00:31:48,720 We put the phone into reader mode 748 00:31:49,720 --> 00:31:50,700 We don't adjust 749 00:31:50,700 --> 00:31:51,760 the frame waiting time because 750 00:31:52,240 --> 00:31:54,240 it's fine, and then we start seeing all the 751 00:31:55,780 --> 00:31:56,580 the messages 752 00:31:56,580 --> 00:31:57,560 flying back and forth 753 00:31:57,560 --> 00:32:00,060 You can see there's quite a few of them going back and forth 754 00:32:00,060 --> 00:32:01,320 We don't really care what they are 755 00:32:03,020 --> 00:32:04,600 and that's the 756 00:32:04,600 --> 00:32:06,920 at that point we're done 757 00:32:06,920 --> 00:32:08,260 We've opened the door 758 00:32:09,820 --> 00:32:10,800 So yeah, I said 759 00:32:10,800 --> 00:32:12,120 we don't care about the waiting time 760 00:32:12,120 --> 00:32:14,860 We default it to 14, which is the max 761 00:32:14,860 --> 00:32:16,660 So we're just leaving it at the max 762 00:32:16,660 --> 00:32:17,780 and it's working fine 763 00:32:18,660 --> 00:32:20,000 On our side here 764 00:32:20,000 --> 00:32:21,380 this is what you would see 765 00:32:21,380 --> 00:32:23,000 So this was us in the green room 766 00:32:23,700 --> 00:32:24,140 So 767 00:32:25,860 --> 00:32:28,240 I put the card up against the reader 768 00:32:28,840 --> 00:32:29,500 and wait 769 00:32:29,500 --> 00:32:31,260 and it goes through that back and forth 770 00:32:38,360 --> 00:32:39,620 And then boom 771 00:32:39,620 --> 00:32:39,940 And then boom 772 00:32:39,940 --> 00:32:40,220 We're done 773 00:32:40,880 --> 00:32:42,480 So it does take more time 774 00:32:42,480 --> 00:32:43,480 It is a little bit more 775 00:32:45,240 --> 00:32:45,680 conspicuous 776 00:32:45,680 --> 00:32:48,040 It's not necessarily the stealthiest of attack 777 00:32:48,040 --> 00:32:50,640 But hey, being able to relay a card 778 00:32:50,640 --> 00:32:52,800 from here 2,400 miles away 779 00:32:52,800 --> 00:32:53,820 I think is pretty good 780 00:32:56,460 --> 00:32:56,900 So 781 00:32:58,560 --> 00:33:00,480 A couple other slides we wanted to show 782 00:33:00,480 --> 00:33:02,720 The prevalence of this 783 00:33:02,740 --> 00:33:03,400 to different technologies 784 00:33:03,400 --> 00:33:05,160 So unfortunately 785 00:33:05,160 --> 00:33:07,660 there's a weird trend in the access control industry 786 00:33:07,660 --> 00:33:10,700 that they don't necessarily move to the newest technologies right away 787 00:33:10,700 --> 00:33:13,320 We're still using a lot of the old technologies 788 00:33:13,320 --> 00:33:15,160 So the 125k 789 00:33:15,160 --> 00:33:16,860 HID proc stuff I mentioned 790 00:33:16,860 --> 00:33:19,500 still has about 32% of the market 791 00:33:20,900 --> 00:33:22,620 Very small market percentage 792 00:33:22,620 --> 00:33:23,560 for the CEOS 793 00:33:23,560 --> 00:33:24,940 and even smaller 794 00:33:25,820 --> 00:33:28,580 for some of the MyFair cards 795 00:33:28,580 --> 00:33:29,480 individually 796 00:33:30,820 --> 00:33:32,160 But it's interesting to note 797 00:33:32,740 --> 00:33:34,360 that these technologies have been around for a while 798 00:33:34,360 --> 00:33:35,640 CEOS came out in 2012 799 00:33:36,400 --> 00:33:37,700 EV1 in 2006 800 00:33:38,400 --> 00:33:38,840 So 801 00:33:41,940 --> 00:33:42,820 It's unfortunate 802 00:33:42,820 --> 00:33:44,140 that the industry has not 803 00:33:45,020 --> 00:33:46,100 adopted these as quickly 804 00:33:46,100 --> 00:33:47,940 as they probably should have 805 00:33:50,580 --> 00:33:56,140 Right, so the other point 806 00:33:56,140 --> 00:33:57,140 that we wanted to make was that 807 00:33:57,140 --> 00:33:59,140 most of the ones that are currently in use 808 00:33:59,140 --> 00:34:01,700 aside from the EV2 and EV3 809 00:34:02,740 --> 00:34:04,220 are vulnerable to some sort of attack at this point 810 00:34:04,740 --> 00:34:06,520 So most of the access control industry 811 00:34:06,520 --> 00:34:07,780 is still vulnerable 812 00:34:09,180 --> 00:34:09,660 So 813 00:34:09,660 --> 00:34:12,280 I also want to talk a little bit about HID's response 814 00:34:12,280 --> 00:34:14,180 So we did a responsible disclosure 815 00:34:14,560 --> 00:34:15,740 of this through Bug Crowd 816 00:34:16,580 --> 00:34:18,160 We disclosed it to Bug Crowd 817 00:34:18,160 --> 00:34:19,780 on December 9th of 2022 818 00:34:20,500 --> 00:34:22,220 It was triaged by HID 819 00:34:22,220 --> 00:34:23,600 on January 17th 820 00:34:23,600 --> 00:34:25,160 and then we got their final response 821 00:34:25,160 --> 00:34:26,300 on March 10th 822 00:34:29,540 --> 00:34:30,280 I'm sorry 823 00:34:30,280 --> 00:34:31,660 I'm not showing the presentation mode 824 00:34:39,940 --> 00:34:40,600 That's why 825 00:34:40,600 --> 00:34:41,020 Alright 826 00:34:41,020 --> 00:34:43,920 One of the recommendations we made to HID 827 00:34:43,920 --> 00:34:46,100 was that they should limit 828 00:34:46,100 --> 00:34:47,560 that frame waiting time integer 829 00:34:47,560 --> 00:34:49,940 not accept values over what are 830 00:34:49,940 --> 00:34:50,800 strictly necessary 831 00:34:52,460 --> 00:34:54,260 and they didn't like that idea 832 00:34:54,260 --> 00:34:55,700 because it would put them out of compliance 833 00:34:55,700 --> 00:34:57,360 with the ISO spec 834 00:34:57,360 --> 00:35:00,480 and it would impact their customers needs 835 00:35:00,480 --> 00:35:01,620 for backward compatibility 836 00:35:02,740 --> 00:35:03,460 I don't know any customer 837 00:35:03,460 --> 00:35:07,100 that needs a 5 second waiting time 838 00:35:07,100 --> 00:35:08,300 for backward compatibility 839 00:35:08,300 --> 00:35:10,120 but that's what they felt like 840 00:35:11,420 --> 00:35:12,840 The other comment 841 00:35:12,840 --> 00:35:14,500 that got to me a little bit 842 00:35:14,500 --> 00:35:16,660 was that the majority of their end users 843 00:35:16,660 --> 00:35:18,040 do not see relay attacks 844 00:35:18,040 --> 00:35:19,140 as a viable threat 845 00:35:20,000 --> 00:35:22,600 That was the motivation for coming here today 846 00:35:22,600 --> 00:35:23,760 for doing the additional work 847 00:35:23,760 --> 00:35:24,860 of creating the pieces 848 00:35:24,860 --> 00:35:28,200 We wanted to show that this is a viable feasible threat 849 00:35:29,040 --> 00:35:30,220 Something that could be done 850 00:35:30,220 --> 00:35:31,480 with simple technology 851 00:35:32,740 --> 00:35:33,040 like Proxmark 852 00:35:33,040 --> 00:35:34,500 a small little add-on 853 00:35:34,500 --> 00:35:35,800 and the relay server 854 00:35:37,340 --> 00:35:39,200 The one comment that they did make 855 00:35:39,200 --> 00:35:41,960 which I think has some good validity 856 00:35:41,960 --> 00:35:44,220 is that their end users that are concerned 857 00:35:44,220 --> 00:35:46,000 will typically add a second factor 858 00:35:46,940 --> 00:35:48,160 PIN or biometric 859 00:35:48,880 --> 00:35:50,680 and some will use their mobile credentials 860 00:35:51,280 --> 00:35:52,580 But the one problem 861 00:35:52,580 --> 00:35:53,780 that we see with this is 862 00:35:54,540 --> 00:35:56,480 Okay, now everybody has to enter 863 00:35:56,480 --> 00:35:57,280 a six digit PIN 864 00:35:57,280 --> 00:35:59,800 Can you imagine the lineups going in and out of that building 865 00:36:01,300 --> 00:36:02,560 Six digit PINs 866 00:36:02,740 --> 00:36:03,760 or biometrics are good 867 00:36:03,760 --> 00:36:05,820 but they're not always the most usable 868 00:36:05,820 --> 00:36:07,240 or user friendly 869 00:36:07,760 --> 00:36:09,320 especially when you're trying to manage 870 00:36:09,320 --> 00:36:11,800 large amounts of people going in and coming out 871 00:36:14,540 --> 00:36:16,660 Alright, so that's the end of our presentation 872 00:36:16,660 --> 00:36:18,620 We have some extra 873 00:36:18,620 --> 00:36:19,680 of the little boards 874 00:36:19,680 --> 00:36:21,280 the card hopper boards that we printed 875 00:36:21,280 --> 00:36:23,240 the correct ones now 876 00:36:24,940 --> 00:36:26,740 So we also run 877 00:36:26,740 --> 00:36:28,740 the embedded CTF 878 00:36:28,740 --> 00:36:29,920 and so if you come play 879 00:36:29,920 --> 00:36:31,620 in the embedded village CTF 880 00:36:32,740 --> 00:36:34,100 the three teams will get one of those boards 881 00:36:34,660 --> 00:36:35,680 So come and play 882 00:36:36,280 --> 00:36:38,120 Or if you're interested in collaborating 883 00:36:38,120 --> 00:36:39,620 if you want to try testing this 884 00:36:39,620 --> 00:36:41,040 at further distances 885 00:36:41,040 --> 00:36:43,220 we're happy to share with you a card 886 00:36:43,220 --> 00:36:44,060 and a board 887 00:36:44,060 --> 00:36:46,580 and we can see how far we can push this 888 00:36:47,820 --> 00:36:49,760 Come chat with us at the side afterwards 889 00:36:49,760 --> 00:36:51,260 and thank you very much 890 00:36:51,260 --> 00:36:52,060 Any questions? 891 00:37:22,200 --> 00:37:23,860 They turn it back on 892 00:37:23,860 --> 00:37:26,720 Okay, you asked whether there's a subset of protocols 893 00:37:26,720 --> 00:37:27,840 that are supported by this 894 00:37:27,840 --> 00:37:30,740 So basically any ISO14443A 895 00:37:31,520 --> 00:37:31,920 um 896 00:37:33,100 --> 00:37:34,720 any technology that uses that 897 00:37:34,720 --> 00:37:37,140 which is most high frequency cards 898 00:37:37,140 --> 00:37:37,740 um 899 00:37:37,740 --> 00:37:40,200 they would be vulnerable to this kind of relay attack 900 00:37:40,200 --> 00:37:40,900 because of that 901 00:37:42,360 --> 00:37:44,500 So the most common that we come across 902 00:37:44,500 --> 00:37:45,960 in access control are CEOS 903 00:37:45,960 --> 00:37:47,840 and EV1, 2, and 3 904 00:37:47,840 --> 00:37:49,860 but I'm sure there are other ones 905 00:37:49,860 --> 00:37:51,180 we're just not super familiar with