 Mianna and Mixen. Let's give them a good Defconn welcome. Okay, thank you. Yes, so my name's Mixen and I'm gonna, or we're gonna present digital skeleton keys. Yep, my name's Mianna. Essentially the talk is about a vulnerability that we found in a RFID access control system called SMARTAR. It's specifically what's known as an update on card system. So the readers are different from normal ones, but I'll let Mixen explain more about that. Yeah, so in short terms, a traditional access control system is a online system where the credential just stores an identifier. And then once you go up to any reader within the installation, it's gonna do a lookup on your credential number towards the databases that are often distributed on the controllers, but essentially then on a database. Whereas in a offline access control system or also referred to as an update on card, you would then provision a credential ahead of time with an often a list of what doors you're supposed to have access to. In, this should be done in a secure way so you can't manipulate it, but as we will see, that's not always the case. Yeah, and there is also some nuances to this because you can get a mixture of offline online readers within the same installation where an online reader will then revalidate your credentials as you're going through so you can have like an online reader on the main entrance door and then the rest of the building is offline. The reason that you would use a update on card system is mainly associated with cost of getting the infrastructure there. So you get places that are remote or hotel rooms or stuff like that where you would have those kind of systems. We've used something called the Proxima Tree to do most of our research on this. In general, the credentials that are being deployed on these systems normally are the micro classic credentials which has so many vulnerabilities these days that the Proxima client has a command called auto porn to just read off the credential and then be able to get the keys necessary to do changes to it. So how, it all started with me dumping one credential but then I saw a pattern in it and wanted to investigate it further. Turns out that if you Google few years good you can find the software online and if you go on eBay you'll find readers that are decommissioned and before I knew it I had a working installation at home. So the first thing I did was I dumped a credential with access to one door and saw what I got and a micro classic credential has multiple sectors to make it simpler. I've taken out one sector state the hair just to illustrate this. So we can see that, well, we're using four bytes and then I made another credential with access to another two doors and we're adding eight bytes. Well, four bytes per door looks kind of repeating and kind of matches the situation I had with my four doors. What would happen if I just continue the pattern of adding another four bytes at the end of it? Well, turns out that's all you need to do a privilege escalation attack in this system. So at this point I was like, okay, this is cool and I was talking with Miana and a few others in a group and in a group of people that does a lot of RFID and it's gonna get much worse as Miana is gonna talk about now. So basically the part that really interested me was now we've worked out some of the data structure involved in the card and can take a credential, an escalator, is there a way to get that information from the reader without ever needing a card? Well, we'll see. Going back to things that are vulnerable about the MiFair classic credentials that they were using and with the Proxmark three tooling, we could use an existing attack to extract the encryption keys for the card from the reader based on simulating a set of specifically crafted cards and the Proxmark does that all by itself thanks to many other people's research. The interesting thing about that encryption key is it happened to have the installation ID which is one of the fields inside the card's data as the last four bytes of that key. So there's one piece of information that we need and you'll see that highlighted on here in green and the keys at the bottom. But that's not all we needed. It turns out from looking through the software that the cards can be configured with different sectors assigned for different purposes and you then have to go and flash all of your readers to have them read the credentials like that. So the next step was to try and work out the card structure that a reader was expecting without ever having seen that card. So made a little script that worked on for a while and the first attempt was running that MyFairKey extraction and working out where the user data sector was as well as the key which gives us the installation ID. And then I would create a card that the Proxmark would simulate that had the fake generated user data sector in the location that the reader was expecting and then it would fill the rest of it with a generated update on card sector. The reason why I've filled the rest of the card with that even though it only needs one is so that it could read that and using the Proxmark we could see exactly what sector it was trying to read and then the next sector it tried to read would be where the reader was expecting the doors to be. So from that card simulation we get the next two important pieces of information and the third step is just brute forcing the doors. It turns out that the doors are sequentially IDed. So the very first door in the installation ID one. Number two ID two. So depending on the size of the card and exactly how far back they had configured the door sector we would just have to fill it with as many access control sectors as we could and keep on generating new credentials until one of them opened. What happens when the reader finds the record for its door is it actually updates the data structure in there saying it's been updated and it stores the user ID in its internal storage so it doesn't need to search through so many pages of data and that's how we can detect what door ID it is because that's the one that it writes to. Now an interesting thing we discovered from this is I sent this proof of concept script to Mixon to try with the readers that he had and those were configured with a different a different card structure from the one that I had wrote the exploit on and yet my script was still working but the Proxmark was saying it was reading the sectors in a different order. Turns out that despite the instruction saying you need to reflash all the readers that's not the case. The full config is on the card as long as you get the first block right which is almost always in sector two anyway but now that we could identify where this update on card block was specified in memory which is that purple spot we could completely get rid of that middle step. This also had the advantage of allowing us to define a much more compact data structure on the card that doesn't use any of the sectors that we didn't care about increasing the number of doors that we could fit on each one of the brute force attempts. In fact, because everything about the card is configured via this system we went from being able to fit on the demo system I was developing this on around 120 doors per card to like 850 which doesn't take long to get through most facilities entire access control system with that. So after this script runs the door will open but also you can then write the generated data to credentials of your own that will open any door in the system and this is what one of them looks like. So this is the sector for the user data. We put the extracted installation ID in come up with a random you ID or less random in this case, fool. Disable any pin code because don't wanna have to type that in and specify where we want the update on card block. Next sector. This is what that looks like. We've got some further research to do to work out what all of the other values in this sector mean but all we really needed was this door block in orange and the number of doors. So we put that the next sector and 840 doors and then every sector following that looks like this where we have the door number and the schedule of when it can be accessed which zero F means all the time and then the zero one means that the door hasn't read it yet and it hasn't updated it so that user ID fool is always allowed in through this door and yeah, that's what the cards look like. The problem that we have with this now is that anyone who can run this script which requires a $30 tool can open any installations within this system and I'll mix and talk about some of the blast radius of that. Yeah, so I started doing disclosure on this around one and a half years ago with the manufacturer of this. It's the manufacturer is TESA which has been bought by ASA Abloy and these days it's then being rebranded and resold under different brands in different areas so in the US it's sold under the Multilock brand and we've seen some fairly secure buildings or buildings that should have been secure that are using this system in an offline capacity and there is for instance a airport in Norway that uses this to in areas between white and red zone which is unclean and clean zones at an airport which is a big issue. They have from what I've disclosed this to them as well they have done things to be able to mitigate for this. There's also, so while we don't know exactly how many of these systems there are and they do advertise that they are using this in at least these places with their case studies so and it's a wide variety of everything from corporate to healthcare to industrial applications where this is being used. So one of the places it was being used is at a power distribution or a company that has a lot of remote sites with power distribution and that's a problem because you're not gonna get any updates from the stores if they are opened. Another thing that Mjolnit didn't mention is that they do not keep a log if you're opening the door with the user idea that doesn't exist. The log is being kept in the lock but as soon as it's being written into the database if you pull the log off the door and then go back to your server to then be able to read off what has happened nothing shows up. So as long as there is no user idea which is valid associated with it they just ignore that entry and that seems to be a big oversight from what we've seen. Another thing that they're doing is so to be able to patch this you now have to contact Tessa and ask for a licensing upgrade because apparently security needs a license. So I haven't spoken to them after I did my initial disclosure. So I don't know the details of how that works but I know that it's quite a sure to be able to get your installation back to a secure state. One of the other bigger issues with these systems is literally by design they are for remote locations or locations where it's not feasible to network all of the readers which means to update them you have to go and flash the firmware manually by plugging a device in to every single one of these readers not once but twice because you need to do it then you need to reissue every single credential in the system and you need to go back out to all these remote stations and reflash the firmware. So yeah, this could be in the wild for an unknown period of time and we're hoping that it gets patched quickly but yeah, I'm not sure if that's the case if you have to reach out for license upgrades and do all that work. So yeah. Do you have anything else to add on that? No, I think I'm getting on that. Well, just in general, we wanted to thank the RFID hacking community. We got a lot of encouragement and advice and bouncing ideas off of people as well as all of the contributions made towards tools like the Proxmark and the previous work done on the My Fair Classic hacking. Without any of that, this exploit would have never been discovered let alone get this far. Also want to thank all the Goons and the whole DefCon community because I've wanted to talk here since I was like 12 and yeah, this community inspires people to look into this sort of stuff, so thanks. So these are our contact details if anyone wants to get in touch and it looks like we've got two and a half minutes if anyone has any questions. Yes, we're gonna release the code shortly after DefCon so follow us on Twitter and we'll make that available. I wanted to have it available but I'm a bit of a perfectionist and I ran out of time. I will get it up, I promise. Any others? So the card itself, we don't need to attack the card itself, we can go directly to the reader and get the keys of that and that's not affected by the hardened RNG that you would have on the card. Yeah, this attack needs absolutely no knowledge of the system walking up to it as long as it's a smart air system that uses these credentials. You walk up with the Proxmark running this code and the door opens. There are also some further things we've been researching with that. It turns out you can configure a fair bit more about the locks but we didn't have enough time to fully dig into that. They're pretty certain you can lock out all existing users and stuff like that as well. So yeah, some fun things. Time for one more question. That's really hard. Sure. Okay, maybe it wasn't that. Cool, well thank you then.