Researchers Can Generate RSA SecurID Random Numbers Flawlessly

← Back to Stories (view on slashdot.org)

Researchers Can Generate RSA SecurID Random Numbers Flawlessly

Posted by Soulskill on Tuesday May 22, 2012 @06:12AM from the everybody-needs-a-hobby dept.

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."

10 of 98 comments (clear)

Min score:

Reason:

Sort:

Not exactly... by Anonymous Coward · 2012-05-22 06:16 · 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.
1. Re:Not exactly... by fuzzyfuzzyfungus · 2012-05-22 06:58 · Score: 5, Informative
  
  My understanding is that the two schemes are the same. The software version is just the cheap-n-lazy implementation for people who don't want to deal with airgapped hardware tokens.
  
  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.
2. Re:Not exactly... by chrb · 2012-05-22 07:02 · Score: 4, 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.
3. Re:Not exactly... by datajack · 2012-05-22 10:24 · 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.
Summary is somewhat misleading by supersat · 2012-05-22 06:23 · Score: 4, Informative

This applies to software tokens only.
Misleading title by Anonymous Coward · 2012-05-22 06:26 · 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? by noc007 · 2012-05-22 06:29 · Score: 3, 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.
1. Re:Isn't this old news? by LordLimecat · 2012-05-22 06:41 · Score: 4, 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.
  Basically, they also need the seed, which is the problem being tackled here.
Re:Suuuuure it's random by YodasEvilTwin · 2012-05-22 06:32 · Score: 4, Informative

This has nothing to do with randomness. For example, you could use numbers that are random (or as good as random) by sampling background radiation and still run into the same issue. The problem lies in the fact that those samples need to be shared. You can't log in if the server isn't using the exact same number sequence as your token. The seed provides the means to get the number sequence; replacing the seed with the data from your radiation sampler might be good in that it's probably harder to hackers to access, but it doesn't change the fundamental nature of the issue.
Re:Suuuuure it's random by JoeMerchant · 2012-05-22 06:41 · Score: 3, 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.