Search my Blog

Tags

Browse Past Posts

Browse by Topic

♥ Special ♥

Blogroll

Frequently Visited Sites

News, Geek & Security

www.flickr.com
This is a Flickr badge showing public photos and videos from Bruce Westbrook. Make your own badge here.

My Hosting Provider

My most excellent hosting provider since 2002...9 years and counting!

This is not the image you are looking for.


RSA’s Recent Compromise

On Thursday, March 17 RSA published an open letter to their customers. It can be found on their website at http://www.rsa.com/node.aspx?id=3872 and is placed here in its entirety. I highlighted some key points, with the second paragraph being what I found most interesting.

Like any large company, EMC experiences and successfully repels multiple cyber attacks on its IT infrastructure every day. Recently, our security systems identified an extremely sophisticated cyber attack in progress being mounted against RSA. We took a variety of aggressive measures against the threat to protect our business and our customers, including further hardening of our IT infrastructure. We also immediately began an extensive investigation of the attack and are working closely with the appropriate authorities.

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

We have no evidence that customer security related to other RSA products has been similarly impacted. We are also confident that no other EMC products were impacted by this attack. It is important to note that we do not believe that either customer or employee personally identifiable information was compromised as a result of this incident.

Our first priority is to ensure the security of our customers and their trust. We are committed to applying all necessary resources to give our SecurID customers the tools, processes and support they require to strengthen the security of their IT systems in the face of this incident. Our full support will include a range of RSA and EMC internal resources as well as close engagement with our partner ecosystems and our customers’ relevant partners.

We regret any inconvenience or concern that this attack on RSA may cause for customers, and we strongly urge you to follow the steps we’ve outlined in our SecurCare Online Note. APT threats are becoming a significant challenge for all large corporations, and it’s a topic I have discussed publicly many times. As appropriate, we will share our experiences from these attacks with our customers, partners and the rest of the security vendor ecosystem and work in concert with these organizations to develop means to better protect all of us from these growing and ever more sophisticated forms of cyber security threat.

Sincerely,

Art Coviello
Executive Chairman, RSA

Essentially, RSA was infiltrated by an attacker (or attackers, nation state, terrorists, Russian mafia, whoever) for an extended period of time before detection occurred (APT), and certain sensitive information was disclosed.

 

My Analysis:

I’m not sure that a bureaucrat could have been any less clear about something then this statement from RSA.  But given the sensitive nature of the compromise it’s probably the best they could do in such a public forum.  They do point actual customers to the SecurCare Online portal for what seems to be more information – however, I will not release any customer-only provided information here.

Regardless of any additional SecurCare information that could potentially add further detail to my analysis, my initial reaction to this was not a huge concern — regardless that some other technical analysts and so-called experts seemed to start yelling that the sky was falling.  This is based on the simple fact that the very worst a compromise at RSA could do is essentially disclose their entire SecurID mapping database, thereby allowing an attacker to retrieve the “seed” keys to customer tokens — my own included.  That’s the most sensitive information RSA houses regarding their SecurID tokens.  While certainly not something to disregard, this cannot in and of itself provide access to systems – likely the reasoning behind the statements “…the information extracted does not enable a successful direct attack” and “…could potentially be used to reduce the effectiveness of a current two-factor authentication implementation…”.

These “seeds” are the most sensitive part of the SecurID tokens — more so then the RSA algorithm itself (which itself has already been replicated before).  It’s the secret number that would allow an attacker to determine the next rotation of a token’s 6-digit display number, provided they also had at least one past number sequence and the exact date/time of that display.  Is that a bad thing?  In and of itself, lacking any further security layers or controls, the answer most certainly is a resounding — YES.  I believe that’s where some “experts” stopped their analysis and started crying wolf.  However, there are several mitigating factors to its successful use against most systems.  In fact, RSA tokens deployed in their default mode with no further security would still be relatively safe.  Even if an attacker knew what those numbers were and the exact 60-second window they would be good for, they would not know the 4-digit (or greater) PIN code of the user.  The PIN is not stored or even known by RSA – PINs are only known by the user and the specific installation of any given organization’s authentication server (RSA ACE Server).

