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.

h1

Good help is so hard to find.

September 2, 2010

This is an interesting read from CSIS: A Human Capital Crisis in Cybersecurity.  In a nutshell, it repeats the timeworn complaint that “there’s not enough good information security people out there”.  There’s nothing new there…we’ve heard it since before legions of self-promoters started using the ‘cyber-‘ prefix.

As usual, the prescription is education and certifications.  The paper does a great job of listing out the many organizations that offer information security certifications.  It proposes that these all be standardized, or unified under a government body.  CSIS put a lot of work into the background and the proposed action plan.  It is worth the read.

h1

Scanners, what are they good for?

August 24, 2010

The more I read the less I can add.  Zalewski covers all the technical reasons around why web application security scanners suck.  I’d go even farther and say in my experience the most popular (and expensive) scanners are pretty awful force multipliers for even experienced testers.

So, why on earth would you drop $30K and $5K/year on one of these things?

Years ago, I had the two “best” scanners in-house.  My testers were free to use whichever they preferred.  This worked out better than you’d expect — these two competing products would often catch each other in quality highs and lows.  When Product A started to become unwieldy and  more trouble than it was worth for an analyst to waste time with, Product B was usually in a quality upswing.  At any given time, one of the two would work.

I had a motive behind the scenes for keeping them both.  Together, these two products had around 85% of the market share.  A few of my clients used one or the other when they assessed my sites.  For a while, knowing ahead of time what false positives their tools would throw made it easy to address their “findings”.  Some clients demanded the canned scan reports from Product A or B as a bureaucratic checkbox.  In fact, they’d demand it even in the face of client facing documentation from a top-tier application testing company.

It is a testament to the marketing strength of these companies that a false-positive-ridden canned report would trump CFD from a well regarded consultancy.  I think deep-down, a significant slice of the information security workforce really does believe the hype that all of this can be automated and metric-ized.

h1

Sad, embloggened world.

August 22, 2010

It’s been way too long since my last post, and this one doesn’t make up for the long pause.

Maybe tomorrow I’ll comment on and add my useful insight to this post by The Esteemed Mr. Zalewski.  Won’t that be a blast?

Here’s a preview:  “I agree with everything Michal Zalewski has to say on the matter.”  I promise there will be at least a sentence more than that.

h1

We were just trying to make logging in easier…

June 14, 2010

ATT is funny.  Not that new, hip, “ironic” funny, but funny-like-a-clown.  From the WSJ article:

AT&T Inc., reaching out to iPad users Sunday to explain why their email addresses were released last week, blamed the incident on “computer hackers” who “maliciously exploited” an attempt by the carrier to speed the process of logging in to its website.

It would have taken some forethought and planning to make the process convenient and secure.  So, they just didn’t bother.