OMNILOCKs and Stupid Politics
by Toby (toby@richards.net)
OMNILOCKs and the impact of stupid corporate politics on security could easily each have its own article. I am using each subject as the example for the other. But as you read, be sure to consider the implications of each on its own merit.
OMNILOCK
OMNILOCKs (www.omnilock.com) are a popular brand of combination lock for securing doors.
You'll commonly find these on the doors to server rooms and, in some companies, you may find them on all perimeter doors. In particular, the OMNILOCK 2000 model can be programmed with employee name and combination pairs, which allows the lock to keep logs of who uses the door.
This model is identified by the model name found on the underside of the lock. The flow generally goes like this: The OMNILOCK software, called "OMNILOCK Facility Manager," is the interface to a database file.
The Facility Manager loads itself onto a PDA (the PDA needs to be IrDA capable for this to be useful). The PDA then synchronizes with the Facility Manager database. Now, point your IrDA capable PDA at an OMNILOCK to synchronize users, combinations, and logs.
You can't just go reprogramming any OMNILOCK 2000 just because you got your hands on a copy of Facility Manager and a PDA with IrDA. When you run Facility Manager for the first time, you create a new "facility."
A facility seems to be the combination of the database and its unique identifier. Unless you have a brand new OMNILOCK 2000, then you cannot synchronize with your lock unless the PDA and lock have the same facility.
But that hardly makes the system secure.
The database file, which is called New Facility.ODF by default, is actually a password protected Microsoft Access database.
Rename the file with a .MDB extension and run any Office/Access password recovery tool on it.
I used Accent's (Office Password Recovery Tools) because it was the first one I found with a fully functional demo version. At this point we can look at the file with Access, or we can rename it back to an .ODF file and run Facility Manager on it.
Stupid Politics
You would think that it is self-evident that keeping the ODF database file secure is key.
But political power struggles and petty personal agendas can cloud people's judgment. In one organization, the OMNILOCKs are managed by the support (building maintenance) department. It is very important to these support folks that they retain the only control over the OMNILOCKs.
They don't want anyone, including IT, to have any control or maintenance access to the locks. They have specifically told the IT department to stay out of OMNILOCK business. So IT was never told where the OMNILOCK files were.
IT never poked around to figure it out, either, because that would be disobeying the V.P. who told them to butt out.
But it was inevitable that the IT department would one day hire someone curious.
And so the new network administrator looked for the OMNILOCK files. He found them in:
That's kind of an obvious place, but it gets worse.
Who do you suppose has read access to these files? All users!
If support had put the best interests of the company ahead of their own political agendas, this would have been avoided. But why should we trust the network administrator (who has access to everything anyway)?
Conclusion
The worst security risk remains the human factor.
And is worse than just social engineering. Stupid politics can compromise network and even physical security.