 guys enjoy it. Mmm breakfast. All right. Morning Defcon. Thanks for all coming. Thanks for having us. Uh this is Badge of Shame. Uh hey I'm uh Dan Pietro. I'm a senior security engineer at Bishop Fox. Uh before that was a long time pen tester here at Bishop Fox. Yeah hi everyone. I'm the uh new speaker here. My name's David Vargas. I'm a senior consultant with uh Red Team at Bishop Fox. Cool. And we're going to be talking about breaking into secure facilities. So uh this actually all came about as a part of a pen test um here at Bishop Fox. Breaking into secure facilities is easily one of the coolest things that we get to do. And uh if you're already familiar with uh like breaking into facilities there's like an ESP key. We'll kind of get into this a little bit more um as a tool and we tried using this on a pen test one time and it just like wasn't working and we were super like curious as to why. And it turned out that we had an OSDP installation. Uh we hadn't actually seen one in the wild at that point. And so like I've got a background in cryptographic protocols to figure why not take a look at this thing. And uh this presentation is the result of that. Cool. So uh let's get into it. So um one of the other things you should know about me is that I hate slides. Um but uh you can't just get away with not having slides. So we made some authentic bespoke one off slides. These slides are like organic. They are allowed to turn fully around in PowerPoint before being exported. So suppose you're trying to break into a secure facility right? Let's say some undisclosed location in Santa Fe, New Mexico. And you like really want to get into this room right? It's like very important to you personally. And this room like a lot of other rooms has an RFID badge reader that is protecting the entrance to it. Even if you're not familiar with physical security I'm sure you've seen these things right? You take a badge out, you just beep it to the little thing and it lets you into the room. Cool. So uh there's lots of ways of attacking these RFID badge reader systems. Um some of which we've actually pioneered here at Bishop Fox. Um this is the TASIC RFID thief. Uh this is a thing that uh my boss Fran made a while ago. It's basically a long range RFID reader. So it can like read badges from about like five, six feet away. Um we developed this cool little maneuver where you like uh put it into a briefcase and then walk up to somebody at Starbucks with like the wearing their badge. And you like set it down and then kind of like pull it up and then up onto your shoulder. Like the briefcase. And really what you're doing is you're scanning the person from like toe to head. Um like surrepetitiously. Um this was even featured on an episode of Mr. Robot. Actually two I think. Um and uh yeah that's cool. Um so uh the hacking tool my boss Fran made but the prop in the show I made. We knew the technical advisor for the show at the time. And so uh they just needed a little gizmo that says like no badges detected. Like when you press little buttons. It's just a raspberry pi inside of a plastic case. But that's kind of cool. So that's what we're talking about today. We're going to be going over uh let's talk a little bit about how RFID badge reader systems work in general because it's going to be pretty important. So on the outside you can see three things. Uh you can see a door, a lock, and a reader. So the uh reader you present with a badge. So the badge is uh at least for passive cards is just basically a number. It's got a number. Sometimes they're very short too. They're not like big 128 bit numbers or whatever right. You present the badge to the reader and you're basically just telling it this number. It says here's my badge number one two three four. Now importantly the reader does not perform authentication or authorization in this system. It's not the thing that lets you into the door. In order to do that it has to talk to a back end controller. The controller is the thing that actually like knows who you are and decides whether you're allowed into this door or not. So the reader then forwards that badge number off to the controller. The controller then says yeah sure this person's allowed into this door and sends it a little like signal that says flash your green light that says that they're allowed in. Now importantly again the reader can't let you in. So it has to have a separate set of wires that is not the same set of wires that like physically unlocks the door because the reader can't control it. Cause obviously if the reader controlled whether you could get in you could just like hack the reader and let you in. It would be super easy. That is not how these things work. Cool. Alright so let's take a look at how everything actually works in the back end. So currently it uses something called weekend right? Everything's unencrypted. The card numbers or whatever data just happens to go across the wire. What that means is we can actually make a small device right now it's you know like an ESP key which you put into the reader. Now what happens is whenever somebody swipes a badge the ESP key can grab the plain text communication and then we can clone the card. Right? And now we can also replay it right? We can make our own cards. We can do all sorts of things to gain access to that facility. So that's a problem and so now comes OSDP. So what's OSDP? OSDP stands for the open supervised device protocol and it's meant to replace weekend. OSDP is built as an encrypted protocol, a secure protocol. It has a couple of other benefits over weekend like it's over RS485 which supports multiple readers on the same bus but we'll get to that a little later. Mainly the big thing was that it's supposed to be encrypted so the same attack we just talked about won't work theoretically. So we started reading about it right? We started looking into alright this sounds interesting what's up with it and we came across some very interesting claims mainly that it was unhackable as of 2020. And so you know that picked our interest so I was like let's take a look at this. So we did a couple of things. To start off we made our own version of an ESP key, a device we dubbed Mellon and so this device just like an ESP key plugs in between the reader and the controller. We also got our hands. David was allowed to call it Mellon as long as he said it like Gandalf at least one time. So Mellon. Alright and so we got the device and so we got a bunch of readers and we got an access A1000 on controller. Now everything that we have supports OSDP so the controller which Dan has over here supports OSDP. We got our eBay. We got some HID signal 20 readers. So what we expected to see was basically encrypted traffic going across the wire. Let's see what we actually saw. I think the name of the video kind of gives it away but yeah. Not encrypted. So what's going on? It's supposed to be encrypted. Everything supports OSDP. Let's see what happened. Well when we kept looking into it it turns out OSDP supports but doesn't actually require encryption. OSDP SC, a secure channel extension added to OSDP is what takes care of the encryption. So what does that mean? It actually means that OSDP devices that support OSDP both can choose to encrypt or not to encrypt traffic and this is going to come playing a role into this a little later on. Cool. So let's back up a minute and talk about protocol and RS485 that is underneath OSDP since this is going to be kind of important. So RS485 is the underlying like physical layer underneath OSDP. It's serial but it's not that serial. It's the other serial. In particular RS485 is multi-drop. So that means that you've got a controller and a reader and you want to hook up additional readers to this controller. You don't have to like have a separate line out to them. You can hook them all up in like succession like this. You can all sort of daisy chain the readers. And importantly in this scenario all messages are broadcast. So like this is a necessity because of just like not like the laws of OSDP but just the laws of physics like they're all connected with the same copper wires. And so necessarily if you're going to send a message to like any of the devices it's going to send them to all of them. So if reader A wants to send a message out to the controller it has to necessarily also send them out to readers B and C. So this is not necessarily vulnerability. It's just like kind of a nice to have. In fact this is really useful for installers since you don't need to have a separate wire out to every single reader in your entire building. You can kind of daisy chain them around. It reduces the wiring makes actually a lot nicer. This does have the consequence though that if suppose we're back in our undisclosed location in Santa Fe, New Mexico and there's like you know some guard out in front of a top secret door like this is the door we really want to get into right. And there's some guy with a beard and suspenders let's just call him George that's in front of this room that like is preventing us from getting in yelling something about Targaryens. There might be a second side door that is like not especially secret that like we wouldn't normally care about getting into. But now you might actually attack this door anyway because it could very well be on the same bus as the secret door. And so if you could listen and sniff badges on this one you might be sniffing badges to like the rest of the building or you know maybe just the door that you really care about. So that's kind of a nice little bonus there for attackers. So if our red teamers are trying to do this just find any door that it might be the one that you care about. Next is around the client server model of OSTP. This is just kind of a practical thing for the protocol which is that in OSTP there's clients and servers the controller is the client all the readers are servers so that means is that readers if you wanted to send a message you can't just asynchronously send a message. It would just get ignored at least according to the spec it should. And in order to send a message you have to reply to responses. So what this means is that controllers have to constantly pull the readers in practices like happens like something on the order of like a hundred curts is pretty typical where you see the controller say hey you got anything for me now. No. You got anything for me now. No. And that's how you like when you badge in it knows amounted immediately because it's like pulling constantly. So this brings us to protocol WTF number one. Something I like to call what are we paying by the bit now. So one of the core functions of a cryptographic protocol is to prevent against replay attacks. So even though it's encrypted what keeps an attacker from just taking the encrypted packet that has like our badge numbers when somebody badges in right and just replaying that packet just taking it and forwarding it off to the controller when we want to authenticate. So normally protocols will do this by having your data attaching a sequence number to it. So the sequence number makes sure that every packet is fresh. It's live. So it has to either just be monotonically increasing from the last one or it's like the number of data like TCP does this by having like the amount of data increasing the sequence number. There's lots of ways of doing this but basically the idea is that the receiver knows what the sequence number should be. It's going to be different every time. It keeps you from replaying things along with an H back that keeps the attacker from tampering with that data. Because obviously if the attacker could just like modify the sequence number to be the correct one then that kind of defeats the whole purpose. So we don't have time to get into like what an H mac is. It's a key hash. If you're not familiar with the way to look it up it's cool. So you might be wondering, all right this sequence number. How many bits does that need to be? Like maybe like 128 bits? Like that would be cryptographically strong right? You can't enumerate that. That would be really good. Maybe 64 bits? Like that's not bad. It's like the edge of enumeration. Like if you're trying to brute force something off the line 64 bits is usually the area where you're like I don't know if that's possible anymore. Like 32 bits? Like that's fine maybe I guess. That's not great. How about two bits? Now I know what you're thinking. Now what you're thinking. Two bits? Those are rookie numbers. We can get that down. How about one and a half bits? Because OSDP actually skips zero in their two bit sequence number scheme. So you start with zero but then everything going off there just goes one two three one two three. So this sequence number exists but for the purposes of security might as well not. In fact I question whether it's useful even for non-security purposes. So let's talk about this H mac. So OSDP has this system of IV chaining where the H mac of the previous packet is the IV of the current packet. By the way we're running in a CBC mode encryption. I can hear the collective groans of all the cryptographers in the room. We don't have time to go over it. It's the CBC mode don't question it. So the IV is just sort of chained down the line where every single H mac is just going to be the IV of the next packet. So this sort of has the effect of providing liveness because like the last packet is going to kind of mutate your current one and so that sort of prevents replay attacks in this kind of like a janky sort of setup. But like in practice it sort of kind of works. We're going to have to come back to that. The problem with the H mac however is that we just take most of it and throw it in the trash. So the first 32 bits of the H mac we keep. And then the last 96 bits we just throw away. The spec even says to reduce the message size and transmission time overhead. Only the first four bytes are sent. Like why would you do this? Like you can't just take like the bits and like reduce the overhead. You know like those are important bits. Like we needed those bits. You can't just do this. So if we do some back of the envelope math on like what this might look like. So imagine you're just sending a badge in attempts with like random Macs right. Like how long would this take us to enumerate in practice. So that's two to the thirty one attempts on average. Let's assume that we're running at like one one five two hundred bod. Which is around the top end of what you can see. I think in practice I'm technically RS forty five can run at ten megabits. In which case if you find some insulation that's running that fast then like fuck. But the this would be a success after like thirty five days. Which like is dangerous and sort of scary if you're a defender but I think as a red team we're unlikely to really exploit this. Like I imagine like sending David on a pen test or like okay. So we're gonna give you a sleeping bag. And you're gonna just like hang out in front of the door for thirty five days. On average. And at some point during that time you might be asleep. The door is gonna beep. And you gotta make a mad dash to it. Because it's gonna be open for like three seconds. We have a we have budgets and I don't think that's gonna be within ours. So I think in practice this is likely not a thing that you're gonna see a ton of. Unless the speed changes. Like if you're running this over a different underlying protocol for some reason that runs at like ten megabits or like if some reason you're RS forty five installation really is that fast. Then this could start getting really scary. Now there's a birthday attack in this. Some of you might have already noticed. So if you just ask the question. Like what are the chances that any of these IVs are the same. Right. On average with only a thirty two bit Mac. You're gonna get it at about seventy seven thousand packets on average. And what that means is that if the data is always the same. Like if we're in this like polling act loop. The data is always gonna be the same. So our data is just gonna loop back around. So like you can actually observe this happening in practice too. Which is just like bizarre and not a good look for a cryptographic protocol. This isn't a vulnerability as far as I can tell. Because anytime somebody does anything like if you badge in it'll perturb the loop and escape you out of the loop and get you into a new loop. But just like this is not a thing that a reasonable protocol should be doing. Where you're just like actually sending the same exact bits looping back around and reusing IVs is like a thing that has gotten other protocols into a lot of hot water. So like we should just not be doing this. Oh and then lastly around this is the key exchange. A key derivation for session keys. So we'll get a bit more into like a key hierarchy that OSDB defines. But the session keys. The thing that's like actually used to encrypt data. Only uses 48 bits of entropy from the back end server. So session keys are derived by having the controller send the reader a nonce. The controller then derives a session key by taking 48 bits of that nonce for reasons unknown. And then encrypting that with the base key, the higher level key. And that becomes the session key basically. And maybe somebody in the audience is clever than us and can figure out a way to actually brute force this offline because if it were 48 bits you could. But because it's encrypted by the base key which the attacker in this scenario presumably does not know. I don't, I couldn't figure out a good way to enumerate this offline. So. Cool. Alright so let's actually attack this thing. Alright we have some background. We know that OSDB supports both encrypted and unencrypted connections. So we can do something called a replay attack. Or sorry downgrade attack. Alright so let me pause it here. Explain what's going on. So on the right hand side we have our controller. So we can see that what it's seeing and we can see on the left hand side the communication going between the controller and the reader. So there's a secure channel setup. We can't see anything right. Everything's secure. We're going to swipe in. And there's absolutely nothing that we can see. Okay but let's remember that again it supports both right. So there's sure a way we can mess around with this. So we do it again. This time we try to carry out a downgrade attack. We try to downgrade. And then we swipe in again. And we can actually see the card data. Cool. Alright so let's see what we actually did there to make that happen. To decide if it can establish encryption or not. There's a couple things that happen first. So the controller first asks the reader what its capabilities are. And the reader replies its capabilities. The capabilities can be a number of very interesting things to us. So it can say maybe we're talking to a fingerprint reader or an iris scanner it supports biometrics. Maybe we're talking to a keypad as a keypad entry. So the capabilities are keypad. The one we're interested in here is communication security. So the communication security bit actually tells the controller whether or not the reader supports encryption. So let's insert our device in the middle here and let's wait for that capabilities request. And now when we actually reply we're going to switch that communication security bit from a 1 to a 0. And so the controller assumes that there's no encryption set up. It doesn't support encryption and we can carry on with everything unencrypted. Alright that brings us to protocol WTF number two. Stop making null ciphers. So Dan explained a little bit about how what happens when a secure channel set up. There's basically a four-step process in which the controller and the reader mutually authenticate to each other to make sure that they each have the same encryption key. Now as a result of this when everything works out there's four message types that can be sent. SES 15 and 17 which are command from the controller to the reader or reply 16 and 18 which are you know replies from from the reader to the controller. If you read the spec SES 15 and 16 say that even though there's a Mac applied the data is still unencrypted. Which is wild right? We're supposed to be having a secure channel set up with encryption but yet the data fields are unencrypted. So that means that in a fully secured session there is a possibility that the data is just going to go over the wire. Now it has a Mac applied to it so we can't just replay it but you know we can still just in the case of car data watch it clone it and just authenticate to the readers. Now to be fair the spec does say that those message types are not meant to be used with any sort of data but then why have them in the first place right? Alright this moves us to demo number three something we have to call the install mode attack. Hominess sounding. It's going to already play. Okay so what you're going to see here on the right is the controller that's going to be running in a terminal. This is an intentionally vulnerable controller software that we wrote. That's basically just the lib OSDP sample code basically actually. And on the left is an attack script that we're writing. We're going to be performing something we call the install mode attack. So we're going to run this with just an dash dash install flag, run up our server and this time we don't just capture a badge number we actually steal the encryption key right out from underneath the server. So how the heck does that work? Let's talk about it. So OSDP has something a bit like the SSH security model which is like a one time insecure setup. This is not by itself in a vacuum a bad thing. We don't care about SSH's security model so much. The problem is that this has to actually be a one time insecure setup. Like if somebody told you they found a way of hacking SSH and you just have to do is man in the middle of the initial connection and be like yeah like that's kind of built into the model of like that's not clever or anything. The problem is when this turns out to not be so one time. So controllers and readers in OSDP have this kind of quasi official install mode that is specified in the spec but it's exact semantics aren't exactly laid out like when you're supposed to do things and how are you supposed to behave. A lot of that is just sort of left up to the individual implementers. And so in this install mode as the name suggests this is not the exact packets but the reader is able to ask it like hey what's the encryption key because I'm just trying to get set up here and the reader just the controller goes here you go here's the key because like that's what the install mode is supposed to do. The problem happens when this install mode persists. If it happens to last more than just this like short ephemeral moment when you're initially installing a reader. So if you happen to have a controller that is just like hanging out in install mode persistently then an attacker can just show up on the bus ask the controller hey what's the encryption key I'm a reader and it'll just respond to you and say here's the key. And the keys in this case are unique per reader controller pair but that ID is just a public ID in fact it's usually written on the back of the reader itself so like you could just lie about your ID and get the key for any reader on the building. So this brings us to this point like where exactly do these vulnerabilities lie. So we've been kind of picking on the protocol and I think there's a fair number of things to pick about the protocol. But like there's lots of other places depending on how you want to kind of squint and look at it that the vulnerabilities could exist on. So you could think of this as a library book some of these like whatever the library does is probably what's going to be out there in practice right like who is going to grow out and roll their own library just for this. So like you could argue that like the behavior of the popular libraries is the thing that needs to change here that's where the fault really lies. You could argue that this is a configuration problem a lot of these vulnerabilities can be fixed in configurations like you should configure your controllers to not sit around persistently in install mode and maybe that's not crazy. You could argue that it's a documentation problem that like like the exact behaviors of how these things are supposed to work is like maybe not documented well or maybe it is but nobody knows where that's at and so like maybe better documentation could get out of this problem. You could argue that this is an implementation bug that the individual like implementers of the controller hardware are responsible for setting these things up properly and what admin is going to go out and tinker with the settings of the fine grain level like whatever is out there in implementation is probably what's going to be out there in practice. You could also argue that this is a marketing problem that a lot of devices such as our access a one thousand one just say that they support OSDP but that's not like a legally defensible like term whereas there's actually a OSDP verified like a program where you can put your hardware into the people that make the specification and they can like certify it as not like secure in some abstract sense but at least that it like does the protocol and does all of the protocol like the encryption parts where like you might just have an entire OSDP setup at home probably not at home at your office and think like I'm all secure like I bought all this stuff I spent a whole bunch of money upgrading it and you could very well go back to your office and discover that none of it's encrypted. It's all just plain text and that's not great and that's also partly a marketing problem. So it's pretty easy to see how these vulnerabilities could just pass by people because no matter who you are in this setup there's always somebody else you could possibly blame and think like well it's not really my problem it's whoever is going to configure the stupid thing. Okay let's stop it up a bit. Let's look at what happens in when everything is set up properly right and how the secure channel is supposed to work so this is protocol what the fuck number three. Oops. Okay so this is what we expected of message 17 and 18. We expected to see the header in plain text and then the command bytes and the data encrypted but this is what we actually see. So the only thing that's encrypted in a fully secure channel setup is the data. Now why does it matter? Why is the command byte important? Well the command byte is what tells us what the message type is. It tells us what the command was, what the reply is so we know what kind of data is in that packet. Some of the interesting ones we want to look at are the OSDP raw. This one contains raw car data so we see that going over the wire. We might want to look at that packet a little more. There's the FMT packet which has formatted car data. Keypad, self-explanatory. The bioreader, I keep going back to the bioreader ones because they're just very interesting to me. I haven't had a chance to poke at them but hoping that's the next step here. Okay and then there's the OSDP key set message. So the key set message is the command from the controller to the reader where the session base key is delivered and basically the encryption key for every message is derived from the session base key so we can get our hands on that base key and compromise the communications. Which brings us to the next demo. The weak keys attack. Cool. So once again we have the controller and our tax script here and we're testing for weak keys and we just found a weak key. So if we find the weak key we can decrypt the packets and we can reset that key set message. Cool. So what happened? First off before I dive in this is not a protocol specific issue. This is something of an implementation issue that we've observed with a lot of open source libraries. So again it doesn't have to do with OSDP but the people writing I guess a code for it. Okay. So there's a hierarchy of keys here. There's the master key which is the session base key which is the one we just spoke about. And then there's the encryption key for all the actual messages which is derived from the base key. Now in the newer implementations of OSDP the spec actually takes out the master key and it recommends eliminating it and instead somehow generating and delivering the session base key. Now it doesn't say how to do that. So we've seen things for the SCBK. And again, this isn't just one library we've seen a number of these. So what does that mean from our attacking perspective? Now we're not going to say we're going to brute force the whole 128-bit space that'd be silly, but what we can do is try say about a thousand-week keys, right? We can try repeating characters, we can try increasing and decreasing characters and so on. If we managed to actually find a reader that's using these hard coded keys for the encryption key and compromise that session. All right. This brings us to protocol WTF number four encryption is not magic fairy dust which was also the very nearly the title of this entire topic. Another possible alternate title was just because you did it on purpose doesn't mean it's not a vulnerability. So let's go back to this, some bold marketing claims about things being unhackable while we can all get a good laugh out of this. One thing that it said was true, which is that it does in fact use 128-bit AES encryption. That is in fact true, so good on them. The problem, however, is that we only use AES as in there's no asymmetric cryptography at all in the spec whatsoever. So naturally cryptographers amongst you are wondering, so how do we do key exchange exactly then, right? So there's no cryptography and then like how do the reader and the controller exchange keys? Ah, dear listener, this is maybe easier than you think. You just send the key. No, okay, okay, okay. We can't just send the key unencrypted, right? That would be insecure. So we encrypt the key. But cryptographers amongst you are scratching their heads right now. With what do we encrypt the key if we are trying to send the key? Ah, that's a good question. We use the SCBKD which is the secure channel base key default. Meaning that's it. That's the key. It's just the ASCII number 0 to F in hex. Like this is not how encryption works. Like you can't just like sprinkle some like crypto on something and say like we encrypted it boss. Like there's no point in this whatsoever. It's just like a really fancy encoding mechanism that only serves to give you a false sense of security and thinking like I don't know what it says it's encrypted right now and I can't read it so I guess it's good, right? Like this is not the airbud rules of cryptography. We're like you can't just like very nothing rules that says a default key can't be an encryption key. Cool. Okay, so this brings us to our final demo and actually my favorite one because just what it actually means. Cool. So again, we're attacking the controller and we managed to capture the key. So how do we capture the key? Up to this point a lot of what we've discussed can be attributed to misconfigurations, right? Not so much like other than the WTFs. A lot of it is the reader being left in install mode or supporting both secure channel and unencrypted traffic. So what happens if best practice are followed? Well first of all I think a lot of us know that best practices usually aren't followed. But let me walk you through a scenario how we would attack a completely secure setup. Number one, we insert our listening device. Number two, we need to break a reader. Number three, we need to wait for IT to replace that reader. And number four, we capture the key set command. So this is how it actually works. So let's say we show up on a site where we want to break in, right? We have the top secret door we want to gain access to and we have maybe a side door that's not so well guarded. We have no possibility of a downgrade attack. Everything is encrypted with a session base key. Well, we start going to go and insert our listening device behind the not so very secret door. Again, let's remember that OSDP on RS485 supports multiple readers. So that's kind of a that's what's going to make the attack practical for us. I'm going to go ahead and insert it on that same bus somewhere where that's not well guarded. Now we need to break the reader we're interested in. How we do that, it's up to you. So you can either use an NFC up on your phone, go up to the reader and mess around with its settings which is actually something you can do with a lot of readers we tested or you can literally go up and rip the reader up the wall. Doesn't matter how you do it you just need to break it. Now what's going to happen? Well, they're going to need to replace that reader or they're going to need to repair it. And so they need to deliver the key to that reader to set up to secure channel encryption. Well, if we're on the bus listening to everything, we know that that key set message is going to be delivered with the default base key which means we're going to be in a position where we can capture it when the reader is being set up. Which means after everything is set up we now have the session base key and we can decrypt all the traffic going to the top secret door. Cool. Alright, so what do we do? How do I defend? Let's look at what we can do from the blue team side. First, check your configuration. So we need to make sure that encryption is actually enforced. We need to make sure that there is no possibility that we can downgrade that. So the readers that support encryption usually have an option that just does not allow it to be for communications to carry on unencrypted. And disable the install mode. Now, something that Dan Felt mentioned is when we were doing the testing for this we actually tested this on a production site where the install mode was and left on. So it's not a theoretical misconfiguration, we've actually seen that in production. So whenever it's set up make sure to disable the install mode. So this is a recommendation that I'm going to give to you that you are definitely not going to do. But I'm going to say it anyway. Never configure a reader in production. Meaning this is basically a way of inventing your own out-of-band key exchange mechanism. So rather than ever using the production wires as in the reader on the wall using the wires that are in your building. Since the entire point of putting encryption on this thing is assuming that those wires are compromised, that there could be somebody listening that doing an insecure key exchange over that mechanism is just hazardous. So what you could do is if you need to install a reader to take the reader off the wall walk it over to the controller with your feet. Plug it into the controller with like a two-foot wire that you're reasonably sure has no listening device on it. Do the configuration there. Do the key exchange there. Take the reader, walk it back to the door with your feet and then put it back onto the wall. You have to do this every single time a reader or needs to be reconfigured or replaced. For a significantly large building this is going to be utterly untenable, but none the less this is a thing you could do. That way anytime the key exchange happens it's never done over the production wires where somebody is actually listening. So if you're like extremely paranoid and this is a thing you want to do then go ahead. It sort of defeats the purpose of like having this whole system but that's a thing that you could do. Never ignore tamper alarms. Modern readers have a little button on the back of them that is like a tamper alarm. And in practice when you are a red teamer and you're going to be performing this attack you're likely to trip that tamper alarm. It's literally just like a button that when you have the reader against the wall it's pressed in and then when you like unscrew it with a Phillips head screwdriver to access the wires behind it it unpresses that button and then sends a little signal out to the controller that says I've been tampered with. And what happens on the controller is kind of up to you as a blue team. Maybe that just goes and gets into a log somewhere that somebody will notice in several months. Don't let that happen. There's often other mitigating physical controls around these sorts of doors especially in physical security systems for high secure facilities. So maybe take a tamper alarm and start recording with the camera when that happens or something if there's a camera there. Whatever you do don't ignore these things if you're being attacked for real you're likely to get one of these things. It is probably possible to like the tamper to get access to the wires behind a reader without triggering a tamper alarm but that's like a whole separate thing that we didn't bother getting into because it's sort of its own rabbit hole. Maybe there's a clever little device you could use to like insert behind it and press the button in and then pull it out. I don't know. That's not me. Buy OSDB verified devices. So if you're a blue teamer or if you're setting up badge control systems for your work, look for this little like check box thing. Don't just buy some random box off the internet that says it supports OSDP because it might just like not even support encryption. Like we literally bought a device on eBay for like $300 because we wanted to test OSDP encryption and it turned out to not support encryption. So I made that mistake and I bet you could too. And then lastly, don't trust things just because it's encrypted. Cryptographic protocols are really hard and security is hard. And just because it has encryption on it doesn't make it like secure magically. And then that is all. Thanks a lot. I think that we have time for some questions. There is a microphone right in the middle here. If you'd like to ask a question you can go up to the microphone there alternatively. You can just shout really loud and I could probably hear you if you do that. If not then we'll just be kind of milling about here and then... How am I splicing 485s here? Oh yeah, you can basically just punch into it. So it's a differential. I'll repeat the question. How are we interfacing with the RS45 from a physical perspective? And you can just tap into it basically so it's a differential signal. And because it's multi-drop it's like meant to be used in that kind of configuration basically. So yeah, you can just kind of like tap into it. And also for our device I'm tapping into the power line as well just to get power from it. So you get the data lines it's a differential signal so you get like power in power data and then negative data. And then you'll also have power lines. In theory you could use a battery but we figured it was just going to be easier to tap into the power lines as well. So yeah. Yes, Oliver the tools are GitHub. It's github.com. You'll find all the code there. We have the hardware schematics for the hardware itself as well as some code. Oh yeah, we actually have a bunch of PCBs to give away. We have 100 like Melon PCBs if you want to nag one. It doesn't have the rest of the components on them so you have to do some soldering. But yeah, we've got some PCBs if you want to get one. You have to bug this guy. People are going for the shouting option more than I thought they were going to. You have to shout. Yes, so the spec is open. In fact it's so open that anyone can purchase it for $200 online. That is the only official way of getting access to it. Yeah. Yeah. The question for those listening is like in one of the attacks the downgrade attack we're going to modify the capabilities packet. Like how are we doing that if we're just passively tapping? We have two versions of the code. There's one that's Python that's meant to run on a laptop with big RS-45 adapters where you're in the middle. And then for the initial version of our hardware device that's miniaturized down into a one inch by one inch thing we decided to just make it a passive tap so we're not doing the man in the middle attacks. And that would be one of them. So yeah, that one, the install mode attack is not part of the hardware one at this point. Maybe we'll make a separate one that has a proper man in the middle and then get it in the middle and then like, I don't know, that seems like a lot for red teaming. So we just avoided it. Yeah.