Slashdot Mirror
RSA Admits SecurID Tokens Have Been Compromised
A few months ago, RSA Servers were hacked, and a few weeks ago Duped tokens were used to hack Lockheed-Martin. Well today
Orome1 writes "RSA has finally admitted publicly that the March breach into its systems has resulted in the compromise of their SecurID two-factor authentication tokens. The admission comes in the wake of cyber intrusions into the networks of three US military contractors: Lockheed Martin, L-3 Communications and Northrop Grumman — one of them confirmed by the company, others hinted at by internal warnings and unusual domain name and password reset process."
Sit back peoples, get some popcorn, this should be interesting...
sysadmins and parents of newborns get the same amount of sleep.
1992 called, they wanted the adjective “cyber” back.
Golly Shucks. As it turns out, maintaining a copy of the seed keys for devices we sold specifically as a high-security access control solution on our under-secured network might have been a less than totally good idea... Well, lessons learned, eh?
Comment removed based on user account deletion
RSA keys are compromised, Sony gets compromised, and meanwhile the bankcard industry continues to come down hard on independent retailers to force them to bring their internal systems into PCI compliance. I know small retailers that have invested tens of thousands to secure their WiFi, update their firewall, upgrade their debit pads, all to protect cardholder data. Seriously, what criminal is going to target Joe's Hardware Store to snag a few hundred bankcards? These guys want the big targets. As Willie Sutton didn't say, "That's where the money is". Criminals are going to aim at the top of the food chain, not at the mom and pop store. And even if they do hack the mom and pop store the damage is minimal compared to an RSA or Sony breach.
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
Are there any big, important checkbox-compliant certifications that RSA's customers might have been using the (Not Cheap) RSA tokens to obtain that, as a consequence of this sordid episode, might no longer be attainable with RSA gear? That seems like it would be a fitting punishment for RSA's questionable security practices and even more questionable disclosure practices; but I'm afraid that I haven't wrapped my head around the alphabet soup of compliance acronyms in different areas enough to know.
Am I the only one getting frustrated by all those companies telling everyone that no important/usable data was taken/accessed and comming out a month later with "Sorry, finally they took everything."
Sony, then RSA, even fucking congressmens seem to think lying to everybody is OK.
To hell with the fuking lies.
...is that I'm going to have to fiddle around to get my RSA key fob off my keyring so I can put a new one on. Damn keyrings always end up hurting my nails.
Here is a link to RSA's official statement made yesterday. They are offering to replace tokens for "customers with concentrated user bases typically focused on protecting intellectual property and corporate networks".
That is corporate VPN, not the people who use tokens issued to get to websites, such as banking info.
Learning HOW to think is more important than learning WHAT to think.
Wow, SecurID is broken. Maybe now my company will move away from the shitty VPN software they use.
Nah, how about just offer them a "sorry" and a couple of old games and call it even?
Command attempted to use minibuffer while in minibuffer
How else would it work? The things change every minute: that's 31.5 million different numbers across a year, and yours have to be different than anyone else's. You think they just fire up the old pseudorandom number generator and cat 30 million numbers into a file, then keep track of which set of 30 million numbers needs to go onto the fob for any given company that might order one? The numbers are calculated based on an algorithm, a seed (which is unique to every company) and the current time/date. Since the seeds are compromised, they has got problems.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
Our secure tokens are Yubikeys. We use RFID for physical access and the challenge response protocol for authentication.
We didn't like the thought of having to trust a 3rd party with our keys, so we run our own authentication services and use our own "seeds". This way we have one less attack/exploit surface (the MFG) to worry about -- Looks like it paid off for us this time!
Key Lifecycle Management
Re-configuration of YubiKeys by customers
If RSA has your keys... are they really secure?!?!!
we're now scrambling to envisage and generate reports from authentication logs for exceptions that might indicate we're being attacked or have been successfully attacked in the past.
why would you need to scramble? shouldn't you be looking at this anyways? on a regular basis? sure this is a good reason to take a second look - but be scrambling.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
but be scrambling.
*but *shouldn't* be scrambling
sorry edit ate text
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
All I can find is the usual journalistic garbage, some fear mongering here and there, some harsh comments about RSA, some financial "news" commentary. No real information.
Can anyone on /. with technical knowledge, comment on the hack breaking the entire system (essentially, rooting the auth system) or is it just breaking one of the two factors, that being able to predict the "random" number generation of the keyfobs, so I'm down to merely having a pretty good "one factor"?
Also is the protocol poorly enough designed that the attackers don't need to know anything about the keyfobs, or rephrased, does keeping the serial number info etc about individuals keyfobs secret prevent the break?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
They care more about their reputation than the service they provide. If someone else announces the problem, they are either "speculating" or they have dangerous inside knowledge which would be hard to prove without official acknowledgement from the company. But after so many others came out, it became increasingly difficult to "deny it without denying it" as their corporate lawyers and PR staff usually do. And at just about the same time that congress is beginning to wonder what's going on and call a hearing, they pre-empt by announcing it themselves.
My company's parent company uses these extensively on their gigantic network. When the story first came out about RSA I asked "should we be concerned?" The answer was "No" at the time. Of course, the answer is "yes" now as my company's parent company is one of the world's largest.
In fairness to RSA, they did release updated best practices to their clients right away and had reason to believe (accurately) that the attackers were interested in the defense industry specifically, so they focused on fixing that first. Really, as long as you lock your system down if someone starts using the wrong RSA token with the wrong username repeatedly, then the chances of an actual penetration are still pretty minimal, at least for any sizable key-space. It's not a situation that would occur in almost any situation in real life, so setting the threshold for lock down to even 2 attempts would be sufficient. Sure it is still much less secure, but with a pool of say 100 users, you are still talking a .01% chance of a breach not being detected and shut down before being effective. That's still a very insignificant, particularly considering it leaves a very characteristic fingerprint of the attack that would make it rapidly obvious if someone was trying it on a large scale and they could take measures accordingly. (Statistically, a broad attack against all RSA clients would likely have a success, but it would still be complex to carry out quickly as usernames and passwords would need to be obtained for the targets as well.)
AJ Henderson
Not that your fundamental point is wrong, but the number only needs to be unique for that authentication server for the 10 second window that the number remains valid. In other words, numbers can be reused amongst users, but not in the same time slot.
we're now scrambling to envisage and generate reports from authentication logs for exceptions that might indicate we're being attacked or have been successfully attacked in the past.
why would you need to scramble? shouldn't you be looking at this anyways? on a regular basis? sure this is a good reason to take a second look - but be scrambling.
Having been there / done that, what he means is that today, over and above the normal procedure, some PHB around 5 to 10 levels higher in the org chart has mandated that he will call every person who logged in on the telephone and verify that at that time and date it was in fact that person who logged in and not someone else. Or similar level of foolishness.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Yep the RSA keyfob is basically doing something like an MD5-challenge (based on the time I'd assume) over SSL,* and this is like the private keys being stolen. It's not a one-time pad (which would actually be a pretty decent idea, but you'd need a new keyfob when the logins are depleted).
*Educated guess, I don't know exactly what it does
"When information is power, privacy is freedom" - Jah-Wren Ryel
After all, at a minimum they had the same access to these networks that the hackers do.
I am very small, utmostly microscopic.
that wouldn't be at all practical. Why store millions of codes (one per minute for the lifetime of the devce) when very very few of them would be used. I use my RSA token maybe once a week on the days when I'm working from home.
2 minutes spent on wikipedia shows you g how 2 factor RSA authetication works.
And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
Comment removed based on user account deletion
If they actually cared about providing security to their customers instead of covering their own asses they'd have kept their customers fully informed, but they didn't.
Have you read their statement? They *still haven't* kept us informed. All they've said is that they'll replace the tokens, and that "the information taken from RSA in March has been used as an element of an attempted broader attack on Lockheed Martin".
Nowhere have they said that the seeds are compromised, nowhere have they told us exactly what information was leaked, only that the leaked information played a role in the LM attack.
The mind boggles.
Check to see if your Company name is available http://bit.ly/m2IHF4
Comment removed based on user account deletion
Their public statement, and their NDA-protected message given directly to clients are two, very different things.
I'm god, but it's a bit of a drag really...
After Enigma, Crypto AG, the Clipper chip initiative - the past would say your right.
Young nerds go to public international crypto conferences, see the new big public math.
They run back to their employee and buy generation after generation of closed boxes promised to be based on the safe math they so enjoyed with their peers.
Domestic spying is now "Benign Information Gathering"
Comment removed based on user account deletion
If you need to keep this machine super-secure and only serving a specific kind of data.....then talk to it via a serial port. No network stacks, no "oh that machine was under-utilized, so we added this function", no nuthin. I hated serial back in the day, but if this shit is going to keep happening, then kill it with fire.
Serves them (rsa's customers) right for not understanding what it is they were buying into...
A system where someone else generates and retains a copy of all the keys, requiring you to have blind faith in that party to keep them secure... Did noone else see the serious flaws in such a system?
In order to build a secure system, look at encryption...
How encryption works is well known, the major algorithms are public knowledge, and are tried and tested. And yet the keys, when used properly are known only to the party who owns them...
You don't run a closed proprietary encryption algorithm, and you don't trust a third party to supply you with crypto keys... That is, unless you're a fool.
If you use such a system, you are placing blind faith in the third party who supplies that system... That party might sell you out to government agencies or for commercial reasons (ie highest bidder), might get hacked, might be infiltrated by a rogue employee, might leave a disk full of data on a train etc...
Because they are an external entity you have no control over them, you probably even gave away your right to sue them when you agreed to the license terms on their software... You are utterly beholden to a company you have no control over, basically they own you, and anyone who owns them also owns you.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
No physical damage was done.
Best Slashdot Co
As far as I can tell the only advantage of this RSA keyfob over SSH passphrased keyfiles on a flash drive is...
Well actually there isn't much of one. With the keyfiles on a flash drive, you have to physically steal the drive or get the data off the drive somehow, and then know the passphrase. If you physically steal this keyfob, you have the keys to the castle.
"When information is power, privacy is freedom" - Jah-Wren Ryel
that is all fine and sounds good - but i don't consider that scrambling.. i guess to me its just a different meaning.. to me scrambling would be - having to figure out what needs to happen to be able to figure out where you are.
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
If I were in business doing high security work, I would design a secure network that is physically separate from the corporate one and have all jacks on the secure network colored in red with red cables. No software development related to high security work or high security information would be allowed on the corporate network. There would be no permanent connection to the outside world from the secure network. In the event that data does need to be transmitted, I would use a dial-on-demand style connection like PPPoE and wrap the data in sftp or scp encryption keeping the connection open only long enough to transmit, then dropping it. This is really the only way to stymie would be intruders. The connection would not be open long enough to try brute force methods. And, finally, perhaps most importantly, use OpenBSD to secure the network for when the transmission line is opened.
Not quite. When it comes to multifactor authentication, knowing the numbers from the fob is only one factor. You usually also have to put in a password.
Imagine an SSH keyfile with no passphrase, which gets you to the login prompt.
In fairness to RSA, they did release updated best practices to their clients right away and had reason to believe (accurately) that the attackers were interested in the defense industry specifically, so they focused on fixing that first. Really, as long as you lock your system down if someone starts using the wrong RSA token with the wrong username repeatedly, then the chances of an actual penetration are still pretty minimal, at least for any sizable key-space.
The "updated" best practices is just a rehash of normal best practices. Meanwhile, customers are in the dark as to what exactly is the threat they're dealing with. I suspect you're right in your description of the threat. But the problem is that it remains pure speculation. We just don't know. A security company should not be leaving their customers to speculate and second guess when they do, in fact, have facts available to them. RSA and their customers would be in a much better position if RSA would have simply stated what the compromise was and provided analysis on what they think that means to their customers. RSA's attackers likely already know.
Oh that makes sense. It looks like Lockheed-Martin only required the numbers from the fob though.
"When information is power, privacy is freedom" - Jah-Wren Ryel
If you are a current customer however, was it you or some other employee who evaluated a system where a third party holds copies of the keys, and deemed such a system fit for use? Surely a system like this, where you are utterly beholden to the supplier would raise a red flag?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
...That if I use a random computer, it can't copy the entire token the second I plug it in?
...That the user can't clone it because it's a physically secured device?
...That there exist robust services and integration with corporate networks to manage them and various enterprise-level software is already set up to interface with them?
I could come up with others, but hopefully I made my point. Yes, RSA screwed up. Yes, they never should have had the keys. But, they really have put a lot of time, effort and money into these. Random ad-hoc solutions like yours may be fine for your home network, but they don't scale to the scale that large enterprises and corporations (RSA's main customers) act at. They also don't come close to solving the problems that these tokens do.
Comment removed based on user account deletion
Just thinking about this pisses me off. SecurID in its current form does not deserve to exist. Simply rerolling the database and issuing new cards is NOT a valid response.
There is no excuse for token vendors not giving their users the tools to program their own fricking tokens they paid for without absurd greed motivated dependancies on RSA.
Given the expense of SecurID and its intended use in high security environments who the hell wants a threat model that includes a third party company? Why are they even storing this data after giving the customer the required license data for the tokens?
Not a single customer should have had any risk of compromise as a result of RSA being hacked. It is inexecusable. Those effected should demand more from RSA than business as ususal.
Yeah, I agree that they need to be more forthcoming with detailed info. I was just defending that they are not untrustworthy as the previous poster had indicated. Though really, it is well understood how the system works and what information could potentially be compromised on their systems. It sounds like it was pretty much the worst case scenario that could occur (the situation I described is basically the worst possible case). It basically assumes that the token value is known and the only thing not known is the token that goes with a particular user. That said, I do realize now that the situation would actually be worse then though. If you can monitor someone's connection, you could gather their token and then run that timestamp against the known tokens to identify the pairing, granted you need to be able to MIM attack it, but it does raise my risk assessment by multiple orders of magnitude.
AJ Henderson
Like many a company before them, they realized that their name alone was their most important asset. Some senior executive decided to save a few bucks by capitalizing on that name. The shareholders lose out, but the people who made those decisions have long ago collected their bonuses.
Yeah, I agree that they need to be more forthcoming with detailed info. I was just defending that they are not untrustworthy as the previous poster had indicated.
I would argue that not being forthcoming with detailed information concerning the effectiveness of your product(s) has a major impact on how much one can trust a security company.
Though really, it is well understood how the system works and what information could potentially be compromised on their systems.
The devil is in the details. Compromise of seed keys means something very different than compromise of source code for a SecurID authentication appliance (as examples). There is all manner of potential but exactly what happened is important to determine the impact. Speculation is no substitute for facts.
If you can monitor someone's connection, you could gather their token and then run that timestamp against the known tokens to identify the pairing, granted you need to be able to MIM attack it, but it does raise my risk assessment by multiple orders of magnitude.
Agreed - this would mean a significant degradation of the product and expose it to a major attack scenario tokens are supposed to be thwarting (keyloggers). And again... this is why detailed information is important where generic assurances and best practice lists are no substitute.