Bruce Schneier
Schneier on Security
A blog covering security and security technology.
« Screenshots of Chinese Hacking Tool | Main | Facebook Privacy Guide »
August 30, 2011
Details of the RSA Hack
We finally have some, even though the company isn't talking:
So just how well crafted was the e-mail that got RSA hacked? Not very, judging by what F-Secure found.The attackers spoofed the e-mail to make it appear to come from a "web master" at Beyond.com, a job-seeking and recruiting site. Inside the e-mail, there was just one line of text: "I forward this file to you for review. Please open and view it." This was apparently enough to get the intruders the keys to RSAs kingdom.
F-Secure produced a brief video showing what happened if the recipient clicked on the attachment. An Excel spreadsheet opened, which was completely blank except for an "X" that appeared in the first box of the spreadsheet. The "X" was the only visible sign that there was an embedded Flash exploit in the spreadsheet. When the spreadsheet opened, Excel triggered the Flash exploit to activate, which then dropped the backdoor -- in this case a backdoor known as Poison Ivy -- onto the system.
Poison Ivy would then reach out to a command-and-control server that the attackers controlled at good.mincesur.com, a domain that F-Secure says has been used in other espionage attacks, giving the attackers remote access to the infected computer at EMC. From there, they were able to reach the systems and data they were ultimately after.
F-Secure notes that neither the phishing e-mail nor the backdoor it dropped onto systems were advanced, although the zero-day Flash exploit it used to drop the backdoor was advanced.
Posted on August 30, 2011 at 6:25 AM • 42 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
JR Smeets • August 30, 2011 7:22 AM
Hi Bruce,
A Dutch company, Diginotar, caused an epic fail: the Iranian governed obtained from them an https certificate for google websites. Either by a break-in or through normal procedures.
Obviously the Iranian goverment used this to snoop on their citizens.
Firefox, IE and Chrome browsers will drop the root certificate of the company. This will cause many Dutch https sites to produce certificate warnings. Among these sites is the website digid.nl, which is a goverment website that is used by the public for logins into government websites and for signing online tax forms.
Security Skeptic • August 30, 2011 7:23 AM
Agree with Paeniteo. Calling an attack for which you have no details regarding delivery method, no executables to examine, etc. an APT serves no one except the vendor trying to FUD buyers. FUD is the vendor's social engineering tool. Someone ought to come up with a way to gauge FUD per acronym and build a warning system into browsers.
JR Smeets • August 30, 2011 7:28 AM
Here's a link (Dutch)
"Iran can snoop on gmail traffic because of Dutch certificate"
http://webwereld.nl/nieuws/107747/...
and "DigiD will be marked unreliable after Firefox update"
http://webwereld.nl/nieuws/107757/...
and a link from F-Secure in English
http://www.f-secure.com/weblog/archives/...
martensms • August 30, 2011 7:30 AM
The exploit / backdoor wouldnt have worked out on a system that is configured correctly and differs between userspace and systemspace correctly. such exploits are nearly impossible on linux. sure, you can exploit a kernel mod, but thats the only way and its then hard to get a socket run, though.
exploiting an nt kernel is just easier... mostly because of falsely configured systems.
sure, software runtimes like java, mono and stuff all have bugs and can result in a memcopy, but you are not forced to use them, right?
but i mean... an actionscript / flash exploit is not like low level exploiting a kernel mod. pretty anyone can do that in a 30min tutorial =/
kingsnake • August 30, 2011 7:49 AM
Attacks don't need to be "advanced" to be successful. Never make the mistake of thinking that just because an enemy is unsophisticated, he should not be respected ...
Clive Robinson • August 30, 2011 8:20 AM
@ JR Smeets,
"A Dutch company, Diginotar, caused an epic fail"
I put up some info on this and links to a Firefox work around over on the friday squid page early this morning,
http://www.schneier.com/blog/archives/2011/08/...
Oh and it looks like Microsoft has also joined Google Chrome and Mozilla Firefox in the ripping out of the root cert for DigiNotar (which may be the kiss of death for them),
http://www.microsoft.com/technet/security/...
Oh and on their website DigiNotar claim to be a Vasco Company... So they not be as small in effect as people think...
Bruce, RSA *is* talking, just not in public. We're a medium-sized business and have been able to interact with them directly and get very specific details that I cannot disclose here.
Jimmm • August 30, 2011 9:08 AM
@ Al
I second this. Having had some interaction with various large organizations, RSA is definitely taking steps to brief (in some detail) those affected.
Anonymous 1 • August 30, 2011 10:44 AM
swim: Same reason we need it in our web sites, because it allows Adobe (and before them Macromedia) to sell more of that crap (i.e. no real reason).
Though on the web it allows for ads to be more annoying than normal which some people (i.e. marketing scum) seem to think is a good idea.
Brandioch Conner • August 30, 2011 11:19 AM
@Al
@Jimmm
I don't think you understand. If they aren't talking about it in public, then anyone can claim anything about what they're saying in private.
"...and get very specific details that I cannot disclose here."
Great. And useless. Why aren't they providing that same information to disinterested 3rd party experts?
RSaunders • August 30, 2011 11:24 AM
@ swim
Because we can. And the fact that this sort of analysis never gets the publicity of the initial event. If "Flash in Excel ruins RSA" was the tag line on CNN today then some CIOs might email their Microsoft support rep and say "Is there a setting to turn that feature off?". Enough blame from enough CIOs might bring about some security. Without the blame, the bloatware vendors just have no reason to stop. In some circles, "better security" is on the list of reasons we need to upgrade to the new version of Microsoft {product name here}. If we were only getting more security through the removal of all this sort of code, then it would be worth it.
OldFish • August 30, 2011 11:24 AM
We "need" flash in our spreadsheets because numbers are just soooo boring. All the electronic crap in my car is what really worries me.
swim • August 30, 2011 11:48 AM
@OldFish
Automotive electronics shouldn't be a security problem...until the manufacturer starts plugging them into a cellular radio for remote control and then selling that as a feature.
I put up some info on this and links to a Firefox work around over on the friday squid page early this morning
Indeed, Clive got the scoop. Please post any further comments about Diginotar to the squid thread.
Chuck • August 30, 2011 1:18 PM
Discussing different vectors to drop an attack is imho a bit of an eyewash...
There are and there will ever be bugs or whatever that can be exploited. Especially in an large environment with ecosystems of different applications for accounting, development,... each (more or less) needed in its specific sub-environment. However, when it is enough to affect one sub-environment to be able to elevate an attack on the whole system (including sensitive components), the barriers in between are the crucial point to discuss.
+ the communication to the outside. Who wants to trust somebody after such a disaster with such a disaster of PR...?
Anonymous 1 • August 30, 2011 2:14 PM
swim: Why don't you read up an old post like http://www.schneier.com/blog/archives/2010/05/... and then see how much you still think it isn't a security problem.
swim • August 30, 2011 2:48 PM
@Anonymous 1 at August 30, 2011 2:14 PM
uh, you do realize that that the paper in the post I linked to is the follow-up to the paper discussed there?
Kenny • August 30, 2011 3:16 PM
What I still don't understand if how a break in at RSA could possibly lead to the break in at companies using the tokens. Why does RSA keep a database with the token seed information for any disgruntled employee to leave with?
I would have expected token setup process to be air gapped with the seeds written once to CD and sent to the customer with the batch of tokens. I can see no reason for RSA to hold on to them.
jD0g • August 30, 2011 5:34 PM
It’s great to see some more details on this; it’s a fail on so many levels. As bad as it is for RSA, no one in IS can deny they secretly love when this stuff happens. This coupled with the Sonpocalypse (and the other juicy ownages this year) has given what we are working on a nice little foot up the butt, not too mention the increase in budgets, wages, contract rates… keep bringing on the headlines fellas, Daddy needs a new car.
nobodyspecial • August 30, 2011 9:46 PM
>I can see no reason for RSA to hold on to them.
Until the customer rings up and says - we forgot to back up the system with the keys on it / our admin deleted them / we changed IT supplier - can you reset them?
If RSA say - "no you have to spend $M on buying and distributing new keys" then they will lose a customer.
Luke • August 31, 2011 12:37 AM
Well this explains how the attackers got access to resources within the corporate network. According to the information available these where not end points of high-value victims - so that doesn't really explain how they apparently got the "keys to RSAs kingdom". Anyway none of this published by F-Secure looks new to me. RSA already published an article on their blogsite months ago! http://blogs.rsa.com/rivner/anatomy-of-an-attack/
Bruce, I'm quite surprised you find this information a) new b) are considering this as "details" of the attack and c) that this might be evidence keys have been taken. If we have missed anything please let us know ...
Nick P • August 31, 2011 1:37 AM
@ nobodyspecial
Does this explain why the computer with access to the database needed to be able to run arbitrary, risky applications and have Internet access? Does it justify the risk? The sheer amount of risk and potential damage justified a medium to high robustness solution. In this case, it would be simple: two PC's (one low watts & specs), IPSec VPN for one to access protected token network, a KVM switch, a non-DMA link between them, and a validated cross-domain transfer mechanism. That by itself would have limited any attacks to getting the data the support personnel needed for the specific customers they worked with.
A security-oriented virtualization solution like Green Hills Padded Cell, HAP, NetTop, or even PitBull might have limited partly or wholly damage if one PC was used. Software isolation with regular VM restarts to clean slate might also have prevented persistent infection. Even DefenseWall or Sandboxie would have probably stopped this attack at a whopping $30 or so.
The point is, a simple solution would have worked & the basic implementations were cheap years ago & even cheaper today. They broke every principle of protecting high value assets by setting up their network the way they did. Doing it right would have still let them help customers, get work done, and make plenty of profit. (And the breach would've been a non-issue practically.) RSA just did what most "infosec" companies do today: the exact opposite of what they preach businesses should be doing.
7 deadly sins of network security - RSA Conf 2008
http://www.csoonline.com/article/470095/...
(I see five sins for sure. Maybe there's two I don't know about. Come on, RSA. Confession is good for the soul.)
grumpy • August 31, 2011 2:28 AM
Heh, as usual the weak link in the security fence is a human. Skynet will solve that, no extra charge.
Several rather large fails there then:
- Human error (the biggest one): it's not *that* convincing of a phishing email. I'd probably be suspicious of it even if I did business with beyond.com. I will concede that they probably cherry picked people (admin/HR?) with lesser IT/security knowledge though. But we can still conclude insufficient/ineffective training.
- No air gap for the really sensitive stuff, as mentioned above. Presuming I'm right about the malware being sent to those most likely to open it, why were they on the same network as the secrets?
- Re. ActiveX in spreadsheets. It's a 'feature', I'm not sure why it's there either. What I do know is that it's perfectly easy to disable through group policy. The functionality is disabled on my work computer for this exact reason.
- Network edge security seems lacking; those UTM/firewall boxen aren't my specialist subject, but I was given to understand that if properly set up they should have picked up the connections to c&c servers (especially since they were already noted for serving malware!), and the exfiltration of that much data?!
Salamandro • August 31, 2011 8:29 AM
What ports does Poison Ivy use? If anything else than http over a proxy, why was that allowed on the firewall?
If there was a proxy, why did it not block the request to a known malicious site?
But as before mentioned, the question as to why RSA stores the seeds (apparently they do?!) of sold tokens, is still the biggest issue for me.
Fortunately, we're going to implement ELCARD soon. Swiss company and no more hassle with ridiculously epensive tokens.
confused very • August 31, 2011 9:39 AM
Why do hacks have to be the best? Doesn't 'good enough' work? After all they got what they were looking for.
NobodySpecial • August 31, 2011 9:46 AM
>Does this explain why the computer with access to the database needed to be able to run arbitrary, risky applications and have Internet access?
Oh that's just because they are drooling morons who shouldn't be allowed near sharp objects. But since they work in the computer security industry then that's pretty much a given !
@ Salamandro: from the RSA blog, exfiltration of data was via FTP upload of multi-part rar archives.
It's pretty shocking they didn't have the technology in place to prevent that. I can certainly only FTP to pre-whitelisted servers here, and it's a reasonably lengthy process with multiple forms to get e.g. a new supplier's FTP site approved.
It really boggles the mind that a *security* company failed to implement anything similar...
Brandioch Conner • August 31, 2011 11:22 AM
@Al
"Need to know, dude. You don't need to know."
No. You are missing the point.
Because RSA isn't telling the public, anyone can make any claims they want to.
The correct handling of the situation would be to reveal as much as possible so RSA's customers could make informed choices about their security practices.
As others have pointed out, the fact that something was stolen means that RSA had a security problem to begin with.
Now the questions are "how big of a problem did they have" and "how does that problem affect me".
Security through obscurity is not effective security.
Nick P • August 31, 2011 1:39 PM
@ salamandro
The ELCARD solution is pretty interesting. The only other paper-based solution that seems usable is Perfect Paper Passwords. It uses one-time 4 character tokens from a paper sheet, maybe in combination with user/pass. Although PPP is easier to use, ELCARD has some advantages like the "something you know" part and the fact that less paper is needed. In a smaller organization, that PPP has no licensing costs & little operation costs might offset this. The brochure says each ELCARD server does 10 authentications a second. This sounds slow compared to many other techniques, but I lack the data to compare to PPP. Both are better options than SecurID. ;)
ELCARD
http://www.elca.ch/sites/elca.ch/files/resources/...
Perfect Paper Passwords
https://www.grc.com/ppp.htm
Nick P • August 31, 2011 1:42 PM
@ S
"It's pretty shocking they didn't have the technology in place to prevent that. I can certainly only FTP to pre-whitelisted servers here, and it's a reasonably lengthy process with multiple forms to get e.g. a new supplier's FTP site approved."
More shocking considering the company sells "Data Loss Prevention Suite", monitoring, "adaptive" authentication, compliance management, etc. They had all the tools they needed to prevent attacks like these. And with no licensing & unlimited support. ;)
Mark Currie • August 31, 2011 4:04 PM
The issue of vendors keeping backup keys for customers is not uncommon and is often associated with symmetric-key type systems where there are a large number of end-points that have distinct keys that cannot be changed.
If the key database gets nuked, all end-point devices have to be replaced, or recalled and re-keyed. Replacing or recalling the end-points can be extremely costly and often much more costly than the initial roll-out.
These are often low budget systems where there is not enough spent on the server-side IT and training. There could also be a high churn rate in personnel who may also not be too competent when it comes to backups and security practices.
This is a recipe for disaster and a disaster is not good for future business so the vendor chooses to keep backups of the customer keys. Over time with many instances of the same system being sold, the accumulated keysets represent a very high value target for thieves.
PKI based systems can certainly have an advantage here but they are typically much more expensive. Symmetric key systems still prevail mainly due to cost at the end-points. So it would be a worthwhile discussion to come up with ideas for improvements in these situations.
Some good ideas have been suggested here but my gut feeling is that you really want to try to prevent the accumulation and single point of failure in the first place.
A low budget, reasonably idiot-proof backup/recovery system for each customer would seem be preferable, but you still have to rely on the customer in that case and the problem always comes down to who has the most to lose? Sometimes it can actually be the vendor, especially when there is a big reputation at stake.
Wouldn’t it make more sense for the vendor to distribute the keysets into several off-site storage points e.g. bank deposit boxes? Then the deposit box keys would have to be dealt with…
Bosh • August 31, 2011 9:44 PM
@Al
@Jimm
re "specific details that I cannot disclose here."
Thinkin Bruce and most everyone here has read all the same excuse emails and has been invited to the same commiseration woo is us drink our cool-aid meetings.
One question do you trust them more or less.
Would you buy another hardware based 6 character numeric password generator again in the future?
Hows your 1 factor 6 number, low complexity, low entropy password working out for you?
Did you ever feel a need rewrite your password complexity policy to support an exception for this low value solution?
Must hurt to consider all the $ spent on a product with near zero improvements from a 30 year old password concept.
If this didn't tip your boat over, consider, what will it take for you to require a device which would meet a modern complexity, length and revocation and manageability requirement?
remember its not magic, its just a crappy 6 length numeric password (they call a pin) and as been proved to have more than one fully exploitable weak link.
AC2 • September 1, 2011 1:41 AM
@Salamandro, Nick P
Thanks for pointer to Elcard. Although after seeing the sample Elcard on their site (13x11 grid with alphanumeric and special chars) I realise I have something similar on the back of my bank debit card.
Of course the available space on the back of the debit card is much smaller so only have a 16 cell grid, but each cell has a 2 digit number so that helps a bit.
Is used to authorise netbanking transactions, in addition to the transaction password. Well yes it doesn't authorise the transaction but its better than just a password I guess
And no I don't hand over the debit card to swipe at a shop/ restaurant...
Clive Robinson • September 1, 2011 8:30 AM
@ Mark Currie,
"PKI based systems can certainly have an advantage here but they are typically much more expensive. Symmetric key systems still prevail mainly due to cost at the end-points. So it would be a worthwhile discussion to come up with ideas for improvements in these situations."
PKI in key fob tokens is not likley to happen for a while. Because the cost is two fold, the first is the vast increase in silicon space or CPU cycles, the second is the cost of a battery to support the extra silicon or cycles.
Effectivly this would mean that the tokens would need replacment batteries and this might cause alsorts of user support issues over and above those that currently exist, at the very least you might get a techsup call every three to six months to deal with the dead battery issues.
Also the problem with "low cost solutions" is that generaly they are not...
For instance, your simple sugestion of,
"Wouldn’t it make more sense for the vendor to distribute the keysets into several off-site storage points e.g. bank deposit boxes?"
Has rather more issues than just,
"Then the deposit box keys would have to be dealt with…"
For instance "farming out" increases the attack surface and vectors of attack. So you store them as encrypted DB's which now gives you Crypto key managment issues as well as physical deposit box keys and valid signitures...
Then there is timelyness you are looking at a day to get the customer request, go to the bank, get the disk and copy off the correct details and return the disk back into the vault whilst ensuring it was not compromised in some way. Longer if it's the afternoon before a four day weekend (which by the way is when it is most likley to happen due to "planed maintanence/upgrade at the customer". The customer of course will be on the tech support guys case atleast every hour because they will have a lot riding on it.
I could go on, but most people can see from this there is a lot more behind this than appears at first glance, and all have either a direct capital cost or an indirect reputational cost, in a business with steadily decreasing profit margins.
The anoying thing is it's actually quite simple to set up a TAN type system of each user having an (apparent) OTP set of numbers on a piece of paper.
Dirk Praet • September 1, 2011 6:54 PM
Email spoofing ? Did they forget to implement SPF at beyond.com before these events ? A quick query shows they do have it now:
beyond.com. 3600 IN TXT "google-site-verification=KjKqze_iZhVAkA1nlt4IMY_DjUZ-JqqfOhF9wWCqCI4"
beyond.com. 3600 IN TXT "google-site-verification=SY8La9SFnNRVL-Xw00hQBWbJFGfGxxcQIwMNqd7nEXM"
beyond.com. 3600 IN TXT "v=spf1 a mx a:mail.beyond.com mx:beyond.com mx:techcareers.com mx:artemishr.com mx:beyondcareers.com ip4:70.91.25.237 ip4:67.216.72.172 ~all"
beyond.com. 3600 IN SOA dns1.name-services.com. info.name-services.com. (2002050701 10001 1801 604801 181)
beyond.com. 3600 IN NS dns5.name-services.com
beyond.com. 3600 IN MX mail.beyond.com
beyond.com. 3600 IN A 68.168.84.140
Mark Currie • September 2, 2011 10:03 AM
@ Clive Robinson,
“PKI in key fob tokens is not likley to happen for a while….”
Yes that was really my point - symmetric key system end-points are much cheaper so they will be with us for some time. Therefore it is worthwhile contemplating alternatives for key backups.
I am also trying to cover the general case i.e. not just authentication OTP, but also encrypt/decrypt.
Ideally customers should take responsibility for their own security systems. So perhaps what vendors should do in cases where the customer is not confident/competent is get them to pay for an independent key custodian. I think that PricewaterhouseCoopers offer services like that.
Derek Harris • September 3, 2011 11:31 PM
To the best of my knowlege, the exploit used does not elevate user privileges, so the only way that the malware could have installed is if RSA allows its users to have admin permissions. This is the most basic failure of security for any computing system. The root (no pun intended) problem is that many, if not most, companies allow their user accounts to have local administrative privileges. Microsoft makes it too easy to perpetuate this bad habit by making all local user accounts administrators by default, and UAC is just a crutch that does nothing to solve the security problem (though it does make it even easier for everyone, including admins, to use a normal user account). Linux is designed slightly better in this respect, and blocks root login to the GUI by default, though removing that restriction only requires a simple edit in Fedora and is even easier in Ubuntu. Restricting all users, including admins, to normal user accounts with no admin permissions for daily login, and giving admins a separate administrative account for tasks requiring elevated privileges, is the best way to prevent malware infections. The vast majority of malware runs in the context of the logged-on user and does not rely on any escallation of privilege exploit, so most malware could be effectively erradicated if the principle of least privilege were followed.
Subscribe to comments on this entry
Post a comment
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.
|
| Subscribe |
Subscribe via Kindle |
| Blog Menu |
SearchPowered by DuckDuckGoBlog Home Page
Archives by Date2013 J F M A M
Tags  |
| Latest Book |
more books by Bruce Schneier |
Comments