Of course, an attacker could attempt to brute force the PIN.  While it’s technically feasible that 1 MILLION attempts (the possible number of outcomes based on the 6-digit display tokens — 100 MILLION on the newer 8-digit displays) could be conducted within a 60-second window on powerful dedicated computers, the vast majority of real-world systems could not react or process fast enough for anywhere near that number of attempts to be done within 60-seconds.  Additionally, provided an organization implemented such a basic security measure as account lockouts after X unsuccessful attempts (let’s say 5 bad passwords), the token would lock any access after just 5 attempts.  And finally, even if the attacker were lucky enough to brute force the PIN in those first 5 attempts – they wouldn’t know the user that token was assigned to and therefore don’t have a username to match it to.  The username, like the PIN, is not something that RSA stores or has any knowledge of whatsoever.

On top of all that, some implementations of SecurID tokens are used in conjunction with additional authentication controls.  Take for instance a Cisco IPSec VPN.  In order to use a token to access such a VPN an attacker would also need to have the VPN group credentials – yet another name and passphrase combination that’s used before they are even prompted to provide the SecurID authentication.  Another example would be a remote control or terminal session, such as GoToMyPC.  In that case the attacker would require a second set of authentication credentials — the corresponding user’s email address and passphrase — to login to GoToMyPC, and then yet ANOTHER secret passphrase known only to the user and their specific workstation, at which point they can finally try to brute force the PIN…with just 5 tries.

So as you can see, the mitigating factors that should be place lower the risk to most organizations dramatically.  It would be exponentially easier for an attacker to have physically stolen a SecurID token (thereby at least having a possibility of knowing the username and possibly even the PIN if the user wrote it down and stored it with the token) then to have stolen the “seed” numbers from RSA associated to any given organization.  Let’s even go so far as to say that the user was silly enough to write down their exact username and even their PIN to the token itself, providing the attacker with everything they need to use the SecurID token.  Given additional security measure that should be in place, they still can’t access our systems using the SecurID token alone.

 

Technical Interest

RSA SecurID keys are known to work around a 64-bit secret and unique “seed” cipher (newer tokens may use 128-bit ciphers).  This 64-bit cipher is combined with a 64-bit value for the current date/time via an undisclosed (but not necessarily indeterminable) algorithm, resulting in a pre-converted 64-bit hexadecimal value.  This hex value is in turn processed through a simple transform to output a 6-digit (or 8-digit in newer models) display number that the user sees and uses.

 

Note that the fact that the pre-converted value is actually obfuscated by the transform is a by-product of the process and not directly intended to provide additional security to the SecurID algorithm.

 

 

 

As an interesting sidebar, examination conducted by mathematical experts has shown that the 64-bit time value is itself generated from a 32-bit representation of current time (GMT) in seconds since SecurID epoch time, which is 01/01/86 (Security Dynamics, the creator of SecurID technology, began operations in 1986).  Even then, through some additional mathematical manipulation, current time is further reduced and represented by only 24-bits of the original 32-bits representing seconds from epoch time, and then again by dropping the 2 least significant digits to finally arrive at a 22-bit time value, providing one of 4,194,304 possible time values.

22-bits may not seem like much in 2011, when we are now using 256-bit SSL ciphers.  However, since the 22-bit key is changed every 60-seconds, it’s very effective and still outlasts the expected lifetime of these tokens.  In fact, even for newer 8-digit tokens with a 60-second display interval, it would take ~16 years to cycle through every value.

The “seed” key that we talk about is the secret 64-bit (or 128-bit) cipher.  Now we don’t know much publicly about how these are established and matched to each specific token, but there’s likely one of two ways.  The first is that there is an algorithm based off of each token’s unique serial number that establishes that cipher key (seed).  It’s very unlikely that RSA did something so inane, and given the many bits of information leaked from RSA over the years this is apparently not how it’s implemented, but it is one possibility.

The more likely scenario is that the seed is a random or pseudo-random number generated when the token is manufactured.  RSA then keeps a database that maps every token ever manufactured (via their serial numbers) to their corresponding seeds.

For an attacker to conduct a successful attack, they would need to gain access to the following information for each of the two systems that I used as examples above:

