Some Random Thoughts On RSA Breach

Last Updated on April 10, 2011

Security tokens from RSA Security designed as ... — Image via Wikipedia

June 7 Update: RSA admits some stolen seeds were used to attack Lockeed Martin and will replace SecurID tokens for customers with concentrated user bases typically focused on protecting intellectual property and corporate networks.

May 31 Update: Wired reports that L-3, a Second Defense Contractor, has been targeted by an attack using information stolen during the RSA Breach

May 28 Update: Other Random Thoughts after Several Sources reported that Lockeed Martin the “largest U. S. Defense contractor” was presumably hit by an alleged attack led by mean of compromised seeds.

Some days have passed since the RSA breach, but the echo has not yet gone. Maybe RSA did not contribute efficiently to suppress rumors as, in the meantime, has continued to issue ambiguous advices to its customers, and, more in general to the infosec community. Only few days ago a post from the Company has explained some more details about the breach. According to the above mentioned post written by Uri Rivner, RSA Head of New Technologies, the breach was due to an APT (Advanced Persistent Threat) exploiting a zero-day Adobe Flash vulnerability (CVE-2011-0609) embedded into an excel spreadsheet attached to an email from an appealing subject “2011 Recruitment Plan”. The poisoned file injected a RAT (Remote Access Tool) used by the attackers to gain privileges and move freely into the network up to the final target.

Curiously, the subject was so appealing to convince some users to recover it from the quarantine folder: to lure victims through pecuniary topics is a consolidated method of cyber scam at all levels, and RSA has not made exception in this circumstance.

This attack deserves much attention from the infosec community as we are used to think to multi-layer protection technologies but too often forget that the individuals are the first (and weakest) layer of defense, hence also the best technology, even that from a primary manufacturer as RSA is, risks to be very little useful, or even useless, if not supported by an adequate education of users. Phishing is considered an old attack method, mainly used in the past to lure individuals. Today its combination with 0-day vulnerabilities is proving to be a devastating weapon for Cybercrime targeting enterprises. (It is not a combination that also the Night Dragon Attack, maybe amplified by McAfee Marketing in response to the attention gained by its eternal competitor Symantec for the role played in the identification of Stuxnet, was initiated by a some phishing emails). Is this the reason why, on April the 1^st, RSA decided to acquire NetWitness, a company whose technology, as stated in the press release:

provide precise and pervasive network visibility, enabling security teams to detect and remediate advanced threats while automating the incident investigation process.

Without invoking philosophical considerations, the main question is: are secureID users really safe or do they need to worry about their level of security after the breach?

My opinion is that the RSA breach was conceived as the final stage of a large scale attack to a wide organization making use of RSA tokens, since in most cases (we should hope in all cases), the alleged stolen information, alone, is not enough to perpetrate a successful attack unless the RSA breach was not preceded by other attacks perpetrated by the same author(s) aimed to steal the missing piece of the puzzle.

Taking a step back, on March, the 17^th when the breach was announced, the open letter on the RSA web site, stated that:

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.

Of course the “potentially be used to reduce the effectiveness” sounds a little bit ambiguous. Anyway a subsequent bulletin for RSA customers was released on March, the 21th 2010, stating that:

RSA SecurID technology continues to be a very effective authentication solution. Whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers.

Said in few words according to the Company, the stolen information, alone, may not be used to perform a successful attack. Even if the RSA algorithm (in its post-2003 implementation using AES hash with 128 bit ECB blocks) is not public, RSA statements sound true since some quantities used in the hash are neither related to the 128 bit random seed nor to the 64 bit standard ISO representation of Current Time: they are a 32-bit token-specific salt (supposedly the serial number of the token, which may have been subtracted in the breach, and a 32 bits padding). Today this quantities are not used for security purposes, but simply to shape the blocks to 128 bits as requested by AES hash (enjoy the math of AES hash algorithm at this link).

