Hands-Free Lockpicking: Opening Doors Like in The Movies

Hands-Free Lockpicking: Opening Doors Like in The Movies

Speakers: Werner Schober (Principal Security Consultant, Certainity); Clemens Stockenreitner (SEC Consult)

Conference: Area41

YouTube: https://www.youtube.com/watch?v=870a3vycNhw

Overview

In a revealing presentation at Area41, Werner Schober and Clemens Stockenreitner unveiled critical vulnerabilities within Dormakaba's Axos 9300 physical access control system (PACS), demonstrating how doors could be opened "hands-free" using simple network packets rather than traditional lockpicking tools. The talk, titled "Hands-Free Lockpicking: Opening Doors Like in The Movies," highlighted a collection of over 20 vulnerabilities, including authentication bypasses, hardcoded credentials, and path traversal flaws, which collectively undermine the fundamental security assurances of a widely deployed access control solution.

The research, conducted at SEC Consult, challenges the perception that physical security systems are impervious to digital attacks. Schober and Stockenreitner's findings expose how conventional IT security weaknesses — such as unauthenticated APIs and unpatched legacy software — can manifest with severe consequences in the physical world, leading to unauthorized access, compromised audit trails, and the disclosure of sensitive information like PINs.

This presentation is highly significant for anyone involved in physical security, IT infrastructure, and pen testing. It underscores the urgent need for robust network segmentation, diligent patching, and secure coding practices in operational technology (OT) environments. The ability to remotely open doors without physical presence or specialized tools represents a worst-case scenario for physical access control, demanding immediate attention from both vendors and system administrators to mitigate these profound risks.

Background

▶ Watch: Introduction to hands-free lock picking and research goal (0:00)

The motivation behind this research stemmed from SEC Consult's annual initiative to pursue unique and impactful security research topics. The speakers noted that hardware-based systems, particularly those that are costly and difficult to obtain for research, often remain under-researched, presenting a fertile ground for novel discoveries. Their opportunity arose serendipitously when SEC Consult moved offices, gaining access to an owned, disused Dormakaba Axos 9300 system, complete with necessary licenses and service components. This provided a rare, hands-on environment for in-depth analysis.

The Dormakaba Axos 9300 system comprises several interconnected components:

• Axos 9300 Central Management Application: Typically running on a Windows server, this C#-based application serves as the central cockpit for managing all aspects of the PACS, including RFID badge assignment, access zone creation, and user management.
• RFID Badge Reader (Registration Unit 9001): These units support various RFID protocols like Legic prime, advanced, Mifare classic, and Desfire. They connect to an access manager via a coax cable.
• Pin Pad: Similar to the badge reader but incorporating a secondary authentication factor (PIN pad), also connecting via coax cable to an access manager.
• Access Manager (9200 K5 and K7): These are the critical intermediaries, connecting readers and pin pads to the central management server and controlling door relays. The K5 version, now end-of-life, was based on Windows CE embedded, an outdated operating system. The newer K7 version runs on Linux.

The researchers set a clear, impactful goal: to open doors without authorization. This target represented the "absolute worst case" for a physical access control system, making it a compelling focus for their efforts. The scope explicitly excluded physical harm or forced entry, concentrating purely on logical and network-based bypasses.

A crucial element in understanding the system's vulnerabilities was its custom addressing scheme. This scheme is used to uniquely identify various devices within the Dormakaba ecosystem. It consists of two main types of addresses:

• Access Manager Addresses: Prefixed with 'I', followed by a communication hub address (01-99), a largely unused port address (always 0 in their observations), and finally an access hub address that uniquely identifies the manager. An example given was I01000101.
• Data Point Addresses: These refer to specific inputs or outputs, such as an electronic lock or relay. They follow the access manager address, specifying a device type (e.g., TR for door manager) and the data point address itself (e.g., _Door_1_1).

Understanding this addressing scheme proved fundamental to crafting the proof-of-concept exploits, as these identifiers were often the only pieces of information required to trigger critical actions.

Key Findings

▶ Watch: Critical unauthenticated SOAP API to open doors (8:00)

