Attack of the clones: Researcher pwns SecureID token system
But RSA claims it would only work on rootkit-compromised gear
Analysis RSA Security has downplayed the significance of an attack that offers a potential way to clone its SecurID software tokens.
The attack, developed by Behrang Fouladi, senior security analyst at SensePost, offers a potential way to defeat the hardware binding and copy protection embedded in RSA's software. Having defeated this protection, Fouladi was subsequently able to copy across sensitive parameters, including the all-important encryption seed value and other data associated with a particular software token. This allowed him to run a second cloned instance of a software token on a separate system.
In a demo, Fouladi set up two separate windows XP virtual machines, one running a cloned copy of the authentication software and the other the original software token. Both were cycling through the same sequence of eight-digit numbers.
However a senior RSA Security exec said that, in practice, the attack would only work on a PC already compromised by a rootkit. Given this level of compromised access, an attacker could more or less do anything they'd like anyway, the exec argued.
Essentially, RSA is saying that the attack is possible only with complete control, via a rootkit, or with physical access. But Fouladi disputes this, and says common or garden malware, launched remotely, would be enough.
The science bit
RSA's SecurID two-factor authentication system is widely used for remote access logins to corporate networks through virtual private networks (VPNs) and other similar applications. Users log into corporate networks using a password known only to them as well as a temporary token code, generated by a hardware or software token. This token code, which changes every 60 seconds or so, is derived from a secret seed value cycled through a cryptographic algorithm.
The AES-based code generation algorithm used is known, so the security of the system depends on keeping seed values – which are different for every token – secret.
RSA SecureID software tokens are available for a wide range of smartphones and Windows desktops.
Fouladi focused on the Windows version of the technology, which (like smartphones) he reasoned would not be able to provide the level of tamper-resistance that hardware tokens offer. Sure enough he discovered a means to clone a SecurID software token after reverse-engineering Windows' versions of RSA's technology. He extracted secret keys from an encoded SQLite database after circumventing copy protection and hardware binding protections. This key step was accomplished, in part, by taking advantage of previous research, as Fouladi explains.
Previous research on the Microsoft Windows DPAPI internals has made offline decryption of the DPAPI (Data Protection Application Programming Interface) protected data possible. This means that if the attacker was able to copy the RSA token database file along with the encryption master keys to their system (for instance by infecting a victim's machine with a rootkit), then it would be possible to decrypt the token database file on their machine.
He was subsequently able to get an extracted seed working on another machine, in part using a combination of the host name and current user's Windows security ID from the primary box. The process allowed him to run a sequence generator and generate valid codes on the second machine.
Software tokens are supposed to be tied to a particular piece of hardware. Cloning would break this security model wide open.
If an attacker gains access to a machine inside a corporate network, using spear phishing and malware, he might be able to lift SecurID software tokens, gaining compromised access to a SecurID-protected network in the process. Other attack scenarios featuring direct access to stolen machines by thieves or mendacious hotel staff are also possible.
Fouladi has published his research, including a proof-of-concept demo, in a blog post entitled "A closer look into the RSA SecureID software token" here .
Governments, spies and military goons: Be warned
The research has potentially important implications for the safekeeping of tokens, in particular, and the security of two-factor authentication, in general.
Government agencies, military contractors, and numerous enterprises use the technology to safeguard remote access. In subsequent posts, Fouladi makes it clear that what he has demonstrated is not a complete end-to-end attack. Rather he says the research points towards the need towards using "trusted platform module" (TPM) bindings, which associates the software token with the TPM chip on a target system.
Scrutiny about the security of two-factor authentication in general, and RSA in particular, has grown since a raid on RSA's network  that led to the theft of sensitive SecurID-related information in March 2011. Information used in this hack was subsequently used in an unsuccessful attack against Lockheed Martin, the defence contractor has confirmed. RSA offered replacement token or free security monitoring services to reassure key customers in the wake of the incident.
RSA has yet to speak to Fouladi directly but has gone through his research since its publication last Thursday.
Dan Schiappa, senior vice president of identity and data protection group at RSA Security, told El Reg that the attack outlined by Fouladi would only work on a "fully compromised machine" where an attacker has "kernel level" access at which stage that stage "all bets are off", as he put it.
"Fouladi hasn't shown any exploit against SecurID soft tokens – this is an exploit against Windows itself," said Schiappa, adding "he's not connecting all the steps together" so that the attack remains "theoretical".
RSA Security's best practice guidelines for software tokens require user entry of a PIN to protect the key as a additional security measure. Schiappa conceded that this PIN might be captured by a keystroke logger but repeated his assurance that Fouladi's research had not exposed any product bug and that users of RSA authentication technology ought to be safe, especially if they follow its best practice guidelines.
Fouladi told El Reg took issue with this assessment and said that the attack "can be launched remotely and does not require a 'fully compromised machine' as RSA have stated".
"Our aim at SensePost was to demonstrate how easy/hard it would be for an attacker, who has already compromised a system, to extract RSA token secrets and clone them on another machine," he explained. "A number of people commented on the fact that we did not disclose the steps required to update the LSA [Local Security Authority] secrets on the cloned system. Whilst this technique is relatively easy to do, it is not required for this attack to function."
"If a piece of malware was written for this attack, it does NOT have to grab the DPAPI blobs and replicate them on the attacker's machine. It can simply hook into the CryptUnprotectData and steal the decrypted blobs once the RSA software token starts execution. The sole reason I included the steps to replicate the DPAPI on another machine was that this research was performed during a real world assessment, which was time-limited. We chose to demonstrate the attack to the client by replicating the DPAPI blobs instead of developing a proof of concept malcode.
"A real-world malware targeting RSA software tokens would choose the API hooking method or a similar approach to grab the decrypted seed and post it back to the attacker," he concluded.
SensePost's research has implications for the two-factor authentication software tokens on smartphones or tablets, which might actually prove more difficult to crack than their Windows desktop equivalents.
"The 'Token Binding' bypass attack would be successful on these devices, but with a different device serial ID calculation formula," Fouladi explained. "However, the application sandboxing model deployed on most modern smartphone operating systems would make it more difficult for a malicious application deployed on the device to extract the software token's secret seeds.
"Obviously, if an attacker has physical access to a device for a short time, they would be able to extract those secrets. This is in contrast to tamper-proof hardware tokens or smart cards, which by design provide a very good level of protection, even if they are in the hands of an attacker for a long time," he concluded. ®