 All right. Hello, everyone. Welcome to the virtual stream of the DEF CON talk. The Pax Man comes for us all. We may still be vaccinated, but access control still sucks. We're going to jump right into it today because we have a lot to cover. For those of you who don't know, my name is Babak Chavadi. I'm a lock picker, hardware hacker, and reverse engineer. I've also been a professional red teamer and covert entry instructor for over a decade. Founded the open organization of lock pickers, the red team alliance, and the core group. Nick, tell us a little bit about yourself. Sure. Yeah, I'm Nick Drafton. I like to hack things where the physical and digital world intersect. I'm involved in the RFID hacking by Iceman Discord and find me there. Eric, can you tell us a little bit about yourself? I'm Eric Betz. Hi, everyone. My name is Anja. I'm a student of computer science in Slovenia, a security researcher for about five years now. Disassemble everything I find. Bug bounty hunter made it into the Google vulnerability research program Hall of Fame. Mostly now I do RFID research. All right. So today we're going to talk about two things. We're going to talk about a new tool that we're releasing that's going to make red team a whole lot more fun and a whole lot more easier. And we're also going to talk about a interesting vulnerability that we found in some readers. So first, what are PAX? What is the PAX man? Well, that refers broadly to physical access control systems. And we're not going to go in depth into how they all work, but we'll give you a very light overview. If you're interested in more, check out our other DEF CON talks or check out the RFID hacking Discord or red team alliance. But we are talking about enterprise access control systems. These are embedded boards that take in inputs of various kinds, most often credentials. And based off of logic, controls certain outputs, such as door hardware, magnetic locks, electrified strikes, etc. The most important concept to keep in mind throughout this first part of the talk here is that RFID credentials, regardless of what technology they are, they are basically very simple, very tiny containers. So whether it's a prox credential or a I class or my fair credential, these are just different ways of all storing the same data. So a lot of older low frequency credentials, they're simply like folders, electronic wireless folders that contain a very small bit of data inside. And when we present that folder to the system, some interesting things happen. So to talk to you about that, we're going to cover a really short, very simple analogy. We have some characters here, some of you may have seen them before. So we have our RFID reader, we have our RFID credential, we have our door controller, and then of course we have the door hardware. So what happens normally is that RFID reader is always scanning, looking for credentials nearby. As soon as that credential comes into range of the reader, it actually is powered on by the field of the reader and immediately starts transmitting the data stored on the credential. The reader receiving that information takes that and then retransmits it out to the door controller. The door controller performs some logic functions, decides, hey, is this person authorized or not? And if so, we go ahead and release the electrified strike, magnetic lock, what have you. Of course, it's not just low frequency credentials that work this way, high frequency credentials work in a very similar way, but with a couple of extra layers of protection. So the data might not be in plain text, it might be stored in some sort of obscured encrypted format. And most importantly, that data is protected. So if we imagine our credential data being folded into an envelope, placed into a secure bag, and then that bag being put into a locked container, that is similar in many ways to how a lot of contactless smart cards and high frequency credentials work. The data inside is ultimately the same, we are just adding additional layers of protection. So again, really oversimplifying how these technologies work. If we take a look at, you know, a high frequency credential, here's an example where mutual authentication takes place. So it doesn't immediately start transmitting the cardholder data, but rather a secret handshake has to take place, where the credential and the reader mutually authenticate each other without revealing any secret key material. And once that information is verified, then the cardholder information is provided to the reader, the reader then retransmits that to the door controller and everything else continues as usual. So credentials come in a lot of different shapes and sizes. A lot of them are broken. A few of them are not. And ultimately, they are just one major component of the access control system. So we have a bunch of different credentials. We have readers, we have the door hardware, different types of sensors, motion sensors, door contact sensors, etc. Then of course, we have the door controller or control panel that is making all the decisions. And that is all managed by some server side software or PAX software package. So oftentimes when in the hacker community, we're talking about interacting with access control systems, very often we're really talking about hacking just the RFID piece, the credential side, which really just refers to the method of communication used between the credential itself, the card itself, and the card reader. So all these different pieces, they are set up in a very interesting way. And they all kind of work independently of each other, but are kind of glued together in a couple of different ways that we'll see. However, let's talk about some of the most common tools of the trade when we're talking about RFID hacking in general or in red teaming as it applies to it. Some of the really common tools that you'll see or may already be familiar with is first of all the Proxmark 3. This thing is ubiquitous. It's an open source hardware project originally released by Jonathan West used ages and ages ago. Since then, there have been many different hardware variants that have come out, some good, some not so good. It's very much a kind of Swiss Army knife of RFID. It's a software-defined RFID tool that can just with, you know, reprogramming the code and firmware, we can change what different credentials that can talk to. And this is one of the reasons why it's been so popular with the community. The most recent, most common variant of this tool is the Proxmark 3 RDV4 made by the RFID research group. And it's one of our favorite variants. It's very mature today and finally has become stable and good enough that it can be used much more easily for red teaming. One of the coolest add-ons that it has that hasn't really been fully taken advantage of yet is the Bluetooth add-on or the Blue Shark, which is a Bluetooth 2 interface to the reader. And we're also going to be using in this first part of the talk the ESP key. This is a weekend interception device originally made by Kenny McElroy or OctoSavvy on GitHub and Twitter. And this is a weekend interception and replay device. And it's not the first of its kind. There have been a number of others before it, the VLE key, and of course the gecko made by Zach Franken and Adam Laurie. And this is a device that is optimized for field deployment. So it's very fast to install. It has a very easy to use user interface. And very happily is one of my favorite and cheapest, fastest ways to weaponize any reader. What do we mean by weaponizing a reader? Well, that's just a fancy way of saying we took a regular card reader that knows how to talk to the credential that we want to talk to. And we're going to connect the data logger to it. So we've supplied some portable power in the form of a battery. We connect a data logger of some kind that can be a Arduino or Raspberry Pi or whatever you want to use. In this case, we're using an ESP key. And that's it. You have a weaponized reader. Data is read by the reader. The reader sends it to the door controller, except there is no door controller over the ESP key, which records it. So this is a really cool versatile multifunction tool. Typically, in the field, what that workflow might look like is once you capture that card holder information, now we have to then encode it onto a card, which we often do manually, either from a computer terminal or if you have an Android phone, you might use the Bluetooth enabled phone application. But it's a little bit clunky sometimes requires some extra steps. And it does take a little bit of time. So once you clone a credential in the field, you still have to then go back and write it to a card later. So how do we improve this experience in the field? Well, we know that there are these Bluetooth capabilities out there for the Proxmark 3, and we know the ESP key has Wi-Fi. So surely there must be a way to automate these things and to tell us what we ended up coming up with to create this automation, I'm going to hand things over to Nick, who wrote some really cool software. So yeah, thanks for the introduction there, Babak. Yeah, Babak and I were on a phone call talking about usage of weaponized readers in Proxmark 3s in the field, trying to come up with a unique way to glue them together and leveraging those functions that are already on the ESP key with the Wi-Fi and the Proxmark 3 with the Bluetooth. We kind of thought about what else had Wi-Fi and Bluetooth. And the quick and easy answer to that, what would be portable in the field was a Raspberry Pi 0W. It's small, it's able to be battery-powered, and it has both Wi-Fi and Bluetooth peripherals, so we can connect it. So this is where we kind of came up with the idea for Odo. Odo, if you don't know, is a character on Star Trek Deep Space 9. Odo is a changeling in this show, which is a shapeshifter, meaning that he can take the shape of any object or person. So with the idea for Odo being that you capture a credential via the weaponized reader, you then shapeshift into that person, essentially leveraging a physical privilege escalation in the field. You can bump into someone, grab their badge, and become that person, and use that to your advantage. So what is Odo under the hood? Odo is an open-source framework that takes credentials in, puts credentials out, and it's language agnostic because it basically leverages the fact that it's a JSON over MQTT API. So there are credential producers, there are credential consumers. One side, like an ESP key, or produces credentials, and emits an MQTT message. The other side, like Proxywork 3, can consume those messages and then do something with that data. So this allows it to be language agnostic. Even though the base framework is written in Python, we have a number of different modules that are in different languages, currently basically Python and Node.js, but it doesn't really matter. So essentially, this framework can drive not just the implementation that we are going to show here today, of the weaponized reader and the ESP key, but any type of thing that can produce a credential data that you can then write to another credential, you could add modules to this framework. So it also gets better with hats and haptics. So for that field usage, being able to see the credentials that you've captured, select a specific one, specifically if one was better for you than another, you can go and select that credential and it will rewrite that to the tag that's on your waistband or on a lanyard, because the proxy mark will be battery powered on a class behind the tag. And then using a haptic feedback device, which we have pictured here, will indicate to you that you have captured or cloned a credential. And with that being said, I'd like to do a quick demo. So let me switch down to my top-down camera and do the big version here. So you'll see that I have a Proxmark 3 powered by its battery. Blue light is on because it's connected to the Raspberry Pi Zero W over there. Our haptic feedback device is here in a case so it doesn't go haywire on us. This is our target credential. And then this here I'm showing in front of me is the source credential. The source and target credential technology doesn't really matter because we're taking that weekend value and encoding that onto a target credential. So I have a weaponized reader here off frame. I'm going to scan this credential. We will see a new item up here on the screen. And the haptic device indicates that it has seen a credential. And then once that credential is written, which we see the blue light blinking on the Proxmark, it vibrates again to indicate that the credential has been written. So yeah, that's pretty much what we have with Odo. The ways that you can contribute and make one, we have a GitHub open source repo with the framework and our initial modules. Raspberry Pi Zero Ws are cheap and readily available. The Pi Sugar that we chose to use here is a great way to battery power the Pi in the field. And the LCD module is helpful for that local interface. And there are a number of different ways that this could be extended pretty much immediately with other credential producers and consumers, new feedback mechanisms, and leveraging some sort of wearable smartwatch or even haptic feedback vest and just go wild with all the different possible producers and consumers. So with that being said, I'd like to hand it back over to Babak with the evolution of PAX. You're muted. Thank you. One of the things I really enjoy about the Odo framework is that this now allows us a way to do in-field, live, privilege escalation, completely automated and touchless. And if you come to our live talk, you'll see what that looks like in action. And it's really, really cool. Now, that's just one part of something we wanted to talk about today. Something else that's really interesting has to do with how evolution takes place in access control. So what we're going to talk about is what I'm calling the physical security chain of trust. And it really kind of underscores how discreet and rather independent a lot of these components are and the way that they're glued together really has nothing to do with other components necessarily in the system. So what I mean by that is, for example, let's take a look at an old, old system that's running weekend wire and a weekend reader. When this system first came out, it was very good. It was the newest technology, very difficult to clone and manipulate, but systems age. So as they age, the chain of trust ages as well. And because of budget constraints, you don't really rip and replace the whole thing. You replace specific links in the chain selectively. So maybe a new technology comes out, Prox hits the market and you're like, oh man, I'm so tired of swiping cards. I just want to use Prox cards so I can just go boop and get through the door. So we replace just those links, but they have to be backwards compatible because that's the only way that we can really afford to deploy a lot of this new technology in massive scale sometimes. So what that means is only parts of those links are replaced. So then the chain of trust continues aging and we have different components replaced. We again upgrade our cards and readers. This time we might also upgrade our door controllers and software, server side software, because maybe we want some of those new functions, some new capabilities, more memory, you know, faster, all of the things, but that's not necessarily, again, addressing the whole thing. So you might notice there's one particular link in this chain that keeps aging more and more and more. And so now by the time that we are in biometrics territory and people have, you know, facial recognition, this and iris scanning that, a lot of systems historically were still using a weekend. That's this really old link in the chain here. So considering that your chain is only as strong as the weakest link, that is of concern, right? So recently over the past couple of years, this has begun to be taken care of with OSTP. It's something that we talk about more and some more other talks and in our trainings, but it is the replacement for weekend is for the replacement for that weak link. And it offers a lot of new functionality in the form of bi-directional communication and encryption that really kind of help improve the overall security of the whole physical security chain. However, security alone is not enough for the industry and for a lot of customers. We keep wanting more and more functionality. So even though we've now have this new tool here for this chain, the development elsewhere has not stopped. Now the new hotness is mobile credentials. So mobile credentials of the new black and access control, they can come in a lot of different shapes and sizes. But ultimately, if we have to work with smartphones, we only have a few different interfaces that we can work with. Ideally, we would want to use NFC with the credential data stored in a secure element on the phone, but not all phones have NFC. Only the more higher end, more modern phones have that. And even of the phones that do, not all phones provide a proper API that you can use. Apple, until very recently, had iOS pretty locked down when it comes to anyone but Apple using that NFC interface on the phone. So a lot of vendors have resorted to BLE or Bluetooth Low Energy because almost all smartphones have this technology. But unfortunately, BLE, as a lot of you know, was not designed for this purpose. So how do we shove BLE into these older readers that did not necessarily have this technology? There's a couple of different ways that vendors have done this. There's inline adapters that you connect to the weekend line that are basically Bluetooth enabled ESP keys that are not used for attacking but rather functionality. And then there's also stuff like this where one major vendor decided, hey, why don't we use the debug interface on the back of the reader that we made for upgrading and programming? Why don't we use that to add Bluetooth functionality to the reader? And now we can have this beautiful new future where everything is mobile enabled. And now we have this phone-based diagnostic capability. We can do firmware upgrades. And most importantly, we can reconfigure the reader. We can disable older technologies that we don't need anymore or that are insecure. So for this particular platform, what was used was an application called Reader Manager. Reader Manager allows you to reconfigure the reader's settings, what protocols it supports, et cetera. It scans for nearby Bluetooth enabled readers. It allows you to reconfigure it. So it allows you to change configuration, turn credentials on, turn credentials off. But if you're using Bluetooth, Bluetooth is not a short-range technology. You can cover quite a bit of distance. If you have a lot of readers, how do you know which one you're reconfiguring? That is the question. So there are a couple of different ways that companies have dealt with this. But what this particular company did, and we'll go ahead and see if we can cut video here. There we go. So what we have here is a example reader. And I just have a little field detector card here in front of it. We're going to talk about that in a few slides. And it's kind of hard to see. So we're going to adjust the brightness here. Let's see if we can see my phone a little bit better. Not really, unfortunately. So one thing that it has, and it should pop up here shortly, is there is, there we go. So we can see all the readers listed there. And when I tap on a reader, I get this option to inspect or locate. So when I tap locate, what it will do is it will make the LED flash and make the reader beep. So I know which reader I'm about to configure or touch. You might have also noticed something else unusual that just happened, which is the LEDs on this field detector card turned off. And we'll talk about in a moment why that's a problem. Because while that reader field is off, we're not actually able to scan and process media. So where does that leave us? We have that locate functionality to identify which readers we're working with. There are some security functions that we found that was built into this. The changes, sorry, the functions were allowing you to make changes to the reader or the inspection functions. These are functions that require some form of authentication. So the most common method that is used is you have to power cycle the reader to apply certain changes because we don't want people just turning credentials on and off unexpectedly. So the reader only accepts certain administrative configuration commands for a very short period after power on. But that by itself may not be enough for a lot of applications. And this is where a lot of customers can go an extra step and get a custom key or elite key in certain systems. So custom keys basically add an additional restriction in that not only do the credentials have to have that special key, but also any phones that need to reconfigure the reader also have to have a special administrative key that is unique to that site. Now, what's interesting here is that some the locate functions did not require any authentication, meaning we found that you could locate a reader regardless of whether or not it was a standard reader or an elite reader. And because that locate function temporarily shuts off the field, that is of concern. So in regards to the Bluetooth, I'd like Anjay to really talk a little bit more about some of the things that we found once we took a closer look at this. Thank you, Babak. So after further looking at what is happening over Bluetooth though energy, we found out that all of the readers advertise a single service, all of them, of course, with the same new ID. The service had a single notify and write without response characteristic upon subscription to that characteristic. The reader sent an initial message. If it didn't receive a reply in a certain amount of time, the reader disconnected automatically quite aggressively. So under the hood, we wanted to see what the BLE conversation looked like. And so we wanted to sniff that out. We got an NRF 52 development kit loaded NRF sniffer for Bluetooth LE located the device, saw what was exchanged and got the messages as PCAP files. So in those PCAP files, we wanted to look at what a BLE conversation looks like. We can see here that the message looks quite similar to an ISO 7816 APDU, which is also used in other smart card protocols, most notably in credit card processing or EMV cards. And to that the phone replied that the AID the reader was trying to select was not found. So you might be wondering now what is with all the readers that everyone has behind them at this talk? And the readers have some blinking lights. So why are the lights blinking? The readers have field detector cards made by prox grind and RFID research group. The LEDs on them are powered by the electromagnetic fields emitted by the readers to make them blink. There are separate LED colors and separate antenna windings on the PCBs for low frequency and high frequency. So the red LED means that an LF or 125 kilohertz field has been detected. And the white LED means that 13.56 megahertz or the HF field was detected. But because we all know that PCAPs are boring, we of course went and implemented our first demo in Python. And it was able to take down one device. We then rewrote it in Node.js, made it async, which allowed us to take down about five liters at a time. But then we wanted to see if we can go even further. We got ourselves an NRF 52 development kit, rewrote the whole thing in C, and we're able to connect to quite a bit more devices. But because we all know that a development kit is something that you don't carry around, we then moved to a Pug.js, which is a NRF 52 832 based development board with RGB LEDs, a button and powered by a CR2032 coin cell battery. And now we will have a demo of what happens when we start sending that to all the readers in our vicinity. So I would ask everyone here to please turn on your dongles. And we'll go ahead and activate. And what the code is going to do is automatically look for any available readers nearby. And one by one add them to the list of readers that we send a barrage of locate commands to. And now you can see almost all the readers, except for that one guy, don't worry about that one guy, have the fields shut off. And in that state, they're unable to process media, meaning no cards will be able to be read by that reader. So you've just had a physical denial of service event. And now I would like to give my word to Eric. Yes. So as Bob mentioned before, these field detectors, they stop blinking. What does it mean? It means there is no EM field. That means it doesn't matter if you present anything to it. These are basically just like dead plastic at this point. And so that is very bad for all of this. Sorry, that's sort of the field detector part of it. And we got to thinking, what else has an NRF 52? And for anybody that's been around at DEF CON the previous couple of days, they may have watched talk about this. You know what else has an R52? My fucking air tag. So we put our firmware on an air tag. So here's me putting the battery going to go ahead and slide that closed, flip over to this and you all can see it has also knocked out the readers, except for that one. Nope, not that one too. And so now I'll hand it back to Ange. Thank you. So we wanted to really bring it home and remember the backpack that added BLE to our readers? Well, we found out that BLE is also powered by an NRF-based chip for Bluetooth Low Energy. And we asked ourselves if we can also reprogram that and we found out it is possible to reprogram it the same way as an air tag. So with that we were able to take down eight readers in the vicinity of the backpack being powered. And then of course, because NRF 52 is such a widespread chipset, we then asked ourselves what else we can use as an emitter for the attack. And we found out that there's a COVID test that has an NRF 52 in it. There's some development devices, personal pleasure devices, and the universe of NRF 52 is pretty much endless. And now I would like to give it to Babak for some closing words. So what does this all mean? What's the real practical impact other than just annoying some people? That depends on the situation. So we've evaluated a number of different customer deployments and different use cases where these readers and Bluetooth backpacks have been used. And what we're looking at is really, really dependent on what the attacker wants to do. So we can do either a highly selective or a very area wide denial of service attack. So we can identify specific readers and attack just specific readers, or we can deny access to an entire area. And in the field and practice, what this means is that there are sensitive egress and ingress points that we can then prevent people from using unexpectedly and without any indications to why or what's going on. So turnstiles, especially locations that have required badge in, badge out systems for mustering purposes, security vestibules and mantraps, you could create some problems by preventing those readers from working properly. So if you disable the RFID readers and the turnstiles or mantraps from working, then you might be able to create artificially a situation where you more easily be able to social engineer your way into the building. Because if none of the employees can use their cards, and you know, business has to go on, they might revert to just visual confirmation or identification by the printed badge, or any other special areas, security operation centers, equipment rooms, etc. On the lighter side, yeah, you could, you know, just use the beeping function to annoy the heck out of some employees by beeping all the readers, or a attacker may choose to use a denial of service post entry to evade security. So after you successfully work your way through a door by whatever means, whether it's lockpicking, bypass or card cloning, you might choose to disable the reader temporarily, so that even if someone does try to come after and inspect what's going on or engage you, that they will have increased difficulty in actually getting to your location. And the final really interesting thing that we came up with, especially after Eric figured out how to reprogram an air tag, is ghost mode, where we can program a device like an air tag to scan for an only jam or rather, do the denial of service attack against the first one or two readers that have the strongest signal. And what this would do is it would create the unusual situation where if you place this air tag in someone's bag, any reader that they approach will suddenly stop working. And by the time they get to the reader and try to present their card, the reader won't actually read the card. And so they'll be like a ghost. They become invisible to card readers. So for some customers, this is a big deal for others who may not have these particular modules or Bluetooth-enabled readers installed yet. It may not be a big deal. However, we have been in contact with the vendor in working with some solutions. So the vendor in question, which in this case is HID, is aware of the problem. They're working on some firmware updates that will mitigate or minimize the risk related to this issue. It will be made available through their reader manager application. So you can remotely go around and update all these readers, although at the moment it does require that you use that app physically at each reader to do so. They're also working on some methods in the future that are not available yet to allow for upgrading of certain readers over OSDP as long as the right hardware fits. So that's not something that is finalized yet, but will be available for certain configurations. In the short term, there's a couple of options that we think may be possible depending on the use case for different customers. We do recommend that if you have to use mobile credentials, if you have to have these Bluetooth-enabled readers in the field, that you do provide some guidance and education to relevant security staff on how to respond to different situations if a bunch of readers stop working correctly, for example. Some customers may decide to ask to have Bluetooth functionality disabled. If you are one of these customers, we do recommend that you reach out to your HID account manager and ask for guidance. We may have updated guidance that we can provide at the live talk, but we don't have that yet, so we're staying nice and general at this time. And finally, some customers that are not using mobile credentials but still require OSDP may be able to, under certain circumstances, get OSDP-only backpacks that don't have that additional Bluetooth layer of functionality. But ultimately, this is something that is really just kind of a byproduct of a lot of things kind of going wrong and adding up to a very unexpected situation. So these are one of the reasons why a lot of us in the hacker and security community get a little bit nervous when people start just adding Bluetooth to all of the things. So we'd really like to send out some thanks and acknowledgements to people who kind of really supported us along the way. First of all, huge thank you to HID for listening and responding to the problem. We know that this is not a problem that is unique to one vendor, but these kinds of mistakes can be made by a number of vendors. In this case, it happened to be them and they are working through it. Thank you to Iceman and all the other core contributors and developers, you know, Philippe or Dogox and everyone else who is constantly contributing a code to make the Proxmark 3 even better and more stable. All of our friends at the RF Village and RFID Hacking Discord, RFID Research Group, and the iCopyX team for donating some prizes that we'll be giving out during our live talk and also Gordon Williams for providing us some guidance on some of the Node.js stuff when Eric was working through that code on some of the things that we had to tweak to improve performance. So we also want to, all of us briefly say thank you. Let me switch back to the quad view and say thanks for joining us, for listening. Thanks for kind of putting up with how fast we've been trying to go through everything to try to fit it into the time slot that was made available. And hopefully you guys really enjoyed it. If you have more questions, as we know you will, feel free to reach out to us, talk to us in person or on the RFID Hacking Discord. We hope that you take a little bit closer look at some of the other Bluetooth solutions that are out there in the access control world. And finally, if you're interested in really getting, you know, cutting your teeth, getting your feet wet, learning more. If you're a hobbyist, come check us out at the RFID Hacking Discord, link is right here in the slides. And if you're a working professional and you're interested in more hands-on training and certification for physical security, come check out Red Team Alliance and see what we have to offer. Thank you very much again. And that's it. That's all we got.