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.