 Okay. So, I'm talking about picking electronic locks using TCP sequence prediction. Thank you. Okay. So, I've probably met a few of you by this point, but I've been drinking a lot this weekend, so I don't remember. So, this is who I am. I've got a couple of security certs. I'm a network technician at Texas State University in beautiful San Marcus, Texas, and I've been working on their electronic building access systems, and in my spare time I've been breaking the electronic access systems. So, basically what I'm talking about is whenever people start talking about the security of these systems, it's usually involving the readers like the RFID cards or vulnerabilities in biometrics and things like that, but nobody really concentrates on the network side of things, and a lot of these door controllers are moving to IP-based systems for obvious reasons in large organizations, but they're networked devices that have little or no network security. They've got persistent TCP sessions with no encryption and predictable sequence numbering. So, what I wondered is is it possible to send a spoofed command across the network and open the door without needing a card or a retinal scan or anything, and since you're seeing this presentation here you can guess what the answer is. So, a brief overview of electronic building access. You've got your authentication device, which is your reader, and then you've got your locking device, and both of those are connected to a door controller, which is then connected to the network. And client programs can send remote commands to these, specifically locking and unlocking commands, and they also monitor the state of the door and alarm points and all that stuff. So, this is the part where I start using goofy diagrams to illustrate my points. So, you've got your client that's connected to a database, that's connected to a door controller, that's connected to some doors. So, the client says, I want to open a door. So, the open command goes through the database, the database sends it to the appropriate door controller, and the door controller opens the door. Now, what happens in this scenario? And you can tell he's the bad guy because he's red, like a communist. Okay, so, same thing again. The client says, open the door, and now the attacker has a copy of that command. And, you know, then he forwards it on to the door controller and the door controller opens the door, just like normal. Everybody's happy. Okay, so now the attacker has a copy of the command, and some time goes by, and he says, okay, I want to open the door. And, pop goes the weasel. The door controller interprets it just like any other command, and you'll notice that nothing happened on the database at all, so there's no log of the command, no alarms are tripped because the door controller saw it as a valid open. Everybody's happy. So, the reason it works is because these devices have really, really predictable sequence numbering that allows you to inject a packet into their session. Sequence number prediction was usually used in hijacking TCP sessions, but we don't really need to do that. We're just sticking our own packet in an existing session. It's been fixed in most modern operating systems, but embedded systems are still notoriously bad. Another goofy diagram. So, here's an example conversation between a sender and a receiver with sequence numbering. Can anybody see a pattern in the sequence numbering? I'd like to say this is a really simple example, but it's not. So, the attacker guesses the next sequence number in order, sends a packet, the receiver says, yeah, that's the next one. The sender then tries to send its packet with that sequence number, and the sender is like, well, I already got that packet. I'll send the next one. So, now we get to talk about some code. So, I used the Scapi library for the packet manipulation. This is really, really simple code. Basically, you just take two variables, one of which is the target IP of the door controller, and the other is the payload that you want to inject. I suppose I should probably mention that I tested this on a, it's an HID door controller that's running a seaboard squadron firmware. I've actually talked to seaboard about this, and they say they've got an update coming. So, we'll see. So, this is a very simple code, but, yeah. So, first things first, it takes the hex stream that you send to it and formats it properly so that it'll interpret it. And then you start sniffing some traffic so that you can get your IP addresses that you need and your window sizes and all that stuff. The important command, and I can't really highlight on here, but I'm going to point, down near the bottom, you'll see a function SR1 that's sending receiving, and basically at the end of that line, it says sequence plus 40. That's it. That's the secret. You add 40 to the sequence number, and then you attach your payload to the end, and yeah, it opens the door. I don't get it. So, my conclusion is it's not necessary to break the authentication medium in order to bypass these systems. You know, these are network devices, and they need to protect themselves against network vulnerabilities. And it's not hard to fix. First off, what you can do to protect yourself is obviously put your door controllers on a separate LAN that your users can't get to and monitor that LAN for man in the middle attacks. But really, what it comes down to is the vendors making their sequence numbers harder to guess, and for the love of God, encrypt the traffic. A C-board at least says that they are encrypting, but I'm thinking they might be confusing encrypting and encoding. Because the open commands, they always start off with the exact same hex values. And I don't care what the rest of the command says. I just know that that's the command that I need. So, I just, you know, grab that hex stream and inject it, whatever it says, and it does what it does. So, yeah, encrypt the traffic at the session level so that I can't see the sequence numbers and I'll fix it. All right. I don't know if that was 20 minutes, but thank you. If it's an incorrect sequence number, it just ignores it. Yeah, you can keep trying as much as you want. If it's a correct sequence number, then it ends up burning the session and redoing the handshake and all that stuff. But yeah, if it's an incorrect sequence number, you can just guess as much as you want. Sorry. It doesn't on the seaboard system, or at least it does, but every once in a while the sessions get torn down anyway, so it's not seen as an important event. It probably could. I mean, again, the normal events aren't really paid attention to. Like, anything that's normal activity isn't really flagged. So, hopefully not often. I mean, we set it up like that originally until I started messing around with this stuff, and now we've taken them off of the networks. But I mean, it's really easy to put these door controllers in a comm room and just plug them into the network. So, it probably happens quite a lot. Maybe? I haven't really messed around with the point of sale side of things. So, I'm not really sure. I mean, this is really, really just scratching the surface of the vulnerabilities in these systems. So, all right. Thank you.