Inside Cryptowall 2.0 Ransomware
msm1267 writes: If you need more evidence that ransomware is here to stay, and could turn into cybercriminals' weapon of choice, look no further than Cryptowall. Researchers at Cisco's Talos group have published an analysis of a Cryptowall 2.0 sample, peeling back many layers of known commodities around this threat, such as its use of the Tor anonymity network to disguise command-and-control communication. But perhaps more telling about the commitment around ransomware is the investment attackers made in its capabilities to detect execution in virtual environments, building in many stages of decryption present before the ransomware activates, and its ability to detect 32- and 64-bit architectures and executing different versions for each.
Cyptowall is very sophisticated. It will go into online backups and encrypt them too. If you are using a common online backup it can find those and encrypt those too. The best protection against this is a usb backup in a drawer. Cyptowall was recently being distributed by yahoo ads via a compromised flash ad http://news.yahoo.com/yahoo-ad.... You could have received it by going to your favorite news site.
Most malware is surprisingly benign. I've been saying it for years.
If you wanted to get really nasty, you can do these kinds of tricks and the thing will be damn-near scary to contract.
The problem is that we've bred a generation of people who see malware as nothing more than a distraction. Who will go to "uninstall" to remove it, thinking that's to be trusted, who don't realise that something running in the background is a problem once you close the advert it pops up.
At some point, something like this is going to be combined with a handful of never-seen-before exploits and it'll go across the globe and take weeks before there are effective patches to get rid of it. But the scary part is that the first few seconds of infection are all that's needed to totally control your ability to use your computer and access your data.
Maybe then we'll get proper application whitelisting / sandboxing by default in a desktop OS. And, hell, why do applications get the run of every file I use under my account? Should they not have to request such things first? Even on Unix-likes, if you get on as my user, you can trash all my data - why? Why is the data store not immutable and applications only get a link to the data IF they are allowed access to it? And thus nothing ever actually runs "as" the user, but only as its own separate user with similar permissions and only the files necessary.
Malware could be a lot worse than even this. Why it isn't yet, I haven't figured out - I presume because money-making is at the heart of it now rather than actually malintent with your data. But that won't last forever.
I'm sorry, but the very concept of a virus scan happening "at scheduled intervals" or after you've already double-clicked on the file just tells you that it's too late before you start. We've got away with it for decades in desktop OS, but it can't continue forever.
Getting a virus on my networks scares the crap out of me. People think I overreact when I just remote-off the machine (or tell them to pull the plug) and just re-image for even the most basic of adware. Fact is, I didn't install it and I have no idea what it ACTUALLY does. And I'll be damned if it's going to get the chance to go on my shared areas and do anything, even with file history, backups, etc. available.
The best protection is to pull your backups not push. You have whatever is performing you backups connect into the machine, and then pull the backups, not having your machine being backed up connecting to the destination and pushing. That way, the machine can be compromised but it has no clue that it's even being backed up (since it's simply a share that's being used.) When you use a usb drive, you'll be safe, until someone plugs it into that machine not knowing that as soon as they do, it will begin encrypting what's accessible on that usb drive. I aways try to backup from outside of the context of what is being backed up. If it's a VM, I backup from the host, not from inside of the VM I need the data from. If it's a storage end point, I don't back up the files, I snapshot the volumes.
It isn't always possible to do it that way, but doing it that way has saved my backside more than a few times.
A lot of people have been talking about backups and the fact that even your backups can be compromised. And that's true. The solution is versioning and rotation. If I'm compromised today, the files on Crashplan will be uploaded as encrypted files. But since they have versioning, I can go back 30 days or so and get the older versions. I may lose some data depending on how long I've been infected, but I'll be able to get some data back. The only other solution is to run a daily/weekly/monthly backup scheme that keeps your monthly backups for a year (or longer if you are really paranoid). It means you need 5 separate disks for each week and then another 12 for each month, which most people aren't going to want to do. Eventually the ransomware people will get patient and encrypt your files but allow access for 3-6 months before telling you.
Crypto$shit isn't something that can only run on Windows. The main reason why Windows is being attacked is the same why the most software is made for it: Its market share. If Linux had a market share of 90% (or however ludicrously high the share of that system still is), Linux would be the target. For exactly the same reason: It's where the money is. Why bother trying to infect 5% of the computers when you can go and try to infect 90% thereof?
Next, they abuse the flaw in a third party product, something MS cannot even mitigate if they wanted. If you want to be mad at someone, be mad at Adobe, they're the one that produced that abominable turdfest called Flash. You think Flash is any more secure on Linux than it is on Windows? Think again. Why would Adobe put more brainpower behind the security of their A-league product on a minor platform than they do for the main platform?
Better security in Linux, you say? Tighter control of permissions? Bzzzzt, nope, doesn't apply. What makes Crypto$shit so dangerous is exactly that it does not need any kind of elevated permissions. It does not want to touch any "system" areas, all it does is execute in the user context and encrypt files in the user's directory. That is something you can do on Linux with the permissions of the current user just as well as you can do it in Windows.
And yes, I'm aware of the various "hardening" strategies that you can employ to make such an attack harder on Linux. ALL of them work as well on Windows. Ok, maybe not in every version of Windows because MS in their never ending wisdom thought security is for Enterprises only, hence the key security features are not available in their Home editions... but even for the "Homes" there is a way to do it. Very inconvenient and quite tricky to pull off, just like most would be in a Linux environment. Yes, it's possible. No, it ain't something Joe Randomsurfer would or even could do.
So no. This time the "Windows sux" club does not strike. I wish for the best and I hope for less market share for that Moloch too, but this time they are not the ones to blame. If anyone is, try Adobe and them STILL NOT getting a grip on Flash security.
It ain't like this is the first time that turd has been the attack vector, ya know...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
We use two strategies. First, the backup device is ONLY a backup device. It doesn't have a web browser and it's not used for email. We use very large servers to backup our customer data, but on a small scale you could use a Raspberry Pi, an old router with OpenWRT, or a smart NAS. Because the device handling backups has no desktop or services, it shouldn't get infected. Access is strictly limited - either console only or strong ssh keys, perhaps through a VPN first. The backup device can be so restricted because it doesn't need to be useable for anything but pulling backups.
Its access to the machines it backs up can also be extremely limited. The ssh key of the backup device is only allowed to run rsync with pull arguments. So even if the backup device were compromised, it can do no harm.