Next-gen OSDP was supposed to make it harder to break in to secure facilities. It failed.

OSDP Secure Channel has yet to gain widespread usage, and it’s already broken.

Researchers have discovered a suite of vulnerabilities that largely break a next-generation protocol that was designed to prevent the hacking of access control systems used at secure facilities on US military bases and buildings belonging to federal, state, and local governments and private organizations.

The next-generation mechanism, known as Secure Channel, was added about 10 years ago to an open standard known as OSDP, short for the Open Supervised Device Protocol. Like an earlier protocol, known as Wiegand, OSDP provides a framework for connecting card readers, fingerprint scanners, and other types of peripheral devices to control panels that check the collected credentials against a database of valid personnel. When credentials match, the control panel sends a message that opens a door, gate, or other entry system.

Broken before getting out of the gate

OSDP came about in the aftermath of an attack demonstrated in 2008 at the Black Hat security conference. In a talk there, researcher Zac Franken demonstrated a device dubbed Gecko, which was no bigger than a US quarter. When surreptitiously inserted by a would-be intruder into the wiring behind a peripheral device, Gecko performed an adversary-in-the-middle attack that monitors all communications sent to and from the control panel.

Because Wiegand sent all data in plaintext, Gecko would record the credentials sent from the reader to the control panel. An attacker could then use them to create a spoof card that an intruder could present at the security checkpoint and gain entry. More recently, researchers devised the ESPKey, a $79 device that weaponizes Franken’s attack and can be used by both security professionals and threat actors.

The industry response was to introduce something called Secure Channel and add it to OSDP, a pre-existing alternative to Wiegand that had yet to be widely adopted. Secure Channel allowed OSDP-based communications between peripheral devices and control panels to be encrypted with 128-bit AES, a tried and tested algorithm that is virtually impossible to break when used correctly.

Research being presented on Wednesday at the Black Hat Security Conference in Las Vegas shows that OSDP Secure Channel does little to rectify the failures of Wiegand. The talk, titled “Badge of Shame: Breaking into Secure Facilities with OSDP,” is the first technical analysis of the open standard. It presents five exploitable vulnerabilities and a host of other weaknesses that strongly call into question the security of OSDP. While all but four of the vulnerabilities can be effectively eliminated, mitigations require configuration settings that aren’t described in the official OSDP specification (available here for $200) and differ depending on the manufacturer of each device.

The takeaway: OSDP is effectively broken even before it has gained anything near widespread adoption.

“The attacks here sort of put us back into parity with basically being unencrypted,” Dan Petro and David Vargas, the two researchers who performed the research and will speak at Black Hat, said in an interview. The attacks are “giving us as attackers and as red teamers back the capability that we lost.”

OSDP works over RS-485, a serial communication protocol designed to provide relatively high bandwidth (up to 10 megabits per second), the ability to span reasonably long distances (up to 4,000 feet), tolerance for lots of radio frequency noise, and capacity for 32 devices on a single line. Use of RS-485 causes peripherals to connect in daisy-chain fashion to a single input port on the control panel. This design, known as multi-drop, means that messages sent to or from one reader run through a single line and are seen by all other readers on the same network bus. This design is sometimes known as a broadcasting network.

Meet Mellon: Son of ESPKey

Petro and Vargas, a senior security engineer and senior security consultant, respectively, at security firm Bishop Fox, have devised their own device with the same size and function as the ESPKey and Gecko. Like the two earlier attack devices, this new one gets placed behind a reader or other peripheral device and is spliced into the wiring that connects the devices to the control panel. While such physical access is a tall hurdle, it’s a threat that secure facilities take seriously when designing their access control systems. It’s also precisely the threat OSDP is designed to protect against. The researchers have named their covert attack device Mellon, the Elvish word for “friend,” which the character Gandalf in The Lord of the Rings uses to enter the Doors of Durin.

In general, the attacks exploit the failure of Secure Channel to strictly enforce encryption in the communications passing through the access control system cables. By default, Secure Channel isn’t turned on. Many admins aren’t aware that they must configure their equipment to use Secure Channel. And even when Secure Channel is on, some critical communications still occur in plaintext. Secure Channel also allows encryption to occur through the use of weak keys that are trivial to crack.

