| I completely agree with you; especially in terms of "security" being a social construct. However, if it's possible to anonymously unlock a door using the Internet, that that door will most definitely be unlocked once a few people catch on. If such a problem were widespread enough, people would write software to scan the Internet, unlock doors and post the GPS co-ordinates to a twitter feed. This is a direct and unfortunate corollary of the "Greater Internet Fuckwad Theory". A small subset of people would go around "doordriving", or "dooring". Now the idea is stuck in my head. You're right that correct code can't be "picked" per se - but it's not just about correct code. It's easy to underestimate the number of moving parts required in real world electronic access control systems and how they interact with the computing and physical environments they're installed in. The full system includes the manufacturer, their networks / personnel / procedures, the building, network cabling, management station, the management network, management policies and procedures, peripheral controllers, peripheral bus, peripheral electronics, the physical doodads and mechanisms, the "card to reader" interface and finally the cards themselves. I personally find the threats against current electronic locking deployments to be pretty interesting. I'm by no means an expert or anything but I had to learn a little bit about it for my job. I'm going to deliberately ignore the SWAT method of e.g. attacking the doorframe if the lock is too hard ;) Or the ceiling and floor tiles, or asking nicely for the key, or dressing up as a fire inspector and asking for the key, or setting off a fire alarm and so on etc. Also, I'm going to focus on the systems I know a bit about, which are corporate office building systems (not e.g. hotels, which are different, or high security systems). Consider e.g. a standard HID based access control system. You have an awful VB/MS-JET (last time I used it :) card / zone / user / rule GUI on the management station. That thing needs to be secured - and you would be surprised in practice how many organisations put the management station straight on their internal network, as a domain member server even. Multi-tenanted buildings tend to have better security on the management computers -- since they're air-gapped from any of the tenant corporate networks ;) They usually live in a maintenance room (locked by a conventional lock, for obvious reasons) down near the ground floor. In the multi-tenant case the management station will often have a modem plus PC anywhere installed. If you can log on to the management computer (e.g. by compromising the domain or dialling in to it if it's standalone), the access management system itself asks for a password. You can pull the usernames directly from the underlying access database. You don't normally need to crack passwords. What you do to gain access is choose the name of the installer company as the login, and use that for the password too ;) IAPT (I am a pentester), and so far it's worked every time. Finding building access control management stations is filed in my notes under sections "fun post exploitation activities" and "amusing screenshot fodder". But going down a level: In practice there is a lot more code running in these systems which I haven't personally looked at in depth. The fittings (e.g. door opener thingy, access card reader widget) are "dumb", and they communicate to peripheral controllers. As I understand it, the management station downloads the various settings and rules and card IDs into the peripheral controller, so that everything still works when if the management computer is down. As I understand it, this communication is plaintext (the name of the bus protocol escapes me right now). If you gain access to any of that wiring (host -> peripheral controller or peripheral controller -> peripheral) it's game over. However there's another possibility I've never seen anyone mention, which is that (I suppose) you might be able to van eck the comms over that bus too. I think it is a setting you can choose (a hardware option on the fittings?) for whether you want things to fail open or closed in the event that the power goes out. Going down another level, the "dumb" peripherals really do have code running on them -- they're just "dumb" in the same way that a "dumb terminal" is dumb. If a reader is designed and installed properly we shouldn't be able to glitch it or just plug into an access port, but that still leaves the air interface. The standard HID systems are just doing plaintext RFID and can fairly trivially be cloned by something like a proxmark. It gets a bit worse though with the plaintext systems. The IDs in the standard HID cards are usually formatted as a facility code, followed by a (sequentially allocated) user ID. So if you get the ID of one card -- even if that card has been cancelled -- you can brute force your way to a valid card fairly quickly. There are encrypted systems (doing things properly) which have been out for a while, but they are still not nearly as common as they should be. Things can still go wrong if that's done poorly (e.g. Mifare classic) but as I understand it the new systems are fairly secure. Finally, electronic locking mechanisms are still subject to manufacturing tolerances and obvious implementation blunders - meet the new problems, just like the old problems. There are lots of electronic door mechanisms out there which are vulnerable to nothing more complex than a good shove. This is common with both the mag plates and the latches. They also have unique hardware problems. We had a really amusing "bug" in our office where our actuator was wired up in parallel with other actuators by a lazy installer. So even though we were supposed to be in a separately secured section of the building (different access group + pin required for entry), people with access to other areas could still open the door by teaming up -- one person swipes on low security door, wait for the click, and other pushes on the high security door. Sigh. In a roundabout way, I hope this explains a little bit of my skepticism when I picture an electronic locking company with a groovy kickstarter video (here at lockify, we've reimagined locking things!) and a shiny web 2.0 front end. |
I'm surprised no one's brought Lockitron [1] into this discussion.
[1] http://news.ycombinator.com/item?id=4602679