The research uncovered a comprehensive array of vulnerabilities, culminating in three distinct methods to open doors remotely, along with numerous other critical security flaws. These findings highlight a pervasive lack of security-by-design principles within the Dormakaba Axos 9300 system.

The primary methods for "hands-free lockpicking" included:

1. Unauthenticated SOAP API on Port 8002: The SOAP API, running on port 8002 on all observed access managers, was found to be entirely unencrypted (HTTP) and lacked any form of authentication. By observing network traffic during a standard "release once" operation (opening a door via the management application), the researchers identified a simple request containing only the access manager identifier, the data point ID (referring to the electronic relay), and a command (e.g., command one for "open door"). Since these identifiers were found to be guessable or easily enumerable, anyone with network access to an access manager could send this unauthenticated request to open any door connected to it.

1. Hardcoded Credentials in the Graphics Application Protocol on Port 1005: The Axos server's graphics application, which visualizes real-time door status, communicates via a custom protocol on port 1005. Reverse engineering the C# DLLs of this application revealed hardcoded credentials labeled "legacy users." These credentials, intended for status visualization, could also be used to log in and send door-opening commands. The process involved logging into port 1005 with the hardcoded credentials, then sending a command specifying the access manager address, data point, and the TR (door command) command one payload, encoded in UTF-16 little endian.

1. Open RPC Port 4000 (SECLock Mojito): During their investigation, the researchers observed mysterious RPC objects being exchanged on port 4000. Further research linked this to an obscure, legacy service called SECLock Mojito, a system from many years ago designed to allow Symbian phones to open Dormakaba doors. Despite its age and obscurity (only three relevant Google results), this interface still functioned. Similar to the other methods, sending specific RPC objects containing the data point address and access manager address to port 4000 would cause the door to open.

Beyond the direct door-opening vulnerabilities, the research also exposed critical issues related to network access and other system components:

• Network Access Vectors: Dormakaba initially argued that network access was a prerequisite for exploiting these vulnerabilities. However, the researchers demonstrated multiple straightforward ways to obtain it:
• Third-Party Devices: Time tracking terminals and biometric systems, often mounted on the unsecured exterior perimeter, are typically connected via Ethernet to the internal PACS network. An attacker could simply disconnect these devices and plug in their own laptop to gain network access.
• Misconfigured Installations: Dormakaba best practices dictate that access manager boxes must be installed in a secured zone. Yet, the researchers observed numerous instances where these boxes were installed in unsecured, publicly accessible areas, allowing direct physical access to the network ports inside. A humorous but alarming example from an airport was shared, where an access manager was found under a bench in a public area.
• Internet Exposure: Using Shodan and Censys, the team discovered a significant number of Dormakaba access managers directly exposed to the internet. Particularly in the Netherlands, numerous real, operational systems were found to be publicly accessible, allowing direct exploitation of the door-opening vulnerabilities from anywhere in the world.

• Other Critical Vulnerabilities:
• Log Forgery: The server's API on port 8002 allowed arbitrary log lines to be sent, including badge numbers, event IDs, and even future or past dates. This completely undermines accountability and non-repudiation in an access control system.
• Plaintext PIN Disclosure: The same server API on port 8002 allowed querying two-factor PINs for known badge numbers (which are often sequential within an organization) without any authorization, returning the PINs in plaintext.
• Insecure Password Derivation: The system used an insecure function to derive passwords for the access database user.
• Local Privilege Escalation: A vulnerability existed within the Axos application itself, allowing for local privilege escalation.
• Weak Cryptography: Two-factor PINs stored in the MS SQL database were protected with weak cryptography.
• Default Passwords: Several components shipped with easily guessable factory-set default passwords.
• Access Manager Admin Password Reset: A specific API call allowed the administrative password of an access manager to be reset without requiring knowledge of the current password, using a specific ID (ID 9) corresponding to an SQLite database parameter.
• Path Traversal Vulnerability: A critical path traversal vulnerability was found in the custom web server running on the access managers. This server, identified as a hobby project from nearly 20 years ago (with "three stars on GitHub" and last committed to 9 years prior), was copied "one-to-one" into the enterprise product. This flaw allowed authenticated attackers to download the entire SQLite database from the device, which contained plaintext admin passwords, two-factor PINs, and full device configurations. The K7 Linux-based access managers ran this C# web server using Mono, demonstrating a lack of secure software development lifecycle practices.
• Pin Pad Vulnerabilities: Although not detailed due to time constraints, the researchers hinted at further vulnerabilities within the pin pads, encouraging readers to consult their blog post for more information.

