DEF CON 29 - Babak Javadi, Nick Draffen, Eric Bettse, Anze Jensterle - The PACS man Comes For Us All
- All right. Hello, everyone. Welcome to the virtual stream of the DEF CON talk, "The PACS-man Comes For Us All: We May Still Be Vaccinated, but Access Control Still Sucks." We're gonna jump right into it today 'cause we have a lot to cover. For those of you who don't know, my name is Babak Javadi.
I am 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 Organisation of Lockpickers, the Red Team Alliance, and The CORE Group.
Nick, tell us a little bit about yourself. - Sure, yeah. I'm Nick Draffen. I like to hack things where the physical and digital world intersect. I'm involved in the RFID Hacking by Iceman Discord and you can find me there.
Eric, can you tell us a little bit about yourself? - I'm Eric Betts. (Babak laughs) - Hi, everyone. My name's Anze. 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 into the Google Vulnerability Research Program Hall of Fame. Mostly now I do RFID research. - All right, so today we're gonna talk about two things. We're gonna talk about a new tool that we're releasing that's gonna make red team a whole lot more fun and a whole lot more easier and we're also gonna talk about a interesting vulnerability that we found in some readers.
So, first, what are PACS? What is the PACS-man? Well, that refers broadly to physical access control systems. And we're not gonna 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, et cetera. 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 iCLASS or a MIFARE 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 gonna 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 obscure to 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 is an example where a 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, et cetera. 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 PACS 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 Ps, 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 of 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 and 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 Proxmark3.
This thing is ubiquitous. It's an open-source hardware project originally released by Jonathan Westheus 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 it 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 it 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 gonna be using in this first part of the talk the ESPKey.
This is a Wiegand interception device originally made by Kenny McElroy or octosavvi on GitHub and Twitter. And this is a Wiegand interception and replay device. And it's not the first of its kind. There have been a number of others before it, the BLEKey and, of course, the Gecko made by Zac 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 wanna talk to and we're gonna connect the data logger to it.
So we supply it some portable power in the form of a battery. We connect a data logger of some kind. That can be a Arduino or a Raspberry Pi or whatever you wanna use. In this case, we're using an ESPKey. 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, only the ESPKey, 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 cardholder information, now we have to then encode it onto a card, which we often do manually either from a computer terminal or maybe 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 Proxmark3 and we know the ESPKey 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 gonna 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 and Proxmark3s in the field, trying to come up with a unique way to glue them together and leveraging those functions that are already on the ESPKey with the Wi-Fi and the Proxmark3 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 Zero W. 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 Nine."
Odo is a Changeling in the 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 ESPKey, produces credentials and emits an MQTT message. The other side, like the Proxmark3, 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, Node.js, but it doesn't really matter. So, essentially, this framework can drive not just the implementation that we are gonna show here today of the weaponized reader and the ESPKey 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 (chuckles) 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 'cause the Proxmark 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 Proxmark3 powered by its battery.
Blue light is on 'cause 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 it in front of me, is the source credential.
Source and target credential technology doesn't really matter 'cause we're taking that Wiegand value and encoding that onto a target credential. So I have a weaponized reader here off-frame. I'm gonna scan this credential. We will see a new item appear on the screen and the haptic device (chuckles) 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 PiSugar 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 smart watch 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 PACS. You're muted. - (chuckles) Thank you. One of the things I really enjoy about the Odo framework is that this now allows us a way to do, like, 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 that 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 gonna talk about is what I'm calling the physical security chain of trust and it really kind of underscores how discrete 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 Wiegand wire and a Wiegand 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 wanna use a prox card so I can just go boop and, you know, get through the door," right? So we replaced just those links but they had 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 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 it'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 Wiegand.
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 years, this has begun to be taken care of with OSDP. It's something that we talk about more in some of our other talks and in our trainings, but it is the replacement for Wiegand.
It's the replacement for that weak link and it offers a lot of new functionality in the form of bidirectional 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 had this new tool here for this chain, the development elsewhere has not stopped.
Now the new hotness is mobile credentials. So mobile credentials are the new black in 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 in-line adapters that you connect to the Wiegand line that are basically Bluetooth-enabled ESPKeys that are not used for attacking but, rather, functionality. And then there's also stuff like this where, you know, 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, you know, 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, you know, 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 settings, what protocols it supports, et cetera.
It scans for nearby Bluetooth-enabled readers and 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.
It 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 gonna talk about that in a few slides. And it's kinda hard to see, so we're gonna 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 could 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 recognize the reader also have to have a special administrative key that is unique to that site. Now, what's interesting here is that some 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 Anze 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 Low Energy, we found out that all of the readers advertise a single service, all of them, of course, with the same UUID. 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 nRF52 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 looked like. We can see here that the message looks quite similar to an ISO 7816 ADPU, 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 Proxgrind and RFID Research Group. The LEDs on them are powered by the electromagnetic field emitted by the readers to make them blink. There are separate LED colors and separate antenna windings on the BCBs for low frequency and high frequency. So the red LED means that an LF or a 125 kilohertz field has been detected and the white LED means that a 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 readers at a time. But then we wanted to see if we can go even further.
We got ourself an nRF52 development kit, rewrote the whole thing in C, and were 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 nRF52832-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, had the fields shut off.
And in that state, they are unable to process media, meaning no cards will be able to be read by that reader. So you just had a physical denial-of-service event. - And now I would like to give my word to Eric.
- Yes, so as Babak mentioned before, these field detectors, they stopped 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 the sort of field detector part of it. And we got to thinking, what else has an nRF52? And for anybody that's been around at DEF CON the previous couple of days, they may have watched a talk about this. You know what else has an nRF52? A motherfucking AirTag. So we put our firmware on an AirTag. So here's me putting in the battery.
Gonna go ahead and slide that closed. Flip over to this and y'all can see it has also knocked out the readers. Except for that one. Nope, no, got that one too. And so now I'll hand it back to Anze.
- 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 that BLE is also powered by an NRF-based chip for Bluetooth Low Energy and we asked ourself if we can also reprogram that and we found out that it is possible to reprogram it the same way as an AirTag. So with that, we were able to take down eight readers in the vicinity of the backpack being powered. And then, of course, because nRF52 is such a widespread chipset, we then asked ourself what else we can use as an emitter for the attack and we came to, we found out that there's a COVID test that has an nRF52 in it, there's some development devices, personal pleasure devices, and the universe of nRF52 is pretty much endless.
And now I would like to give it to Babak for some closing words. - So what does this all mean, right? 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 dependent on what the attacker wants to do. So we can do either a very high 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, in 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 indication as to why or what's going on. So turnstiles, especially locations that have a required, you know, 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, you know, if you disabled the RFID readers and the turnstiles or mantraps from working, then you might be able to create artificially a situation where you'd 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 via the printed badge. Or any other special areas, security operation centers, equipment rooms, et cetera. 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 the denial of service post-entry to evade security.
So after you successfully work your way through a door by whatever means, whether it's lock picking, 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 AirTag, is ghost mode where we can program a device like an AirTag to scan for and only jam or, rather, you know, 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 AirTag 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 are 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 update 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, you know, 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, a 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, you know, 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 doegox, and everyone else who is constantly contributing code to make the Proxmark3 even better and more stable.
All of our friends at the RF Village and RFID Hacking Discord. RFID Research Group and the iCopy-X 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 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.