EuroPoli

Following a debate with a peer over the severity of the RSA breach, I thought I would put together a more reasoned response following my rant a few days ago.

So, from rumours circulating the RSA breach seems to involve the seeds being stolen; but what else could have been stolen? Well, there are a few possibilities:

- The seeds were stolen

- The source code was stolen

- Some other IP was stolen

I’m leaving out the possibility that anything was compromised as it was shipped to customers as RSA have stated that their breach on its own cannot compromise customers.

So, let’s go into each one in more depth… If the source code was stolen, then there are two possibilities. Assuming the code was well designed, and no vulnerabilities are found in the code, then there is no real issue. In fact, some may suggest that RSA releasing the source code for public peer review may indeed strengthen their product. If, on the other hand, the source was designed in such a way that it can be bypassed; then it’s back to the drawing board for RSA.

On that note, there are rumours that there may be a backdoor in the system, allowing government(s) access to systems as they please… That said, this seems like a very far fetched option. I doubt RSA/EMC would indeed implement this, and if this were the case I doubt RSA’s network would be where the data eventually leaked from.

Onto the seeds… but first, let’s quickly run over the basics… 2 factor authentication relies on, as the name suggests 2 of the basic 3 factors of authentication (something you know, have or are) (apologies, not trying to teach you to suck eggs, I’m just trying to be coherent!)

In the case of RSA SecurID tokens, the PIN is something you know, and the token something you have. To “prove” you have it, you use the pseudo-random number it generates.

The pseudo-random number is generated from a combination of 3 things, the token serial number, the seed and the time. The time is trivial to find. The seed, we can assume, has been compromised. Thus, the token’s security relies on the serial number, which isn’t something you “have” but more of something you “know” (as it can be transferred without any noticeable change to the first instance. I can email you my serial without tampering with the serial).

Thus, an attacker can, quite easily, create a software token that takes that seed (which we assume they have stolen), the time (reasonably easy to guess) and a serial number (harder to find, but still doable) to generate the “unique” code.

As such, that reduces the 2-factor authentication to 1-factor, i.e. something you know; in this case your PIN and your serial number.

Many organisations keep large databases of serial numbers in their asset trackers, which aren’t hardened (indeed, from experience, many allow all members of staff read access to these; but that’s another debate).

So, going back to my argument, reducing 2-factor to 1-factor isn’t that “doomsday”; but then you need to consider that that 1-factor is a 4-digit PIN number, so 10^4 possible combinations, or 10,000 permutations. Let’s say the attacker then has to try this for 1minute before and 1minute after the time on his machine (as the server time may have strayed), so 30,000 permutations.

10,000-30,000 attempts to log in, for a brute force attack, are minimal (obviously assuming there aren’t other mitigating protections enabled, e.g. timeouts, etc).

Which is why I think that RSA have told everyone to safeguard their serial numbers, lengthen their PINs to 8 digits and keep an eye out for failed attempted logins…

 So… assuming the seeds were indeed stolen, what do we do? Well, in the sort run, the usual. Harden, monitor, educate and enlarge your PIN length. Then, you need to decide if to jump ship (CA are doing a free swap of RSA SecurID tokens, click here for info and of course, I need to mention that Symantec recently bought VeriSign, which also have their own identity management solutions) or whether to stay with RSA and go with a redeployment of all your tokens (again, assuming the seeds were indeed stolen)

M.

(an addendum, I’m assuming the seeds were stolen with a mapping to the clients they were used for… e.g. CompanyA:seedA, CompanyB:seedB, … if the seeds were stolen as a simple file of all the seeds with no other data… well, then it’s more complicated to mount an effective attack!)