In summary, the key findings illustrate a systemic failure in securing critical components of the Axos 9300 system, from its network interfaces to its internal data handling and software development practices. The sheer number and severity of the vulnerabilities underscore a significant security debt within the product.

Technical Deep Dive

▶ Watch: Creative ways to gain network access to systems (15:00)

The technical core of the vulnerabilities revolved around poorly secured network services and inadequate software development practices. The researchers meticulously analyzed various interfaces to uncover these flaws.

The SOAP API on port 8002 of the access managers presented the most straightforward attack vector for door opening. This API, intended for device configuration and status exchange, operated entirely over HTTP, meaning all communications were unencrypted. Crucially, it implemented no authentication whatsoever. The researchers used Wireshark to capture traffic while performing a "release once" operation (opening a door) from the central management server. They observed a simple XML POST request containing three key pieces of information:

• The access manager identifier (e.g., I01000101).
• The data point ID, which corresponds to the specific relay controlling the door (e.g., TR_Door_1_1).
• The command value, typically 1 for "release once" or "open door."

An attacker with network access could simply craft and send this unauthenticated HTTP POST request to open any door connected to an access manager, as the identifiers were either guessable or easily enumerable within a typical network.

The graphics application on port 1005 exposed a different, but equally critical, flaw. This application used a proprietary, custom protocol. By reverse engineering the C# DLLs, the researchers discovered hardcoded credentials designated as "legacy users." These credentials provided login access to the custom protocol. Once authenticated with these hardcoded values, an attacker could send commands to open doors. The command structure mirrored that of the SOAP API, requiring the access manager address, data point, and the "release once" command (TR for door command, command one). Messages sent over this protocol needed to be encoded in UTF-16 little endian. This vulnerability highlights the danger of embedding static, privileged credentials directly into application binaries.

The third door-opening method involved port 4000, which hosted a service related to SECLock Mojito. This service, an obscure legacy component dating back to Symbian phones, processed RPC objects. The research involved piecing together information from scarce online resources, including an old PDF detailing the system's operation, to understand the structure of these RPC objects. By crafting and sending specific RPC objects containing the target access manager and data point addresses, unauthorized door opening was possible. The continued presence and functionality of such an outdated and poorly documented service in a modern PACS underscore significant legacy system risks.

Beyond immediate door access, the central Axos 9300 server itself exposed critical vulnerabilities on its API, also on port 8002. This API allowed for severe compromises of system integrity:

• Log Forgery: Attackers could send arbitrary log lines to the server, including specific badge numbers, event IDs (e.g., "door opened"), and crucially, any desired timestamp – past or future. This ability to falsify audit trails completely undermines the accountability and non-repudiation features fundamental to any access control system.
• Plaintext PIN Disclosure: The API also allowed unauthenticated queries for two-factor PINs. Given a known badge number (which are often sequentially assigned and thus guessable within an organization), an attacker could query the API and receive the associated plaintext PIN without any authorization.

One of the most concerning technical findings was the path traversal vulnerability in the web server running on the access managers. This web server was identified as a hobby project created almost 20 years ago for Windows CE devices, with its code copied "one-to-one" into the Dormakaba product. This inclusion of an unmaintained, community-developed component, complete with its known flaws, is a stark example of poor software supply chain management. The path traversal vulnerability (e.g., using ../ sequences in a URL) allowed attackers to download the device's SQLite database. This database contained highly sensitive information, including plaintext administrative passwords, all two-factor PINs, and the entire device configuration, effectively providing a complete blueprint for compromising the access manager. The fact that the newer K7 Linux-based access managers ran this C# web server using Mono (a free and open-source implementation of the .NET Framework) further highlights the legacy code and architectural decisions that contributed to these widespread vulnerabilities.

