Breaking Hotel Security: Exploiting Saflok and Onity Access Control Systems

TLDR: Researchers at DEF CON 2025 demonstrated that widely deployed Saflok and Onity hotel lock systems remain vulnerable to master key creation due to weak encryption and insecure data handling. By sniffing card traffic or using a handheld programmer, an attacker can extract the property ID and generate arbitrary keys, including master keys that bypass deadbolts. Pentesters should prioritize testing these systems during physical security assessments, as many properties have failed to fully implement the manufacturer's recommended security patches.

Physical security is often the forgotten stepchild of a penetration test. We spend weeks hunting for blind SQL injection or misconfigured S3 buckets, but we rarely stop to consider that the door to the server room or the hotel suite might be secured by a system that is fundamentally broken by design. The research presented on Saflok and Onity locks at DEF CON 2025 is a stark reminder that proprietary hardware is rarely as secure as the vendor claims.

The core issue here is not a single bug, but a systemic failure in how these locks handle authentication and data storage. These systems, particularly those using MIFARE Classic or MIFARE Ultralight C cards, rely on a security-through-obscurity model that falls apart under basic scrutiny. The encryption algorithms are rudimentary, often relying on simple substitution tables and bit-shifts that are identical across every property. Because these keys are not unique to each site, the entire security model collapses once the algorithm is reversed.

The Mechanics of the Exploit

At the heart of the attack is the ability to manipulate the 17 bytes of data stored in sector zero of the hotel key card. This data contains the property ID, the card level, and the sequence and combination fields. The sequence and combination fields act as a passcode that must match the value stored on the lock for the card to be accepted.

When a guest checks into a hotel, the front desk encoder writes this data to the card. If you can obtain a valid card, you can use a tool like the Proxmark3 to dump the data. Once you have the data, you can use a custom utility to decrypt the block, modify the card level to "Emergency" or "Master," and update the sequence and combination fields to match the target lock.

The most dangerous aspect of this research is the use of the handheld programmer, often referred to as the HH6. This device is intended for maintenance and configuration, but it provides a direct interface to the lock's internal memory. By plugging an HH6 into the lock's programming port, an attacker can extract the property ID directly from the lock's logs, even if they do not have a physical key card. This eliminates the need to sniff traffic at the front desk or wait for a guest to drop a card.

Practical Application for Pentesters

During a physical security engagement, your first step should be identifying the lock brand. If you see a Saflok or Onity system, assume it is vulnerable until proven otherwise. You do not need to be a hardware wizard to perform this test. If you can gain access to a programming port, you can interrogate the lock to pull the property ID.

Once you have the property ID, you can create your own master key. The process involves:

1. Identifying the lock's property ID via the HH6 or by sniffing a legitimate card.
2. Encoding a new card with the correct property ID and the "Emergency" card level.
3. Using the card to open any door on the property, including those with deadbolts engaged.

The impact is total. An attacker with a single forged master key can access every room in a hotel, bypass privacy locks, and potentially gain access to sensitive areas like back-office suites or storage rooms. This is not a theoretical risk; it is a direct path to unauthorized physical access.

The Defensive Reality

Defending against this is difficult because the vulnerability is baked into the hardware. The manufacturer has released a two-part mitigation strategy: upgrading from MIFARE Classic to MIFARE Ultralight C and implementing per-site AES-128 encryption for the data at rest. However, many hotels have only completed the first step. Upgrading to Ultralight C provides a marginal security improvement, but it does not fix the underlying issue if the property is still using standard, non-unique keys.

If you are working with a client in the hospitality sector, your advice should be clear: upgrading the card format is not enough. They must ensure that their system is configured to use unique, per-site encryption keys. If the vendor cannot provide this, the locks are effectively insecure.

Security in the physical world is just as dynamic as it is in the digital one. We often assume that physical locks are "hard" and software is "soft," but when the lock is just a computer with a solenoid attached, the same rules of reverse engineering and vulnerability research apply. Stop treating the physical layer as an afterthought. The next time you walk into a hotel, take a look at the lock on your door. It might be the most interesting piece of hardware you encounter all week.