For those who, like me, wondering how SecurID might be affected by attacks on their servers, from Wikipedia:
"""
The RSA SecurID authentication mechanism consists of a "token"—a piece of hardware (e.g. a token or USB) or software (e.g. a "soft token" for a computer, PDA or cell phone)—assigned to a computer user that generates an authentication code at fixed intervals (usually 30 or 60 seconds) using a built-in clock and the card's factory-encoded random key (known as the "seed" and often provided as an ASCII file). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased.
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.
To me that sounds a lot stronger than "the thieves took the SecureID implementation plans and could theoretically build a 'soft' SecureID. Your long, random, hard-to-guess seed still protects you."
To me, what Coviello is saying is don't worry the thieves haven't stolen some secret 0-day that would provide them immediate access through your RSA kit. But they did get something that will make the RSA part of your 2-Factor authentication scheme null and void.
To me, what Coviello is saying is don't worry the thieves haven't stolen some secret 0-day that would provide them immediate access through your RSA kit
I am no security expert (far from it!), but I've seen enough compromise disclosures with inside information to read this the exact same way as you, especially with this note from the advisory:
We recommend customers enforce strong password and pin policies.
Advisories like this are like poetry: every word matters, and a phrase like "... reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack" is too pretty to not raise my suspicion. RSA could be 100% busted, and this phrase would still be technically true.
The second factor is called a "PIN" in the RSA documentation, but the details can be configured by the administrator in a particular deployment. The administrator can set an allowed length range (with minimum and maximum between 4 and 8), and can choose to allow alphanumeric "PIN"s.
RSA's recommendation is for alphanumeric PINs of at least 6 characters.
Note also that a small number of tries with an incorrect PIN but correct tokencode will lock the account as "token stolen".
I worked there 10 years ago and if I remember correctly, the system that generated seed files wasn't on the network. They wanted an "air gap" just for this reason.
And yes - the method for SecurID was long ago known - just read the patent.
I am wondering if this is another case where vulnerabilities in Adobe products were used to strategically infiltrate an organization. Here's hoping for more information soon.
Edit 2: "Another case" in the post implies there are multiple cases. I was thinking specifically of the prominent Google/China hack in which attackers first got access inside the networks of google and "more than 30 companies" based on vulnerabilities in Acrobat Reader.
Source: http://www.wired.com/threatlevel/2010/01/google-hack-attack/
I'm sorry but you can't just throw a name out there like that! They didn't say anything at all that could possibly implicate Adobe. Are you just speculating idly or where did you come up with Adobe?
I apologize -- I should have cited recent events as the reason I brought up Adobe specifically. I did think I worded it in a way that made it clear I was speculating, but I see now I should have been much more specific.
And I was thinking of the highest-profile hacking case I can remember, when Google was infiltrated primarily by vulnerabilities in Adobe software. If I recall correctly, maliciously crafted PDFs were e-mailed to staff with cleverly engineered "From" addresses and subjects. For example, an employee received an e-mail from their boss's e-mail address.
the context may not be right, but you do have a point. flash and acrobat are the easiest attack vector, as it seems that for years now they have almost constantly been vulnerable to one exploit or another, upgrading them is a PITA for users, and they are often easy to exploit
for years now, whatever computer I have myself, or whenever I am setting a network policy (if the owner agrees), I always always disable flash and acrobat/pdf readr.
"Hackers exploited an unpatched vulnerability in Microsoft's Internet Explorer (IE) browser to break into some of the firms targeted in a widespread attack that compromised Google's and Adobe's corporate networks"
"Google and Adobe, the only two companies to have stepped forward thus far to acknowledge the attacks, were hacked using malicious PDF files that exploited a zero-day vulnerability in Adobe's popular Reader software"
It is a bit of a slur, but if _I_ had to attack an organization, I'd do it with PDF and Flash. If I were the CIA, then I'd pay for it. What's the market price for an Acrobat zero-day? A hundred thousand dollars?
Mark is one of the best vulnerability researchers in the world. We used to hang in the same groups, and I remember that there was a 2-3 month period where he found and wrote exploits for vulnerabilities in almost a dozen different operating systems on 5-6 different architectures. the guy is a god
Back then the only way to learn was to try it out yourself. there were no books, only phrack, IRC, and setting up boxes on your own network and having a go at them with a debugger running. you really have to be motivated, as the work is laborious, but worthwhile because there is nothing better than the rush you get from developing your own exploit. it is awesome that ppl like Mark are now writing books and dumping the knowledge they have gained through decades of real experience
there are different types and categories of exploit. local apps and targeting privilege escalation, kernel exploits, server daemons (ie. anything that has a port opening and waiting for a connection), crypto implementation exploits and then webapps and browsers (more popular today).
then there are different discovery methods: black box testing, where you throw data at an unknown system and through known inputs and outputs figure out what is in the box. white box testing, where it is still closed source, but you are able to attach a debugger, and then code auditing - which is simply going through the source code and attempting to find common errors that you can exploit.
you will find that you will levitate to one particular type as you learn. for eg. for me personally it was IIS server (found and developed 6 diff vulnerabilities for IIS 4.0 and 5.0), NT kernel and web apps. good luck with it - if you find something, send it to me :)
There are dozens of forums hosted on Katz Global anonymous servers. Payment happens via anonymous gold-based payment systems like Pecunix. A top-of-the-range zero day exploit can set you back at least 5 figures. Also available: botnets for hire, stolen credit cards, WoW accounts, fake 'high yeild investment' scams and anything else you could think of.
It depends on what was compromised if anything. There could be a possibility of source code leakage which may have an overlooked implementation flaw. Or there could have been some malicious injection in source, or even tools.
If I recall correctly, the "seed" of the tokens are generated at manufacture time and are uploaded to the Token Manager. So it's possible the source was read which could potentially show the method of seed generation, if it's strong that might not be troublesome. I doubt there were any seeds stored along with the source which are then used in production. It's hard to speculate from the lack of information going around.
I've never set one up. There's an RSA encryption cabinet in our datacenter at work, it has red rope around it like a nightclub line and a sign that says no non RSA certified personnel. I imagine anyone who knows what it might be can't confirm what would be useful.
There's an RSA encryption cabinet in our datacenter at work, it has red rope around it like a nightclub line and a sign that says no non RSA certified personnel.
Almost as effective as the ssh banner that says "Unauthorized use is prohibited."
Security through hoping people won't step over a rope is no security at all.
It's my understanding that such login banners are used to provide support for prosecution efforts, should someone break in and claim they did not know that access by random people was prohibited.
I would hope nobody thinks such warning messages are an adequate substitute for human-based and technology-based security measures, any more than wearing garlic cloves or putting up "no guns allowed" signs are replacements for being wary of vampires and armed criminals.
I've only been in that datacenter once and I was signed in by someone with authority to help them with something. Like others have said here, it's more to help with "I didn't know I wasn't supposed to touch it" type cases. The RSA cabinet is the security, the rope is legalease.
A thief broke in to our house and stole some special blueprints from a safe in the drawing room. We don't think they took any cash or gadgets from other parts of the house, but we have so much lying around who can tell?
i have set up rsa auth systems. would it surprise anyone to know that sometimes vulnerabilities are purposefully included because its easier or allows you to keep some old insecure app working? securid is not some golden impermeable shield. it just helps stop a few attack vectors.
It appears as though the data stolen might include RSA seeds. I thought I'd explain what this means for some of the people here not familiar with SecurID.
The seed is used a random key for the token and is used to generate a string of random numbers periodically to use. This is called a one-time pad as you use the numbers in combination with a pass code (PIN) in order to log in. In theory you won't use the same code twice although in practice you can as long as the token number is valid (normally a few seconds).
So this provides you with two 'factors' for authentication - something you have (the token number) and something you know (the PIN).
If you know the seed for a token you can simulate a token [1](or put it on a real one) and use it. Where the token is being used in conjunction with a PIN (probably the majority of use cases) you'd need to know the PIN.
The PIN is between 4 and 8 alphanumeric characters in length, but most people use a 4 digit number (possibly as it's called a PIN and people associated it with bank numbers, I don't know).
Now imagine the scenario, you want to break into PG's VPN and he uses SecurID but you have his seed and you've synced up with his token, but you don't know his PIN. You can take a guess that it's a 4 digit PIN (as is common) and that means a maximum of 10,000 authentication attempts. Using a tool like IKECrack[2] you can brute force about 18,000 guesses with a P3-700, so it becomes quite easy to target an organisation that way.
Likewise you can start brute forcing two factor auth on Citrix servers as well to great extent.
The great thing about all this (from an attacker's perspective) is that people don't change their PINs. Why change one factor when the other is so infallible?
But what if you have a more complex PIN? Well, that 62^8 possible combinations for an 8 character alphanumeric PIN. Let's break this down:
That's for a P3-700, modern computers will be considerably more powerful, although at some point the limitations of the machine at the other end kicks in.
Bottom line - 4 digit PIN and you're screwed. 8 character alphanumeric PIN and you're probably alright.
"""
The RSA SecurID authentication mechanism consists of a "token"—a piece of hardware (e.g. a token or USB) or software (e.g. a "soft token" for a computer, PDA or cell phone)—assigned to a computer user that generates an authentication code at fixed intervals (usually 30 or 60 seconds) using a built-in clock and the card's factory-encoded random key (known as the "seed" and often provided as an ASCII file). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased.
"""
http://en.wikipedia.org/wiki/SecurID