Researchers Can Generate RSA SecurID Random Numbers Flawlessly 98
Fluffeh writes "A researcher has found and published a way to tune into an RSA SecurID Token. Once a few easy steps are followed, anyone can generate the exact numbers shown on the token. The method relies on finding the seed that is used to generate the numbers in a way that seems random. Once it is known, it can be used to generate the exact numbers displayed on the targeted Token. The technique, described on Thursday by a senior security analyst at a firm called SensePost, has important implications for the safekeeping of the tokens. An estimated 40 million people use these to access confidential data belonging to government agencies, military contractors, and corporations. Scrutiny of the widely used two-factor authentication system has grown since last year, when RSA revealed that intruders on its networks stole sensitive SecurID information that could be used to reduce its security. Defense contractor Lockheed Martin later confirmed that a separate attack on its systems was aided by the theft of the RSA data."
Not exactly... (Score:5, Informative)
"When the above has been performed, you should have successfully cloned the victim's software token and if they run the SecurID software token program on your computer, it will generate the exact same random numbers that are displayed on the victim's token," Fouladi wrote.
Good job leaving the word software out of the summary there in the /. lead in.
Summary is somewhat misleading (Score:5, Informative)
Misleading title (Score:2, Informative)
and they aren't doing it by reverse engineering RSA software, but rather exploiting windows API's.
Isn't this old news? (Score:4, Informative)
DNRTF
If it's about figuring out the algorythm used by their SecureID fobs, this is old news. At the last job during a PCI audit, the auditor was showing off the pen test tools he downloaded for free off the net. I think it was Cain and Able had a tool that did this; as long as you knew the serial numbers on the back (a brief amount of physical access or social engineering) it would report back the six digit number the fob was displaying. Obviously you still need the other parts of the credentials, but the algorithm used by the fob was already broken.
Comment removed (Score:5, Informative)
Re:Isn't this old news? (Score:5, Informative)
The token generation algorithm uses essentially two parameters: the key fob serial number and a token activation key; each of them are usually provided by the vendor in *.XML files.
From here [www.oxid.it].
Basically, they also need the seed, which is the problem being tackled here.
Re:Suuuuure it's random (Score:4, Informative)
Solved with public/private key pairs (long ago), short version:
Server publishes public key and has internal copies of its private key and all authorized users' public keys.
User wants to authenticate, server challenges with a unique nonce (sampled from background radiation, or whatever) authenticated with server's private key if you're paranoid.
User responds with self-authenticated version of the nonce, possibly encoded with server's public key for good measure.
The only hole is key control, which is where the two+ factor stuff starts playing in.
Re:Not exactly... (Score:5, Informative)
Honestly, what makes me nervous about this is not the fact that, shocking!, software can be reverse engineered; but that RSA seems to mix a disconcerting amount of laziness and hubris in with their competent math.
As best we currently know, it is Not Possible to deduce subsequent token outputs merely given access to previous token outputs. However, it is trivial to do so given access to the seed value. And yet, RSA's last big security fuckup was because they weren't purging seed values for tokens sold to customers. And now it turns out that their software 'tokens' retain their seed values in local storage forever.
Way to let a desire for convenience drag defeat from the jaws of victory, guys.
Re:Not exactly... (Score:5, Informative)
They're cloning the software token, not breaking the scheme that the hardware uses.
The algorithm that the software and hardware implement is the same. What has been done here is to show that the software mechanisms in place to protect the token file under Windows can be broken, despite the claims of RSA:
This file can be viewed by any SQLite database browser, but sensitive information such as the checksum and seed values are encrypted. RSA documentation states that this database file is both encrypted and copy protected: “RSA SecurID Software Token for Windows uses the following data protection mechanisms to tie the token database to a specific computer:
* Binding the database to the computer's primary hard disk drive
* Implementing the Windows Data Protection API (DPAPI)
These mechanisms ensure that an intruder cannot move the token database to another computer and access the tokens. Even if you disable copy protection, the database is still protected by DPAPI.”
So if the RSA software token is installed on a Windows PC, and you can access that PC (remotely or physically), then you can copy the token; the result is the same as having cloned a person's hardware token.
Re:Not exactly... (Score:5, Informative)
The server cannot 'recover' the seed from the serial number.
When you buy hardware tokens, you are supplied with a copy of the seeds, associated with the token serial numbers, to import into the server. The SecurID scheme is time based. What is recovered through supplying the serial number and two token-codes (combined with the existing knowledge of the seed) is the current state of the token's internal clock.
The serial number printed on the back of the token is NOT the seed. It is not (to the best of my knowledge and trust in RSA) related to the seed in any way other than the mapping held in the database of the server.
This story is purely sensationalist. The SecurID algorithm has been known for a long time, that token codes can be generated when the seed is somehow compromised is a non-issue. That a software token seed can be recovered given full access to the host is also obvious to anyone reasonably aware of the realities of cryptography.