Archive for the ‘RFID’ Category

h1

No Reader is Trustworthy

February 12, 2013

This guy.  This guy!

The protocol stands, but yet another implementation falls.  Take this as a lesson.

Holy crap, it worked! (Of course, it was only logical that it would, but it always gives you a thrill to see that “I’m in!” moment…) And in only 10 minutes too! Out of the 4.2 million bytes in the file, there were only 53,442 unique contiguous 16 byte chunks, and our key was the 13,675th.

This is the future of hacking.  Stay alert.  Trust no one.  Keep your JTAG interface handy.

h1

I don’t share your greed…

October 16, 2012

…the only card I need is:

Here is an interesting concern for people with proximity card access control systems. Does your brand of reader have a default “backdoor” card ID that is considered valid?

You really should tear apart and check your card readers.

h1

I’m in the wrong country this week!

December 30, 2010

I missed this:  https://events.ccc.de/congress/2010/Fahrplan/events/4114.en.html

Remember where I said here: “HID’s iClass hasn’t been broken to my knowledge, and is the best bet to transition from their legacy systems”?  That’s not quite true anymore.  Standard Security Mode in iClass has been broken.   Quoting Milosch Meriac’s paper “Heart of Darkness — Exploring the uncharted backwaters of HID iClass security”:

Standard Security Mode is dead. Switch immediately to High Security by asking your local HID vendor for programming cards that will upgrade your Standard Security system to High Security and rotate your existing cards to the new keys at a trusted location only. Make sure that your vendor tells you the new High Security key.

That guy did some cool hacking to get the standard security keys.  Additionally, HID screwed up big-time in their implementation.

As a side note, I couldn’t join in the laughter here: https://events.ccc.de/congress/2010/Fahrplan/events/4036.en.html.  Someone should have read the Wikipedia page on MIFARE before they made their payment system.  The talk explains why.

h1

The eye of the enemy is gazing upon: static proximity cards

December 8, 2010

Two times in the last month, complete strangers have asked me how to clone proximity cards.  One actually framed the question in a way that implied they wanted to clone a card so they could gain unauthorized entry somewhere.  Tip:  Don’t try to include someone you don’t know in a criminal plan.

I think that ordinary criminals are becoming aware of the inherent vulnerabilities of old-fashioned static-ID proximity cards.

If you’re using cards that spit out a 26 or 32 or 84 bit value in the presence of the right LF carrier, there are threats you shouldn’t ignore.  Given the upswing in interest, “Nobody does that!” is probably no longer a viable excuse.

Cloning cards

Yes, cards can be cloned.  Easily.  You can use programmable tags, or put together easily-hidden electronics to do the deed.  If you want the card to look perfect, the biggest expense is a card printer.  Even the used ones are not cheap.  All you need to do is collect a number from a valid card.

Proximity cards are great because unlike cut keys, you can individually assign and revoke access without headaches like re-keying locks and issuing new keys to a crowd of people.  Static proximity cards are terrible because unlike cut keys, which you can only copy if you get access to one (or take a photo of it), you can make a copy of the card without the owner ever showing it or knowingly using it.  Flash the card with the right carrier frequency and out spits the card’s number.

Brute Force

Go and check your security system’s logs.  Are there any long strings of access denials, thousands in a row?  Someone may be brute forcing your system.  It’s easier than it sounds, particularly if the person doing the forcing is not particular about what valid card number trips the lock, and your lock responds to a lot of cards.  Remember that many of your ‘bits’ might be an unchanging facility code, and at least one is a parity bit.  When you have a 26 bit card system, it doesn’t take long for an attacker to stumble upon one of the 1000 cards you authorize for your perimeter locks.

It may be the case that *your* attacker doesn’t want to stand around one of your doors in the cold for six hours.  This attacker doesn’t even have the good sense to crank up the power on the ol’ brute-forcer, leave it in a backpack with a couple of “beep sensors” near the door, and pick it up later.  Maybe your attacker already has a card to get in, but wants access to an area his card won’t let him into.  Here’s where that facility code becomes an instant liability.  The attacker with the card knows what it is.

The mechanism is cumbersome, but may be worth someone’s effort for privilege escalation.

Passive Interception

If you’re going to the trouble of standing by a card reader (or leaving a backpack near a card reader), why bother *guessing* valid cards?  There may be dozens, or even hundreds of people with valid cards going through the door every hour.  All you have to do is listen to the card spit out its number.  You don’t even have to energize the card yourself…the reader five feet away does it for you.

You don’t need a six-hundred meter long quarter-wave antenna.  There are very efficient inductive antenna designs that will easily fit in a backpack or briefcase.  You can pick up low power 125Khz transmissions across a lobby.

Stupid tricks

