RSA Security, Inc Hacked

The company, not the algorithm. Here’s the corporate spin.

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.

Here are news articles. The worry is that source code to the company’s SecurID two-factor authentication product was stolen, which would possibly allow hackers to reverse-engineer or otherwise break the system. It’s hard to make any assessments about whether this is possible or likely without knowing 1) how SecurID’s cryptography works, and 2) exactly what was stolen from the company’s servers. We do not know either, and the corporate spin is as short on details as it is long on reassurances.

RSA Data Security, Inc. is probably pretty screwed if SecurID is compromised. Those hardware tokens have no upgrade path, and would have to be replaced. How many of the company’s customers will replace them with competitors’ tokens. Probably a bunch. Hence, it’s in RSA’s best interest for their customers to forget this incident as quickly as possible.

There seems to be two likely scenarios if the attackers have compromised SecurID. One, they are a sophisticated organization who wants the information for a specific purpose. The attackers actually are on RSA’s side in the public-relations spin, and we’re unlikely to see widespread use of this information. Or two, they stole the stuff for conventional criminal purposes and will sell it. In that case, we’re likely to know pretty quickly.

Again, without detailed information—or at least an impartial assessment—it’s impossible to make any recommendations. Security is all about trust, and when trust is lost there is no security. User’s of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers’ trust.

Tags: , , , ,

Posted on March 21, 2011 at 6:52 AM • 85 Comments

Comments

Ralph • March 21, 2011 7:12 AM

Excellent assessment of the situation. Wonder how pending contracts with RSA will be impacted.

Ian Toltz • March 21, 2011 7:12 AM

My guess, based on absolutely nothing, is that they have gained access to whatever the algorithm is for generating the security tokens, and can now generate security tokens if they have the device’s serial number.

If accurate, this would mean they’ve simplified the attack from needing both a password and a physical keyfob, to needing a password and the serial number from the physical keyfob.

Again, just a guess, with no supporting info… but I can’t imagine what else it could possibly be.

Juergen • March 21, 2011 7:23 AM

The algorithm itself was hacked a long time ago – tools like “Cain & Abel” are able to guess the correct Tokencode if you have the seed file for a particular token (or rather, tell you which are the likely tokencodes – there is more than one, the ones before and after the currently displayed ones are also important for synchronisation reasons).

Short term, the main danger would be if the seed files are lost – all customers would need to replace tokens. Even then, though… a cracker who knows the serial number of the token of the user he wants to attack would also need the PIN.

My main concern is that somebody might discover exploitable holes in the ACE server itself…

Guillaume • March 21, 2011 7:25 AM

The algorithm is known, maybe in a reverse engineering kind of way. The tool Cain (http://www.oxid.it/ca_um/topics/rsa_securid_token_calculator.htm) allows you to show the token codes IF you have the seed records (the AES key that is burned in each token). In a lab setup, we had plain text seed records (production seed records are encrypted) that worked fine with the tool.

Maybe/probably there is a master seed record from which individual token keys are derived.

An horror story would have the master key compromised, as well as the algorithm to derive a token key, especially if the serial number is the only entropy to the process.

Alan • March 21, 2011 7:28 AM

I’m still not sure what my feelings towards what this means to RSA or SecurID; but to be fair, at least they’re telling us the attack happened.

I imagine it would have been much easier for them to sweep all this under the covers and save them a lot of heartache.

Ron Livesey • March 21, 2011 7:31 AM

From what I understand there has been persistent attack at RSA for nearly 6 months. Seems to be have been successful.

Frederic Thomas • March 21, 2011 7:51 AM

FWIW, my bank in Switzerland (Credit Suisse) sent a letter 3 days ago about moving away from SecurID from the next connection to my accounts.
Maybe such a large bank knows more than we do 🙂

Clive Robinson • March 21, 2011 8:06 AM

From my point of view it’s not so much what has been lost but the fact they have been attacked

[Disclosure : I don’t use SecureID for a variety of reasons, not the least as I like one or two thers here know sufficient at all the required levels to have make my own secure tokens but that’s another matter]

The people who performed this attack have presumably realised that the best place to attack the trust “star” is at the center where it starts not at the myriad of end of chain points.

I’m not very surprised (its where I would start 😉 and it is an indicator of various attackers gaining maturity.

If you think about it attacking the “root of trust” gives a very very much greater return on investmant than attacking any other point.

I will however remined people of. Kerckhoffs’s 6 basic principles from 1883,

1, The system must be practicaly if not logicaly and mathmaticaly indercipherable (ie cryptographicaly secure).

2, The system must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience (this is the “Enemy Knows the System” phrase from Shannon and is often called Kerckhoffs Law).

3, The keys for the system must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents (that is the system must be both practical and secure in use).

4, The system must be compatable with the mode of communication.

5, The system must be portable, and its usage and function must not require the use of several people.

6, It is of necessity, that given the requirments of its use, that the system be easy to use. Requiring neither excess mental effort by the user, nor that the user need have knowledge of a long series of procedures to use it effectivly.

I will leave it to others to make up their minds which parts of these six rules the SecureID tokens respect in fact or just by apperances.

However there is an important rule that Kerckhoffs did not mention,

0, The system must be tamper evident at all times.

AlanS • March 21, 2011 8:09 AM

What makes an attack an APT? Whether there is such a thing or not isn’t every company that gets attacked from now on going to claim it was an APT, especially if the company is in the security biz. More on RSA’s “corporate spin” here: http://daveshackleford.com/?p=549

RSA just published a paper “that explains in detail a) what the APT is, b) how it works, and c) how to counter it effectively with “next generation SOC” concepts.” But Shackleford points out that what they describe in their paper is a “Simple Short-term Threat”.

