RSA SecurID Theft Spawns Speculation on Potential Attack Scenarios
The network of one the world's largest and trusted security firms has been breached, and an unknown amount of information about its popular multifactor authentication technology has been stolen. Customers are worried about what form potential attacks could take.
The SecurID information that was stolen would not allow attackers to launch a successful direct attack on existing SecureID customers, Art Coviello, executive chairman of RSA Security, wrote in an open letter to customers posted on the company's Website March 17. However, the company acknowledged the information could be potentially used to "reduce the effectiveness" of an existing SecurID deployment as part of a broader attack.
With RSA keeping mum about what exactly was stolen, when the data breach occurred, how attackers got into the network and how long the breach lasted, security experts can more or less give their imaginations free reign to suggest potential attack scenarios.
Adam Vincent, CTO of the Public Sector group at Layer 7 Technologies, wondered about the implications of a broader attack hinted at by Coviello. "Reading between the lines," RSA made it sound as if the data theft made RSA SecureID ineffective without needing to compromise any specific usernames or passwords, Vincent told eWEEK.
The "well-organized group" of hackers behind this targeted attack would have to complete "many steps" to successfully attack an organization using SecurID tokens for authentication, Nick Percoco, senior vice president of SpiderLabs, told eWEEK. While it was "less likely" there will be a direct head-on attack, it wasn't impossible, he said.
There were four kinds of possible attack scenarios, according to David Schuetz, a security consultant at Intrepidus Group, a mobile security firm. His scenarios all assume the stolen information is either the seed library or the algorithm used to generate seeds for future tokens, Schuetz wrote on the Intrepidus Group blog.
In the first scenario, attackers obtained a list that showed seed values and token serial numbers. With this information, the attackers can create a software version of the token, according to Schuetz. The imposter software can trick the target system into thinking the generated numeric code is the legitimate one, he said.
Just this information is not sufficient as the attacker will still need the user's PIN code. Some form of social engineering would be required to get that information, according to Schuetz and Percoco.
Schuetz said it could be obtained by somehow viewing the login process, such as a keylogger. Percoco said a targeted phishing attack was also conceivable. The campaign could masquerade as an e-mail from the targeted customer to its users in response to the RSA data breach. The subject line could even be, "Important Action in Response to RSA's Data Breach," which nervous users may be inclined to click on. Once they obtain a PIN, the attackers gain access to the target system, said Percoco.
In fact, regardless of what attackers do with the SecurID data, other scammers may jump on the news to launch their own phishing campaigns to try to steal information about other online services, Schuetz said.
Schuetz said if the stolen list contains information about which seeds belong to which RSA customer, then attackers can focus their attempts to a specific sub-set of their choice. If the list contains only the seeds that have been issued to date and not just every conceivable seed, then the available target becomes even smaller, he said. It also means the attackers have to move before the companies make changes, such as re-issuing new tokens, he said.
Replacing all the tokens would actually be the easiest way to prevent any of these possible scenarios from being successful, according to Schuetz.
Combined with a successful phishing attempt, attackers can compromise systems protected with SecurID, but there is a lot of guesswork still involved in how likely it is that the seed value can be correlated to token serial numbers.
A more significant risk would arise if attackers stole the source code or somehow find a weakness in the method used to generate seeds. This may be as simple as using a weak random number algorithm or using a "master seed" to generate additional seeds, Schuetz said. If that's the case, then both deployed tokens and the existing stock of tokens used for replacement would be compromised he said. In that scenario, RSA would need to change the seed-generation process or the token algorithm itself and manufacture new tokens, he said.
All this is still conjecture, Schuetz warned. Maybe RSA didn't store any seeds, and maybe there are no weaknesses inside the token algorithm. "Until we know more, there's no way to say" what the risk is for the enterprise, Schuetz said.