At a recent deep-dive session during the Black Hat conference, we had the chance to discuss complexities and novel vulnerabilities within modern Physical Access Control Systems (PACS), shining a light on the OSDP protocol — which defines a new era of security for PACS communication.
During our session, we’ve demonstrated two attacks targeting PACS: First, gaining unauthorized access to secured facilities, and second - infiltrating the internal IP network directly from the front door and highlighting an interesting paradox in modern PACS security.
Physical access control reader
PACS are everywhere these days, securing entry to anything from offices to industrial sites, critical infrastructure and airports. These systems are the gatekeepers, managing entry and exit using various forms of identification like cards, codes, tags, or biometrics.
Intrigued by the importance of PACS and whether they inadvertently introduce risk within our customers' networks, we’ve decided to investigate further, focusing on the architecture of PACS and the protocols that support their functionality.
Imagine an employee is standing before a secure area they require access to. The process of opening the gate is a cascade of events involving several components and communication channels:
Also, for management of the process, controllers typically have an Ethernet interface, allowing for direct configuration or integration with a centralized security server.
The security landscape for reader-controller communication has long been dominated by the Wiegand protocol. Despite its widespread adoption since the '70s, it is well-known for its lack of security, allowing threat actors to eavesdrop plaintext identifications and replay them to open gates - without any authorization.
Since then, the Security Industry Association (SIA) has developed OSDP (Open Supervised Device Protocol), a successor for the Wiegand protocol. OSDP is an advanced protocol, using the RS-485 physical layer and promising enhanced capabilities. One of the significant improvements provided by this protocol - is the option to configure secure communication. And, when security is optional, subpar configurations could leave systems exposed - as demonstrated by Bishop Fox's research.
But, given proper configuration - this protocol is expected to resolve the security issues of Wiegand and enable new advancements.
Focusing on properly secured and correctly deployed OSDP systems, we set up a Man-in-the-middle (MitM) in our lab and started to intercept and manipulate OSDP communications. Working both with physical and virtual controllers.
Research MitM setup options: physical or virtual controller
During our research, we’ve uncovered risks both in the protocol specifications and in implementations of different communication stacks.
Attacking the OSDP channel requires first to have physical access to the serial communication cables on the back of the access controller. Having tamper protection to protect against such activities is standard in most readers and is expected to harden these devices against these kinds of attacks. Yet, with a little ingenuity and a small homemade tool, we discovered it’s possible to circumvent this safeguard, accessing the communication wires without tripping any alarms.
Demo video: Bypassing tamper protection - green led indicates tamper protection is not triggered
OSDP brings a secure channel option with pre-shared secrets, encryption and proper message integrity. Diving into the specs we’ve managed to uncover 2 attacks at the protocol level against this .
The Initialization Vector (IV) plays a critical role in the encryption and integrity assurance of messages: it guarantees that identical messages will be encrypted in unique ways, provided that the IV changes consistently. In the context of OSDP, the IV for each message derives from data contained in preceding messages, and if for some reason the IV will return to a previous state - it may allow the attacker to perform replay attacks.
Surprisingly, we were able to execute this type of attack by leveraging one of the messages transmitted during the secure channel initialization process: the RMAC_I reply. Replaying a manipulated version of this message allowed us to successfully revert the current IV of the secure channel and carry out a replay attack against LibOSDP. While this might not be an expected behavior according to the protocol specifications, it is raising a few concerns related to the specifications in this area and might impact additional implementations.
In pursuit of vulnerabilities with broader implications, we revisited the protocol documentation and discovered a novel attack vector utilizing the “PD Busy” response. This message informs the controller (CP) that the reader (PD) is currently "busy" processing previous commands. This message possesses unique characteristics: it can be sent unencrypted, even during an active secure channel session, and there is no limit for how long these messages can be sent.
An adversary can exploit this to create a controlled delay in the processing of legitimate access requests, effectively controlling the timing of door operations. This tactic effectively bypasses the receive timeout mechanisms and jeopardizes message integrity. An attacker could strategically delay a valid access attempt to subsequently use it to their advantage. This vulnerability has profound implications, as it has the potential to impact all OSDP-compliant systems that strictly adhere to the specified standards.
The OSDP protocol's advanced capabilities, including encryption, remote configuration, and remote firmware updates, add a layer of complexity to its implementation. This complexity results in a substantial increase in the codebase when compared to the simpler Wiegand implementations, escalating the likelihood of bugs and vulnerabilities.
Through vulnerability assessment of LibOSDP open-source library and AXIS access controller firmware, we confirmed that increased complexity indeed presents additional risks, and raises a paradoxical issue: as we deter conventional PACS attacks, we create new attack surfaces.
Targeting our physical AXIS controller, we’ve managed to extract its firmware and gain debugging capabilities on the device. Focusing on logics that can be exploited without prior knowledge on secure OSDP communication, we uncovered a vulnerability within the message reception logic, leading to heap overflow, allowing remote code execution.
Recognizing the need for deep analysis, we developed a custom fuzzing framework to evaluate diverse OSDP devices and uncover additional vulnerabilities, also supporting fuzzing of serial connections and physical devices. We’ve managed to trigger the previous vulnerability, and to uncover 2 new vulnerabilities on the AXIS controller after fuzzing its OSDP implementation over an RS-485 serial channel.
Our journey bypassing access control and reaching from the front door to the heart of an IP network foreshadows new concerns regarding PACS security. To stay ahead of these threats and reduce, we suggest a few steps to be taken:
OTORIO’s open-source OSDP assessment and fuzzing tool
The convergence of cyber-physical devices reminds us that even doors may be more than just points of entry - and serve as harbors to the next significant cyber breach - even without stepping inside. As we embrace OSDP for its potential, remember that with complexity comes additional risk, and in an ever-connected world, security is only as strong as the weakest component.
Our OSDP assessment tool will soon be released as an open-source for the community, and is intended to assist with further research and assessment of the OSDP protocol. The tool encompasses man-in-the-middle (MitM) capabilities tailored for OSDP and include support for serial communication and fuzzing of physical devices.