Dennis • March 21, 2011 8:23 AM

Re algorithms: There are two types of tokens, legacy ones and so-called AES tokens. AFAIK only the algorithm of the legacy tokens is widely known and Cain & Able can emulate these (given the seed). There should not be a large number of legacy tokens still active, because these haven’t been sold for some time, and all tokens expire (normally after 3 years).

I could not find a public source for the new algorithm, but given the existence of soft-tokens, we can assume that the underground knows it. Or at least that a wellfunded attacker would prefer reversing it from there, rather than risking discovery with a breakin.

Anyway, as all here know, a good algorithm should withstand being public, the real security depends on the seeds staying secret.

The seed is burnt into the token by RSA (possible non-randomness problem here), then shipped to the customer (your next opportunity is to sniff that) and stored in its Authentication Manger (the server side of the SecurID system).

But here’s the bomb: RSA holds on to the seed. So there is probably a database somewhere connecting seeds and customers. If someone gets ahold of that (and the algorithm), she can just pick any customer, and basically emulated all of their tokens.

Louis • March 21, 2011 8:32 AM

It’s probably a good thing for them their big conference was just two weeks ago.

By next year, some other big security coporation will have been compromised and this one will be long forgotten, and need not be addressed at the 2012 show.

Make me wonder when exactly did the hack occur though…

Hagai • March 21, 2011 8:36 AM

We don’t really know what the impact of the RSA Security breach is, because not enough information is available. If it turns out that a leak of the design or source code was enough to cause damage to the security model, then the token may need to be redesigned. If only seeds were stolen, then we may just need to replace the affected tokens.

See also: “Understanding the Impact of the RSA SecurID Breach”
http://www.hbarel.com/blog?itemid=62

Johnny • March 21, 2011 8:59 AM

You can download the SecurID Java soft token from RSA’s web site, and running it through a Java decompiler produces quite readable source code. So the algorithm is pretty much publicly known already (and yes, this is the new AES-based algorithm, not the old one).

Jorgen • March 21, 2011 9:04 AM

It’s seem like there is something with the seeds. And I don’t understand why RSA would need to have a copy of that? It seems like a very risky thing to have. And are customers awear of that RSA are storing the token seeds?

S • March 21, 2011 9:15 AM

Was RSA really so stupid to retain the seeds? I mean, there is no valid reason for doing so. Or were the attackers able to sniff the seeds while being written to the tokens? Or did the US Government require RSA to retain the seed numbers.

In the end, it doesn’t really matter…

Either case, something went very wrong. Unless we need a lot more, I consider SecurID (why do a lot of people write SecureID??) tokens to be broken and not to be trusted in any possible way.

Paeniteo • March 21, 2011 9:39 AM

@S: “Was RSA really so stupid to retain the seeds? I mean, there is no valid reason for doing so.”

The valid reason would be “customer support”.
A customer’s whole set of SecurID tokens would become worthless if the customer had lost his seed database.
(Yes, it would be stupid for a customer not to secure such an important file.)

Trichinosis USA • March 21, 2011 9:42 AM

Motives for attacks, ESPECIALLY when they are sophisticated, should not be limited to internal policing and conventional criminality.

Third option: a political motive. We saw this with the Stuxnet Worm.

Fourth option: a competitive motive.

Carlo Graziani • March 21, 2011 9:51 AM

What a PITA. I bet the DOE labs are panicked. The securocracy is probably working three-shift work days until they can swap out all the tokens.

One thing that has always puzzled me about the two-factor token craze is, whatever happened to S/Key? It was a perfectly simple, software-based one-time password system, which was easy to initialize or reinitialize, locally or remotely, and was as secure as the hashing algorithm it was based on. No physical hardware required.

A system that uses S/Key-based OTP as a second auth factor would regard this sort of compromise as a minor nuisance, rather than a corporate existential threat. So why are we all carrying around these idiotic tokens instead?

xyz • March 21, 2011 10:17 AM

“corporate spin”?

If it was Google that was hacked (lets say gmail), would Googles announcements after the fact also be termed “corporate spin”?

Lets say for example these announcements about Chinese hackers infiltrating gmail because of “a bug in a MICROSOFT product”. Or their streetview gathering wireless network data because of “a ROGUE employee”.

Or perhaps there is so much respect for Google that nobody believes THEY would do something like that…

Paeniteo • March 21, 2011 10:21 AM

@S: “It would be better to issue new tokens in that case.”

While it would certainly be “more secure” that is absolutely not the same thing as “better”.

Seiran • March 21, 2011 10:42 AM

The RSA SecurID product has a JTAG-like bare contact pad on the back of the device hidden under a plastic patch. I would guess this is used for the key injection. SafeWord tokens also have a similar port which allows the seed to be updated using a pogo pin wand (wand and software available from vendor), so the SecurID might have the same capability. Vasco tokens (Verisign VIP, Blizzard, Wachovia) do not appear to have a visible programming port.

Keeping the seeds in and of itself is not sinister, it allows RSA to help prevent a costly reissue if customers lose their ACE/Server data, which happens more likely than you’d think. I would consider this a welcome convenience. But, if RSA Security, of all companies, had been storing live keymat on an online system, who can we trust anymore?

I am not aware if government standards require you NOT to let others keep a copy of your keys (they probably don’t), but it could be a contract stipulation. Major customers may have their own storage arrangements for seed data, which are delivered in a sealed envelope on CD (formerly on floppy), and have told RSA not to keep any copies. Perhaps the DoD/CIA had already demanded that RSA provide them Authentication Manager code without RSA’s vendor-signed-seedfile licensing validation so they can generate their own.

