 Thanks for coming out. This is our talk, Unlocking Doors from Half a Continent Away. I hope you have some fun. So this isn't working. All right. My name is Trevor Savatto. I'm the founder of a small cybersecurity company up in Canada called LabMath Security. I've been doing offensive stuff for, I think, counted about 15 years now, but I just stopped counting and put 12 plus in the slides. My biggest personal or professional achievement, it was winning a DEF CON Black Badge back at DEF CON 26. Thank you. Thank you. Hi. My name is Sam Haskins. I'm a hacker working for LabMath Security. I'm also a current computer science student at Carleton University up in Ottawa in the computer and internet security stream. I've been hacking things since I was 12 at least. I have two CVEs from ages 16 and 19. That was just last year. This is my second year at DEF CON, and I'm really excited and happy to be here. I'm just a little bit scared. All right. So we're going to be talking about physical access systems. So just to give you a quick background of all the components, you have a card that has the credential on it. The reader that's going to read that credential off the card, 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. If it is, it will send a signal to the lock, opens the door, opens Sesame Year Golden. We're going to be focusing mostly, well, entirely on the card to reader interactions. In that space, there's quite a few technologies that have been a part of this. 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, MyFairDestifier and CS. 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. So that's what the reader is trying to do. And so because of that, there's some ways that people have come up to attack it. The first one is the most basic card cloning attack. If you can see a card, capture the data off of it, write that to a new card, present that to a reader. It has no idea that it's a different card. So you have a duplicate and you can authenticate as the original card. A kind of offshoot of that one is a downgrade attack. So if you have a technology that can't be cloned, but you can read it with a standard reader, 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. And if the reader will accept both, then you've duplicated the card just as effectively. The other category that I don't see very much in the physical security space, but we just put it in for posterity, is the replay attack. So if you can capture a sequence of messages between a card and a reader and then replay that, you may be able to trick a reader into thinking that there is a credential there at that time. And then the final one, the one that we're going to be talking most about in doing the demos of today is the relay attack. And you might be familiar with this in the space of car thefts, where people are putting readers up next to your door and trying to relay the signal from your key fobs to your car. The same kind of thing that we're doing with RFID cards. We're going to try to relay an RFID card over a very long distance and just show you how that can be done. So to give you some context about how we got started down this path of research, it's good to know what the history of access control technologies are and what the flaws were that kind of led them to where they are today. So what are the original technologies? The HID prox, very simplistic technology. Once the card got energized, it broadcasts its ID. Anybody around can listen to it. Super insecure. There's no encryption on it. You can buy a reader from Amazon for very cheap. Fun fact, my very first DEF CON was DEF CON 21. I went to go see the Bishop Fox talk on the Tastic RFID thief, where he took a garage door reader, was a high-powered garage door reader and basically tagged on to the data line so he could record the card data. But that extended his read range from a couple of inches to a couple of feet. And he would walk around with that in a briefcase and collect cards. It's a pretty fun talk. I still have the piece that I got from it and it kind of inspired some of the stuff that moved me forward into this talk. So HID realized that that wasn't a good idea. So they came up with another version called the HID iClass and it was designed to protect card cloning replays. The way he did that was it had a key between the card and the reader that shared key that only they knew. HID created one shared key between the card and reader for most of the systems that they released. If you wanted to have a special key, you had to ask HID to create a new one for you and they called that the elite key system. So only your readers and your cards would use that shared key. And it was done through a proprietary cipher that they created, which was then reverse engineered by some researchers. And they came up with a key recovery attack where you can recover the keys of any, not just the standard, but even the elite keyed readers. So now it's trivially simple to create a copy of an iClass card using things like the Proxmark. Another kind of entry in the mid-range RFID is the MyFair Classic. So we don't see this very often used in access control, but it's kind of the precursor to the Desfire EV1 that sometimes does get into access control. So we thought we'd throw it in as well. It uses a different mechanism. It has keys for each sector and you can have two keys that you can define as a read or a write key. But again, they used a proprietary algorithm for that crypto. And again, it was reverse engineered by a team of researchers. So very easy to copy and clone MyFair Classic cards. I think this is about the point where both HID and NXP who make the MyFair cards kind of realize that maybe making proprietary crypto was not a good idea. And you can see that in a lot of their marketing about the new technology. So the new one for HID is CS, and MyFair, NXP came out with the MyFair Desfire. And there's a couple variants of that, EV1, 2, and 3. And so they all use industry standard ciphers. And the worthwhile thing to note is that EV1 came out in 2006. So 17 years since EV1 came out in CS after that in 2012, there's been no public techniques disclosed to clone a CS card. The only attack that was that is currently known before what we're going to show today, I guess, is the downgrade attack. So if you have a CS reader that has a standard key set and your card is in the standard key set, you could read the data off the back end, program that onto a low frequency or a lower security card, and create a duplicate that way. But that can be easily defeated by using elite keyed systems, because then you would have to have a reader that has that same elite key. So if you're targeting a facility, you'd have to go and rip that reader off the wall. And I'm pretty sure they're going to notice that. Or the other thing they can do is they can configure their readers to only accept the CS or desfire cards. So if you clone it to a lower frequency or lower security card, it's useless because the reader won't accept it. Now you might come into situations where they have different configurations around the building. In a loading bay, they might use a dual frequency reader, but most often the secured protected areas of a high security building are going to be protected by elite keyed CS or high frequency only cards. So, and that was actually the scenario that we faced when we were doing a red team engagement. So that's what led to the motivation. If we can't break the crypto, we go for a relay attack instead. And I'm going to pass it to Sam to talk about how we did that. Thank you. So first, I'm just going to talk a bit about the relay attack scenario. So what this would look like from an attacker deploying it. So basically, you're going to send one of your guys to stand besides a legitimate employee of the place you're trying to access on public transit or some other environment like that. And then they can hold a Proxmark fairly close to the guy's pass. Then you send one of your other guys right up to the door and just badge in. And you need some way of communicating between the two Proxmarks. We use the internet as a backbone, which is super convenient because it's available like everywhere with cell networks and stuff, but it theoretically could be anything there. So here's the architecture of our original attack here. The first version used laptops instead of mobile devices. We since migrated to that. But as you can see, we have the real card and then two Proxmarks acting as a fake reader and a fake card. And then if you follow that green line there, messages go from the real reader all the way to the real card and then responses go all the way back. You repeat that about 10 or 12 times or whatever. And then the door opens. And even this original attack did use over the internet. We had a web socket connection between the two laptops. And in this original attack, we also used Bluetooth between the laptop and the phone, or sorry, between the laptop and the Proxmark just to get them a bit further apart and not have to run wires. So because all of the messages are generated by a real card and a real reader, the contents are guaranteed to be correct if they weren't, the system wouldn't work in the first place and the legitimate cards would not open the doors. So the only way that readers could detect our attacks is by detecting timing variations. And that's because the round trip time of request response over about an inch between the legitimate scenario versus auto to Vegas is significantly shorter. So we were investigating can we make the readers support longer than normal timings? And it turns out that we can. There's a few mechanisms. So all of the high frequency cards that we've discussed so far, so the 13.56 megahertz ones are based on ISO 14443 tack for type A or just 14 a since that's a lot of letter soup. And most access controls would be based on the standards. There's a few that aren't, but most of them are. And this is analogous to like how HTTP is built on top of TCP. This provides like a messaging layer that the application specific data would travel over. But before any application layer data, so the CS protocol or the desktop protocol before any of that happens, the card and a reader must exchange parameters in what we call the 14 a handshake. And this is both documented very nicely. It's an ISO standard, but it's also not encrypted or authenticated at all. There's a 16 bit CRC on some parts, but the details of that are public. So we can mess with that. So let's have a quick look. So this diagram here shows a wheel handshake that we captured between a real CS card and a real reader. You don't have to understand most of it. The spec is about 100 pages, but there are a few parts of like the highlight here. So the first message I like to highlight is this UID CLN message. Now, the standard actually has a mechanism for the card to give a UID to the reader. CS doesn't use this because it's completely unauthenticated, as said earlier. But other mechanisms do, but CS actually just provides a random value each time. So you can't even use this with readers that don't support the CS protocol just by falling back to that number. And then the other thing I like to highlight is that ATS message there, and specifically that blue byte, which is interface byte TB1. ATS here is answer select with our ATS being request answer select. And the important bit of TB1 there is the frame waiting time integer, which is coded in the high nipple. And that the frame is the frame waiting time. And I'll explain what that is in just a second in accordance with that little equation there. And the FWT tells the reader how long to wait between frames. So after the reader sends a request, it will wait that amount of time before expecting a response from the card. And if it doesn't receive one at that point, it will usually restart the entire authentication attempt from the beginning. However, this is unauthenticated. It's sent by the card, which we are pretending to be, and we can mess with it. And if you notice at just the end of that equation there, there's that exponential term, we can make that go pretty high. So after the 14A handshake is complete, it goes into the COS protocol, which is a bunch of random bytes. And I have no idea what they mean. But who cares? Because these are generated by a real card and a real reader. We know they're right. We just need to get them from point A to point B. Yes, a lot of the messages in the 14A handshake are sent before that ATS message. So the modified frame rating time won't apply yet, and therefore we can't relay them. The latency over any internet connection, even basic Ethernet will be far too long. It's messed up by print statements, in fact. So that initial 14A handshake does have to be handled on the Proxmox themselves. But thankfully it can really just be hard-coded for the most part. It doesn't really vary, but we'll get into a few more details on that later. And as for how long we can get the reader to wait between frames, if we set the FWI to its highest value of 14, we can make it wait 4,949 milliseconds, which is almost five seconds. I'm not sure why that's supported by the standard, because I don't see a real use case. But it's very convenient for us. There is another technique in the 14A standard that we can use to bypass the ran-trip time check, which is waiting time extensions. And that's a mechanism that applies to just the next message, not all subsequent messages. But it can also be repeated, which is nice. So theoretically, if you keep the fake card by the reader for 20 minutes, and it just keeps sending these, you could have 20 minutes of time. But in practice, at least with the readers that we tested, we found it was less reliable. So we're mostly relying on modifying the FWT. I think it's a big problem with the WT access. It does need to be sent for each message. So if it's missed once, the entire authentication attempt fails. So our original design was implemented as an extension to the already existing and open source HF V-Blade Proxmark standalone mode, which was originally written by Salvador Mendoza. That was to relay credit cards, actually, which was pretty cool. And we made some changes to allow Ving to see us protocol, or really any protocol, instead of just credit cards, and also adding the long-range internet component, instead of just over Bluetooth like it was originally. And this original design was strongly coupled with the Blue Shark Bluetooth add-on. Messages were conveyed from Proxmark to laptop, and then sent over IP. We did have a lot of success with this design. The big highlight being unlocking a door in Ottawa with a card in Florida, because my colleague over here has a vacation home in Florida. So we sent him down with a card and just tried that out. And it worked after a few tries. There were, however, some fairly major reliability issues in this original design. So the Blue Shark add-on does come with an integrated rechargeable battery. And we did like that design at first because it's a lot more convenient for, like, real deployments, like actually standing beside someone on the bus and trying to relay their card than running a cable up their sleeve. You get to put a bit further away. You don't have that whole cable to deal with. But the ability of the Proxmark that's pretending to be a reader to read the card, which is its job, is very dependent on the battery level. If it's too high, we get bad reads. If it's too low, we also get bad reads. We're not entirely sure why that happens. We think it's related to, like, the voltage level being output by the battery, but we're not 100 percent sure on that. It did prove very frustrating, like, while we developing this, we'd develop little rules of thumb, like, when it starts failing, plug it in for 12 minutes and try again. And that kind of worked, but it wasn't very nice. The other problem was latency. So we can make the reader accept ridiculous amounts of latency, but on the card side, real cards are designed under the assumption that the reader will respond within most a few milliseconds and typically much faster. And we load that assumption out of the water by several orders of magnitude when we're doing this over longer ranges. So we find that the card sometimes, like, forgets that it's supposed to be in the middle of an authentication attempt, and this happens increasingly often as the latency increases. This isn't, like, necessarily a deal-breaker by itself because it just means you need to retry from the beginning. So if you're guys still standing beside the guy in public transit, you're good to go, but maybe it's a little suspicious if you're standing beside a reader for two minutes waiting for the door to open. Not the best. And different cards could be more resilient to this. Most of our observations here were with Seos cards in particular. We actually only tested with Desfire for the first time earlier today before we went to sleep. It was hard to source a card. So between that and the battery issues, the initial design was not reliable. It was usable, not really reliable, but usable within the same city. And even then I'd say this was a practical attack that higher security, higher value facilities would be more concerned about. But it was much harder to make it work over longer distances. And even in the same city, it wasn't perfectly reliable. So our revised design, we incorporated quite a few changes. So first off, we swapped laptops with phones. Laptop on your back, that is fine, but phone in your pocket is even better. And then, more importantly, we swapped that little Bluetooth link there with a serial link. And we're also powering the Proxmark from the phone over that serial link. So we knocked out the battery and we knocked out Bluetooth. Bluetooth was nice, but Bluetooth Classic is a horrible protocol and 15 milliseconds of latency on each side, 100 milliseconds total. When Florida to Ottawa is only a 99 millisecond ping, that's almost doubling it. And we didn't really want to eat that. And getting rid of that really did increase our reliability. Additionally, we just operated over a cell network where phones will not have public IPs. Instead of them connecting directly to each other by WebSocket, we have a little relay server just hosted in digital ocean in between them. So the software in our revised design is called HF Card Hopper. It's a new standalone module for Iceman's Proxmark 3 firmware. We were releasing it later this week whenever I get around to doing a pull request. It's inspired by Salvador Mendoza's HF Replay, the original design, but doesn't share any code. And it has to code to trick readers into using a longer frame rating time. It can relay any ISO 14443A 14A based protocol. And it actually has support for relaying that initial UID and DATS. That doesn't matter so much for COS because the UID is random each time. But for Desfire, that UID actually contributes like material to later cryptographic operations. So to get it to match up on both sides, you do need to get that right. Now because that's sent over DATS, we can't actually relay that in real time because the modified frame rating time won't apply. But it doesn't actually change, like for when it matters, it doesn't change. So Desfire codes always give it the same UID. So if you just read it once, then transmit it, then the Proxmark can set itself up to emulate that specific card and that doesn't have to happen in real time, which is nice. And it works with BlueShark and our custom hardware, which handles that CO-Link, which my colleague Trevor will talk to you about. Yeah, so as Sam mentioned, we wanted to swap out the Bluetooth module, mainly because of the latency issues. So we came up with another module that is USB to UART bridge, basically. If you're familiar with things like the Chikra, it uses the FT-232 chip that's in the Chikra. We just modified the design to have a USB-C, which is much more convenient for connecting to modern phones, and then a ribbon cable for connecting to the Proxmark. We chose to use a ribbon cable to connect to that interface on the Proxmark for a couple of reasons. A, we think it's a little bit faster. We're directly connecting to the Proxmark over UART, whereas if you're connecting to the USB on the side of the Proxmark, that's actually an emulated modem, so that would add a little bit of latency. But also, this makes it completely interchangeable with the BlueShark add-on. So if you wanted to use the BlueShark for wire-free, our emulator, the standalone mode, will still work with the BlueShark and with this interchangeably. We did have one little hiccup when creating these and ordering these for Defcon. It turns out that just casually mentioning that you need a 14-pin, 0.5-millimeter spaced ribbon cable adapter is not enough to make sure it actually gets ordered properly. So lessons learned. We managed to get it reordered, rebuilt, props to one of my colleagues who actually disassembled half a dozen of these. And if you see one of these, if you come up, I'll show you, there's a lot of tiny little components in here. He took every single component off and resoldered it onto a new board with the right pin header. And that's the board that's being used in Ottawa right now for the other side of this demo. So appreciate that. It was a lot of hard work, I know. And then the other thing we added is a custom Android app. So to make it easy to interface with the Proxmark, we created an Android app that will bridge the communication between the FTDI and therefore the Proxmark and the Relay server. And it supports card or reader modes. You can alternate it. And it supports CS and Desvire cards. And you can adjust the frame weighting values for your specific target. And it also will handle hardware resets because we came across a lot of those. We needed to build that in to be able to quickly reset and start over again. So it's quite easy to start over with that. But I will say it is my first Android app. I've never done this before and we kind of just went function over style. I know it's pretty ugly, but it works. All right, so let's go over some of the results before we get into the demo. So we've tested this on a variety of different HID readers. So the first couple are older generation HID multiclass readers, the RP40 and RPK40, a couple of different models. But these were ones that will accept both low frequency and high frequency cards. So there is some requirement for them to adjust the frame weighting time because older cards are a bit slower. So it makes sense that adjusting them was a successful attack. But the one that was a little more surprising was the signal readers from HID, which are their latest and greatest readers. And there's three variants of them, 00102. And that just, the difference in those is the protocols that it supports. So 01 is kind of like your multiclass. It will support the low frequency and high frequency. Sorry, that's the 00. The 01, I think, is the only CS protocol, CS and DESFIRE, and then 02 is CS, DESFIRE, and smartphones. So that one's the one that, to me, is surprising that the frame weighting time attack works on because, especially for the 01 and 02, they're only talking to high frequency cards that are fast, quick responding cards. There's really no need for them to have, to accept an increased weighting time. In terms of the card technologies, most of our research was focused on CS because, as I said, this was motivated by a specific engagement we were trying to get into a building. But we have since, as of last night at 1 a.m. in the morning, acquired an EV1 card and compatible reader and were able to test, and it does work for EV1 cards as well. The other ones that we haven't tested with and we want to are the EV2 and EV3. The problem with that is so EV cards are not super common in HID access control systems. And so getting an EV1 card or an EV2 card that is programmed with an HID secure identity object, which is the object that they write in the card to, for the reader to unpack and pull the identification out of. So to get a card coded for that is quite challenging and quite expensive. So we haven't come across those cards yet. But the interesting thing about those is the NXP does have a patent for being able to do the proximity check for communication devices. So based on that, these two technologies should be immune to our relay attack because they should be able to detect the proximity of the card. But it's something we would like to verify and try for ourselves. In terms of distances, we started out in our lab, just across the room 12 feet. One of us took the reader's home, went back from our house to the office, tried that. And then, as Sam mentioned, when I went down to Florida, I took the card with me. We relayed it from Florida back to Ottawa, which is about 1,400 miles of distance that we're going across. And then, earlier today in the green room, we finally got a successful test of doing Vegas to Ottawa. And I say, finally, got us successful. We just didn't have an opportunity because production issues on the card hoppers. It actually worked quite smoothly, quite well. So that's about 2,400 miles now we've gone. Can we do it on stage? Is that possible? So I better text my colleague on the other side who's waiting for us to say, we're ready. So I'll tell them to join now. We also would like to test this further. So if there are people here that are interested in collaborating with us, if you live far the way, Brazil, or other places, that we can try this out and see how far we can push this distance, come chat with us afterwards. All right, so we are good to go. They are ready on their side. Let's jump on. Hello. I don't think this sound is working. Welcome, Noon and Liz to DEF CON. Everyone say hello. All right, so Liz is just going to demonstrate right now that she can't get into the door. It's locked, right? And just presenting the reader that she has to the door is not going to work because we're not relaying the card at this point. So if she puts it up against the door, if you put the thing up against the reader, yeah, exactly, it doesn't work because we need to relay the card. All right, you're ready to go, Sam? Liz, you're ready to go? Give me a thumbs up when you're ready. Thumbs up? Let's see. I think we need to do a reset on her side. One sec. Sorry. This is what happens when we do it live, right? She's working with the pre-production version, the one that my colleague put together by hand. So it's not the most production-ready system. So we'll give her another second here. All right, she's good to go. We're good to go. All right, go for it, Sam. Put it closer to the reader. All right, we're going to try it one more time. If not, we'll switch. Just pull back, Liz, and cancel will try again. Give me a thumbs up when you're ready to go. If this doesn't work, we'll switch to the video of us doing it previously in the green room just to prove. OK, I think she's good, and it's not working. All right, well, I guess that's where we're going to jump to video. Demo gods prove too much for us. Thanks anyway, Liz. Noon, thank you. All right, so we kind of planned for this, so that's fine. So this is what it should have looked like. So when she puts it up to the reader, it does take some time because we're relaying these messages one at a time over the internet. So it's not as quick as normally when you when you push it up against the reader. But after a certain amount of time, it does work and she can open the door. So on the phone side, this is what you would have seen if you're looking at the phone. So we connect the card hopper. Card hopper is the term we're giving this this board. We connect it to the phone. We put the phone into reader mode. We don't adjust the frame waiting time because it's fine. And then we start seeing all the messages flying back and forth. You can see there's quite a few of them going back and forth. We don't really care what they are. They're right. They're fine. And that's the at that point we're done. We've opened the door. So yeah, I said we don't care about the waiting time. We default it to 14, which is the max. So we're just leaving it at the max and it's working fine. On our side here, this is what you would see. So this was us in the green room. So I put the card up against the reader and wait and it goes through that back and forth, back and forth, back and forth. And then boom, we're done. So it does take more time. It is a little bit more conspicuous. It's not necessarily the stealthiest of attack, but hey, being able to really get a card from here 2,400 miles away, I think is pretty good. So the other slide, a couple of other slides we wanted to show, the prevalence of the different technologies. So unfortunately, there's a weird trend in the access control industry that they don't necessarily move to the newest technologies right away. We're still using a lot of the old technologies. So the 125K HID proc stuff I mentioned still has about 32% of the market. Very small market percentage for the Seos and even smaller for some of the MyFair cards individually. But it's interesting to note that these technologies have been around for a while. Like Seos came out in 2012, EV1 2006. So it's unfortunate that the industry has not adopted these as quickly as they probably should have. Was there something else? Right, so yeah, the other point that we wanted to make was that most of the ones that are currently in use aside from the EV2, EV3 are vulnerable to some sort of attack at this point. So most of the access control industries is still vulnerable. So also wanna talk a little bit about HID's response. So we did a responsible disclosure of this through Bug Crowd. We disclosed it to Bug Crowd on December 9th of 2022. It was triaged by HID on January 17th and then we got their final response on March 10th. I'm sorry, I'm just not showing the presentation mode. I should have switched back. Why? All right. One of the recommendations we made to HID was that they should limit that frame waiting time integer, not accept values over what are strictly necessary. And they didn't like that idea because it would put them out of compliance with the ISO spec and it would impact their customer's needs for backward compatibility. I don't know any customer that needs a five millisecond, or five second waiting time for backward compatibility but that's what they felt like. The other comment that got to me a little bit was that the majority of their end users do not see relay attacks as a viable threat. That was the motivation for coming here today for doing the additional work of creating the pieces. We wanted to show that this is a viable feasible threat, something that could be done with simple technology from the Proxmark, a small little add-on in the relay server. The one comment that they did make, which has I think some good validity is that their end users that are concerned will typically add a second factor, pin or biometric and some will use their mobile credentials. But the one problem that we see with this is, okay, now everybody has to enter a six-digit pin. Can you imagine the lineups going in and out of that building? Six-digit pins or biometrics are good but they're not always the most usable or user-friendly, especially when you're trying to manage large amounts of people going in and coming out. All right, so that's the end of our presentation. We have some extra of the little boards, the card hopper boards that we printed, one of the correct ones now. So we also run the Inverted CTF and so if you come and play in the Inverted Village CTF, the top three teams will get one of those boards, so come and play. Or if you're interested in collaborating, if you wanna try testing this at further distances, we're happy to share with you a card and a board and we can see how far we can push this. Come chat with us at the side afterwards and thank you very much, any questions? They turn it back on. Okay, you asked whether there's a subset of protocols that are supported by this, so basically any ISO 14443A card, any technology that uses that, which is most high-frequency cards, they would be vulnerable to this kind of relay attack because of that. So the most common that we come across in access control are SEOS and EV123, but I'm sure there are other ones we're just not super familiar with.