Update (Jun 7): RSA chairman Art Coviello has now admitted that the attack was linked to the March 2011 SecurID breach, and offers to implement risk-based authentication or replace all tokens as a gesture to customers. Still no official confirmation of what was stolen, however.
U.S. aerospace giant Lockheed Martin reported on Saturday that it detected and thwarted a “significant and tenacious attack” on its network a week ago.
An unnamed source with direct knowledge of the attacks claimed that hackers broke in by creating duplicates of the SecurID tokens used by Lockheed Martin’s users. The company responded by shutting down remote access to its networks and replacing almost 100,000 of the SecurID tokens.
Although the link to the RSA data breach has not yet been confirmed, it is another possible clue to what many in the information security community have long suspected: The RSA breach involved the theft of the token seed records which, with some additional information, could be used to duplicate the functionality of the RSA tokens.
Interestingly, it appears that RSA has secretly briefed some of its customers on the details of the March 2011 data theft. Two people familiar with the briefings reported that the company required them to sign non-disclosure agreements promising not to discuss the advice that was provided.
RSA employee Uri Rivner shares new details on the SecurID breach in an April 1st blog post. What was initially described as an “extremely sophisticated attack” of the “Advanced Persistent Threat” variety turns out to have been a simple spear-phishing campaign with a malicious Excel attachment containing a 0-day Adobe Flash exploit (perhaps this is what RSA means by “extremely sophisticated”). Once the attacker established a foothold inside the network, it was apparently a simple matter to find a way to the crown jewels. The attack was reportedly detected in progress, although this did not prevent the stolen data from making its way to an unknown destination on the Internet via FTP. RSA is not doing itself any favors by continuing to withhold the details of what was stolen, and putting a ridiculous corporate spin on what was essentially a simple, run-of-the-mill phishing attack.
UPDATE 5 (March 25): A surprisingly well-informed and technically accurate article from a mainstream site? Go figure.
UPDATE 3 (March 23): Some observers are putting two and two together regarding the nature of the breach and what was stolen.
- Wikipedia [NOTE: This article has since been cleaned. The IP address of the individual who made the change is owned by RSA's parent company EMC.]
UPDATE 2 (March 21): Reports of a new official email to customers regarding the breach are beginning to appear. RSA is still not willing to confirm the theft of the token seed record database. However, reading carefully between the lines leaves one with the unmistakable impression that the strength of the SecurID solution has been reduced to the single factor of “something you know”.
1. What happened?
Recently, our security systems identified an extremely sophisticated cyber attack in progress, targeting our RSA business unit. We took a variety of aggressive measures against the threat to protect our customers and our business including further hardening our IT infrastructure and working closely with appropriate authorities.
2. What information was lost?
Our investigation to date has revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.
3. Why can’t you provide more details about the information that was extracted related to RSA SecurID technology?
Our customers’ security is our number one priority. We continue to provide our customers with all the information they need to assess their risk and ensure they are protected. Providing additional specific information about the nature of the attack on RSA or about certain elements of RSA SecurID design could enable others to try to compromise our customers’ RSA SecurID implementations.
4. Does this event weaken my RSA SecurID solution against attacks?
RSA SecurID technology continues to be an effective authentication solution. To the best of our knowledge, 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. We have provided best practices so customers can strengthen the protection of the RSA SecurID information they hold. RSA SecurID technology is as effective as it was before against other attacks.
5. What constitutes a direct attack on an RSA SecurID customer?
To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.
6. What constitutes a broader attack on an RSA SecurID customer?
To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.
The broader attack we referenced most likely would be an indirect attack on a customer that uses a combination of technical and social engineering techniques to attempt to compromise all pieces of information about the token, the customer, the individual users and their PINs. Social engineering attacks typically target customers’ end users and help desks. Technical attacks typically target customers’ back end servers, networks and end user machines. Our prioritized remediation steps in the RSA SecurID Best Practices Guides are focused on strengthening your security against these potential broader attacks.
7. Have my SecurID token records been taken?
For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.
To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.
8. Has RSA stopped manufacturing and/or distributing RSA SecurID tokens or other products?
As part of our standard operating procedures, while we further harden our environment some operations are interrupted. We expect to resume distribution soon and will share information on this when available.
UPDATE 1 (March 20): Apparently, RSA executives have been telling customers to ensure that they don’t give out the serial numbers on their tokens. This is yet another clue that the breach may have involved the theft of the database mapping token seed records to token serial numbers.
In an open letter to its customers, RSA chief Art Coviello disclosed yesterday that an internal data breach had been discovered affecting the security of RSA’s SecurID product line. He states:
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 are left to wonder and speculate on the exact meaning of this statement. Perhaps the worst-case scenario would be the theft of the token seed record database. A little background information will clarify why this would be of significant concern.
Each RSA token uses 3 input numbers which are mangled using the AES-128 block cipher to generate a new 6-digit token code every 30 or 60 seconds:
- A token-specific 128-bit random seed (used as the AES encryption key)
- The current date/time in YY/M/D/H/M/S format (64-bit)
- The token’s serial number (32-bit) + 32 bits of padding
The security of the token depends on the fact that the 6-digit code is unpredictable. If hackers stole RSA’s database containing a mapping of token serial numbers to corresponding random seeds, it would allow the hackers, in effect, to predict what 6-digit number is displayed on any token at any time.
In order to exploit this information, they would also need to know:
- the serial number of the token attached to the account they are targeting, and
- the PIN (password) of the owner of the account
This information would need to be gathered using the same methods used to attack standard password information, i.e. through phishing, social engineering, repeated guessing, etc. In effect, it would reduce the security of the RSA token from two-factor to single-factor: Once you have the victim’s PIN and token serial number (which is stamped on the back of the token itself), you have all the information necessary to authenticate as the victim.
Without further details from RSA about the extent of the data breach, it is impossible to say whether this is in fact what happened. However, one thing is clear: RSA’s customers need more reassurance than they are currently getting.
The news today is reporting that the City of San Francisco computer systems have been hijacked by a rogue network engineer. The highly-paid employee of the city’s technical department had been exhibiting increasingly erratic behavior which culminated in his locking out all administrative access to the systems and refusing to divulge the password. The 43-year-old individual had been hired in spite of a felony record for aggravated robbery 25 years prior.
Two thoughts come to mind. First, the glaringly obvious: Knowingly hiring an individual with a criminal history for such a sensitive position was probably not a good idea. Second, it is essential to ensure that people in trusted positions are worthy of that trust. If ethics and work-life balance take a back seat to technical competence in a prospective job applicant’s value system, wise employers look elsewhere.
Verizon Business Security Solutions has released a study of breach data from more than 500 forensic investigations conducted by their incident response team.
This is exciting because it represents an opportunity to examine trends from an objective data source instead of relying on the usual biased surveys and vendor-influenced trade publications. A fine example of the “new school” approach to information security.
The government of India wants to monitor messages sent over the BlackBerry wireless network, because terrorists could be using these handheld devices to coordinate attacks. They are demanding that Canadian vendor Research In Motion hand over “master decryption keys” (which are very unlikely to exist) or lower the encryption level from 256 bits to 40 bits, presumably so that the Indian government can recover the keys by brute force. What I don’t understand is, wouldn’t the terrorists use PGP to encrypt their e-mails anyway? Terrorist or not, who in their right mind would depend on a foreign vendor for something like this?