What does Coviello's RSA breach letter mean?
After spending a while crowing about the ChoicePoint breach, I decided that laughing about breaches doesn’t help us as much as analyzing them. In the wake of RSA’s recent breach, we should give them time to figure out what happened, and look forward to them fulfilling their commitment to share their experiences.
Right now we don’t know a lot, and this pair of sentences is getting a lot of attention:
Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.
With the exception of RSA and its employees, I may be one of the best positioned people to talk about their protocols, because a long time ago, I reverse engineered their system. And when I did, I discovered that “The protocol used by Security Dynamics has substantial flaws which appear to be exploitable and reduce the security of a system using Security Dynamics software to that of a username and password.” It’s important to note that that’s from a 1996 paper, and the flaws I discovered have been corrected.
I’ve been trying to keep up with the actual facts revealed, and I’ve read a lot of analysis on what happened. In particular, Steve Bellovin’s technical analysis is quite good, and I’d like to add a little nuance and color. Bellovin writes: “Is the risk that the attackers have now learned H? If that’s a problem, H was a bad choice to start with.” In conversations after I wrote my 1996 paper, it was clear to me that John Brainard and his engineering colleagues knew that. (Their marketing department felt differently.) RSA has lots of cryptographers who still know it.
The nuance I’d like to point out is that many prominent cryptographers had reviewed their system before I noticed the key management error. So it’s possible that that lesson leads to the statement that the information could be used. That is, the crypto or implementation, however aware of Kerkhoffs’ Principle, could still contain flaws.
If someone had compromised the database of secrets that enable synchronization, then that would “enable a successful direct attack on” one or more customers. So speculation that that’s the compromise cannot be correct without the CEO of a publicly traded company lying in statements submitted to the SEC. That seems unlikely.
But there’s another layer of nuance, which we can see if we read the advice RSA has given their customers. When I read that list, it becomes apparent that the APT used a variety of social engineering attacks. So it’s possible that amongst what was stolen was a database of contacts who run SecurId deployments. That knowledge “could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack”
My opinion is that social engineers using the contacts database in some way is more likely than a cryptanalytic attack, and a cryptanalytic attack is more likely than a compromise of a secrets database. But we don’t know. Speculating like mad isn’t helping. Maybe I shouldn’t even post this, but the leaps of logic out there provoke some skeptical thinking.
[update: some great comments coming in, don’t skip them.]
[Update 2: Between Nicko’s comment on the new letter, and Paul Kocher’s analysis in his Threatpost podcast I’m not sure that this analysis is still valid.]
Adam:
Interesting take. I am not among those who think the seed DB has been stolen. If it had, I would expect it to be considered a material event. I’d love to hear someone with expertise in that area opine on this question – I think we’ve gone as far as we can about the technical/engineering aspects, given the sparse facts available.
Great post! I am one who thinks that the seed DB has been stolen, or at least that RSA is not sure if it was compromised or not. If they were confident, then RSA would have stated that clearly to limit the reputation damage.
I also am looking forward the commitment to sharing the experience – there are some very important lessons for many people to learn out of this.
IIRC, you need the serial number of the token and a pin to sync the token to the server. If they stole a list of serial numbers and the companies they were assigned to, maybe they don’t need the physical (or software) token anymore and therefore RSA is warning about social engineering for PIN resets (which used to happen frequently when I managed a SecurID implementation in late 90’s).
>When I read that list, it becomes apparent that the APT used a variety of social engineering attacks.
@adam: The list looks more like RSA marketing collateral than actionable information to mitigate the impact of the specific breach that RSA suffered. You could almost tie the purchase of a specific RSA product to many items in the list. Overall the laundry list of recommendations is generically applicable to the security program of any organization. There has been absolutely no substance in RSA’s communications to their customers, who for the most part are IT or infosec professionals that possibly expect more precise and unambiguous guidance.
“If someone had compromised the database of secrets that enable synchronization, then that would “enable a successful direct attack on” one or more customers.”
If the seeds database had been stolen then for an attack to be successful you still need to know both the username-serial number mapping and the user’s PIN. As such I don’t think that such a breach in itself enables a successful direct attack. In the case of the ‘dumb’ tokens without a PIN pad, if the attackers can keystroke log the target user then they can get the PIN and an instance of the OTP. Coupled with a timestamp on the log they could then run a computationally intensive search to see which seeds might have produced this OTP around that time. If you capture a few such OTP values then you might be able to narrow it down to the right seed, at which point you can impersonate the user. I’d say that if use of the database requires either key-looging and heavy crypto or getting brief access to the token (to see the serial number) and shouldering the user’s PIN, then I think it’s fair to say that “this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.”
As someone who does not describe himself as a crypo-expert, I really appreciate when such people can offer up opinions and speculation on what may be happening.
I’m with Ivan. Right now RSA is not giving me enough information to say anything meaningful to my boss other than it sounds kinda serious, but not an entirely sleep-depriving issue, yet. All those steps are just same-old ‘best practices’ that neatly enough fit into RSA’s security offerings and other recommended behaviors.
If it can happen to RSA, it can happen to anyone. I think this may be one of the very few high-profile attacks I can finally really get behind with that statement… (Granted, I don’t work for them or know anything about their internal org-workings.)
[Damn WordPress. It totally destroyed my comment above. I’ll try that again. Adam, feel free to delete the last try.] [“It has been sent to the memory hole” – Editor]
FWIW, the latest missive from RSA (released yesterday) includes the following paragraph:
“RSA SecurID technology continues to be a very effective authentication solution. *** Whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers. *** We have provided best practices so customers can strengthen the protection of the RSA SecurID information they hold.”
It seems to me that ***this statement*** is more consistent with a leak of the serial number to seed mapping database that it is with a leak of the hash function source code. Since the only additional information held by their customers are which token belongs to which user and what their PINs are, it seems increasingly likely that it is not just source code that has been compromised.
Under the now-likely assumption that the token seed records have been compromised, I’ve written up some threat-specific detection and prevention practices: RSA SecurID Authentication Security