Slashdot Mirror

← Back to Stories (view on slashdot.org)

Researchers Can Generate RSA SecurID Random Numbers Flawlessly

Posted by Soulskill on 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."

7 of 98 comments (clear)

  1. Not exactly... by Anonymous Coward · · 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 · · 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 · · 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 · · 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.

  2. Summary is somewhat misleading by supersat · · Score: 4, Informative

    This applies to software tokens only.

  3. Re:Suuuuure it's random by YodasEvilTwin · · 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.

  4. Re:Isn't this old news? by LordLimecat · · 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.