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.
I shall stay on my quad G5 under Linux or the time being. The market is too small for them to try to attack my machine.
Why didn't people realize that a single monoculture of CPU architecture (x86 in this case) would simplify the job of these guys. I've been clamoring against x86 monoculure ever since Apple became just another resale channel for Wintel clone hardware.
Monoculture is bad, it has always been bad and will always be.
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.
In reading TFA, a prevention may be to add the Tor list into your hosts file so it cant download a Tor client to continue. Add the list into your router blacklist can be out of reach of the malware to bypass the block.
In the arms race this is effective on the current version. An update may have a new list of Tor download locations.
Not sure if blocking TOR at the router is possible or effective.
The truth shall set you free!
How is this crap spread?
Can I laugh at the people who have Flash enabled and let arbitrary sites run javascript? Or does this spread through some other vectors I don't know about?
I suspect the problem is the idiots who write websites, who demand your browser run in the most insecure possible configuration so you can see their ads and other shit they've hidden behind code which needs to run on your browser.
And I've always said I'm not willing to run my browser wide open just to make web sites work, because these things have been security holes for years.
Browsers need to be a whole lot less trusting, and not default to just running any old thing which comes along. And certainly stop trusting scripts from 3rd parties and running whatever crap pile of Flash comes along.
Unfortunately, users are used to seeing pages which give you detailed directions for re-enabling javascript and cookies.
So to all you web developers out there who have ever written that page ... fuck you, you slimy bastard. It's partly your fault the internet is a shit hole.
Lost at C:>. Found at C.
In reading TFA, having an executable called VBoxService.exe or vmtoolsd.exe seems like a sure fire way to have it skip right over you, as it thinks you're running inside a VM.
My backups are done on a USB harddisk that's connected to the media server on my home network. Switch the HD on, and it'll appear and backups can be made.
How can I prevent malware from changing my backups? Would it be possible/effective to mount the drive as write-only, making it impossible to change existing files?
It's detecting the guest services, rather than the VM as such. VirtualBox at least will be no defense unless you run the guest services. OTOH, a fake guest service should defeat Cryptowall. Create a service named "VBoxService.exe" or "vmtoolsd.exe" which does nothing.
Ooh, moderator points! Five more idjits go to Minus One Hell!
Delendae sunt RIAA, MPAA et Windoze
Part of the problem is that the software is getting clever enough to detect backups and goes after them too. Putting in a pull backup can help, but is more complex and costly, not to mention another vector that the writers could potentially take advantage of anyway.
It is a pity tape has become so expensive since that was a great way to handle offline backups in a very user friendly way.
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.
There is a place in research labs for "true" virtualization/emulation, where a particular hardware environment is virtualized/emulated right down to the timing characteristics of the hardware it's pretending to be.
Obviously you can't do this with stock hardware - you'll probably have to use supercomputer-type hardware and do large chunks of it in an emulator but in principle and maybe in practice we should able to emulate at least a few mid-2000s motherboard/CPU/typical-other-hardware setups well enough to fool any software running on them.
The hard part will be doing all of the timing right while running the emulated clock at real-time speed rather than some slowed-down or other fake-time speed. If the timing isn't precisely right, when the evil software connects to its C&C and checks the "real world clock" it will know something is fishy if the emulation environment's clock isn't running at real time.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Assuming a Windows shop with a Windows server holding the online backups, the worst that any client-side app can do is corrupt the current version of the networked backup. It can't delete the shadow copies. Oh, I suppose it could try to fill up the disk so the earlier non-corrupted shadow copies get purged, but it can't outright delete them unless it infects the server first (or otherwise gets admin access to the server).
It also can't touch existing tape or other offline sever backups from an infected desktop/laptop.
In other words, if the server is being managed well, the worst that malware on an end-user device can do is obliterate anything that hasn't made its way to an offline backup, and it will be very difficult to obliterate server-side shadow copies.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I suspect most backup software on the computer pushes the backups to a network share somewhere that I suspect these ransomware packages go looking for and encrypt those files as well.
What if the backup system was remote and pulled the data from a network share on the client. If the client is infected, the infection cannot get to the backup file locations because they are not shared.
I realize this is not trivial for average users to setup, but I'm exploring this option for my home network. Setup NAS type server that looks for read only network shares accessable to userid BACKUP and slurps up any files it finds. Have it keep some kind of version control of a few days (multiple copies). Now when any new system is setup in my house (kid's laptops, wife's desktop, etc) I just have them create a read only share of their personal folders with a userid BACKUP and appropriate password.
Thoughts?
I'm in my right mind and I have the answer to everything!
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.
Does the ransomware only work on Windows machines, or can it also affect *NIX/Mac/Android operating systems?
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.
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.
Disk drives - hard, floppy, etc. - used to have a hardware write protect feature. (Switch, punched-notch, etc.) Set it and there was no way the stored content could be changed. A backup that you'd set would not be vulnerable to rewrite attacks when plugged into an insufficiently-cleaned machine to restore the files.
Then drives came out where software could override the write protection.
Then the feature went out of fashion. Drives were apparently a bit cheaper that way.
A pity.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Well, after reading the article again, indeed that could work on Linux. I thought there were windows vulnerabilities in the mix, but it turns out I read that wrong.
That said, I think that malware/adware is a major attack vector. And Linux/Android/iOS do not fear adware because applications are reviewed and controlled. Of course, you can always have a vulnerability in the Linux packages / Android Apps, but it makes things much harder and especially for the average guy's PC.
But true, for that special case, linux could as well be a target.
Wouldn't one way to stop it be to fake being a virtual machine? I'm sure that would start a cat & mouse game as they make their VM detection algorithm more sophisticated, but I'm thinking the faking code would be easier to write than the detection code.
Around 1% of RSA keys are easily broken, meaning you could decrypt your data without paying the ransom. This is because about 1% of keys are weak in one way or another. I wonder about the key generation function this malware uses. If they are using one of the weaker algorithms to generate keys, many victims may be able to decrypt fairly easily.
Done.
Another lesson is to use virtual machines when possible. An infected VM is a lot less of a hassle to deal with than an infected physical box, especially if snapshots are used [1].
For personal use, I wonder about moving to a NAS and two ESXi nodes. Browsing using RDP is just as fast as a local Web browser, and if configured right, none of the stuff in the VMs would have access to the NAS itself, which helps isolate damage to just that VM itself. As for "real" backups, plugging an external drive to the NAS, copying the VMs after suspending them, and unmounting the external drive should do the trick.
[1]: Snapshots are not backups, but they do have their place.
Around 1% of RSA keys are easily broken, meaning you could decrypt your data without paying the ransom. This is because about 1% of keys are weak in one way or another. I wonder about the key generation function this malware uses. If they are using one of the weaker algorithms to generate keys, many victims may be able to decrypt fairly easily.
Please check with the NSA about this strategy.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
Cryptowall specifically overwrites all shadow copies of files.
You missed my point. I was talking about a case where a user's desktop is infected but the user has a network share from a Windows Server mounted, and where the backup files are stored on that share.
Because it lacks administrative rights to the server, the infected desktop cannot directly erase the shadow copies on the server.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
There is a place in research labs for "true" virtualization/emulation, where a particular hardware environment is virtualized/emulated right down to the timing characteristics of the hardware it's pretending to be.
But randsomware authors are not interested at that. As in previous story they do price gouging how much you are willing to pay. As they won't get penny from vm they do not bother with these.
One purpose for research-lab "true" visualizations is to be successful honey-pots, allowing malware to be studied in a captive environment without giving away the fact that it's a captive environment.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
You may rest assured that Adobe does indeed review its software before releasing it, just that security takes a back seat to feature creep and "ohh shiny". That's just as true for Android and iOS soft. Or do you think Google or Apple does a through security audit for every kind of software in their store?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Yeah, but the drives are really pricey, esp since most consumers tend to want things new rather than second hand.
Does anyone know if it aims to encrypt all your files quickly or over a time period to increase the chance of poisoning backups?
If the former, one mitigation might be to check file types on the backup? Assuming you do a backup to a different architecture, such as Linux, check file types - is a jpeg really a jpeg? Can it read plain text files? As soon as it finds one it can't, flag it up for investigation. Perhaps have a number of canary files, pull those first each time and compare them to known good copies stored in a non-shared filesystem on the backup machine, halting the backup if the file has changed in any way. It'd be a pain to set up, but once scripted it would all be automatic.
Question for cryptography gurus - does having a known good file or files increase the feasibility of decrpyting? I.e A file is encrypted. You have an unencrypted copy of it on read only media. Does that increase the chance of finding the keys used to encrypt A, and thus enable you decrypt other files for which you don't have good copies? Probably not, but thought I'd ask. Apologies if it's a stupid question before I get the piss ripped out of me ;)
Sigs are so 1990s. No way would I be seen dead with one.
Please provide your email address [1] and an encrypted file [2] that has been encrypted by CryptoLocker. This portal will then email you a master decryption key along with a download link to our recovery program that can be used together with the master decryption key to repair all encrypted files on your system.
Found it at this site.
Reputable security firms Fox-IT and FireEye collaborated on the free DecryptoLocker project, which provides a simple way for CryptoWall victims to recover their files and their privacy.
Disclaimer: I read this stuff but I know nothing more than that.
It little behooves the best of us to comment on the rest of us.
The article says that the malware works by creating temporary .exe files in the folder specified by the %appdata% environment variable. Eg "C:\Documents and Settings\[username]\Application Data". As does numerous other malware.
FoolishIT's "Cryptoprevent" utility uses Windows' "Software Restriction Policies" to try and stop .exe files from running in the %appdata% location. It is a good idea so for what it's worth, here's the URL: https://www.foolishit.com/vb6-...
Hosts is of dubious efficacy compared to an actual DNS server.
Advantages:
APK is delusional and fundamentally doesn't understand DNS. Don't be APK.
Hosts by default is cached in memory by Windows, which if you have a huge hosts file is going to eat up a ton of memory. Unless it's paged to disk, or if you've disabled the DNS client service, and in that case you will be hitting the disk with every request. This is unlikely to be faster than a local network request. Also if you've disabled the client service (this is almost a requirement for an APK-style hosts file), you have disabled indexing, so you have to read the file line-by-line to figure out if a domain is a match, for each request. Any sites not in your list require reading the entire file.
If you care about security, you should run your own local DNS server. You should also use an ad blocker, which will prevent many requests to ad networks from even being made. The hosts file is for temporary and machine-specific DNS changes, like if you're developing a website and need http://test.local/ to point to your local web server. It's better to have an actual domain registered and and a subdomain, but it's not a big deal. Hosts is a bad solution for almost anything else. Having a program to manage your hosts file is just writing a really shitty, stupid DNS server.
I know I'm going to be trolled for weeks — again — for saying this, but someone has to.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Older versions of CryptoWall didn't wipe the shadow copies.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Btrfs snapshots would have defended against this sort of attack effectively - they provide incremental backups that can only be deleted by root. It's trivially easy to setup a cron job to perform a daily snapshot of /home - I did so a while back and just found I'd accumulated a years' worth of snapshots. Admittedly, this isn't something the average user would have set up, but given that there are already distros which automatically snapshot the root fs before installing updates, it's not a huge stretch to say it could be added to a noob-friendly distro.
While Windows does have various mechanisms for creating backups, I'm not aware of anything equivalent to btrfs on it (incremental backups, takes less than a second to create the backup/snapshot).
Most human behaviour can be explained in terms of identity.