Looks like CryptoLocker still leads the field..
Unless they have made the same mistake.
Somehow I don't think we'll get that lucky.
A basic rookie programming error has crippled an otherwise advanced piece of ransomware dubbed CryptoDefense – but the crap coders are still pulling in more than $30,000 a month from unwary punters. Symantec reports that the malware, once it infects a Windows PC, encrypts the victim's files using a 2,048-bit RSA public key, …
Looks like CryptoDefense ran a beta with Symantec reporting on bugs. Of course it was fixed within 24 hours and now reports like this make people think they are safe when they are not. Besides not opening an unknown attachment - get reliable backup, suggest on-line and not locally mapped drives as that (local mapped backup) is one of the ransomware targets.
If they are technically literate and login as admin then there might be argument that they deserve what they get.
However, most users haven't got a clue about admin and user accounts - they simply use the computer as a tool and use whatever is more convenient for them. This does not make them idiots and deserving of being extorted, it makes them victims.
>This does not make them idiots and deserving of being extorted, it makes them victims.
On a similar note, lay users aren't encouraged to back up their machines on an hourly basis... I mean, most PCs or laptops are sold with a single HDD, so they aren't designed for near-continuous back-up by default. For sure, this requires extra hardware (and cost) but PCs are pretty cheap these days, so it's an issue of educating the customer than an extra 20% cost is a worthwhile investment.
Does anyone know how prone HDDs and NASs attached to the PC are to this sort of malware?
Seriously, are continuous backups any defence against this kind of attack.
Surely, by the time you've received the ransom notice you've already backed-up the encrypted versions.
Aside from large outfits, who can back up to a fresh tape every hour with a month-long (or even year-long) rotation policy, what can a mere mortal do?
And how does one stop those backups from being directly encrypted - if it's on the network it's surely at risk.
@Harston - You don't have to be logged in as admin. Code run as your user will have access to all your files, and all files (eg on network shares) that you have access to - unsurprisingly.
What it won't be able to do is encrypt eg server-side databases that you have front-end access to, and that sort of thing. So you can trash the department's spreadsheets, but not the accounts database system. Unless it's a local copy of Sage...
@Dave - malware like this may have access to your backup destination, depending on how that's implemented. If it's a local HDD, or a permanently attached network share that has stacks of backup files in, then your hourly backups could easily get mashed.
In summary - any file that *you* have rights to delete, can be encrypted by this malware. No admin rights required.
Like almost every private key in the world stored on a Linux machine for use in an Apache SSL webserver, for example?
Yep. Unless you want to type a passphrase into the machine every time it boots up. Some people do this (i.e. those who take security very seriously), some don't (i.e. those more worried about getting the PC back up and running without having to physically be in front of it every reboot than someone who might have obtained root access to the machine stealing only their private key portion of their SSL certificate which they have to have accessible for, e.g. Apache, IIS, etc. to be able to read the other side of the SSL connection anyway).
Good practice says you encrypt the whole drive. Then "storing in plaintext" is neither here nor there. But if someone has read-access to your private keys which your webserver / SSH server / mail server etc. has to have access to, then it's game-over whether they are "encrypted" or not really. And, pretty much, means you can't reboot a system remotely and have it come back up with all your services operational.
No, every account has its own encryption key used to encrypt the keystore (keys used by the OS are stored in the SYSTEM account's keystore and encrypted with the machine's key).
The source of this key depends on the account type: on locally created accounts the key is made from a one-way hash of the user's password and some other unique data. In directory services, such as Active Directory, the key is stored and generated by the directory software.
The only place the key is stored in plain text is in a protected section of memory (Assuming your MMU isn't a pile of crap) and is processed by non-interruptible software ISR.
And, er... let's just take my scenario again.
A web server has to boot at startup. It has to read wherever you've put the key and get the PRIVATE key out of it (in order to be able to decrypt communications encrypted by the PUBLIC key that you give out to everyone and send to them as part of TLS etc.).
So then that machine, when powered on, without requiring passphrases, has enough information to boot, log in at the service account user (e.g. "httpd" or equivalent), read the keystore and get the PRIVATE key out of it.
Game over. It might be more tricky but still game over. Encryption is useless if you're storing the credentials on the same disk and you are booting from it without supplying external information (e.g. dongle, manual login, etc.). It's either storing the key in plain text or it's storing it somewhere where it can get to using no more information than is contained on its default storage devices.
And, thus, why most OS's don't try to "obfuscate" access to it, because that's just pretending to actually be secure. Fact is, if you have enough info to boot up and decrypt SSL encrypted with your private key, you have enough information that the key is effectively plain-text.
The point of the Keystore isn't to obfuscate access to certificates, but rather to put them all in one place and make it much easier to work with using a common API for all your crypto needs rather than having it done on an application-by-application basis.
Yes, the system has to get access to the key from somewhere, in modern computers this would be the TPM in conjunction with SecureBoot. The SYSTEM account's keys are stored in the TPM and without those keys the keystore is unreadable. Of course now the TMP is the weakest link, but if your attackers have the technology to break one of those, I think you have bigger problems.
Besides, if someone malicious has physical access to your machine, it doesn't matter what OS you are using, you have already lost. A system's security isn't just about the OS, you also have to protect
It's purpose is to serve the ends of the USA's political/military/industrial complex, not save puppies from drowning or do anything of benefit to anyone else. (Unless that's incidental to making a random scumbag politician look good for a moment).
I went to look for the Application Data > Application Data > Microsoft > Crypto > RSA folder to find out what might hide there. But this folder resides in a different location on Windows 8: C:\Users\Username\AppData\Roaming\Microsoft\Crypto\RSA. Just in case somebody was looking for it ...
This is what we want the law enforcement agencies to deal with. I know that it isn't piracy, but I think they should concentrate on dealing with scams instead of going after poor people who happen to pirate music or videos.
This is the kind of thing that really affects people and their lives. But no, they go after the easy target of those who copy films and music.
Hi All, unfortunately my laptop has been infected by CryptoDefense. I've been googling to try and find support in getting rid of it. The article mentions locating the private key in the Crypto file. I've located the file, but is anyone able to advise what to do next? What do I do with the key?
Thanks,
Lynn
J.G. Harston wrote, "Surely you have to be logged on as Admin to let these things take over? In which case, the bloody idiots are getting everything they deserve."
Well, I'd much rather be, on any day, a decent bloody idiot than a cruel (long string of expletives deleted). As it happens, there are at least two good reasons to be logged on as an Administrator. As Condiment implies, we are not all so totally saavy as the imperious Mr. Harsh ~ton. A computer is hardly a simple instrument.
When in my early computer-leaning stage—which seems, btw, to be ever on-going—an "expert" once advised me, "Don't be afraid of clicking the wrong key. You can't hurt it."
(Experts!)
Secondly, years ago and when, upon having to reinstall Windows I did something wrong, I found I couldn't access any of my User files and so I lost ALL of them.
Log on as a user? Never again