Videx CyberLock Vulnerabilities

Author: Steve Pordon
Version: 1.21
Date: May 11, 2014
Original publication: July 22, 2013
Changelog: 1.21 (further correction of hash definitions)
     1.20 (corrected definition of hash values in DB)
     1.01 (minor HTML cleanup)
     1.00 (initial public release)
Acknowledgements:

• Jim McGowan at Videx, who understood the problem and had an engineering fix almost immediately, considering the time it took to mail locks back and forth.
• Members of lockpicking101.com, without whom I wouldn't have even started looking at CyberLock.
• Jericho, for proofreading, fixing my bad grammar, and making sure I didn't make erroneously false statements.

Any errors are my responsibility.

CyberLock and CyberAudit are trademarks of Videx, Inc.: http://www.videx.com/

Abstract: Older Videx CyberLock hardware installations (prior to around August 2011) may be vulnerable to a simple physical attack, and older versions of the CyberAudit management software (version 1.2a tested, probably other versions written in Visual Basic 6 prior to the "CyberAudit-Web" rollout ca.2009) are vulnerable to multiple attacks, one of which I will focus on in this paper. The physical attack leaves no audit trail within the locks, and the database attack logs can be trivially obfuscated in the CyberAudit Lite software.

Methodology: I developed the physical exploit on a new (old stock) 2010-era T-bar vending machine lock held in a pair of Vise Grips in March 2011. I developed the database attacks on this same lock and a 2002-era Schlage form factor CyberLock in May 2011, using version 1.2a of the CyberAudit Lite software. A locksmith who declines to be named confirmed that the physical attack also worked with a mortise form factor CyberLock installed in a Chubb Viper Deadlock.

Mitigation: Upgrading to locks manufactured after August 2011 and any version of the CyberAudit-Web software will prevent the specific attacks discussed here. Both of these mitigation vectors require new hardware. At a minimum, installations running CyberAudit software prior to the "Web" versions should physically isolate the computer running CyberAudit from the network, and follow best practices regarding employee access to this computer.

Timeline

Date vendor notified: June 29, 2011
Date of vendor fix: August 10, 2011 (Note: no software fix known. Upgrade to CyberAudit-Web.)
Date of initial public release: July 22, 2013

Introduction

