Intrepidus Group
Insight

The RSA/SecurID Compromise: What is my risk?

Posted: March 18, 2011 – 8:32 am | Author: | Filed under: Cryptography, Risk Analysis | Tags: , , , , , ,

So yesterday, RSA, a security division within EMC and the folks responsible for SecurID, one of the most popular forms of two-factor authentication, announced that they’d been hacked.

What does this mean? Well, we don’t have many details, but the most troubling bit is that apparently the attackers acquired information “specifically related to RSA’s SecurID two-factor authentication products.” In particular, that “this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.”

This is quite troubling. SecurID is used by over 25,000 customers, with an estimated 40 million physical tokens in circulation (in addition to 250 million software-based tokens). Many of these are used for secure authentication to corporate websites and email, and they’ve seen increasing use in online banking. A “reduction in effectiveness” could have very serious, and wide-ranging, consequences.

So what exactly could the attackers have gotten away with? First, a quick review of how SecurID tokens work.

At its core, SecurID is a cryptographic algorithm that produces random numbers in a pre-determined sequence. This sequence is known to an authentication server, and used to validate that the person logging in has the token in their possession. To keep the tokens unique, each is pre-loaded with a seed that initializes the sequence for each token. The resulting 6-digit numbers, or “tokencodes,” are therefore produced in a sequence specific and unique to each token.

This seed is typically 128-bits in length, so there are approximately 500 gagillion (a really really big number) potential sequences that any individual token could produce. Far too many for an attacker to have any practical chance at a brute-force attack.

Where the attack gets scary is if the seeds have been revealed to a third party. While there are many good reasons why RSA should not keep copies of tokens’ initial seeds, there are also some reasons why they might. Ultimately, I believe we’re facing four attack scenarios:

  1. Attackers get a list of seeds and token serial numbers. Then if they are able to acquire the serial number from a target’s token, they can replicate the token in software and use that to impersonate the target.
  2. Attackers get a list of seeds, and the corporations to which they’ve been assigned. This makes the attack a little tougher, but having only several thousand seeds to test is enormously better than having a 128-bit seed to test.
  3. Attackers get a list of all seeds issued thus far. Instead of having several thousand potential seeds to test, they have a few hundred million. Still much better than searching a 128-bit keyspace.
  4. Attackers find some weakness in the method used to generate seeds in the first place. Perhaps it uses a weak random number algorithm. Or maybe there’s a “master seed” that generates new seeds in sequence, just like the tokens itself.

(There’s actually a fifth scenario — internal documentation revealing a known weakness in the algorithm that allows an attacker to derive the key simply by observing multiple tokencodes. Without knowing how their tokencode algorithm works, we can’t know if this is even possible, but it seems exceedingly remote. At least we hope so.)

In all scenarios, the attacker will also need to observe at least one, probably two, tokencodes from the target in order to synchronize their sequence with the target’s token. They’ll need to observe a login anyway, just to get the target’s PIN (which is usually prepended to the tokencode at login).

So what’s the risk to your enterprise? Until we know more, there’s no way to say. If any of the first three scenarios come into play, then the risk for some high-value targets may be reasonably high. Any attacker who can monitor login attempts, perhaps through something as simple as a fake login page, will be able in short order to duplicate the target’s token and authenticate as them. The only way to mitigate that would be to replace all the tokens in circulation.

If the fourth (or worse, fifth) scenario is true, then there’s a much more significant risk to the RSA/SecurID system as a whole. It would compromise not only issued tokens, but every replacement token in stock. It breaks the system, until the seed-generation process, or even the token algorithm itself, can be changed, and new tokens produced.

Ideally, though, RSA won’t have any seeds stored, nor will there be any weakness in the methods used to generate those seeds. If that’s the case, then the worst that could happen is that the token algorithm itself may be leaked. Perhaps study of the algorithm could reveal weaknesses….but that’s a much longer term concern.

