Cardkey Access Systems

Slates

Active Member
Thought everyone might find this interesting. Something to consider as we start moving to access cards for the home. Apparently all it needs is the IP address that the system is working on, and brute forces from there.

http://www.youtube.com/watch?v=gBDVkY9KgtM&feature=player_embedded

Just to clarify, I am posting this as I find it disconcerting. I am in no way suggesting that people should use this(nor am I even sure it's readily available). Hopefully it will open some eyes and these systems can implement better security.

I guess its even more evidence that wifi networks should never be unsecured.
 
There are more things wrong with that install than the IP access issues. There are several ways to get in there without using anything remotely electronic. I get that you posted this as a proof of concept but wanted to bring to light that card access doesn't ever mean secure.

It only keeps out the honest people.
 
Anyone have details on that? That is, is it for Weigand/HID prox readers? Looks to be only for IP-'based' locks. Would many Weigand/HID prox readers be 'IP-based'?

I see the same 'press release' everywhere, no mention of Weigand or HID.
 
The video shows it's HID (check the access card, it has the HID logo). Many commercial systems have some sort of IP interface now.

This is one of those reasons why I insist on telling people not to do any port forwarding to your important equipment (such as your IP based alarm panel, CCTV DVR or home automation) and why wireless security really is important (and why it should be isolated).
 
Dan, I get this as a proof of concept post, BUT
Many systems do have some sort of IP accessiblity as well as even IP at the door, such as HID Edge readers, etc. but a poor install with the network not appropriately firewalled and ports either remaining default or open is a poor practice.

The HID card makes no difference, it could be an Indala card running 50 bit. What I see, and guess, based on the location, is that the controllers are not individually scanning the cards themselves, but the site code on the card itself.

Honestly, hotel type systems are usually the least secure and the hotel keys are typically encoded with a site code only, with the majority of systems running some sort of interface with a Galaxy system (reservation/booking) interfaced with the access control for areas of the site or with parking access hardware. The crux of the issue is usually they have too many people coming/going and cards out there to use an hard or timed antipassback or any other true features of the software/hardware in many of these places.

A poor security install is exactly that. You can have the best hardware and installation out there, but poor practices on the network administration side need to be addressed as they will provide a big hole in the physical security of a site.
 
Dan, I was agreeing, just thought the HID post was misleading, because any access credential 26 bit up to a 50 bit is secure, but how the system is set up is the important factor. We don't even know if that panel was IP based or even had the ability, because a ton of these panels need to be serially connected directly to a server for admin purposes and programming. I won't address client PC's to that server, because that is a firewall and network situation, not a hardware or software issue or exploit.

As a clarification for those that don't know about access control cards/fobs/credentials and these systems, readers, etc. without getting involved with dual-technology readers, larger bit credentials and the whole system setup or swipe readers like hotels commonly use:

An access control credential has 2 things, a site code and a card # associated with it. The system's programming can recognize and allow the credential based on only the site code(s) that are allowed on that system, ignoring the card #, or it can look for both. In the case of a 26 bit card, the site code is one of 255 (for HID) and then the card # is 0-65,535. Brute forcing a site code is nothing, but forcing both and hoping that the site code and card # are both valid...big difference, then factor in the other data bit lengths and formats.

That said, it could've been a brute force attack on an "open" panel or it could also be something else with that app, I, myself, don't know, but I'm willing to bet the most that was brute forced was only a site ID based on the location, time taken and it's inherent security. Too few details and things that are unanswered to me, but having worked on many these systems and installs, I believe there is more to the story.
 
So some observations - it doesn't matter what the card reader's security was - it had nothing to do with this app. This developer found a way to exploit the controller that the card readers and locks are hooked up to. It doesn't matter how secure your card readers are if your controller is vulnerable.

Do some searches for Caribou and Cardaccess - weird that it comes up all over the Droid forums - yet the video shows a Verizon iPhone - so there's some amount of BS here.

Regardless - this in no way shows issues with the security of the HID Cards or their readers - they're not even part of the equation... the person in the video is hacking a weak controller that's hooked to the HID reader.

Personally I don't think this is some brilliant hacker who's learned to hack any cardaccess system in the world... I'd bet you he works for a place that has this crappy system installed and knew the weaknesses from first hand experience - then wrote an app to exploit them. I doubt he can go next door and do the same thing unless the next hotel over has the exact same system installed by the same integrator.

All that said - it should open your eyes to security... your system should allow you to fire anyone and make sure they can't get back in. When you design a system you should do so intending that some day someone may want to lock you out - and you should give them the tools to do so; never the opposite (leaving back doors).
 
FYI - that is actually a Droid Incredible that he is using, not an iPhone. They do look very similar though. You can tell by the circular button on the bottom, which is the trackball that Incredibles have and the red speaker port on the top. It is claimed as an Android app as well.

Makes a lot of sense that this could be a very specific system that he coded for, knowing the weakness (and possessing an access card already). I know very little about these systems or network security, so this is the kind of input I was hoping to hear.
 
The other point is he may not be going through IP at all, but flooding the RF portion of the reader and brute forcing a site ID that way. He may or may not be forcing the controller, you can't tell other than the strike operating.
 
It's definitely an IP based attack, the app even shows 2 input boxes for IP/PORT, plus I am not sure how a phone could perform an RF attack directly since most phones don't even have the hardware to do that (closest I can think of is some phones shipping with the NFC tech).

I am guessing it's just a vulnerability in the management software and/or IP interface.
 
I PM'd a card access system a couple of years ago. It was still in the serial world and I used serial to IP boxes. I put the relays / controllers and main MB in a locked panel in the "server" room. One of my issues was for the system to utilize two encryption methods of the HID cards; and it did. I was involved in training (and writing docs training) of the new system. I started with an entirely new DB importing and cleaning the old one. One base server covered three controllers in three distinct buildings with a custom propietary client. Only two folks had access to the system (and myself).

I guess the way that someone could have circumvented the system was via a brute force physical attack but not really via the network from what I could see. I set up a similiar system in Wales and remembered an employee just punching out the RFID reader; making it not work for anyone including himself.
 
Back
Top