Archive for the ‘Security’ Category


So when did RSA start shipping *your* replacement tokens?

June 7, 2011


It appears it was a seed compromise after all.  You need new tokens, and you need them months ago.  Cleartext token use is one way that someone could start gathering your tokens en masse.  An even scarier problem you are open to is a keylogger or other workstation compromise that has captured a token being used.

Pretend there was a keylogger trojan on one of your user’s workstations back in 2009.  Before it was removed/wiped/whatever, someone was able to capture a VPN login with username, tokencode, and PIN.  You know, “juser/908235123456”.  Oh, and for grins, the trojan also logged a decent timestamp:  “03/04/2009 17:34”.

Recovering the token based on this capture is a matter of grinding to find the appropriate seed.  The attacker just has to crank through each seed with nearby clock values (to account for drift), and id the seed that matches the tokencode generated…908235.  Now the attacker can simulate the correct token and pretend to be juser at will.

This breach not only put you in danger from the moment it happened (which is necessarily prior to when it was detected by RSA, which was before it  was reported by RSA…), it adds value to historical captures of SecurID authentications. Depending on when your tokens expire and how often you force PIN changes, that could be very, very bad.


RSA #3

March 20, 2011

Another “whoops, there go the seed files” scenario.  This one also works if for some reason you keep all your seed files lying around and someone snags them.

  • Get a good clock, as good a clock as your target has.  NTP makes this easy, of course.
  • Start running every token virtually, recording every token code that pops up.
  • Observe tokens being used.  Maybe you found a system using it to protect telnet or FTP.  Or, something else entirely.
  • Watch the logins.  If it’s a hard token, check to see where that code pops up.  Hopefully it won’t be way too fast or slow, so you’ll have a decent chance of catching it.  If it’s a soft token, you have a little brute forcing to do.

Moral of the story:  If seed records have been obtained, a compromised system or unprotected login method using SecurID can be the weakest link used to enumerate tokens.


RSA Schadenfreude #2

March 18, 2011

Here’s an interesting thought experiment for the vulnerability researchers out there.  Let’s say the signing key RSA uses for seed files has been compromised.

  • Can you “root” either the Authentication Manager or soft token by having someone load up a malformed seed file?
  • Can you “root” either the Authentication Manager or soft token by having someone load up a malformed, but properly signed seed file?

RSA Schadenfreude #1

March 18, 2011

I suspect that IF RSA’s database of seed, serial number, and customer assignation has been acquired, we will start seeing chunks of it for sale very soon.  There’s two scenarios I’m thinking of.

1.  The database was acquired specifically with the idea to sell the information.  It has a limited lifetime, and is particularly useful to potential buyers that possess other information they can use in conjunction with the db.  You’d need to make that money now before RSA replaces tokens, or comes up with a clever scheme to neutralize the threat.

2.  The database was acquired with the goal of compromising specific customers of RSA.  In that case, the same lifetime applies, but you will want a smokescreen to mask your attacks, and to potentially mask your intentions.

My friend Mike shared his ideas regarding one potential attack.  We agree that it’s nasty, but disagree (slightly) on a detail of how effective it could be made.  It *is* noisy, so a smokescreen would add beneficial confusion.

I really, really dislike soft tokens, but in this case I think that IF an attack compromised their token issue database, the length of time it will take to replace hard tokens will keep them exposed longer.

I wonder if RSA has anything interesting they can do with the way PINs are used to buy some time…if that’s what happened.


Wasn’t lies, it was just…

January 24, 2011

A friend recently posted about being stonewalled by vendors when asking them how they deal with employee turnover.  The odds are that you have procedures of your own to handle terminations and job changes.  It’s reasonable to hold vendors that run your infrastructure to a similar standard.  Read it for why.

When you outsource infrastructure administration, or when you end up hosting important data under outside control, you definitely want to set up the agreements so they follow your existing security policy.  An honest outsourcing vendor who wants your business is going to agree with some few exceptions where the two of you negotiate to a middle ground.

If you aren’t getting the right to inspect the systems (or portions thereof) moving, storing, and processing your data, there’s a chance that important security requirements you negotiated for, maybe even that you paid extra for, aren’t being met.  In fact, if you didn’t nail down the right to audit, you probably didn’t get security goals in the SLA to penalize incentivize the vendor.

I’ve had the pleasure of performing investigations on behalf of clients who entered into agreements with vendors that held all the cards.  Every single time, the vendor “had not been forthright about the security posture they claimed to hold”.  Each one was lying about their security situation, in significant ways that ranged from not patching when they said they patched to sharing infrastructure they claimed wasn’t shared.   It isn’t a large or scientific sample — there were already suspicions that led to my arrival on-scene.  Surprisingly, these weren’t small-time infrastructure outsourcers…these were the big names with the big price tags.

The moral of the story:  If they promise it to you, but won’t let you see it, smell it, or touch it…it probably doesn’t exist.  Honest vendors will be up-front about how they operate, explain the limits of how far they can conform to your policies and expectations, and most of all will want you to be able to check so there’s no ambiguity haunting anyone down the road.

Less-than-honest vendors will prevaricate, hide their operations, and when caught claim that they weren’t actually technically violating the contract, or trot out the old line that “everyone does it this way”.  They’ll pull an Elwood Blues on you.


It will come to an end.

January 12, 2011

Here’s a fun one:

The days of you taking your company laptop home to do “whatever”, or browsing the internet at large from work are going to come to an end.  It’s going to come to an end soon because the costs of “blocking everything bad” overtook “only allow what is known to be good” a long time ago.  Those deferred costs (breaches, theft, etc) are now being realized because Big Time Computer Crime is starting to mature.

Some organizations have done their best to aim for the “known good” solution, but they’re in the minority.  The challenge for everyone is accommodating the proven benefits of access to the internet while trying to protect data and systems from increasingly prolific and savvy opponents.

Yes, all of this was figured out in the 1960’s and 70’s.  Somewhere in between we lost it.  Technology’s progress during the passing decades makes it conceivable that we can unearth and reinvent those old solutions …  but make them easier to carry and faster.


Yes, those are four mistakes you will make in 2011

January 6, 2011

Recap: you will make mistakes.


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.


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.


I’m in the wrong country this week!

December 30, 2010

I missed this:

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:  Someone should have read the Wikipedia page on MIFARE before they made their payment system.  The talk explains why.