It isn’t hard to take a card reader you bought off Ebay and set it up to collect cards independent of an actual access control system.  Stick it up next to a door and watch everyone badge themselves through.  You have to remember the “beep”, or the Pavlovian trick doesn’t work.

This doesn’t apply to us because everything *valuable* is behind doors with a card+PIN reader

The claim that anything of value is in a card+pin secured area doesn’t hold water.  Think what a single person with a roll-aboard can make off with in a large office during lunch.  Laptops, smartphones, people’s petty cash, car keys…there’s a lot of valuable things laying around the average office.  Talking about secured areas means you’re defending against a presumed attacker that is willing to spend tens of thousands of dollars to get access to your precious database servers or machine tools or your stacks of pre-assembly components.  The barrier of entry to get past the front door of a disturbingly large number of “secured” buildings is less than $500.  This means someone looking to walk off with a dozen laptops now needs to be in your list of threat actors alongside the “skilled and motivated” attackers.

What if someone isn’t looking to take something, but wants to *leave* something?  How much of your information security posture is dependent on the integrity of your physical security perimeter?  It’s not just cat burglars and petty thieves interested in breaking into your office.

So, what do we do?

Use contactless smartcards that authenticate reader and card.  Don’t use MIFARE Classic, of course.  It’s been broken for years.  NXP’s MIFARE Plus or DESFire using AES are good choices.  HID’s iClass hasn’t been broken to my knowledge, and is the best bet to transition from their legacy systems.

Too expensive!

Proximity cards are cheap.  Smartcards aren’t significantly more expensive when you take into account the actual costs of card issuance.  A $1 proximity card still has a $10-$20+ overhead of getting the card enrolled to the right person securely.  That overhead is the same when you issue a $4 DESFire EV1 card.

Plan for the future and ensure new readers can accept the technologies you want to use when you eventually crank out the smartcards.

We’re stuck with static proximity cards for now…

Don’t hand out “visitor” cards.  If you absolutely need to give people temporary cards, don’t re-use them.  If you have to re-use them, only give the cards access to specific entry points at limited times.  If you can’t do that…you’re out of luck.

Keep a camera watching every entry point where someone may try to passively intercept or brute force your system.  Make sure that entry points are clear with no place to hide small receivers near card readers.

When buying cards, make sure you use as few bits as possible for any sort of facility code.  Ensure the card numbers are randomly distributed throughout the remaining bit space.  Never use cards with predictable or sequentially assigned numbers.  Don’t custom program your cards with employee ID or anything else that can be derived or learned from other sources.

Use a pin pad on as many readers as you can.

Hand out RF-shielding badge holders or sleeves to help users protect the access cards when they aren’t in your facility.

Have your security personnel specifically look for “new card readers” on the property.

Programmatically look in your logs for anomalies.  Shut down a reader and dispatch a guard if you get ten strikes in a row.  If nothing else, the reader may have broke and you’ll need someone there to direct traffic anyway.

Good luck.

 

30DEC — A note from the future!  HID iClass “Standard Security” has been publically broken.  See http://www.openpcd.org/HID_iClass_demystified for details.  Make sure you’re using your own keys in “High Security” mode.

h1

Mifare 1K cards in.

March 6, 2010

I just got my new S50 1K cards in today.  They come individually wrapped and ready to go.

Here you can see the chip in the corner of the card.

A random sampling of the cards read fine in the Omnikey 5321.  They appear to have a default KeyA and KeyB of 0xFFFFFFFFFFFF.  I’m going to have to tweak some python I’ve been using (RFIDIOt) so I can write the data I want to the cards.  Hopefully it will all work as planned!

h1

Cards side-by-side

March 2, 2010

HID Prox, HID iClass, Indala ESP

From left to right, the cards are:

  • HID Prox card, clamshell form-factor
  • HID iClass card, ISO form-factor
  • Indala ESP card, clamshell form-factor

Notice the thickness of each card.  Those Indala cards were like bricks!

h1

HID Omnikey customer service proves me wrong.

March 2, 2010

After a day of back-and-forth over the weekend, HID reps in the UK and Austria were able to assure me that the OSX drivers for the Omnikey 5321 are supposed to enable the RFID functions on the reader.  Based on their insistence, I started troubleshooting and discovered that pcscd in OSX is flaky.  It cannot handle USB reconnects or machine suspends.  If you are careful to kill pcscd before connecting the reader or waking from suspend every time, it restarts, loads the driver, and works correctly.

Although their site says that contactless cards are not supported by the OSX driver, the latest one does in fact work the same as the Linux driver with the cards I have at my disposal.  Like the Linux driver, it still does not react to EMV tokens.  I can verify that it senses and IDs iClass cards just fine.

A sincere thank-you to Markus and Mike from HID, especially to Mike for getting back to me on a Sunday.