T Colgate • March 21, 2011 11:00 AM

The price of snakeoil just hit $200 a barrel! Perhaps something good will come of this and people will start to understand that you can productise “security”.

tdp • March 21, 2011 11:09 AM

We are operating under the assumption that the seed records have been stolen. The algorithm isn’t the security here, it’s the seeds.

Because of this, the worst case (note that RSA went out of their way to claim that no ‘direct’ attack was possible) is as follows:

  • I have the algorithm
  • I have the seed record
  • This means I can generate a valid token code for any token serial number
  • I do not have the username
  • I do not have the PIN
  • I do not have the serial number of the token assigned to the user name

Keep in mind RSA’s warnings about phishing and social media attacks. The two-factor system is reduced to single-factor (PIN) as soon as I can get a user to divulge what their current token code is. If I can get a PIN too, I have defeated the system entirely.

This is all speculation, but the absolute blackout that smaller users of this system are facing from EMC / RSA leaves us no choice but to prepare for the worst-case.

Graham Steel • March 21, 2011 11:18 AM

Hello, in our ACM CCS paper last year “Attacking and Fixing PKCS#11 Security Tokens” we found another vulnerability in the RSA SecurID 800: sensitive keys on the device are directly readable in clear via the PKCS#11 interface, in complete breach of the (RSA!) standard PKCS#11.

You might want to check out the paper if you use PKCS#11 tokens – we found vulnerabilities in Aladdin, Siemens, Gemalto, and Bull devices amongst others

http://www.lsv.ens-cachan.fr/Publis/PAPERS/PDF/BCFS-ccs10.pdf

Note that RSA’s response involves a patch to the middleware, not to the firmware on the token, so the vulnerability still exists if you are using a <v3.5.3 driver. RSA’s response is here:

http://secgroup.ext.dsi.unive.it/projects/security-apis/pkcs11-security/tookan/rsa-secureid-800/

Merritt • March 21, 2011 11:20 AM

Several points

Tokens pre-2002 used proprietary 64-bit algorithm. Algorithm was privately reviewed by many and deemed ok at time. RSA switched to 128 bit AES tokens thereafter. Tokens are only sold with 5 year maximum life so there should be no 64-bit tokens in circulation. And tokens reset when life expires, so reverse engineering on a dead token is not easy.

Many SecurID tokens are sold via indirect channel. In these cases, RSA systems generally have knowledge of VAR who bought token, not necessarily the end-user organization.

And seed records are kept to avoid collisions (seed generation done via hardware instead of s/w at customer site).

Peter A. • March 21, 2011 11:29 AM

@Carlo Graziani:

I do not know what happened to S/Key but an open source derivative called OPIE is available. I use it all the time – in setups and situations when I can’t or won’t use ssh keys for some reason.

Brandioch Conner • March 21, 2011 11:46 AM

If the seeds were compromised then an attacker should be able to generate current keys for each physical token.

In the implementation that we use, you are required to prefix a 4 digit code to the token’s generated key to get you through the first login.

4 digits = 10,000 options.

Supposing that they sold 100,000 tokens and kept the seeds for those in a compromised database.

That would mean that a brute force attempt at the first login would only take 1,000,000,000 (one billion) attempts (maximum). (10,000 variations of 100,000 keys.) That sounds like a lot but it isn’t.

Over a weekend (2 days – 48 hours – 2,880 minutes – 172,800 seconds) an attacker would only need to attempt 5,788 token combinations a second.

And the worst part is that it is only a linear progression. If they sold 200.000 tokens it would only take 2x the time of the above example.

Brandioch Conner • March 21, 2011 11:55 AM

@Merritt
“And seed records are kept to avoid collisions (seed generation done via hardware instead of s/w at customer site).”

They shouldn’t be storing the seeds themselves.

They should be storing hashes of the seeds. With a salt just to be safer. Off-line.

Nick P • March 21, 2011 11:58 AM

@ Bruce and Security Community

Unrelated, but important event: Paul Karger died last September. I just ran across it trying to get his email. 🙁

For those who didn’t know him, Karger was a legend in the field of high assurance system design, jokingly called “Mr. High Assurance” by Microsoft’s Steve Lipner. He did some of the first significant vulnerability assessments in mainframe-class OS’s, contributed to most high assurance systems of the 80’s, inspired many approaches still used today, debunked various virtualization security claims, and most recently led a team that developed an EAL7-certifiable smart card OS at IBM.

He will be missed. It’s truly a shame because I never got a chance to talk to him. He was so good he probably could have solved important design decisions I’ll be hammering at for weeks in a twenty minute interview. I like what Lipner said: “Paul was ‘Mr. High Assurance.’ If it wasn’t highly secure, he didn’t have much use for it – and if it was, there were few people in the industry who better understood it. ”

ACM Article and Obituary
http://www.ieee-security.org/Cipher/Newsbriefs/2010/karger.html

jennings • March 21, 2011 12:23 PM

The term “snake oil” used to mean something. Now, anytime someone even uses the expression they immediately lose all legitimacy. Don’t tell me what it means or what you think it’s supposed to mean or what it supposedly refers to. It’s been so abused for so long it means anything anyone wants it to mean, but you have to guess what it means. I wish I had a dime for everytime I heard someone sling snake oil this and snake oil that at a recent conference. Some I discovered used it to refer to a technology they didn’t understand. Others used it to refer to something poorly documented. And yet others used it to refer to something they thought was suspicious or illegal, but without their having to support the charge in any way. Anytime I hear snake oil now, I just walk away.