Other technical issues included an insecure password derivation function for the access database user, weak cryptography for PIN storage, and the pervasive use of default passwords. The ability to reset the access manager's administrative password via a simple API call (specifying ID 9 for the SQLite parameter) demonstrates a critical design flaw in parameter handling.

Collectively, these technical details paint a picture of a system built with insufficient attention to modern security principles, relying on unauthenticated services, legacy components, and weak cryptographic practices, leading to a highly vulnerable state.

Demo / Proof of Concept

▶ Watch: Beyond doors: log forgery, admin passwords, path traversal (19:00)

The speakers provided live demonstrations of the most critical door-opening vulnerabilities, showcasing the practical impact of their findings. To facilitate the conference demonstration, they created a specialized setup: a small door was literally drilled into a Dormakaba box, complete with the necessary access manager and relay, to simulate a real-world door in a portable, hand-luggage-friendly format.

The first proof of concept demonstrated the exploitation of the unauthenticated SOAP API on port 8002. The speakers showed a simple HTTP POST request. This request included the identifier of the access manager (e.g., ID one), the data point corresponding to the door's relay (e.g., relay two), and the command one to initiate a single door opening. Upon sending this request, a distinct "click" sound was heard, and the miniature door on their custom setup visibly opened, eliciting applause from the audience. This visually confirmed the ease with which an attacker with network access could bypass physical security.

The second demonstration focused on the hardcoded credentials used by the graphics application's custom protocol on port 1005. For this, the researchers had developed what they humorously dubbed a "highly sophisticated hacking exploit"—a custom script designed to automate the process. The script first connected to the access manager, then logged in using the discovered hardcoded credentials. After successful authentication, it sent the specific payload containing the command to open the door. Again, a "click" was heard, and the door opened, illustrating the severe risk posed by static, embedded credentials. The speakers emphasized how deceptively simple these exploits appeared, yet their impact was profound.

The third method for opening doors, involving the open RPC port 4000 and the legacy SECLock Mojito service, was acknowledged during the talk but not demonstrated live due to time constraints. The speakers assured the audience that this method was equally effective and encouraged them to refer to their detailed blog post for further technical specifics and proof-of-concept code.

These demonstrations effectively conveyed the gravity of the vulnerabilities, showing that theoretical flaws translated directly into practical, hands-free door bypasses, challenging the conventional understanding of physical access control security.

Defensive Implications

▶ Watch: Q&A: Discussing the quality of industrial software (26:20)

The findings from this research present a clear and urgent call to action for anyone responsible for the security of Dormakaba Axos 9300 systems, and indeed for all physical access control systems (PACS). The defensive implications span network architecture, system configuration, software patching, and physical security practices.

