Security Breach Forces RSA to Offer to Replace SecurIDs
online.wsj.com
online.wsj.com
That's quite a danger sign! If your security relies on attackers not knowing the details of your system then your security is quite poor.
(As opposed to a random secret that has no particular meaning and is different for each device.)
It almost seems like they didn't actually know for definite if the database had been stolen and where unwilling to burden the cost of replacing all the tokens as a precaution. Now with the Lockheed Martin incident they know it was compromised and are forced to.
The securid tokens are basically sealed, tamper-proof etc hardware pseudorandom generators. RSA knows the seed burned into the PRNG for every device they manufacture.
At customer premises, there's a RSA server component that simulates the same algorithm as the securid devices owned by that customer. This is how they verify that the number you enter is what it's supposed to be, hence proving that you possess the securid. To do this, the customer server needs to know the seeds of all of that customer's devices. This is a trivial computational burden btw, since securid generates a new number only once a minute.
I strongly suspect that RSA continued to store the seeds for their customer's tokens after selling them on an internet-connected computer on their premises. Somebody cracked into this database and stole the seeds for all RSA devices in use by all of RSA's customers.
Once the crackers have this information, they can predict the sequence of numbers for any device out there.
The only fix is to change the seeds: since the hardware is sealed, the only way to do so is to replace the tokens.
I think it's ULTRASTUPID of RSA to (1) keep the seeds after selling a device, (2) keep it on a internet-connected computer.
THIS IS A BIG DEAL, imho.
When authentication is required, the server sends a challenge to the device ("sign this"). The device signs it with its private key, which no other device can do.
This way it's impossible for a single point of failure to compromise the entire system during operation, like it has here with SecureID. The authentication server might be compromised, but that could happen in any system and it would only need that server to be rebuilt.
There are attacks against this system too of course - for example the RNG could be compromised on the devices themselves, or there could be an attack allowing the extraction of a private key due to a design flaw. But the single point of failure as in this case doesn't exist.
It's a bigger deal they didn't replace the devices when they found out.
a little background -
On March 17, RSA reported their security had been breached. http://www.nytimes.com/2011/03/18/technology/18secure.html?_...
Apparently they got targeted by a zero-day Adobe/Excel virus - http://news.cnet.com/8301-27080_3-20051071-245.html
They sent out warnings and did conference calls, but did not give details when people asked if the algorithm that generated the codes had been compromised, and if tokens should be replaced.
One prime contractor reportedly felt it necessary to change to another multifactor system (there are still a few real men)
Around May 21, Lockheed's network was breached by hackers who duped SecurID token codes
http://www.cringely.com/2011/05/insecureid-no-more-secrets/
(submitted that one, sank like a rock and went nowhere LOL)
Now, June 6, they say they will replace the tokens, because, quote "customers don't want to tolerate any level of risk, whether it's real or perceived."
I would say after prime defense contractors have been breached, it's not a perceived risk, it's a hair on fire situation.
Un-freaking-believable.
I was surprised to find out that a large number of tokens were still in use. I think some of the problem may be with a few large organizations that simply didn't have the logistics in place to replace their tokens quickly.
Two organizations that I'm familiar with had each replaced their thousands of tokens by early May.
Is that just your assumption? I believe everyone who received guidance from RSA on the subject was asked to sign a non-disclosure, but I think some of them might be surprised to hear you say that.
In order to clone a given token you require the token seed, token serial and its current token code[1]. The attacker my have the token seeds and serial numbers from the RSA security hack but not a token code without physical access to the token or a keylogger.
If the attacker could install a keylogger on some employee computer they could perhaps capture a token code and then use that to start emulating say 20,000 tokens with the seed and serial pairs stolen from the database. Next time they capture a code compare it with all the tokens being emulated to see if there is a match, if yes, possible success, you have cloned their token and a keylogger will also capture their pin. If there is no match, move onto next set of seed serial pairs with the code you just captured.