Paeniteo • March 21, 2011 12:29 PM

@Brandioch: “Over a weekend (2 days – 48 hours – 2,880 minutes – 172,800 seconds) an attacker would only need to attempt 5,788 token combinations a second.”

How about limiting the allowed logins per time unit?
I don’t believe that five thousand attempts per second is anywhere near your normal load…

Curby • March 21, 2011 12:43 PM

@Carlo Graziani:

In short, S/Key doesn’t guarantee an air gap.

Let’s say I’m at a net cafe, SSHing to a server. It’s OPIE-protected, so I open up something like http://www.ocf.berkeley.edu/~jjlin/jsotp/md5.html and generate the OTP. Problem is, if there’s a sniffer on my public terminal, OTP is now just as broken as a static password would be.

Cryptocard, SecureID, etc. is “something you have” and is theoretically distinct from any “something you know.”

Sure, you could put a S/Key client on a smartphone, but then you can’t bring cellular/wireless devices into certain secure environments.

Sure you could make a Cryptocard-like S/Key-specific device, but if you could compute the OTP without fiddling around with annoying single-purpose devices, you probably would … and then you would have compromised the air gap.

Anyway, anyone who is thinking of making such a device for enterprise/govt use would likely just make it proprietary for vendor lock-in … just as Cryptocard and RSA have done.

Brandioch Conner • March 21, 2011 1:03 PM

@Paeniteo
“How about limiting the allowed logins per time unit?
I don’t believe that five thousand attempts per second is anywhere near your normal load…”

Ideally, all the systems should be doing that … AND ADMINS SHOULD BE REVIEWING THE LOGS OF LOGIN ATTEMPTS.

This has been brought up before in this forum. I’m in agreement with you. The worst that can happen in that situation is a DoS for whomever’s account it being attacked. Which is, in my opinion, a MUCH better option than being cracked.

Michael T. • March 21, 2011 1:54 PM

A lot of these posts seem to deal with the “hey, you need TWO pieces of information to access it, so we’re cool”.

Let’s suppose the RSA hackers set up a database for the querying of information associated with the tokens. Company name, serial number, etc.

Now suppose that there was a way of buying data that was scarfed by trojans… You know, usernames, passwords, personal information, etc. In fact, you could say that those trojan records include PREVIOUSLY ENTERED ONE TIME PASSWORDS and the PRECISE TIME THE OTPs WERE ENTERED.

Now, lets pretend that a savvy attacker can merge those two datasets, generate the previous OTPs at the given time, discover which token is used by which human… What kind of attacks are possible THEN?

None of this is beyond the realm of possibility. And once done, it can be automated.

Mike T.
My opinions are my own.

Peter A. • March 21, 2011 2:16 PM

@Curby:

Indeed, in today’s world of powerful portable devices and ubiquitous wireless connectivity S/Key and the like may get less use. In the past it was not like this: it was often practical to get a relatively cheap portable device that will readily run an OTP generator (e.g. some programmable calculator or a simple PDA like Palm I/II or some micro PC or…), while a similarly portable device with cellular connectivity and a possibility to run an ssh client was prohibitely expensive – and the cellular data service was not so ubiquitous. By the way, this is still somewhat valid: having a low-end mobile phone without a QWERTY keyboard or a touchscreen would make ssh client unusable, while a Java OTP generator would be just fine.

Other than that, it is indeed a conundrum – you need a relatively secure device (airgapped or not) to generate an OTP in order to access the OTP-protected system; so why not use it for accessing the system in the first place using a secure protocol. But there are still other valid uses of the technology that do not need a separate device for OTP:

  • Working on a trusted device, so you can have a local OTP generator (or even use a Web-based one), but beeing forced to use an unencrypted channel (e.g. TELNET) to your target system, because you’re firewalled and outgoing ssh is blocked (this is the case I use OTP most often).

  • For working on an untrusted device, like a public terminal, have a bunch of pre-generated OTPs on a scrap of paper in your wallet. You can even obscure them somehow. Pro: needs no power source and does not break any no-mobile-phones-allowed rule. Con: attacker can copy your OTPs and use them, but it is unlikely, he needs to: 1. know that you have them with you, 2. physically get the paper and either keep it or – not ot alert the victim – copy the contents and replace it, 3. know the server the OTPs are for, 4. know the username, 5. possibly de-obscure the OTPs, 6. (depending on configuration) know the static password as well. I won’t use that approach in a high-security setup, but in such case using an untrusted device is a folly in the first place – you can have your session hijacked. Indeed some online banks use similar approach (a paper list of one-time codes) as a second means of authentication. Bonus for rolling out a scrape-off card with a bunch of OTPs on it.

  • Hardcore hackers can memorize a few of their OTPs ;-P Seriously: I tried that once as an experiment; with considerable effort I was able to memorize and keep in my memory five-six at a time which allowed me to use my system for two or three days before I had to repeat memorizing session. The experiment lasted for two rounds of five OTPs 🙂

Seth • March 21, 2011 2:28 PM

@Curby

so I open up something like url://… and generate the OTP

The point to it is that is supposed to be a secret OTP (one-time). So you print a list it on a tiny piece of paper and keep it in your wallet to guard it like your creditcard.

The password is there to prevent someone from guessing what this logs onto if he ‘finds’ the list of OTP.

You can not -ever- go and ‘publicly’ ask for a password (OTP is just a password). Also, if someone overhears (sniffs) it, it would be ‘jsut as broken as a static password’. BUT with the major difference that a one-time-password would work …. you guessed it: one time only.