Videx CyberLock is a patented (http://www.google.com/patents/US6615625) drop-in replacement for existing mechanical locks, and comes in several different form factors to conform to different lock core shapes. Although differing externally, CyberLocks generally share the same internals, composed primarily of logic circuitry, memory, solenoid-engaged blocking pin, and an anti-tampering pin. Locks are powered by a battery in the key. If the key contains the correct password hash and is authorized to open a specific lock, the lock will write an entry to an access log and pull the solenoid out of the way of the blocking pin, allowing the lock plug to rotate and engage the locking mechanism (cam, T-bar bolt, etc.). Keys will automatically sync any new lock audit logs with the database on key updates, and locks keep a rolling log of all events (the number of entries varies with the number of locks in the database, but locks in a CyberAudit Lite installation hold a maximum of 1100 entries).

Magnetic attacks against CyberLock were developed by parties unknown several years after the first patent (see https://www.youtube.com/watch?v=D0rTbcWtCek for an early example). These attacks depended on a sharp blow to the face of the lock coupled with a strong rare-earth magnet. My understanding is that the impact makes the solenoid bounce toward the front of the lock, close enough so that the magnet is able to capture the solenoid plunger and hold it out of the way of the blocking pin, at which point the lock is effectively open. In my testing, I could not get the magnetic attack to work on my specific lock, which I was later informed was the result of Videx replacing the tamper pins in newer locks with steel instead of brass (thus capturing the tamper pin against the magnet along with the solenoid, which stops the blocking pin from dropping out of the lock's shell so that the plug can turn).

Exploded view from patent continuation, showing solenoid plunger pin (290),
blocking pin (304), and tamper pin (286). The face of the lock is to the left.

Physical Attack

Although I couldn't perform the magnetic attack, the "bouncing solenoid" theory was still a sound one. Building off of this idea and the idea of timing in bump attacks, I was able to open my locks in as little as one second with a piece of metal and a 12-oz. plastic-faced hammer. The attack is carried out by using a piece of spring steel with a 90-degree bend (or a basic lockpicking set tension wrench) in the face of the lock and slamming the plastic head of the hammer into the front, either applying turning torque at the time of the blow or simply holding torque steady during the process. Without torque timing, the attack generally requires several blows, but my average time to open was still around four seconds. Locks bypassed this way will have considerable, obvious damage from the tension wrench deforming the metal of the lock face, but the lock itself will have no record of opening due to a lack of power. If there is already an audit log in the lock's memory, the last log entry will be the last evidence of opening. According to the patents, the tamper pin in CyberLock plugs is designed specifically to defeat this type of physical attack, but I found it to be ineffective in the locks I tested.

LP101 forum member mh pointed out that a specialized torque tool could be made that would minimize the forensic physical damage to the lock, but I have not tested this theory.

Videx sent me a newly manufactured lock to test after I contacted them. I was able to open the new lock in one second with the hammer attack. In August of 2011 Videx sent me one that I could not bypass. I was not allowed to disassemble this lock, and therefore don't know what specific modifications were made, but it is safe to say that locks manufactured after then should not be vulnerable to this specific attack.

There is no skill required to perform the physical attack. The technique most closely resembles the pin tumbler bump attack, which I have never performed, and I was able to get my CyberLock open in about ten seconds the first time I tried this attack.

Database Attack

A proper CyberLock installation consists of one or more locks and keys, a hardware key programmer, and CyberAudit software which reads and writes database entries, using password authentication. A hash of the CyberAudit system password is used by keys to open the locks. When the key is synchronized with a lock, the lock verifies the correct password hash and opens the lock if information supplied by the key indicates that this key is authorized to open this lock. An attacker's key can thus fool any lock into accepting its validity as long as the key knows the correct password hash.

After a successful key/lock handshake, the key copies the lock's recent audit logs to its own memory and updates the CyberAudit database during the next key synchronization. This database is absolutely trivial to manipulate in pre-"Web" versions of the software, but it requires access to the files, either by an internal attacker or by an external attacker able to exploit OS vulnerabilities over the network (minimum OS required to run CyberAudit: Windows NT 4.0 or Windows 95). The CyberAudit user manual stresses the importance of securing the program's files.

Prior to the CyberAudit-Web overhaul, the management software was written in Visual Basic 6. The database is an MS Access 97 format that uses JET 3.5 encryption, which has been known for years to be broken (see https://groups.google.com/d/msg/relcom.netnews.big/LtbiWVrvlWw/l7DuKh17wg4J). When I asked Videx whether I should upgrade my software to a newer version for security purposes, they told me I should get familiar with my current installation before considering an upgrade.

The database is stored as the file CyberLock.cld (a renamed .mdb file) in the CyberAudit installation directory. Dragging this file into MS Access will prompt the user for a master database password (this is not the password set by the program administrator, but rather by Videx itself, when the software creates a new database). The password is easily obtained with a hex editor and a calculator, and is only useful as a means to open the database directly with MS Access–the password isn't used by the locks in an installation, as far as I know.

Passwords hash to the same value across different installations, which means there is no salting based on timestamp, etc. I haven't tried to reverse the hashing algorithm because with direct database access, it isn't needed.

Interesting components of table structure:

Table	Description
Assignments	Contains various key/lock relationships, flags indicating whether lock needs to be configured or transfer logs on next access, etc.
Globals	Contains current hashed CyberAudit communication password (gl_comm_pw), various key/lock data relating to password changes (old hash and new hash will both be stored here until all locks are successfully updated).
Keys	List of all key IDs with communication hash (k_comm_pw), flags indicating whether key needs to update locks with new info, number of log entries to store before overwriting old ones, etc.
Locks	List of all lock IDs with common assigned names, flags indicating whether the lock has a pending update, etc.
Events & EventsFinal	Audit logs.
Inv	Contains altered password hashes in chronological order of changes. iv_val is derived from a hashing algorithm which will be explored in the next whitepaper. This algorithm is combined with the last byte of the iv_recstamp in a lookup table scheme to generate XOR values which transform the initial password hash into the iv_val.

There are many things an attacker can do with direct access to the database, but the most severe attack is key injection. Key/lock relationships are stored in the Assignments table and key information is stored in the Keys table. An attacker wishing to use his own key in someone else's facility would simply:

• find a key with high-level access in Assignments and copy/paste the relevant rows (one for each lock listed in the as_l_id field)
• change the as_k_id field in Assignments to his own key's serial number for each copied row
• copy/paste an arbitrary row in the Keys table
• change the k_id field in Keys to his own key's serial number in the newly copied row.
• save the database, start CyberAudit, and insert his key into the programmer to be updated with the password hash that already exists in the database.

At this point, the attacker's key–I got mine on eBay along with one lock, the key programmer, and software for about $80, and another key/lock combo for about $30–will open any lock it's assigned to in the Assignments table, subject to any time/date restrictions in place on the original copied key rows, although schedule restrictions can be easily bypassed if necessary. The attacker does not ever need to know the system password set by the victim facility's administrator.

It is important to note that an attacker with his own key, copy of the software, and a key programmer can perform this attack from anywhere, provided he has obtained a copy of the CyberLock.cld file from the facility installation computer (see caveat above, as this is the only non-trivial part of the attack). The CyberAudit software demands the system password every time it is started, but crucially does not require this password to be entered in order to update a key inserted into the key programmer. As long as the correct entries for a particular key exist within the database, the software will happily read and write key information via the programmer immediately on insertion while the program is still displaying the password entry window. Technically, a child program named CyberCom.exe is started by CyberAudit.exe, and is responsible for serial communication with the key programmer–the program can be run manually and will update keys automatically based on database information without requiring user interaction.

An attacker can also easily obfuscate logs in CyberAudit Lite by setting the k_name field of his key in the Keys table of the original facility install to match the name of one of the legitimate keys in the database. When lock audit logs are examined, the log window will display the key's name instead of the serial number, making the attacker's key appear to be one of the legitimate ones. This trick will not work in CyberAudit Professional, which allows the administrator to generate audit reports that include key serials, but CyberAudit Lite makes it easy to frame other people for unauthorized entry. Obviously, these extra keys will be noticed by an alert administrator.

The skill level needed to exploit the database attack varies widely depending on the network, filesystem, and workstation security protecting the .cld file. For the sake of argument, an attacker with the database in hand would need a basic level of relational database knowledge to understand and manipulate the structure successfully.

Potential Impact

According to Videx literature, CyberLock is mainly used in facilities that require high physical security and strong auditing capabilities. Some of the uses listed at http://www.cyberlock.com/cyberlock_case_studies.html include class 2 narcotics safes in Fire Department vehicles, police evidence rooms, water treatment facilities, and vending machines. The potential impact of any of these use cases should be self-evident, but I will focus on the vending machines in the next section.

Attack Scenario

Bob and Mallory are vending machine technicians working for Alice. Each time they go into the field to empty coin boxes, they take along an employee-assigned key which has been programmed to only open vending machines during specific time periods. Mallory collects coins every Monday and Bob collects coins every Thursday. Keys must be returned to the office when not in use, and are only handed out at the start of a shift. Alice stores the keys in a safe when they're in the office but has a bad habit of not password-locking her Windows NT 4.0 workstation running the CyberAudit Lite software.

One day, Mallory finds a Craigslist post for a used CyberLock starter kit, and buys it for $100. She copies the CyberLock.cld file from Alice's computer onto a USB drive, sets up the software at home, injects her new key into the database, gives it the name "Bob", and updates the key. She puts this modified database back onto Alice's computer on Wednesday.

On Thursday, Mallory uses her new key to skim money from the vending machines just before Bob gets to them. After he completes his rounds and returns the key to Alice, the day's audit logs are synchronized with the database. If Alice looks at the logs before Mallory has a chance to alter them to remove the extra entries, she will see only that Bob has been accessing the vending machines twice per shift. Given the advertised security of CyberLock, she will have little reason to suspect anyone other than Bob in the event of accounting discrepancies.

Conclusion

Videx CyberLock is a very nice product overall, with continual security improvements. Due to the nature of physical locks, however, "patches" aren't always feasible. The time and cost involved in replacing locks, especially in large facilities, are considerably more expensive than software patch maintenance windows. Older installations may still be vulnerable to the attacks outlined here. Layered security is, as always, a good defense. If your installation depends on older hardware which you can't replace at once, it's still a good idea to at least update the software to the CyberAudit-Web versions.