RSA hit by targeted attacks, SecurID 2-factor auth possibly compromised
rsa.com
rsa.com
"""
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.
This sounds like they could well have stolen copies of some customers seeds, which would reduce the RSA authentication from two-factor to one-factor.
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 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.
And yes - the method for SecurID was long ago known - just read the patent.
Edit: I referenced Adobe specifically because of their recent security announcements. HN Discussion: http://news.ycombinator.com/item?id=2328928
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/
Once upon a time http://www.wslabi.com/ tried to create some kind of eBay for vulnerabilities too but it did not seem to go well.
This is a guide I found on /r/reverseengineering on reddit (which actually has a decent community, considering the fact that its on reddit)
http://www.amazon.com/Art-Software-Security-Assessment-Vulne...
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 :)
Yesterday Adobe released a very serious advisory for Flash Player: http://blogs.adobe.com/psirt/2011/03/security-advisory-for-a... http://news.ycombinator.com/item?id=2328928
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.
If you read the various news reports closely, you'll see one vector was the 0-day IE vulnerability, another was malicious payloads in PDFs.
The headlines haven't helped.
http://www.computerworld.com/s/article/9144844/Hackers_used_...
"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"
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.
What could this be? Initialization settings?
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.
I really hope the story behind that rope is more like:
"What the fuck did you do? Every salesman on the East Coast is locked out of the VPN!"
"You told me to reboot ALL the servers!"
Than some crazy RSA security requirement.
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.
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.
http://www.sec.gov/Archives/edgar/data/790070/00011931251107...
With helpful tips like (paraphrasing) "don't use facebook on your critical systems" and "only give people the rights they need."
Too much corpspeak, not enough real information.
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:
62^8 == 2.18340106 × 10^14 combinations
62^8 / 18 000 = 1.21300059 × 10^10 seconds
62^8 / 18 000 / 60 = 202,166,764 minutes
62^8 / 18 000 / 60 / 60 = 3 369 446.07 hours
62^8 / 18 000 / 60 / 60 / 24 = 140,393 machine days
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.
[1] - http://seclists.org/bugtraq/2000/Dec/459 [2] - http://ikecrack.sourceforge.net/