So either the legitimate user logs in first and the sniffer fails subsequently, or the sniffer beats him to it and the legitimate user is warned that the one-time password isn’t accepted (meaning: server failure or security breach)

Diocyde • March 21, 2011 2:33 PM

It’s amazing you guys are so focused on the impact vice a vis the actual threat. People in the know have known there has been a FULL FRONTAL assault on cryptovendors for a couple years now. Reference Mandiants reporting of the circumvention of the DOD CAC infrastructure/devices,certificates…What you know or think you know is wholly insufficient. Dont you think its a little convenient that the Adobe Flash 0-day popped at the same time as this being reported? Of course they COULD have been compromised for months, but if thats the case God help us. I write all about it at http://www.conanthedestroyer.net — Educate your selves, you’ve been left out in the cold without a blanket. You need to start identifying the threat and then coming up with real world consequences, not superflous reports that get put on shelves and sell more useless products.

Diocyde

Seiran • March 21, 2011 2:57 PM

@Seth – are you referring to a race attack? RSA ACE/Server and many other security software have features that try to mitigate this attack. If identical login requests are received too quickly, it will log off both sessions.

This assumes that the passive sniffer cannot block the authentic user’s login attempt, and that the authenticating agent has a way to tell the relying service (VPN, Webmail, etc.) to log off all the user’s sessions.

Seth • March 21, 2011 3:07 PM

@Seiran: nice, seems an effective strategy. Thanks for telling me a new tidbit

I did respond to a chain of comments that started with OPIE – normally used on moderate linux boxes without such nicely integrated sign-on sessions, so I assume it works the way it works with me, but I haven’t tested for any such smart behaviour myself.

Andrew • March 21, 2011 3:10 PM

If they give too much detail the chatter will be full of noise. You want to keep the communication channels clear for legitimate suspects to ping the spy networks.

Stephen Wilson • March 21, 2011 3:53 PM

I haven’t used SecurID for many years but I had two of them for a while, one for corporate VPN and the other banking. I believe it was standard practice to have a static password (and user name) as well as the OTP. Is that still the case?

If so then the first response by any corporate to this compromise is surely to have all users change their static passwords? Another good idea would be to suspend as many non-critical accounts as possible, and monitor them for unauthorised usage.

Why has RSA only reiterated all the normal vanilla advice, like ‘have strong policies’? Duh!

tdp • March 21, 2011 7:39 PM

RSA’s latest customer communication still refuses to confirm or deny that the token seed records have been stolen, however the non-denial is starting to become very telling:

“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.”

They also note that token production is currently suspended. We have been persistently asking when non-compromised tokens will be available, but there is no answer so far.

L • March 21, 2011 9:27 PM

Did some research – here’s what I found out.

Looks like the internal IT guys spotted some unusual traffic on their PCs & notified the security team about 2 weeks ago. The company is in total lock down now. Part of the reason they are not saying more is that RSA doesn’t yet know the impact of the breach – the staff is in total shock. There’s also some serious finger pointing going on now.

Raphael • March 21, 2011 10:42 PM

I have been trying to open a RSA KB account for over a week and every time I called them, they were very frantic telling me that the site is down… ok. Then on St. Patties day (when most people will be out drinking) they announce this. During the conf call they did not sound confident and were only reporting what they have to for SEC reasons. I am not impressed with how RSA is handling this.

E • March 21, 2011 11:19 PM

Hope the SEC has fun rewinding / auditing the tale of the stock EMC ticker.
This is very sad, at least some of the “staff” appear to have put there “shock” aside long enough to well, make your own conclusions.

http://moneycentral.msn.com/investor/charts/chartdl.aspx?PT=7&compsyms=&D4=1&DD=1&D5=0&DCS=2&MA0=0&MA1=0&CP=1&C5=2&C5D=1&C6=2011&C7=3&C7D=22&C8=2011&C9=-1&CF=0&D7=&D6=&showchartbt=Redraw+chart&symbol=emc&nocookie=1&SZ=0

For the record, I own no stocks.

AC2 • March 22, 2011 12:41 AM

Re comments that while the numbers generated by the token may be cracked, the PIN is not…

This requires that the attacker knows your token serial no (which is BTW never entered by the end user during validation) either
– via physical access for a limited time
– via an asset register in the organisation that has issued the tokens to users

And also, presumably, the user name associated with that particular token.

Getting from this level of access to the PIN is relatively straightforward
– Call the support desk requesting a new PIN. After some far from foolproof id checks the support desk will basically say ‘tell me your currently displayed code’
– Tell the code generated from the algorithm for the given token/ time
– You will be told that the next displayed code (or some subset of digits displayed) is the new PIN
– Get the PIN from the next code generated from the algorithm

But the user will notice this the next time he tries to logon and gets bumped…

Other way would be to get a keylogger on the target system, but if the attacker can do that then threat of SecureId PIN access is the least of the worries.

Anоnymоus • March 22, 2011 4:28 AM

I work for a large multi-national corporation. Pretty serious about security, a few classified contracts. Remote VPN access is mediated by SecurID.