The most damaging of the attacks to be demonstrated on Wednesday exploits a mechanism that OSDP uses to transfer an encryption key from the control panel to a card reader when the latter first joins the network. When coming online, the reader sends the control panel a message requesting what the OSDP specification calls an SCBK, short for Secure Channel Base Key. The SCBK is unique to each reader-controller pair and is used to encrypt the connection between them.

Fatal flaw

The researchers found a fatal flaw in this key exchange. Since OSDP provides no means to transfer the SCBK out of band—meaning through a channel other than the daisy chain connecting the peripheral devices to the control panel—the standard has no choice but to send it through the RS-485 line. That presents a vexing chicken-and-egg problem: Without possession of the SCBK, the control panel has no means to securely encrypt the key before sending said key to the new reader.

Unfortunately, the fix OSDP developers devised does nothing to solve that problem. When transmitting an SCBK to a new device, the standard encrypts it with a default key, known as an SCBK-D. Since the SCBK-D is known to all devices—including the researchers’ covert listening device—it’s trivial for the attackers to obtain a valid SCBK. From there, the attackers can view all messages transmitted on the network, including secret credentials stored on badges presented at security checkpoints.

“As a defender, this one is hard to protect against,” the researchers wrote in a post accompanying their talk. “There’s no simple configuration change that can help you.”

Several of the other attacks exploit the failure of OSDP to strictly enforce the use of encryption. Devices often advertise themselves as being OSDP-compliant or as supporting OSDP and yet provide no means of delivering the Secure Channel encryption described in the OSDP specification. An example is the A1001 door controller manufactured by Axis, which the researchers tested in their research.

“We bought it because it said that it supports OSDP,” the Bishop Fox researchers said. After taking it out of the box and setting it up, they soon discovered it provided no means to encrypt communications passing between readers and the control panel. “I suspect that other people might run into the exact same problem. They’re going to buy a controller that supports OSDP. They’ll think: ‘Wow, great, I’m running on OSDP. Now I’m safe and secure’ when in reality nothing is encrypted.”

In other cases, even when readers and control panels run with Secure Channel turned on, they may not use the encryption it provides. One way the researchers’ listening device can turn off encryption when Secure Channel is running is to abuse a feature that runs when a reader comes online. Just after bootup, a reader transmits a message to the controller that provides a list of capabilities, including fingerprint scanning and the ability to provide tactile feedback.

Once again, for chicken-and-egg reasons, this message can’t be encrypted. The researchers’ listening device can exploit this lack of encryption by intercepting the message and changing it to say the reader doesn’t support encryption. Depending on the device, it may not be possible at all to stop it from transmitting the unencrypted communications. In other cases, enforcing encryption may be possible only by making configuration changes that aren’t well documented.

Downgrading encryption like this “is a perfectly valid thing to do in OSDP,” the researchers said. “It’s really kind of up to the configuration of the controller whether that’s going to be allowed.”

Another attack exploits an OSDP installation mode that control panels and readers use when they’re first set up. Just as the SCBK is effectively transmitted in plaintext when a reader first comes online, the key is similarly sent in the clear when install mode is on.

“Problem is, many controllers are configured to remain in ‘install mode’ persistently, perhaps forever,” the researchers wrote in their post. “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!”

OSDP also provides no means for generating the master encryption key that underpins the security of all other keys it uses. In this absence, it’s up to users to generate them on their own. The researchers said some admins simply choose easy-to-guess keys such as those hardcoded into sample code, such as this, available online.

The WTFs abound

The researchers also found a series of design decisions that weaken the encryption available. While the weaknesses aren’t currently exploitable, the researchers have dubbed them “WTFs” because it’s hard to understand why OSDP architects chose designs that are both unnecessary and undermine the entire point of the protocol.

The WTFs include:

