With the alleged Northrop Grumman Cyber-attack, we have experienced three attempts, unleashed in few days, to leverage the compromised RSA seeds in order to steal data from U.S. Contractors.
Albeit the above mentioned events are characterized by two evident points in common: all the targeted companies are U.S. Defense Contractors, and all of them use RSA tokens; there is a point that seems confusing, and it is the timeline with which the attacks were carried out and subsequently unleashed (we will see that the two are very different and somehow confusing).
Analyzing the timeline: the first attack unleashed was the one led against Martin Lockheed. According to the sources, remote access to internal resources was disabled late on Sunday, May, the 22nd, just immediately after the attack was detected. The first details, although the target was not immediately revealed, were given few days after, on May, the 26th.
The second cyber-attack targeted L-3 and was unleashed few days after , on May, the 31st. According to the information revealed, the event occurred at the beginning of April (more exactly on April, the 6th, that is more than a month and a half before) and described into an e-mail sent by an executive to the 5000 group’s employees belonging to the division affected. Nothing strange apparently: the late disclosure was unintended for the target company and probably a consequence of the huge echo raised after the Lockheed Martin affair which led an anonymous source to reveal details to Wired.
On June, the 2nd, an alleged third attempt to attack a U.S. Defense Contractor using compromised seeds was unleashed, this time against Northrop Grumman. According to the revealed timeline, this attack was held on May, the 26th, that is nearly in contemporary (4 days after) the event of Lockheed Martin.
So definitively although the three attacks were revealed nearly in contemporary, only two of them were (i.e. the ones towards Lockheed Martin and Northrop Grumman), while the second one, to L-3 happened a couple of weeks after the RSA Breach and almost one month and half before the others. This sounds not clear to me.
If I had been in the attackers’ shoes, I would have attacked all at once in order to prevent the spreading of the information, and definitively to avoid the possibility for the others victims to organize themselves, for instance immediately replacing the tokens as made by Raytheon immediately after the RSA Breach.
Let us suppose (as it seems clear) that the alleged theft of the seeds was only the first step of the “perfect plan” to attack the U.S. Defense contractors, let us also suppose that the attackers took some time to obtain the missing pieces of the puzzle, that is to link the tokens to users, and eventually to obtain the PINs, by mean of keylogger trojans or phishing e-mails as suggested by by Rick Moy, president of NSS Labs. Do you really think that they would have left one month and a half between one attack and the other? Honestly speaking I do not think so. Of course I can imagine that obtaining all the PINs or user to token mappings at once was simply impossible, for reasons of time because it is impossible that all the victims to a specific targeted phishing campaign could reply simultaneously, but also because a massive “vertical” campaign of phishing targeting all the U.S. Contractors (and aimed to obtain information about RSA tokens) would have probably raised too much attention, so that I do not exclude that the necessary information to perform the attack had to be obtained with “evasion” techniques.
Nevertheless, provided the above depicted scenario is real, even if it is unlikely the attackers could attack all the target simultaneously, one month and half between one wave and the other seems actually too much: I doubt they already knew that the information concerning the first alleged attack to L-3 would have been revealed only many days after, of course it is easy to predict that L-3 and the eventual other victims would not have been happy to do it immediately after; but if they really had the perfect plan, relying on a similar occurrence would have been a huge hazard capable to put at risk the entire operation.
I seriously fear the truth is different. Of course this is a mere personal speculation, but I am more and more considering the hypothesis that a first wave of attacks was really held at the beginning of April (more or less in contemporary with L-3), that is after a short interval the original breach, short enough to catch the most part of the victims unprepared, most of all in case of very big companies. The consequence could be that many others attacks have not been revealed or simply were not detected at all, since, as I said a couple of days ago:
I wonder if military contractors are really the only targets or if they have been the only ones capable to detect the attempts because of their strict security protocols and policies.
How to explain the alleged second wave of May? It might be that the attackers have tried once, since the result was successful (it is not clear if they were able to steal sensitive data, but for sure the information was not immediately revealed) so they decided to try a second and a third chance (and who knows how many others). Otherwise, it might be that after the first wave they decided to sell the seeds on the black market (probably at a lower price since at that point the seeds would have been considered a good of second choice), and this could explain the late attack to Lockheed Martin and Northrop Grumman (and who knows who else). In this case I am afraid we will see many other attacks, unless other potential targets (that so far refused to comment the events) will not decide to follow the example of Raytheon and replace the tokens.
Hard Times to come for U.S. Defense Contractors: it looks like each new day reveals information of a new cyber-attack to military technology companies using (alleged) compromised SecureID seeds.
This time Fox News reports that Northrop Grumman, another Defense Contractor has been the victims of a Cyber Attack, on On May 26, when the company shut down remote access to its network without warning, catching even senior managers by surprise and leading to speculation that a similar breach had occurred.
Even if there is no evidence so far that the cyber attack could be the consequence of the RSA Breach on March, there are at least two strange coincidences: the fact that this is the third attack to a U.S. Defense Contractor unleashed in less than a week (after Lockheed Martin and L-3), and the fact that Northrop Grumman is an RSA SecureID customer.
If the attack should be confirmed to have been carryed out by mean of compromised seeds, this would undoubtely confirm the RSA Breach was only the first stage of a (vertical) cyber-operation targeted to steal U.S. Military secretes (at this point I would not be surprised if other institutions belonging to different verticals are already under attack without realizing it).
Probably, as David Cenciotti said in a post of ysterday, it is time to rethink Strong Authentication: “something you know and something you have” is revealing to be a too weak paradigm if compared with the strenghts of Ciberweapons (because we are talking of Cyberweapons) who have shown to be capable to subtract any kind of data, sometimes leveraging users’ naivety with old-school techniques).
Morevoer also the users should be educated to face the new shape of cyberwar phishing if it is true, as it supposed to have happened in case of Lockheed Martin, that phishing techniques were used to map users to their token.
I just finished reading this interesting article that seems to offer a different view for the attack at Lockheed Martin (actually, a lone voice which does not consider the attack related to compromised seeds), that here it is another bolt from the Blue. As a matter of fact Wired reports that a second Defense Contractor, L-3, has been targeted with penetration attacks leveraging information stolen from the infamous RSA Breach. This information was contained into an E-mail, dated April 6, sent to the 5000 group’s employees. t’s not clear from the e-mail whether the hackers were successful in their attack, or how L-3 determined SecurID was involved.
Protecting our network is a top priority and we have a robust set of protocols in place to ensure sensitive information is safeguarded. We have gotten to the bottom of the issue.
Is the only comment of the company.
This revelation occurs few days after the explosive news pertaining the attack led with similar methods to another Defense Contractor, Lockeed Martin.
Maybe all the defense contractors should have followed the wise example of Raytheon (another Defense Contractor) which declared to have taken immediate companywide actions in March when incident information was initially provided to RSA customers, to prevent a widespread disruption of their network.
If confirmed, this event is a further corroboration of the fact the real target of the Hackers was not RSA but their customers, event if at this point I wonder if military contractors are the only targets or if they have been the only ones capable to detect the attempts because of their strict security protocols and policies.
- Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks (wired.com)
- More Random Thoughts on the RSA Breach (paulsparrows.wordpress.com)
- Some Random Thoughts On RSA Breach (paulsparrows.wordpress.com)
Probably it was a quite easy prediction, however it looks like what I suggested on my random thoughts on the RSA Breach has definitively come true: RSA was not the target, probably its customers were.
On this front, the last two days were quite turbulent, and what seemed initially a simple speculation of an attack using compromised SecureID seeds targeted to “a very large U. S. defense contractor”, is revealing to be one of several attacks towards military contractors of U.S. Defense, using the data stolen during the famous breach of March.
According to a source with direct knowledge of the attacks, quoted in the above linked Reuters article:
The hackers learned how to copy the security keys with data stolen from RSA during a sophisticated attack that EMC disclosed in March, according to the source.
In any case EMC, the parent company of RSA, and the other main U.S. defense contractors possibly involved refused to comment.
I was not surprised by these details, more than one month ago I delineated a possible attack scenario which seems to be very close to what happened, at least for Lockheed Martin. Since the token on its own it is not enough to carry on a successful attack (it must be linked to the owner and very often the real password is also combined with a PIN), other combined actions must be performed to obtain the missing pieces of the puzzle.
I suggested a possible scenario of exploiting the weakness of software tokens, for instance by mean of specific keylogger malware to grab user details and the PIN. It is not exactly what happened in case of Lockheed Martin, but the real attack scenario is quite close since a keylogger was involved as well and used to access the intranet and consequently to get access to the internal network: as a matter of fact, for security reasons many companies use a double layer of authentication for remote access and internal resources. In this case the company forced 100.000 users to reset their passwords.
In reality, as stated by Rick Moy, president of NSS Labs, the initial RSA attack was followed by malware and phishing campaigns seeking specific data that would link tokens to end-users, suggesting that the current attacks may have been carried out by the same hackers. And the game is not over.
Unfortunately the use of phishing to lure the users (and to attack an organization for cybercrime purposes) is not surprising as well. Nowadays this technique, to initially target the users with phishing, leading them to download malware, is the “main engine” of APTs (Advanced Persistent Threats) and it is revealing to be the common denominator of the main breaches and huge scale attacks of this annus horribilis for Information Security. The fact that in this circumstance it was used in combination with the duplicated key of SecureID is only the last unedited variant, and I am afraid it will not be the last.
Fortunately, in any serious situation there is always a flash of humor: according to this article of NYT, the intruders had been detected as they were trying to transfer data by security software provided by NetWitness Corporation, a company that provides network monitoring software. Does NetWitness Corporation sound familiar to you? Of course It does indeed! In April, just after the breach, NetWitness was acquired by RSA’s parent company, EMC.
As Morpheus stated: “Fate, it seems, is not without a sense of irony”, and this is worthwhile for Information Security as well.
A bolt from the blue! Source report some details of the alleged first attack to a very large U. S. Defense contractor perpetrated by mean of compromised RSA seeds.
Late on Sunday all remote access to the internal corporate network was disabled. All workers were told was that it would be down for at least a week. Folks who regularly telecommute were asked to come into nearby offices to work. Then earlier today (Wednesday) came word that everybody with RSA SecureID tokens would be getting new tokens over the next several weeks. Also, everybody on the network (over 100,000 people) would be asked to reset their passwords, which means admin files have probably been compromised.
It seems likely that whoever hacked the RSA network got the algorithm for the current tokens and then managed to get a key-logger installed on one or more computers used to access the intranet at this company. With those two pieces of information they were then able to get access to the internal network.
Fortunately the contractor was able to detect the breach and to manage it, avoiding worst consequences.
But many questions remain unsolved: was this the first attempt? Were all the seeds compromised during the famous breach? For Sure it will not be the last and my sixth sense and one half thinks we will have to get used to this kinds of attacks.
As I told in previous post I am more and more convinced that the final target of the attack was not RSA…
- Some Random Thoughts On RSA Breach (paulsparrows.wordpress.com)
- What do RSA, Epsilon and Sony breaches have in common? (paulsparrows.wordpress.com)
The month of March will go into the annals of Information security. First the breach of RSA, then the issue of fake Comodo Certificates (with the subsequent claim by the Iranian Comodo Hacker) have gradually brought down the (few) certainties the Strong Authentication technologies relied on.
While commenting the beginning of this new era made of very few certainties for our digital identity, I could not help thinking about the (apparently) downward trend to which I was getting used with regards to the strong authentication mechanism adopted for my home banking (be quiet I do not currently have any RSA SecurID tokens, fortunately). Hindsight it could be interpreted as a strange omen (I would suggest RSA to follow the same path).
My first E-Banking contract dates back to 2005, and it was signed with a Regional Italian Bank. In that year, for perfoming operations such as money transfer, I was given a digital certificate stored in a floppy disk (in 2005 sigh!) for electronically signing every transaction. At that time I was firmly convinced that Digital Certificates were the most secure method to strong authenticate transactions, but I never used that certificate since, back in far 2005, a floppy disk was already a thing of the past.
A couple of years later the same bank made a Copernican (r)evolution and decided to dismiss all the certificates in exchange of OTP tokens (not manufactured by RSA but from competitor). Despite some scattered small issues due to a poor IT governance (in a couple of circumstances there was no way to make the PIN to be recognized and I also was victim of a data loss related to the electronic transactions of the previous four months (of course rigorously without backup, even if the operations had effectively been made), I was quite satisfied with the tokens (but not with the bank). Of course needless to say that these kinds of incidents always happened when I desperately needed to complete the transaction.
Five months ago I changed my bank (looking for better conditions) and decided to open a brand new completely on-line account. Well! Guess what kind of device I was given to authenticate the transactions? After a digital certificate and a token, I would have expected at least a PKCS#11 OTP USB Key… Not at all, I was given instead an efficient (but not very elegant or technological) card with a numerical grid composed by 24 triplets. Nowadays for each operation I am asked to insert three numbers each of them belonging to a different triplet randomically chosen between the 24 printed in one face of the card.
Of course even the most fervid imagination could not imagine that the parable of the strong authentication methods for my bank accounts during these years, could be interpreted as a premonition. Actually banks always know more than the devil, especially when it comes to other people’s money, but I must confess, that, although my initial disappointment for the progressive weakening of the authenticated mechanism necessary to sign transactions, in the last month I changed my mind and now I feel more comfortable with a card having impressed a kind of Caesar Cipher (yes I know that is just not the same thing but the comparison is appealing: back to the future!) than with an OTP Token or a certificate.
I was almost thinking of trying the strong authentication via SMS, but just today I realized that it is not particularly advisable, most of all on the iPhone, where the 2FA (Two Factor Authentication) mechanism has just been compromised. Ok I have an Android terminal but maybe is better not to use any mobile terminals, the threats like Zitmo (Zeus in The Mobile), are always around the corner.
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 1st, 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 17th 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 222 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).
- It was only a matter of time… (paulsparrows.wordpress.com)