1. Strict Network Segmentation: This is the paramount defensive measure. PACS networks, including all access managers and the central server, must be isolated from the general corporate network and, critically, from the internet. A flat network architecture, where PACS components are directly accessible from other internal segments, allows an attacker who gains a foothold anywhere on the network to immediately pivot to the access control system. Implement robust firewall rules to restrict communication to only necessary ports and protocols between specific, authorized hosts.
2. Adherence to Secure Installation Best Practices: Dormakaba's own guidelines require access managers to be installed within secured zones. Administrators must rigorously enforce this, ensuring that critical control units are not placed in publicly accessible or unsecured areas (e.g., under benches, in unlocked utility closets). Regular physical security audits of installation sites are essential to identify and rectify such misconfigurations.
3. Prompt Patching and Firmware Updates: Dormakaba has addressed all identified issues. It is imperative that all organizations running Axos 9300 systems apply the latest patches and firmware updates immediately. For older systems or specific configurations, manual mitigation steps might be required. Referencing Dormakaba's official advisories and the researchers' detailed blog post is crucial for a comprehensive understanding of affected versions and necessary remedies.
4. Enforce Strong Authentication and Encryption: All management interfaces and APIs must enforce strong authentication mechanisms. Default credentials must be changed immediately upon installation. Unencrypted protocols like HTTP for sensitive APIs should be replaced with HTTPS/TLS to prevent eavesdropping and manipulation. The absence of authentication on critical APIs, as demonstrated, must be rectified with robust access control.
5. Secure Software Development Lifecycle (SSDLC): This research highlights the dangers of using outdated, unmaintained, or insecure third-party components (like the hobby project web server) in critical enterprise products. Vendors must adopt a rigorous SSDLC, including code reviews, static and dynamic analysis, penetration testing, and careful third-party component vetting, to prevent such vulnerabilities from reaching production.
6. Tamper-Proof Logging and Auditing: The ability to forge log entries severely undermines security. Implement systems that ensure log integrity and non-repudiation. Centralized logging solutions with strong access controls and tamper detection should be used. Regular review of audit logs for suspicious activity is also critical.
7. Inventory and Exposure Monitoring: Organizations should maintain a comprehensive inventory of all PACS components. Regularly use tools like Shodan and Censys to scan their external IP ranges for any inadvertently exposed PACS devices. Any internet-exposed access managers or servers must be immediately secured and brought behind appropriate network defenses.
8. Secure Third-Party Device Integration: Any third-party devices (time tracking, biometrics) connecting to the PACS network must be treated as potential entry points. Their security posture should be thoroughly evaluated, and if they are deployed in unsecured physical locations, their network connections must be physically protected or isolated.
9. Two-Factor Authentication (2FA) Security: If 2FA is implemented, ensure that PINs are stored securely using strong, modern encryption and that they cannot be retrieved in plaintext via any API.
10. Regular Security Assessments: Conduct periodic penetration tests and security assessments specifically targeting the physical access control infrastructure, including both network and physical attack vectors, to proactively identify and remediate vulnerabilities.

By implementing these defensive strategies, organizations can significantly enhance the security posture of their physical access control systems, moving beyond a reliance on physical barriers to include a robust digital defense.

Key Takeaways

• Physical Access Control Systems are Vulnerable to Cyber Attacks: The research demonstrates that PACS, often perceived as purely physical security, are susceptible to common IT security vulnerabilities like unauthenticated APIs, hardcoded credentials, and path traversal, leading to critical bypasses.
• Network Segmentation is Non-Negotiable: A flat network architecture poses an extreme risk. Without strict isolation between PACS components and other networks (corporate, internet), unauthorized network access can directly lead to unauthorized physical access.
• Legacy Code and Insecure Development Practices are Widespread: The use of decades-old, unmaintained hobby project code in critical enterprise products, and the presence of unencrypted communication and weak authentication, highlight significant security debt and a lack of modern secure development lifecycle practices.
• Physical Security Misconfigurations Create Digital Entry Points: Poor installation practices, such as placing access managers in unsecured physical zones or connecting internet-exposed third-party devices to the PACS network, provide easy pathways for attackers to gain the necessary network access.
• Internet Exposure of Critical Infrastructure is a Real Threat: The discovery of numerous Dormakaba access managers directly exposed to the internet, allowing remote door opening, underscores a severe and often overlooked risk for physical security.
• Accountability and Non-Repudiation Can Be Compromised: Vulnerabilities like log forgery and plaintext PIN disclosure directly undermine the integrity of audit trails and the reliability of authentication mechanisms, making it impossible to trust system records.

About the Speaker(s)

Werner Schober is a Principal Security Consultant at Certainity. Prior to this role, he spent 12 years at SEC Consult, where the extensive research into the Dormakaba Axos 9300 system was conducted. Schober has a background in security research and has delivered conference talks on a variety of topics, including smart sex toys, indicating a broad interest in exploring security vulnerabilities across diverse technological domains.

Clemens Stockenreitner is a security consultant at SEC Consult, where he has worked for nearly seven years. His expertise lies with a strong focus on infrastructure security. Stockenreitner collaborated with Werner Schober on this in-depth research, contributing his specialized knowledge to uncover and analyze the complex vulnerabilities within the physical access control system.