Threat Forward

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.

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?

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.

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.

Here’s a fun one: https://threatpost.com/en_us/blogs/infected-pc-compromises-pentagon-credit-union-011211

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.