There is, however, one last, very likely scenario: Just as with any big-news item, this compromise could open the doors for any of several phishing scenarios. Attackers could certainly capitalize on the uncertainty of what’s happened to trick users into revealing information that would enable a reset of their credentials, regardless of whether they’re even using the SecurID system in the first place. In the long run, this attack could affect far more than just RSA’s customers.

Both comments and trackbacks are currently closed.

11 Comments

  1. HEscalona
    Posted March 18, 2011 at 5:42 pm | Permalink

    I believe that exist other scenario that is related to attacker get access to the backdoor that RSA put for government access inside the products and algorithms and all the complete system can be in danger.

    I still thinking that: If RSA accept a success attack (a company that is alive for security) the real impact must be bigger than the actual acceptation.

  2. jgajek
    Posted March 18, 2011 at 11:18 pm | Permalink

    The algorithm to generate the tokencodes is known to be AES-128. So most likely the breach has something to do with the token seeds. These would almost certainly have been stored in a database by RSA for scalability reasons during token distribution to customers.

    Reflections on Security

  3. Anonymous
    Posted March 19, 2011 at 10:11 am | Permalink

    This information is not correct for every type of token. In fact, most of these token do not produce a specific pre-determined sequence of numbers. What they do is that they perform an operation based on their seed an the current time which they keep using a small battery, and using these two inputs produce a 6 digit number. When the user inputs the number to the authentication server, the server performs the same operation based on his clock (and readjusts it to match the users, or discards the number if not within a 3 minute period for example).

  4. Anonymous
    Posted March 19, 2011 at 10:15 am | Permalink

    And a sixth scenario (similar to the first): What they got may be an algorithm and a master seed used to derive the each token’s seed based on the serial number of the token.

  5. Anonymous
    Posted March 19, 2011 at 10:25 am | Permalink

    A better analysis on the operation of SecureID from a world-renown security professor (Steven Bellovin) http://www.cs.columbia.edu/~smb/blog//2011-03/201

  6. bitexploder
    Posted March 19, 2011 at 11:44 am | Permalink

    To Anonymous regarding the numbers not being predetermined. For any given point in time the token code must be predictable. So, if you were to record a tokencode every second for a given seed it would be the same tokencode stream the server has. The server will know every token code in the future as well due to this. You can pick any specific point in time with a given seed and that token will not change as long as these algorithms are relying on a shared secret and the time as the only two basic inputs. Very basic things about these tokens would not work if the stream were not predictable for a given seed. The seed is the shared secret and magic. After that everything is predictable (but the seed is theoretically very hard to guess).

    Regarding professor Bellovin’s analysis, I feel we were addressing the same concerns for different audiences. We were aiming for a higher level risk analysis this time vs. digging into the technical details.

    Thanks,

    @bitexploder

  7. Posted March 19, 2011 at 4:44 pm | Permalink

    First, thanks for the great responses!

    jgajek: I’ve read that they use AES, but hadn’t seen anything authoritative I could cite. For this analysis, though, the algorithm doesn’t matter — the risks depend on whether seeds were compromised.

    Also, I still don’t see why RSA would need to keep a database of seeds. It’s been argued that they’re necessary in case a customer loses their copies, but that’s why they should have backups. You’ve mentioned scalability, but I’m not sure I follow that. Finally, some might say a list of issued seeds is needed to avoid duplicate tokens, but with a 128-bit space, the chances of that happening are so infitissemally small that I’m not sure it’s even worth protecting against.

    Truth is, if I were an RSA customer, using SecurID to protect high-value systems, I wouldn’t want anyone other than my own people having access to any seed values. Ever.

    Anonymous (1): The algorithm isn’t public, and I don’t know it firsthand, so I felt it wrong to be too specific in how I described it. I’ve seen speculation that it’s time-based, and since “time is an arrow,” the end result will still be a pre-determined sequence of numbers. Further, I don’t know if it’s based on clock time, or simply the time since the token was powered on.

    I didn’t explain my (theoretical) attack in detail, so here’s a quick description:

    1. Observe two consecutive tokencodes, possibly by performing a man-in-the-middle attack, or directing the target to a fake login page. This also gets the attacker the PIN, which they’d need later.

    2. Presume some list of seed values has been compromised. This could be a list of actual issued seeds, or a way to generate them which significantly reduces the valid seed attack space.

    3. For each seed on that list (or reduced seed space), iterate the algorithm forward until you see the two tokencodes recorded in step 1. Set a limit for how far you’ll go forward — a token which changes every 30 seconds would display just over 5.25 million codes in 5 years, so that’s probably a good place to stop.

    4. If you didn’t find the code, go to the next seed, and do it again.

    I’ve personally had tokens “re-synchronized” by providing two consecutive codes to customer support, so that kind of drove my understanding of the system. (Or at least that’s how I recall it — it’s been a while). When activating a new token, a similar step would be performed, essentially, establishing a known good offset between the arbitrary “token time” and real clock time.

    However, if tokens use absolute clock time, then it actually makes the attack easier. In this case, the attackers only need to observe a single tokencode, note the time, and simply try all known seed values against that time value.

    Finally, thanks to Anonymous (3) for the link to Bellovin’s analysis. He pretty clearly explained a lot of what I’ve been thinking, or trying to describe here, but did it in nice, clean, mathematical terms. Unfortunately, he also doesn’t know any more than the rest of us about how the actual algorithm works, nor what data RSA may store on their systems. In the end, though, I believe bitexploder was correct — Bellovin’s analysis is saying the same thing we are, just in different terms, for different audiences.

    Again, thanks for your comments…keep ‘em coming!

  8. Steve
    Posted March 22, 2011 at 10:07 am | Permalink

    For reference, in response to a comment above, RSA state that the algorithm they use is “built upon the Advanced Encryption Standard (AES) algorithm”. http://www.rsa.com/node.aspx?id=3050

  9. jgajek
    Posted March 22, 2011 at 4:38 pm | Permalink

    The reasoning for RSA keeping a database of token seeds is as follows:

    1) The token seeds are truly random, i.e. there is no way to compute them based on any information about the token, customer, etc.

    2) The token seeds are injected into the tokens during production.

    3) The token seeds need to be loaded into the customer’s Authentication Manager server so that it is able to process logins for those tokens.

    4) The tokens need to be distributed to the customer through a third-party vendor, who must not have access to the token seeds.

    It follows that the process must be such that the customer, upon receiving the physical tokens from a third-party vendor, then contacts RSA directly with the serial numbers of the tokens they purchased, and obtains the token seed records from their database.

    At this point, RSA could theoretically delete the token seeds for the customer’s tokens (and apparently can be requested to do so), but most customers do not make that request. Instead, the token records are kept in RSA’s database in case the customer ever needs them again (e.g. to rebuild a crashed authentication server).

  10. incognito
    Posted March 23, 2011 at 6:10 pm | Permalink

    I wouldn’t say it’s better, but it’s lower-level and a nice complement to this discussion. Thanks for the link.

  11. Myguess
    Posted April 5, 2011 at 9:22 pm | Permalink

    I’ll go with #4 – the master seed theory. It seems too tempting to eliminate the need to track millions of seeds. Likely there is no single master seed because that would be stupid. My guess is that there is a new master seed used for every lot manufactured and the list of those seeds are what get stored and what was compromised. Since the hardware tokens are only good for a couple years, assuming the breach has been rectified, that’s how long the bad guys have until the stolen seeds are useless. RSA is advising using good pins and probably just crossing their fingers for the next two years.

4 Trackbacks

  1. [...] countenance that a chairman logging in, indeed has a token in their possession, Intrepidus said in a blog post today [...]

  2. [...] Intrepidus Group published a great overview of the possible impact of this exploit and describing the four or five possible [...]

  3. [...] about it other than it’s a post that looks at the risks of RSA/SecurID being compromised. Click here for more [...]

  4. [...] the constantly changing numeric codes that appear on the device’s display. For instance, in one scenario described by David Scheutz of the Intrepidus Group, the attackers might have found a list of seeds [...]

image

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24731 items have been purified.