• A cryptographic nonce used to ensure that session keys are random uses just 6 bytes of entropy. Similarly, message authentication codes, or MACs, used to verify that a message hasn’t been altered, are truncated to 32-bit to, as the OSDP spec puts it, “reduce overhead.”
• Secure Channel encryption has two modes that don’t actually encrypt data passing through the RS-485 cabling. Instead, these modes, known as Modes 15 and 16, apply only a MAC. As a consequence, anyone can read the data encrypted in these modes. “It’s such a bizarre choice to have that mode which is basically doing a null cipher for most of the actual packets that are going back and forth,” the researchers said.
• Even when Secure Channel is set to encrypt data, a single byte of that data reserved for message commands is never encrypted. This allows a passive listener to learn all kinds of things, including when someone swiped a badge, whether that badge was valid, when the LEDs light up, and when the buzzer beeps.

Security is hard—it’s even harder with OSDP

Given the lack of security in the official OSDP specification, it’s up to each implementation to make up for the shortfall. An open source implementation, known as LibOSDP, has introduced a flag called Enforce Secure. It prevents several of the insecure practices, including peripheral devices and control panels operating when Secure Channel is disabled. It also disallows the use of the SCBK-D key.

“When you see a ‘… due to ENFORCE_SECURE’ failure log message, the CP/PD is doing something that LibOSDP deemed to be a protected action that needs to be performed under supervision,” the LibOSDP documentation states. CP and PD refer to control panel and peripheral device, respectively.

The researchers said that the use of the Enforce Secure flag prevents three of their attacks—specifically, those that exploit devices that (1) don’t support Secure Channel, (2) allow Secure Channel to be turned off, or (3) remain in install mode. But the library provides no means for preventing the most serious attack: recovery of the SCBK while a new reader is coming online.

There are a few nuances involved in the research that will be of interest to security practitioners. First, the researchers’ attack device can recover only the unencrypted contents of communications passing through the access control system itself. That makes it most useful for intercepting credentials or other data from passive cards, such as the Prox, Indala, and iClass cards available from the manufacturer HID. These types of passive cards are widely used in secure facilities.

Mellon can’t defeat any encryption that may be layered on top. Secrets stored on smartcards that use x509 encryption, for example, can’t be decrypted because the attack device has no means to defeat the encryption the smartcards provide. It’s currently unknown what kind of data might be exposed by readers that have keypads, scan fingerprints, or use other biometrics. The researchers said they have yet to study how these types of peripherals communicate with control panels.

An intruder can use Mellon to cause a reader somewhere on the RS-485 line to factory-reset, break, or report that it has just come online and then wait for an IT employee to reinstall it. The process necessarily requires the control panel to exchange the SCBK using the known SCBK-D key. During this brief window, Mellon will obtain the encrypted payload and decrypt it. With possession of a valid SCBK, Mellon is then free to monitor all communications in their decrypted form.

“We actually went on site to a client that had a system like that and we verified that this is an attack that works on production systems,” the researchers said. “It’s not just us reading the protocol.”

They said that fixes won’t be available in the foreseeable future because they require breaking key parts of OSDP. Even when a fix is available, installing it into millions of embedded devices already running in secure facilities across the world will be a non-trivial undertaking.

“The vast majority of installations out there in the wild are still Wiegand, and this [OSDP] is the future technology that’s just starting to roll out into production,” the researchers said. “We have seen OSDP installs on our clients’ infrastructure, but they’re a pretty small minority.”

The researchers provide a variety of measures to shore up security until a more secure out-of-the-box alternative becomes available. Chief among them: If a reader experiences any technical problems or shows signs of tampering, consider the event serious enough to warrant immediate attention since they may indicate the system is under attack. Also important: never configure a reader on the production wiring. Instead, physically walk it up to the controller and connect it using a short wire that you’re sure doesn’t contain a listening device. Use this wire to set the keys and then walk the reader back to its place in the facility. Advice also includes reading user manuals carefully and ensuring that there is video footage being taken at all times.

A pessimistic view is that OSDP, as it exists now, is hopelessly broken before it has even rolled out. But the researchers proposed an alternate take: “This is a forward-looking future technology that people are trying to migrate to. One optimistic thing to say is that it’s not too late, right?” The irony of such optimism, and it’s not lost on the researchers, is that until a fixed version of OSDP becomes available and is finally rolled out in large numbers, the world is stuck with either Wiegand or the current version of OSDP, both of which are broken.

Listing image: Getty Images

125 Comments