A few comments:

  1. Our security guys received some information directly from RSA. It was confidential “for the time being”, and they haven’t passed it on. However, they have said that as a result of the attack, “it cannot be ruled out” that an attacker can’t generate valid tokencodes. Various pieces of advice were offered to mitigate the risk until the problem is fixed. One of them is to treat the token’s serial number as confidential. Well, we have always done that. Not to the extent of covering them up, but certainly you can’t send serial numbers over unencrypted email. But now, we will be covering it with liquid paper.
  2. Many RSA SecurIDs are “soft tokens”, i.e. software running on a trusted machine rather than firmware in a key-fob token. Soft tokens should be very simple to re-seed, if that is really the problem.
  3. A lot of people seem to assume that SecurID PINs are 4 digits. Actually minimum and maximum lengths are configurable. Ours are 6 – 8 digits, which is RSA’s standard recommendation.
  4. It is possible to set up ACE/Server to require only the tokencode from the token, with no PIN. Not a good idea. Anyone who has done that is now in a world of hurt.

  5. Our Help Desk has been told to deny all remote PIN resets until further notice. If you forget your PIN, too bad: you can’t login until you come into the office in person.

  6. I’m puzzled by suggestions that RSA may have kept a master seed file to aid in disaster recovery. The admin docs go into detail about backing up data to do your own disaster recovery, and mention nothing about getting help from RSA. In fact so far as I can tell, RSA has no contractual requirement to provide any such assistance.

@Brandioch Connor:
ACE/Server logins support rate limiting if the underlying domain does so (and most do.) The couple I have seen in detail all had very strict lockout policies. Basically, there’s little excuse for getting a login attempt wrong if you are a legitimate user, so it is a routine to regard two failures in a row as an attack based on a stolen token; we lock the account until the legitimate user can confirm what is going on.

By the way, RSA have actually sold 25 million of them. They are by far the most common two-factor system actually in use.

tdp • March 22, 2011 9:28 AM

What I want to know is how possible is it to track state of 25 million stolen tokens? If I am able to determine what a user’s token code is during one iteration of the device, how broad is my search for tokens that were displaying that token code at that time? Are there ways to streamline this? Can I set the seed records up and run a search against a particular time/tokencode value?

It can’t be that complicated of an attack, as long as I have a way to log time and tokencode for each device.

@AC2 – the comments about the PIN not being cracked kind of ignore the fact that you have a weak one-factor authentication mechanism as soon as a serial number can be correlated with a user. This holds for RSA’s security advice as well, they are treating this as if the strong second-factor is irrelevant and the important part is protecting your PIN. That is certainly frustrating, when the strength of the system was predicated on the secrecy of the token seed.

jacob • March 22, 2011 10:08 AM

It is an interesting story for a lot of reasons to me. You will see the “experts” coming out and saying 2 factor authentication won’t work..etc.
Other speculating if it was the seeds that were compromised. If so, why was it accessible?

Above, someone mentioned panic at RSA. I picture people flailing, we gonna die!!! We’re gonna die!!

Seriously, security is never going to be perfect where people are involved. Anything and I mean anything can be broken. The code too hard, social engineering. I rather like RSA’s approach, the seed problem question aside. I would prefer to use a local solution rather then running the risk of someone having it on an outside server. Would it be better to use a local server implementation? Just thinking or as close as I can come to it. 😉

Reginald • March 22, 2011 10:35 AM

It has to be seed data or some other per-token/customer info, as opposed to the algorithm. HOTP/OATH is published in an RFC. Unless, of course, their algorithm was spectacularly poor; which I think we can all agree is unlikely at best.

You have to hold onto the key data for the period between manufacture and activation, I guess it is a small step to keep it longer.

Jacob Gajek • March 22, 2011 3:43 PM

The reasoning for RSA keeping a database of token seeds is as follows:

1) The token seeds are truly random, i.e. there is no way to compute them based on any information about the token, customer, etc.

2) The token seeds are injected into the tokens during production.

3) The token seeds need to be loaded into the customer’s Authentication Manager server so that it is able to process logins for those tokens.

4) The tokens need to be distributed to the customer through a third-party vendor, who must not have access to the token seeds.

It follows that the process must be such that the customer, upon receiving the physical tokens from a third-party vendor, then contacts RSA directly with the serial numbers of the tokens they purchased, and obtains the token seed records from their database.

At this point, RSA could theoretically delete the token seeds for the customer’s tokens (and apparently can be requested to do so), but most customers do not make that request. Instead, the token records are kept in RSA’s database in case the customer ever needs them again (e.g. to rebuild a crashed authentication server).

w • March 22, 2011 4:26 PM

@Reginald , the algo good have a problem not so much the encrypted data, but when you enter keys/file the program would allow a authentication bypass.
One part might need some external value like a serial number or what not to get to the area that is effected.

Daniel Rothman • March 22, 2011 5:10 PM

One item that most folks seem to be missing/ignoring here is the question of clock sync. The ACE Server database also maintains a ‘drift’ for each token. The clocks on the tokens are not super-good (intentionally?) and fall out of sync on a regular basis. The drift calculation on each local ACE server maintains for each token the net drift from ‘true’ it detects, and rejects token submissions that are not previous/next in the scheme.

Assuming compromises as proposed in the comments, assuming an attacker has the UID, PIN, and S/N of the target account, the attacker is still missing the token clock.

Imperfect Citizen • March 22, 2011 5:22 PM

Security is all about trust, and when trust is lost there is no security.

I wish the NSA would read that line. They need to fire a few contractors.

Dirk Praet • March 22, 2011 5:49 PM

In absence of a detailed disclosure of what exactly happened, there is sufficient probable cause to seriously affect SecureID’s trust rating. I took Christian Hessler’s hint and had a brief peek at LiveEnsure. It looks very interesting.

Clive Robinson • March 22, 2011 5:52 PM

@ Jacob Gajek,

“Instead, the token records are kept in RSA’s database in case the customer ever needs them again…”

Whilst all that may be true and even desirable it side steps an important issue.

Why on earth considering the security implications of unauthorized access to this database is it doing connected to an external network either directly or indirectly.

