In-Depth
Analysis: RSA SecurID Token Vulnerabilities Back in the Spotlight
The other shoe finally dropped in the case of the SecurID data breach at RSA. Could the fallout have been avoided?
The other shoe finally dropped in the case of the SecurID data breach at RSA Security Inc. Was the fallout preventable?
In late May, at least three prominent defense contractors -- Lockheed Martin, Northrop Grumman, and L3 Communications Holdings -- were targeted by cyber-attacks according to several media reports.
Security experts conjecture that crackers used cloned RSA SecurID tokens to attack L3 Communications; media reports suggest that cloned RSA SecurID tokens were likely used in an attack that struck Lockheed Martin one week earlier.
Back in March, attackers managed to steal an internal RSA database that contained information about the serial numbers associated with specific SecurID tokens. The database was believed to match the serial number of a specific token with the specific master "seed" used to generate its key.
If an attacker could then match the serial numbers of a specific token with the respective company in which it was being used, the attacker could conceivably "clone" a SecurID credential that could be used to gain unauthorized access to a system.
That appears to be just what happened in all three attacks. It's likely that the companies targeted last month won't be the last, either.
"There have been malware and phishing campaigns in the wild seeking specific data linking RSA tokens to the end-user, leading us to believe that this attack was carried out by the original RSA attackers. Given the military targets, and that millions of compromised keys are in circulation, this is not over," wrote Rick Moy, CEO of security testing specialist NSS Labs Inc., on his blog.
In a report issued two months ago, immediately following RSA's disclosure that its SecurID token system had potentially been compromised, NSSLabs predicted just such an outbreak, Moy pointed out.
"One or several RSA clients are likely the ultimate target of this attack. Military, financial, governmental, and other organizations with critical intellectual property, plans and finances are at risk. ... NSS Labs expects a string of breaches stemming from this event," the report (RSA Breach) predicted.
Tough but Not Impossible
Once it disclosed the breach, RSA advised clients to safeguard the serial numbers of their SecurID tokens.
If an attacker wanted to clone a SecurID token, after all, the attacker would first have to figure out where that token was being used. If an attacker wanted to target a specific RSA customer -- or (as was the case) an RSA customer in a specific vertical -- the attacker would first have to obtain at least a few of the serial numbers associated with a few of the tokens used in these environments.
The attacker would also have to know a user's PIN, as well as the timesync of the SecurID server being exploited. (In addition to using a unique token seed, the SecurID algorithm also uses the time of day, plus or minus one minute, to generate its response. In this regard, an attacker would have to know the timezone of the SecurID system being authenticated.)
The attacker would encounter other issues, too, such as being constrained by the access level of the user being impersonated; to gain root-level access to a system at the Pentagon, for example, an attacker would need to know the specific serial number (and PIN) of a key that's assigned to a user with root-level privileges. It doesn't necessarily have to be that hard, of course.
According to Mark Diodati, a research vice-president with market-watcher Gartner Inc., SecurID customers themselves are often careless with sensitive information -- including, shockingly, the very master seeds that were stolen from RSA.
"[T]he attack vector that organizations dismiss at their peril is the on-premises secure storage of the token information. I have seen many seed record CDs ... on the desks of system administrators or sitting on top of the SecurID server. Also, the token information can be retrieved out of the server by the knowledgeable SecurID system administrator," Diodati wrote in a blog entry.
Instead of simply safeguarding their token serial numbers, Diodati argues, customers should demand that RSA issue them new tokens, generated after the March breach. Diodati stops short of saying so, but his implication is that RSA should have moved to do just that after it disclosed the breach.
"[T]he real damage is limited to the token information that was stolen. In other words, tokens created by RSA after the attack should not be vulnerable, assuming that RSA's new precautions are effective," he writes.
Some More Vulnerable Than Others
Rich Mogull, analyst and CEO with security researcher Securosis Inc., offers a pragmatic take on the recent RSA attacks.
First, he notes, they don't appear to have been successful -- at least in the case of Lockheed Martin, which suggests that RSA's initial recommendations -- e.g., safeguarding token serial numbers, changing PINs, protecting against phishing, monitoring system logs for unusual events -- were, to a degree, sufficient.
"I don't think the attacks were successful," Mogull wrote on the Securosis blog, stressing that -- in the case of Lockheed Martin (which turned off remote access for its telecommuting employees) -- "it's only prudent to yank remote access and swap out tokens."
The salient point, he argues, is that the late-May attacks almost certainly weren't the exploits of a conventional cracker or cracking group. They were the product of international intrigue.
"Only the party which breached RSA could initiate these attacks. Countries aren't in the habits of sharing that kind of intel with random hackers, criminals, or even allies," wrote Mogull on his company blog. "These breach disclosures have a political component, especially in combination with Google [Inc.] revealing that they stopped additional attacks emanating from China,"
Although it's naïve to suggest that companies that don't compete in sensitive verticals have nothing to worry about, it's likewise the case that companies that do compete in sensitive verticals -- such as the defense industry -- have more to worry about than others. Every SecurID customer needs to be vigilant, Mogull argues; customers in sensitive verticals need to be the most vigilant of all.
"If you are an RSA customer you need to ask yourself whether you are a target for international espionage. All SecurID customers should change out PINs, inform employees to never give out information about their tokens, and start looking hard at logs. If you think you're on the target list, look harder," he writes.