Of course, together with the PIN known only by the user, there is, in theory, enough stuff to make an attack unsuccessful in case a (organized) gang of cybercrooks come in possess of the database mapping a SecurID token with its seed. But unfortunately, as often happens, reality is much worse than theory, so one discovers that someone reversed the RSA algorithm and developed Cain & Abel, which, by mean of an RSA SecurID Token Calculator is able to retrieve the One Time Password from an RSA token, provided the malicious user owns the file contained in the RSA Authentication Server (mapping the token serial number with the seed) and knows the User PIN. Small “negligible” detail: from version 4.9.10 (released in 2007), Cain & Abel supports AES-128 of post-2003 securID implementation.

So at the end, supposed the information stolen from RSA is comparable, or could be brought in some manner to be comparable (in form and content) with that contained in each RSA Authentication Server (and it should be since each RSA token must be synchronized with its own authentication server), Cain & Abel (or a similar tool) could be applied to successfully obtain the password for each token whose seed was stolen, provided the attacker come somehow in possess of the only missing information: the user PIN.

There are several ways to steal a user PIN, from Social Engineering to sniffing. Often social engineering leverages the shallowness of the user or the lack of policies of the organization (yes… In my life I have also seen some SecurID tokens with attached a post-it containing the PIN). Of course when I mention sniffing I do not mean network sniffing since both in case of an organization adopting SecurID tokens either in native ACE mode or RADIUS mode, the PIN is never transmitted in clear, anyway we have not to forget that many organizations adopt software tokens (also in mobile devices), so one might not exclude a priori that a large scale attack had deserved the development and the deployment of a Trojan tailored to steal PIN from RSA software tokens.

This is the reason why I expect that the target of the attackers was not RSA but an important organization making use of RSA securID authenticators. As a consequence I would not be surprised if a malicious tool to sniff PINs from RSA Software authenticators were discovered.

Seeds on the Black Market?

If I fly with my imagination I do not feel to completely exclude that the stolen information one day could be available in the black market to target other major organizations besides the presumed original victim: in fact do not forget that Banks worldwide are among the bigger customers of RSA). This is the reason why, RSA users should take in serious consideration the recommendations provided by the Company the day after the breach.

Personal Note 1

The Italian Security Professional group on Linkedin dedicated an interesting post to the RSA affaire (in Italian) which is continuously updated as new information is released. Today the last controversial advice: it looks like RSA will provide hack data in exchange of customer secrecy (thanks to Andrea Zapparoli Manzoni for reporting this information). This advise comes in the same day in which I discovered a further controversial article (actually dating back to a couple of weeks ago) reporting a possible (unconfirmed) backdoor in the SecurID tokens requested by the NSA in exchange of the authorization to export the technology… Very strange the temporal proximity with the breach, as much strange the fact that this information is passed nearly unnoticed…

Personal Note 2

I must confess I was really intrigued on better understanding how the SecureID algorithm works for understanding which is the missing part “to make the successful attack complete” (to use the same words in the RSA bulletin).

Since, as already mentioned, the RSA algorithm is not public (even if the first version pre-2003 was reversed in 2000) I only may perform some kind of speculations. In these days I searched all the possible documentation and probably in this link I found a scenario which might be quite close to reality. Please notice that what follows is a mere speculation.

Since the beginning of 2003, SecurID performs an AES hash operation, in standard ECB mode, to hash

a 128-bit token-specific true-random seed;
a 64-bit standard ISO representation of Current Time in the following format: year/month/day/hour/min/second;
a 32-bit token-specific salt (the serial number of the token);
another 32 bits of padding, which can be adapted for new functions or additional defensive layers in the future.

The latter two are not a specific security feature but are needed since the AES-Hash operation needs 128 bit multiples. The 64 bit standard ISO representation is derived from a 32-bit representation of the current time (GMT) in seconds since midnight on 01/01/86, from which, only 22 bits are used from the original value, leaving 2²² or 4,194,304 total possible time values. These inputs, conflated and hashed by the AES, generate the series of 6-8 digit (or alphanumeric) token-codes that are continuously displayed on the SecurID’s LCD as a “one-time password.” Rolled over every 30 or 60 seconds. In order to implement a pure two factor authentication, the user must insert a known PIN in order to complete the authentication process (but this is configured by the administrator).