Air Gaps are still part of Network Security 101, even if they can be crossed (with great difficulty) via the use of USB tokens and other media.

There is no excuse for it. I don’t know what EMC/RSA gross income from these products is or what the resulting profit is but the “margins excuse” might be OK for “mom-n-pops knitware site” but for a company who’s entire business rests on “trust” it’s a realy quite stupid thing to do.

Oh and when I say “air gap” I don’t mean “virtulised networks” I realy do mean “no equipment or cable in common” after all it’s not that difficult to hack a level three switch or router to get access toe the “virtual private network”.

Although it may never become (publicaly) clear exactly what has happened at RSA the least that can be said is that “they’ve dropped tha ball” by “playing fast and lose” with their reputation. And for a company that needs to be trusted to stay in business the way they are going about things does not encorage confidence in what they are doing at the managment level…

Reginald • March 22, 2011 6:23 PM

@Daniel R

I think token start times are more than likely to be held in the same place as the SN/key combo, since they need to be served up to the customer’s ACE server when a token is commissioned. So assume that leaked too.

Jabiru • March 23, 2011 2:10 AM

The reason RSA retain the records/ seeds etc is in case a customer loses their copy and needs them. It saves the customer re-issuing all their tokens again which can get kind of crazy in costs.
Vasco have the same issue.

AC2 • March 23, 2011 3:38 AM

@Anonymous

“5. Our Help Desk has been told to deny all remote PIN resets until further notice. If you forget your PIN, too bad: you can’t login until you come into the office in person.”

That’s interesting, so end customers are being affected already…

Clive Robinson • March 23, 2011 4:10 AM

@ Jabiru,

“The reason RSA retain the records/ seeds etc is in case a customer loses their copy and needs them.”

As I’ve said all well and good…

However from what has been said it can be inferred that it is these that the “APT” attackers have got access to (otherwise why are RSA behaving the way they are).

So the question arises,

If these are so importent to the security of the system what were RSA doing keeping them on an externaly available system?

As I’ve said their business is based on “trust” and basic KeyMat handeling procedures is what you would expect from a “Network Security 101” course and they would have said “Segregation segregation segregation”. Which is a true not virtual “air gap” and proper physical and electronic “accsess controls”.

As I noted in my first post on this page what is of most interest to me is the fact that the attackers are walking backwards up the security/trust chain towards the center where the ROI on the attack is likely to be maximized.

What however amazes me is that a security company has not considered this in their business plan and mitigated this serious risk appropriatly by design…

To put it another way if the US Gov had managed to enforce “Key Escrow” on the world and “outsourced” the database to an organisation like RSA how would you feel if you knew that all the information to reconstruct the key had been stolen?

As these tokens are about “access control” and not “communications” then the problem is atleast equivalent if not worse…

Oh and there are better ways of going about “access control” than “two factor” with Psuedo One Time Passwords” and a PIN but in nearly all cases it leads to “user inconveniance”…

Gweihir • March 23, 2011 6:11 AM

For a number of reasons the only real threat should be compromised seeds. Everything else would indicate a rather stupid design and would (in the long run) be even worse. In the short run, if it is the seeds, why do they have them anyways? Or is this one of these low-cost low-security things where the seed is derived in a deterministic fashion from the serial number? That would be really stupid as well, although understandable from a cost perspective. Even then, I would expect the keying to be customer specific, and the key to that keying to be only known to to customer, so that again a compromise of RSA does not help an attacker at all.

As there is no ready repudiation along these lines, I think RSA messed up massively in the design of these tokens and/or handling of the seeds.

Andy G • March 23, 2011 9:45 AM

The seeds could be stored offsite in encrypted vaults; it wouldn’t necessarily matter. If seed recovery is an unexceptional thing, then there will be a human process akin to restoring any other data from archives. Human processes can be social-engineered. 🙂

Rich Rumble • March 23, 2011 10:11 AM

To me, as a user of SecurID, this add’s nothing to the attack vector, it would actually make you do more work than you needed… Just get your malware on a users computer, wait for them to connect to the Corporate Network, and use Pass-The-Hash etc… from there. I’ve seen it a few years ago… One user got backdoored, connected to the network and the attacker went from there. This is why RSA issued the Best Practice’s reitteration, their two factor, unless deployed completely in your Lan doesn’t offer any additional security. Most people I know do the bare minimum, use 2-factor on the VPN and that’s it… If your org goes beyond that, then the loss of the seeds is a bigger deal for them, but most of the org’s I’ve worked for don’t go that far with 2-factor. An attacker can just wait for the user(s) to do things and piggy back after access is granted, nothing new here for me.
-rich

Gweihir • March 23, 2011 1:14 PM

@Andi G

I don’t see how it could be a common process. If the user still has the token, it is unnecessary. If not, it is also unnecessary as the user needs a new token.

Basically, the only use for recovery I see is when the validation server forgets the data. But that is a larger and exceptional situation, that should be possible to secure by 4-eye principle and additional measures.

john walker • March 23, 2011 5:13 PM

Wondering, if the hackers now have the seed code, a simple mitm attack, picking up the auth code, can then generate auth codes for that token?

Gopiballava • March 23, 2011 6:03 PM

All this talk of one time passwords reminds me of my car’s keyless entry system. It guards against replay protection: each bit sequence is valid only once.

Of course, sometimes a transmission is lost. The receiver calculates the next 100 sequences. If you press your remote button more than 100 times out of range of the car, it will lose sync and require a reset procedure that involves telling the car you need to reset, and telling the key fob as well.

I did empirically test it and verified that it behaves like that.

