Breaking into secure facilities is easily one of the most entertaining things we do here as consultants at Bishop Fox. There’s just something so visceral about physical entry into a place you’re not supposed to be. Naturally, this is also something we help our clients protect against.

RFID badge readers are the industry’s default when it comes to performing authorization at door entries. There are many ways of attacking RFID badge systems (some of which were pioneered here at Bishop Fox!) but we’re going to focus on the backend for now. If you’re familiar at all with RFID badge security, you probably know about the ESPKey. This is a clever little gizmo that can be inserted on the wires behind the badge reader and reads all the card numbers as they go to the backend controller. The ESPKey exploits the fact that the legacy Wiegand protocol (still in widespread use) is unencrypted, and simply transmits RFID badge numbers such that anyone listening can intercept.

But the physical security industry has taken notice, which brings us to OSDP (Open Supervised Device Protocol). Among OSDP’s many features is security: it’s a cryptographic protocol that aims to solve these pesky ESPKeys with encryption. And as long as it’s encrypted, we’re all good right?

In this blog post, we’ll lay out the five exploitable vulnerabilities we’ve identified in OSDP and describe what you as a defender can do about them. There are other medium-to-low severity weaknesses, too. For the full details on those and instructions on how to build your own attack tool, we recommend checking out our GitHub page here.

Vulnerability #1: Encryption is Optional

So, it turns out that OSDP supports but doesn’t strictly require encryption. Thus, just because you bought a brand-new controller that “Supports OSDP”, doesn’t mean that it has any encryption whatsoever. In fact, we purchased an Axis A1001 badge controller on eBay specifically because it claimed OSDP support. What it fails to mention is that it doesn’t support ALL of OSDP, namely the security parts.

If you’re a defender and recently upgraded your old badge systems to OSDP, you might want to go and check that the hardware you purchased actually does encryption. It might not. While you’re at it, make sure that you only purchase hardware that is OSDP Verified. This is an extra certification step that SIA (the folks who make the protocol) provide to make sure the implementation is correct and not missing something obvious. You know, like encryption.

Vulnerability #2: Downgrade Attack

Just because an OSDP controller and reader support encryption doesn’t mean that they both enforce that it actually be used. One of the first things that happens when a reader comes online is that it transmits a list of capabilities to the controller. This tells the controller all sorts of things, such as whether it has a fingerprint reader, tactile buttons, and (importantly) whether it supports encryption. For chicken-and-egg reasons, this message cannot itself be encrypted. Thus, an intercepting device in the wire can modify this capability message to lie about the reader’s capabilities and claim that it does not support encryption.

Depending on your hardware, and how it is configured, the controller might just continue on anyway. Without encryption. Letting the attacker steal badge numbers yet again. This is what you’re seeing in the demonstration below:

If you’re a defender, go and check the configuration on your OSDP controller. Exactly what this setting is called will vary from device-to-device. It might not even be present at all. But try to make sure that the controller refuses any connections from readers that are not encrypted.

Vulnerability #3: Install-Mode Attack

OSDP has a quasi-official “install mode” that applies to both readers and controllers. As the name suggests, it’s supposed to be used when first setting up a reader. What it does is essentially allow readers to ask the controller for what the base encryption key (the SCBK) is. (Strictly speaking, there’s a bunch of back-and-forths in the protocol that aren’t important to understanding the core concept).

This by itself isn’t a crazy idea. It’s basically the SSH security model: A one-time insecure setup step, then secure communications thereafter. The problem is, many controllers are configured to remain in “install mode” persistently, perhaps forever. Some controllers make the administrator manually click out of “install mode” when they’re done. And if you forget to do that, your encryption is toast since an attacker can just request the encryption key!

If you’re a defender, you’ll want to check the configuration on your OSDP controller again. Make sure that “install mode” is not enabled except when actually installing a new reader.

Vulnerability #4: Weak Keys

This is not so much a vulnerability in OSDP the protocol as much as it is in common OSDP implementations. If you look around the Internet for OSDP sample code, you’ll find a lot with hardcoded keys. Clearly these are meant to be samples, where the user is meant to generate keys in a secure way on their own. This is not clearly explained or made simple, however. And anyone who’s been in security long enough knows that whatever’s the default is likely to be there in production.

So as an attack vector, when the link between reader and controller is encrypted, it’s worth a shot to enumerate some common weak keys. Now these are 128-bit AES keys, so we’re not going to be able to enumerate them all. Or even a meaningful portion of them. But what we can do is hit some common patterns that you see when someone hardcodes a key:

• All single-byte values. [0x04, 0x04, 0x04, 0x04 …]
• All monotonically increasing byte values. [0x01, 0x02, 0x03, 0x04, …]
• All monotonically decreasing byte values. [0x0A, 0x09, 0x08, 0x07, …]

In total that only makes 768 keys, so it’s very achievable as an attack. And covers many of the sorts of keys that someone would hand-type.

As a defender, make sure that your hardware is OSDP Verified, as none of this should occur in a fully compliant implementation.

Vulnerability #5: Keyset Capture

OSDP has no secure in-band mechanism for key exchange, and there are currently no out-of-band mechanisms for key exchange. What this means is that the only way for a reader to obtain the base key (which is used to derive session keys) is for the controller to just transmit it over data lines where attackers potentially are.

Similar to the install-mode attack, this wouldn’t be much of a problem if it only ever happened one time. The problem is that the attackers also have access to the reader hardware. So, what an attacker can do is:

• Break, factory reset, replace, or otherwise decommission an RFID reader. If you’re a red teamer, then you can try to do this non-destructively. But all that’s necessary for the attack is that the reader goes persistently offline such that it needs fixing.
• Insert a covert listening device behind the reader, along the RS485 wires.
• Wait for IT to come along and replace the broken reader.
• Capture the keyset message as it goes over the wire.

As a defender, this one is hard to protect against. There’s no simple configuration change that can help you. One piece of advice would be to never ignore tamper alarms from readers. In order to exploit this, an attacker will likely (but not necessarily) trigger the tamper alarm on the reader first. Treat all tampers as if you’re under attack. Similarly, if a reader suddenly goes offline and needs replacing, be on high alert. This is exactly what it would look like if you’re being attacked.

If you would like to be extra paranoid, what you could do is invent your own out-of-band key exchange mechanism: Never configure a reader on the production wiring. Any time a reader needs to be configured, walk it physically up to the controller and hook it up using a short 2-foot wire that you’re sure doesn’t contain a listening device. Use this wire to set the keys and then walk the reader over to its place at the door. It’ll be a huge pain, but it’s all you’ve got.

Conclusion

As a defender with an OSDP install, there’s going to be a lot on your plate. Walk through each of the configuration issues listed above carefully. Unfortunately, we can’t give step-by-step advice since each controller will vary wildly in how (or whether) these configuration options are presented. Keep your eyes peeled for forthcoming firmware updates that will (hopefully) address these issues in a more holistic way.

If you’re a Red Teamer, check out the code on our GitHub here for more details on the vulnerabilities and instructions on how to make an attack tool of your own.

Always remember not to trust something just because “it’s encrypted”. Security is hard, and encryption is not magic fairy dust.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.