RSA Finally Admits 40 Million SecurID Tokens Have Been Compromised

Outsmart Malicious Hackers


Well we did say assume SecurID was broken back in March when we wrote – RSA Silent About Compromise For 7 Days – Assume SecurID Is Broken.

With the recent news Lockheed Martin Hacked – Rumoured To Be Linked to RSA SecurID Breach and another US Military sub-contractor compromised through SecurID tokens – RSA have FINALLY come clean about it.

They basically have to replace all 40 million SecurID tokens out there, imagine how much of a headache that is going to be – and how much is it going to cost? This is going to end up as one hell of a costly hack for RSA.

RSA Security is to replace virtually every one of the 40 million SecurID tokens currently in use as a result of the hacking attack the company disclosed back in March. The EMC subsidiary issued a letter to customers acknowledging that SecurID failed to protect defense contractor Lockheed Martin, which last month reported a hack attempt.

SecurID tokens are used in two-factor authentication systems. Each user account is linked to a token, and each token generates a pseudo-random number that changes periodically, typically every 30 or 60 seconds. To log in, the user enters a username, password, and the number shown on their token. The authentication server knows what number a particular token should be showing, and so uses this number to prove that the user is in possession of their token.

The exact sequence of numbers that a token generates is determined by a secret RSA-developed algorthm, and a seed value used to initialize the token. Each token has a different seed, and it’s this seed that is linked to each user account. If the algorithm and seed are disclosed, the token itself becomes worthless; the numbers can be calculated in just the same way that the authentication server calculates them.

What bothers me, from a cryptography stand-point at least, is that RSA should not know or even be able regenerate the seed and associated token value for their clients.

And along side that, surely SecurID is used as a part of a two or three factor authentication system, so what happened to the other factors in these hacks? Why were they so easily compromised once the hackers could generate the token values?

It just amazes me how these security related companies (with military information) can be so lax on security. Even if the token failed – no one should have been able to get in!


This admission puts paid to RSA’s initial claims that the hack would not allow any “direct attack” on SecurID tokens; wholesale replacement of the tokens can only mean that the tokens currently in the wild do not offer the security that they are supposed to. Sources close to RSA tell Ars that the March breach did indeed result in seeds being compromised. The algorithm is already public knowledge.

As a result, SecurID offered no defense against the hackers that broke into RSA in March. For those hackers, SecurID was rendered equivalent to basic password authentication, with all the vulnerability to keyloggers and password reuse that entails.

RSA Security Chairman Art Coviello said that the reason RSA had not disclosed the full extent of the vulnerability because doing so would have revealed to the hackers how to perform further attacks. RSA’s customers might question this reasoning; the Lockheed Martin incident suggests that the RSA hackers knew what to do anyway—failing to properly disclose the true nature of the attack served only to mislead RSA’s customers about the risks they faced.

I’m fairly sure we’re going to hear more about this, and I wouldn’t be surprised if we start seeing some lawsuits from disgruntled clients of RSA popping up. It seems like RSA went the security through obscurity route – rather than responsible disclosure and letting everyone what was going on.

They thought they could protect against hackers…by not saying anything?

Seriously RSA, is that the best you’ve got? The recent compromises of US military contractors proves that that tactic didn’t work at all (unsurprisingly).

Source: ars technica

Posted in: Cryptography, Exploits/Vulnerabilities, Legal Issues

, ,


Latest Posts:


BootStomp - Find Bootloader Vulnerabilities BootStomp – Find Android Bootloader Vulnerabilities
BootStomp is a Python-based tool, with Docker support that helps you find two different classes of bootloader vulnerabilities and bugs.
Google Chrome Marking ALL Non-HTTPS Sites Insecure July 2018 Google Chrome Marking ALL Non-HTTPS Sites Insecure July 2018
Google is ramping up its campaign against HTTP only sites and is going to mark ALL Non-HTTPS sites insecure in July 2018 with the release of Chrome 68.
altdns - Subdomain Recon Tool With Permutation Generation altdns – Subdomain Recon Tool With Permutation Generation
Altdns is a subdomain recon tool in Python that allows for the discovery of subdomains that conform to patterns. The tool takes in words that could be present in subdomains under a domain (such as test, dev, staging) as well as takes in a list of subdomains that you know of.
0-Day Flash Vulnerability Exploited In The Wild 0-Day Flash Vulnerability Exploited In The Wild
So another 0-Day Flash Vulnerability is being exploited in the Wild, a previously unknown flaw which has been labelled CVE-2018-4878 and it affects 28.0.0.137 and earlier versions
dorkbot - Command-Line Tool For Google Dorking dorkbot – Command-Line Tool For Google Dorking
dorkbot is a modular command-line tool for Google dorking, which is performing vulnerability scans against a set of web pages returned by Google search queries in a given Google Custom Search Engine.
USBPcap - USB Packet Capture For Windows USBPcap – USB Packet Capture For Windows
USBPcap is an open-source USB Packet Capture tool for Windows that can be used together with Wireshark in order to analyse USB traffic without using a Virtual Machine.


3 Responses to RSA Finally Admits 40 Million SecurID Tokens Have Been Compromised

  1. Bogwitch June 7, 2011 at 12:53 pm #

    Without knowing details of the attack on LM, I can only guess how the other factor(s) were obtained.
    The usual implementation of RSA tokens is the usual username/password combination, followed by a PIN finally followed by the RSA generated code.
    Once the attackers had the code & seed information from the RSA hack, they would still need to get hold of the username/password/pin elements to effect an intrusion. I would guess that these details were obtained via a phishing attack. It does raise the question as to whether the mere existence of the 2FA caused the users at LM to rely on the security afforded to them, causing them to be more relaxed with the other elements making them more susceptible to a phishing attack.

    Like I said, I’m only guessing. There may be more to this than we are being told but the lesson to be learned here is that passwords should be protected, no matter what other mechanisms are in place.

    • Darknet June 7, 2011 at 4:00 pm #

      My thoughts exactly, when people have a hardware token they get the whole ubersecure superman vibe and are much more slack with their passwords and password policy. As demonstrated here, that should never be the case and the organisations should ensure that with strict infosec policies.

      • Bogwitch June 7, 2011 at 11:55 pm #

        it astonishes me that a company with the supposed pedigree of RSA did not disclose this information sooner.
        I can only guess (again) that they were hoping that the hackers could not figure out how to launch an attack using the information they gained. Bearing in mind how targeted that attack was, it seems unlikely that the hackers were amateurs.
        The lesson RSA should learn:
        “NEVER underestimate your opponent” – Sun Tzu

        Some of the negative comments on Twitter I’m currently seeing suggest RSA are in for a rocky time. Glad I’m not a shareholder.