Steve Gibson and Leo have been talking about this for weeks on the Security Now podcast. Interesting story if you'd like to listen. Amazing how a well known security company kept its crown jewels within reach general employees with Windows boxes. When are they gonna learn?
Not only that, they have employed a security-by-obscurity strategy:
RSA Security Chairman Art Coviello said that the reason RSA had not disclosed the full extent of the vulnerability because doing so would have revealed to the hackers how to perform further attacks.
In their "defense", keeping it secret might have had more to do with saving their public image than with any belief that it was actually better security.
I don't think so. More a long the lines of not disclosing all the companies who may have had their seed stored as it would provide these intruders with a list of targets to attempt to phish their pins.
> It's taken this long for the RSA Lawyers to allow a public statement
Fixed that for you. Customers were notified and I believe many a secureid token was replaced, at least for all mission critical businesses.
That letter to the public would have been second to the priority of customer notifications, even sony was late in their press release -- carefully wording their response to forgo accepting blame. Since the attack was "thwarted" we can assume that RSA did in fact communicate with these businesses and shared the knowledge of the potential attack.
It's not a "serious problem" like if the fundamental cryptology is flawed or implemented with a level of security through obscurity. The only "serious problem" was storing seeds for some unknown reason. If your seed wasn't stored then you have nothing to worry about, and I can only assume if you were contacted by someone from RSA(personally) than you should probably assume your seed was stored.
One would hope that a business like Lockheed Martin then setup a honey pot to try and gather information on the attackers logging in with these compromised SecureIDs.
> The only "serious problem" was storing seeds for some unknown reason.
I read somewhere else that the seeds are stored by RSA as an additional backup for the customers. In the event that the customer accidentally loses their seed database, it would be a very costly operation to replace all the SecurID hardware tokens.
But... well... they are forced to replace all the SecurID hardware tokens anyway.
> In the event that the customer accidentally loses their seed database, it would be a very costly operation to replace all the SecurID hardware tokens.
It'd be a very profitable operation for RSA, so I doubt this explanation.
I've programmed some for OTP devices. Vasco primarily, but some RSA too. Normally, the OTP algorithm takes two args... a "shared secret" (each customer has a different secret) and the exact date/time. All the fobs and the back-end server know/share the secret.
On the fob thingy, one calculation occurs. The fob can be physical or virtual. So you may have a physical key fob or a virtual software fob for your blackberry, iPhone, Droid, etc. They even work with dumb phones over SMS. Either way, the same calculation occurs. Again, it looks something like this:
So when you push the button on the fob (or just look at it if it's the always on type), it returns an OTP. On the server, the exact same calculation occurs except that it calculates a range of OTPs (in case the time on the fob has drifted... and this does indeed occur). A minute or so worth of calculations. The fob's OTP must fall into the server's calculated range, if not, the OTP will fail and the fob will need to be recalibrated (resync its clock).
So, if this story is true, then the list of customer shared secrets was stolen and whoever has them now knows that company X uses secret Y on their fobs. It's hard to believe that RSA actually had a list matching company names to shared secrets unencrypted. I'm not sure I believe that.
It doesn't matter if it was store unencrypted if they could capture the credentials used to decrypt it. It was previously disclosed that they managed to get credentials and administrator / root level access through large parts of RSA. Do you think that this level of acces would still be unable to access the database?
There is fundamental issue about those kind of tokens. The customer is not able to renew or set the private key (seed in RSA terms) of their tokens. It's a kind of insecure business model where the customer has no control over the tokens and is bound to the security of the supplier (if the supplier is compromised...). There are solutions like Yubikey or other compliant HOTP/TOTP tokens where the customer has the control of the private keys inside the token.
True, but the positive fundamental property of these tokens is that it is very very unlikely that someone ever messes with your device without you knowing it. Which prevents a MITM attack.
But as we've seen that security is only as good as the security on RSA's servers. Imagine if someone more sophisticated had (has?) attacked RSA's servers and avoided RSA becoming aware, how secure would your token be then?
This fundamental situation isn't particularly different from the existing dependences on purchased digital certificates and the lists of trusted vendors that are embedded in PKE-based tools including many browsers.
Indeed. It's rather shoddy engineering if you ask me. Consider that, for example, SSL certs are generated and the private key is never disclosed to the cert authority when purchasing a key. That way only the owner of the SSL cert can actually use it.
Not entirely sure that's correct either. One could use a Hardware Security Module, such as the Thales nShield Connect[1], which will keep the private keys secure (at least in theory).
Yeah, there are known and used alternatives - I'm working on a project right now where the ssl connections terminate at the load balancers. Rooting the web servers won't reveal those private keys. But I also know of many whm/cpanel servers each with dozens of cpanel accounts, around half of which have ssl certs. One ftp password sniffed customer/cpanel account is probably enough to lose root to a whm box, exposing all the local ssl keys...
Yup, that's how it works. The point I was making is that that's the only point of vulnerability, there is no way to gain access to every private key from some central point.
For example, let's say you collected a large amount of https traffic by listening in on wifi hotspots or such like, then you attacked a certificate authority and managed to gain access to everything they have. This would be very bad, but you wouldn't be able to decrypt the traffic you'd recorded because you still wouldn't have each of the private keys used. That's very different from the problem of RSA tokens. Gaining access to RSA's servers resulted in compromising every token. Decentralization is often key to security.
Can anyone compare this to Google's two-factor authentication using the Authenticator App? The app is open source (http://code.google.com/p/google-authenticator/) and the private key(correct?) is provided via a QR scan.
It's the same concept, yes. And if the servers running the Authenticator at Google were hacked this system would likely be broken (but you'd also have much bigger problems)
there's no online component... your phone takes the current time (divided by some value), the secret key, and performs a cryptographic function on it, then the system you're logging into does the same thing and compares the results.
with secureid the secret key is fixed in the hardware (and RSA keep a copy of the key), whereas with Google authenticator you can generate and input the key yourself, so that Google never sees it.
I can confirm that. The app doesn't require any permissions. I rebooted my phone while in flight mode and the Google login via Authenticator code works as expected.
Right, but a compromise of your token for Google's services would not mean your token for your job was compromised as well. You could even generate a new key for each machine you connect to, if you were paranoid enough.
Although RSA were absolutely at fault it seems like a design failure that the seeds cannot be revoked. Give the keys 4 possible seeds and put 3 of them in a safe. Security is about having defence in depth.
This is nitpicky, but shouldn't the title (on Ars I guess, since it was used verbatim) be "was compromised" since this was a one-time data theft that rendered all currently-live SecurID tokens useless?
True, on the other hand there are still 40 million of those tokens out there, which are all compromised and have to be replaced. So that is still very much present tense.
Sources close to RSA tell Ars that the March breach did indeed result in seeds being compromised. The algorithm is already public knowledge.
As a result, SecurID offered no defense against the hackers that broke into RSA in March. For those hackers, SecurID was rendered equivalent to basic password authentication, with all the vulnerability to keyloggers and password reuse that entails.
So they got a lot of the seeds and then were basically down to trial and error, similar to know passwords.
It seems that they were reduced to guessing the PIN's and/or brute forcing them, hence the initial comment from RSA about increasing PIN length.
One would have hoped that the LMC admins would have detected a brute force attack against their RSA servers, I guess they were already infested with keyloggers?
So the seeds are in fact equivalent to a signature made with symmetric keys... If the SecureID card used asymmetric keys with a truly private key, such incident could not have happened.
Using private keys stored in a hardware carried with the owner with a challenge Q&A seems more secure.
The SecureID device S computes S(s,t) without any input from the server the user is authenticating to. t is synchronized time and available to everyone. s is a secret specific to that device. I don't know if it's a shared secret, but the compromise suggests that either it is, or RSA kept the 'private key' part on their servers for convenience.
You're right that a different device S' that received a challenge c from the server and computed S'(c,s,t) could offer more security via public key crypto. But it would take more power (if communicating to the client machine to avoid user transcription of the challenge) or have a more cumbersome UI. I'll bet such devices are already sold.
Hm, defense contractors were attacked, and it's taken so long for RSA to acknowledge the compromise to the rest of the world? It's was most definitely perpetrated by a government, and it's taken so long for them to respond because our government has been assessing the damage.
