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.
Sponsored: Protecting mobile certificates