Archive for December, 2010

h1

Number 2: The Equivalency Trap

December 31, 2010

“Well, we already have Bad Thing X out there, and Y isn’t any worse…”

A year later, when the time comes to fix Bad Thing X:

“We already accept Bad Thing Y, and X isn’t any worse…”

Danger is cumulative.  Accepting risk should never imply that all risk of equal or lesser value is accepted.  Two risks of equal impact means there’s two ways the bad result can happen. Once you start down this road, inertia keeps all of it from getting fixed.

Alone in your office, it is safe to compare risk.  Out in public, comparison invites people to come out of the woodwork and claim they have that “risk of equal or lesser value” coupon.  You don’t stop wearing your seatbelt because you smoke three packs a day, and you don’t refuse to quit smoking because you’re an awful driver.

h1

Number 3: All or Nothing

December 31, 2010

“We’re waiting on a complete fix”

…and waiting, and waiting…

Meanwhile, anyone looking to take advantage of your situation won’t be waiting for your fix.  They won’t wait for a patch from the vendor, or for a replacement to make it through your procurement process.  Timelines slip, so put something in place now to protect yourself.  The ones arguing that it’s too much work will be the ones arguing that it isn’t their fault that it never got fixed–after you get nailed.

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

Number 1: The Hubris of Prediction

December 29, 2010

“If it hasn’t been exploited yet, it probably won’t be.”

Repeat this ten times out loud:  You can’t predict the future.  We like to think we can “forecast” and come up with likely scenarios about what is going to happen, but it never works for long.  Risk management models fall apart in information security because there is so very, very much that you do not know.  The more specific you try to be, the shorter the lifetime of your prediction.

Of course, that’s nuance for people who understand forecasting and risk.  Headstrong predictions will be coming from the stakeholders who have to spend time and money to fix problems.  They will have tortured explanations–the whip marks still fresh–for why the problem of the day won’t ever really be a problem.  In these cases, it pays to be the only one in the organization with the official magic 8-ball.

h1

Number 4: Settled for All Time

December 29, 2010

“We decided five years ago to accept this risk!”

When a decision is made, people involved are loathe to revisit it.  This is especially true when an organization decides that something is “worth the risk”.  The obvious problem is that situations and what you know change, which changes the risk equation that drove the decision in the first place.  It may be inconvenient, but every risk decision deserves periodic scrutiny.  Don’t accept risk without an expiration date.

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.