Advanced attackers—and pen-testers—targeting access controls guarding secure facilities will often zero in on badge readers and controllers enabling physical access to anything from a military base, to a research facility, or manufacturing facility.
In the past, tools such as ESPKey have been surreptitiously installed on readers to steal badge numbers as they crossed the wires between the reader and the controller that actually unlocks the door. ESPKey was a successful route for attackers and pen-testers because the unencrypted Weigand communication protocol running under the hood transmitted card data in plaintext.
The Open Supervised Device Protocol (OSDP), specifically its Secure Channel add-on, was meant to bring encryption to this information exchange between readers and controllers. Unfortunately, this hasn’t been a complete success, as demonstrated during Black Hat by Bishop Fox researchers Dan Petro and David Vargas. Their presentation [blog], called “Badge of Shame: Breaking into Secure Facilities with OSDP” demonstrated five vulnerabilities and security weaknesses that break the security promise of the protocol.
In this episode of the Nexus podcast, recorded in Las Vegas during Black Hat, Petro and Vargas explain numerous attacks that leverage weaknesses in the protocol itself that may not be easily rectified, in addition to implementation and configuration errors, and vulnerabilities, that may be effectively mitigated with some work by vendors of readers and controllers.
“There are things that manufacturers can do to coerce people to not use the insecure setup in order to stop our attack,” Vargas said. “A lot of the problems are within the protocol itself.”
One of the primary weaknesses of OSDP, for example, is that while Secure Channel is available, it is not turned on by default. More dire is a serious key exchange issue whereby the Secure Channel Base Key generated by the controller, that is used to encrypt communication, is sent through a daisy chain of wires between readers at a facility, including an attacker’s listening device if one is in place. This gives the attacker the key used to decrypt traffic, essentially rendering the encryption useless.
The key exchange, short of writing your own key exchange and using NFC or out of band [neither of which is accounted for in the protocol], there is nothing [to be done],” Vargas said. “That is a protocol-specific problem.”
Petro and Vargas covered numerous attacks in their talk, including the possibility of replay attacks, downgrade attacks, and an array of others related to the key exchange or weak keys in use. Their research was conducted on an Axis A1001 reader/controller that supports OSDP, but a closer look revealed that plaintext data was crossing the wire.
“It says it supports OSDP, got a reader, hooked it up and lo and behold, there was the data unencrypted. That is not what I was thinking was going to happen,” Petro said, adding that the Axis A1001 doesn’t even have an option to turn on encryption. “That was stunning too. That led us down a rabbit hole of ‘What else is happening on this?’”
The way forward is a protocol overhaul; OSDP, despite being available to manufacturers for more than 10 years, still hasn’t achieved mainstream status within the reader space. Unfortunately, it’s best security option in OSDP isn’t as locked down as hoped for.
“Often the vulnerabilities aren’t a deep, in-the-weeds cryptographic attack,” Petro said. “Often they are a simple reading of the protocol and pointing at it and saying ‘That’s not the way it should be.’”
Michael Mimoso is Director of Influencer Marketing at Claroty and Editorial Director of Nexus.