VPN

  1. One of the following:
    • A token seed + one or more 6-digit output displays with their exact corresponding date/time (the more the better in order to narrow the 60-second window down)
      OR
    • A stolen physical token
  2. The corresponding username assigned to the token
  3. The user’s secret PIN for the token
  4. The system the token is used for (VPN IP address or DNS name)
  5. Yet another set of credentials (username + password) to the VPN group credentials of the Cisco VPN itself.

GoToMyPC

  1. One of the following:
    • A token seed + one or more 6-digit output displays with their exact corresponding date/time (the more the better in order to narrow the 60-second window down)
      OR
    • A stolen physical token
  2. The user’s secret PIN for the token
  3. The system the token is used for (GoToMyPC)
  4. The corresponding username (email address) assigned to the token
  5. The user’s password to the GoToMyPC website
  6. Yet another secret passphrase known only to the user and stored only on their workstation (not stored on any other system)

Given the worst-case scenario of an attacker having breached RSA’s serial number to seed database (or even having discovered a universal algorithm that breaks every token), that only provides an attacker with step #1a of both authentication processes in our examples.

 

Final Words:

Now having said all that, I’m certain there are organizations that have implemented SecurID without ANY additional controls in place — and in that case, likely don’t have any monitoring either.  If the seeds to their tokens were disclosed to an attacker, those particular organizations MAY be at risk.  I say MAY because even then, unless the organization has eliminated every default setting (account lockouts, PIN use, etc.) AND  associated the key directly with a user without any corresponding username, the risk is higher but certainly doesn’t provide immediate access.

I would recommend that existing users of RSA tokens indeed follow the RSA guidance that may be provided.  But I take the line that from a technical standpoint the disclosure of the seed database from RSA, while a critical issue of information disclosure, does not provide an attacker with any direct access to systems.

The one caveat I’ll throw out is this — given that the attack was itself an APT (something that, if correctly identified as such by RSA, is an attack postured by nation-states and such) it’s possible that the attacker was looking for specific information within the seed database based on additional information already gathered by the attacker.  In that case, there may certainly be reason for further concern for that particular entity.  In that case…ruh roh.

References:

—————-
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading ... Loading ...

2 Responses to RSA’s Recent Compromise

  1. Jacob Gajek

    Hi Bruce,

    great post and you certainly make some good points. I would like to point out one thing however. You list a number of pieces of information an attacker would need to have in order to exploit a vulnerable SecurID system (user account name, PIN/password, IP address, etc.). These are all examples of “something you know” and can be obtained via standard social engineering or reconnaissance methods. If you consider this single factor authentication to be strong enough, then why go through the trouble and expense of implementing a two-factor system like SecurID? The answer to this rhetorical question may shed some light on why many security professionals consider this a serious breach with potentially significant impact.

  2. Bruce

    Thank you, and I appreciate the feedback!

    If I may respond in kind, let me first acknowledge the fact that I agree with you — from the perspective that all of those bits of information are indeed things a dedicated, targeted attacker could potentially gain knowledge of. The two-factor authentication provided by the RSA SecurID is a strong additional layer of security. The real difference between multiple passwords or “something you know” and “something you have” is simply the need to have multiple attack vectors. Not only do you have to social engineer or otherwise obtain “something a user knows”, but you also have to steal “something they have” and/or pretty much cut off “something they are”. The same argument here could be made if someone ONLY used the SecurID without anything else, as I indicated in my original analysis. It would be reduced to a single-factor and therefore a single attack vector.

    In this case, one of those attack vectors succeeded — essentially obtaining “something you have”. However, that does not mean the entire castle crumbles when the moat is breached. There are still layers of security in place via “something you know” — such as the castle archers (IP address or where that information can be used) to keep attackers well away, the outer wall (corresponding username(s)) and the inner keep (password(s) and potentially additional sets of credentials).

    My point was really an attempt to put some perspective on the issue. After reading a couple other opinions on the matter I felt that some were making claims of the sky is falling and laying blame completely on RSA if/when they or some other customer gets breached. Yes, RSA must take responsibility for their part in the disclosure of highly sensitive information. Yes, RSA should be held accountable for that and make proper amends (replace disclosed tokens, for instance). However, if a customer gets breached on that one disclosure alone — well, they didn’t do their own due diligence with their own security controls, access monitoring, security awareness, etc. And in the end, that’s all on them.

Leave a Reply

FireStats icon Powered by FireStats