What I was wondering was, can you tell if a transmission is a lock or an unlock, and can you change it?

With a fancy software-defined radio, you could most likely:
Transmit noise in a manner that interferes with the keyfob and stops the car working
Monitor the signal and extract the signal from the noise.
Now, you have the keyfob’s transmission and the car doesn’t.
So:
1. Driver gets out, presses lock button, keyfob sends out s0. You intercept, scramble.
2. Driver presses button again. Keyfob sends s1, another lock attempt. You intercept while scrambling, then immediately re-transmit s0, lock.
3. Driver walks away, you re-transmit s1, modified to be an unlock.

tz • March 23, 2011 9:23 PM

“Security is all about trust, and when trust is lost there is no security”.

I don’ understand this statement. You can have a fully secure physical lock and key that you happen not to trust, and you can have complete confidence in snake-oil.

I suppose you could call it “trust” in the algorithms behind AES or public key encryption as such, but it is more that it has been attacked and so far has fended them off.

The secure IDs though were a case where you had to trust. You don’t know the algorithm, the mapping from the serial number to the secret key, or several other things, and the layers of security protecting them.

You could make similar tokens where each user would have unique key material, public algorithms were used, etc.

Trust but verify?

BF Skinner • March 24, 2011 6:33 AM

ts “You can have a fully secure physical lock and key that you happen not to trust, and you can have complete confidence in snake-oil.”

Probably something to do with knowing more about the threat enviornment. I can doubt the integrity of my lock and key since they are on a shed in the country and could be bypassed/cut/broken without anyone being aware for some time.
I can believe the assurances of my security company in the services they provide because they think about thier processes, have auditors come in to make sure thier processes (inlcuding safeguards on key data) are conformed to and buy people to come in and attempt to bypass their safeguards, correct any problems found.

Clive Robinson • March 24, 2011 9:44 AM

@ tz

You said,

“I don’t understand this statment”

About,

“Security is all about trust, and when trust is lost there is no security”

It all revolves around your definition of “trust”.

In overly generalized human terms we trust people implicitly and get hurt when the trust is broken.

In security terms you only trust where you absolutly have to and not otherwise. That is you take measures to remove what you know as weak links from your “chain of trust”. If the trust in one of those links in your chain is found to be faulty in effect the whole chain is broken, not just that one link.

Kevin R. Winegardner • March 25, 2011 4:39 PM

A fundamental issue for any security solution based on a ‘secret’, no?

Tony • March 27, 2011 9:41 AM

Would not be easier to generate a new seed to replace the one that was apparently compromised?

Clive Robinson • March 27, 2011 12:22 PM

@ Tony,

“Would not be easier to generate a new seed to replace the one that was apparently replace the one that was apparently compromised?”

If it were a software only system then yes.

But we are talking (supposadly) tamper evident physical tokens. That in effect would have to go back to the factory to have their basic seed changed.

This would be a logistic nightmare, however it appears that there may be another way around from some of what has been said, though how effective or secure this will be needs a lot more information than has been given here.

Velaclasp • April 11, 2011 10:45 AM

Three Card Poker is actually two games in one. There is the Play/Ante game where you are playing against the dealer to see who has the highest hand.

GraistorsRida • April 12, 2011 11:07 AM

The reason for this is simple: money and fame have historically been a less powerful motivator for creative types than the prospect of receiving oral sex

Mike Angelinovich • December 21, 2011 5:58 AM

Bruce,

By now I would have thought that Financial Institutions (FI’s) would realize that Single Factor Authentication is NOT very secure! Unfortunately, they continue to use Single Factor to access online bank accounts because either they do not understand what 2-Factor is or they have been tricked into believing they have a 2-Factor solution when they really have Single-Factor. Almost every major Security Provider offers an OTP Token, which displays a code on a physical token, or a card the size of a credit card, or it is sent via your phone. It’s true, these are things you have but all they are doing is providing the user with something the user now knows and must enter it quickly because it is under a time constraint. What the user enters is simply a Single Factor one-time password code under a time limit. So regardless if the RSA hack lost valuable information for their SecurID solution, a Real-Time Keylogger, such as used by the Zeus Trojan, simply steals the OTP code along with the rest of the user entered credentials and immediately logs them into the user’s online bank account login page and gains access.

There are a large amount of 2-Factor solutions that automatically send an IP Address or a Cookie to the authentication server for validation and these are MFA solutions but the two items they are using can easily be moved, stolen, or erased and when that happens these systems will automatically revert to a Challenge Response Question, which is a Single Factor Authentication solution that is not very secure.

Now, the FFIEC states that online Retail banking should use a layer approach to Authentication and one suggestion is to use an Out-of-Band (OoB) solution. So adding a layer of OoB to any of the existing solutions above, we are told, will provide 2-Factor using a phone as something the user has. Again Zeus has repeatedly demonstrated that putting the user on a fake Login page and using it’s Real-Time Keylogger to grab the user entered credentials (including a OTP displayed code) and immediately logging in on the real login page, will instruct the authentication server to automatically place the phone call to the user, who will enter their PIN and the Hacker will then gain access into the user’s online bank account.

This is pretty basic stuff that Bank’s IT Groups need to be aware of not only from a position of Security but so they are not spending money on known and easily breached solutions. I understand that a Bank cannot afford to give all members expensive MFA solutions such as Smart Cards & Readers or Smart USB Tokens. However, there are MFA solutions available that are Software Tokens designed after a Smart Card, which are fully portable and highly secure. Therefore, adding such a layer of this type of security should be used for both Retail and Commercial online bank accounts!

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.