This is one reason why I tell people to have both offsite backups (in case of fire, theft, etc.) and offline backups. There are a lot of us that are just one SSH worm away from having all of our files destroyed.
I've been thinking about ways to create an offline-equivalent backup, so that it can be automated. One way would be to have a computer that is only connected via serial cable, which only accepts new files to be backed up. (No ability to delete via the serial cable.)
A pretty low-tech system I saw in use in the '90s, without having to go all the way to serial cables, was just FTP with delete/overwrite disabled, to a machine with no other network services running. You dump a snapshot and FTP it to the backup host over your local ethernet. The FTP server accepts new files, but doesn't allow deletions or modifications of previously uploaded files (lots of FTP servers have this option, in order to be able to create a public "anonymous upload" folder without people overwriting each others' uploads). If you ever need to retrieve the backups, you physically log in on the backup machine and do something from there.
This does rely on the FTP implementation being solid (vsftpd seems like a reasonable choice).
That is a good idea. I have considered having a network service like that, but I'm a little too paranoid. I want something that will survive heretofore unseen events, like a 0-day remote root exploit in the Linux kernel networking stack.
If such a remote root exploit exists, and the person that discovers it decides to write something like the Code Red worm from 2001, and also decides to have the worm erase all block devices, I'd currently lose every file I have and all of my backups, even though they are geographically dispersed. It's possible that even services like S3 and Dropbox would be wiped in such an event.
Once again, I realize I'm unusually paranoid in this regard, but I really don't want to lose my stuff.
Not everything is running on Linux you know, and therefore not everything is prone to the 0 day remote Linux kernel exploit. Get yourself other backup layers on other operatying systems, like Tarsnap, that runs FreeBSD, and you should get another level of security.
> I've been thinking about ways to create an offline-equivalent backup, so that it can be automated.
One of the approaches we take with Efficito is to ensure our offsite backups are pulled by the backup server, not pushed there by the backed up server (exception is made for archiving Pg wal segments). A backed-up server has no access to its own offsite, online backups for db base backups, file backups, and the like and only write-once-read-only access to its own WAL segment archives.
It's not quite an offline backup (and for our purposes there are real limitations with fully offline backups), but it is about as close as you can get.
You create a backup system that has credentials into your target system, but the target has no credentials for the backup. The backup system can maintain the point-in-time history.
Of course if you backup system gets hit then the whole thing falls apart, but you can isolate this one system and it doesn't need to accept any incoming connections.
> Of course if you backup system gets hit then the whole thing falls apart, but you can isolate this one system and it doesn't need to accept any incoming connections.
Unless you need to remote administer it.... But I suppose that's what virtualization helps with.
Or a step further: don't let either the live and backup sites connect to each other directly, instead use an intermediary site that both connect to (which can not connect back to them).
I've been thinking about ways to create an offline-equivalent backup, so that it can be automated.
You can do this with Tarsnap. The tarsnap-keymgmt utility allows you to create key file which can only create new archives, not delete or overwrite existing ones.
> I've been thinking about ways to create an offline-equivalent backup, so that it can be automated. One way would be to have a computer that is only connected via serial cable, which only accepts new files to be backed up. (No ability to delete via the serial cable.)
A lower tech alternative is to use a Linear Tape-Open drive/cartridge. Not only are they archival safe (20 years+), but either you can use a new one every time or I think there is an option somewhere to only write once.
If the size of your data is less than 4GB, a box of DVD+R's is also a cheap, secure and convenient way to make read-only backups. Just burn a new disc at the end of each workday, or whatever other interval your schedule and budget allows.
Of course this isn't really automated, but if you have one of those disc changers that people often use with audio CDs, you might be able to turn that into an automated system with a bit of scripting and hardware hacking.
DVD's and pretty much all optical media are terrible for backup. they degrade just siting on the shelf. and one scratch and 'poof' goes your data. I'm surprised as a medium that they have lasted this long.
[1]"Manufacturers claim that CD-R and DVD-R discs have a shelf life of 5 to 10 years before recording," note that is "before recording"
[1] http://www.clir.org/pubs/reports/pub121/sec4.html
Sure, but shelf life won't be a problem when you burn a new disc every day and you intend to keep at most a couple of months' worth of daily snapshots.
As terrible as optical discs are for long-term archiving, I'm sure their shelf life usually exceeds that of a carton of eggs. That should be enough to protect against ransomware and most other kinds of disasters that can strike a personal computer.
a) Creating multiple DVDs each time you back up (if your dataset is small enough and stable enough that DVDs are an option, doing two burns seems like an acceptable burden to me).
b) Storing parity files[0] on the DVDs to allow you to actually recover from bit rot and disk damage.
> a lot of us that are just one SSH worm away from having all of our files destroyed.
This has happened quite a lot in some high profile cases over recent years, where [Company Name Here] was hacked and as well as taking down their live service the attackers got from there to the backups and killed them too.
> I've been thinking about ways to create an offline-equivalent backup, so that it can be automated.
The trick I use to improve the safety of my online+offsite backups is to stop any one service being able to connect and authenticate with all the others, disconnecting the online backups from their source as much as possible.
My "live" stores connect to an intermediary and push updates, and my online backup stores connect to the intermediary and pull updates (with restores and automated tests being the same thing in reverse). The live stores and the backups can not connect+authenticate to each other directly, and the intermediary can't connect+authenticate to either the live store or the backups. This way if a malicious entity (be it a human or an automated exploit) gains access to a privileged account on any of the three locations it does not automatically gain access to all the others, but the process of taking and testing backups can still be automated.
Of course this isn't perfect: it is a little more hassle to setup, needs an extra resource (the intermediate location) which could potentially be a point of failure (though your automated backup tests will hopefully detect problems there before they become serious) and it depends on good credentials management (I sill need to be able to connect to all three for remote admin and if you use the same credentials for them all, and/or store said credentials in the same insecure place, the extra protection is lost) but I find it works well in practise. Also as I'm using the same OS+libs+tools in all three places I'm still susceptable to attacks using "zero day" exploits on some part of that stack, so for that reason (amongst others) this does not remove the need for truly offline backups.
The number has 128 digits, which could indicate a (big)
mistake from the malware author, who wanted to generate
a 128 bytes key.
Finally, we simply deal with RSA-464 encryption, which
can easily be broken on a standard PC in a matter of hours.
* Update your anti-virus software
* Apply all software updates
* Pick a hard password
Rarely do these matter: ransomware, Target, etc., are exploits unrelated to these defenses. Why do we push them so hard? Does anyone feel safer and more righteous from advocating this security theatre?
Anti-virus programs detect many kinds of trojans and malware. Why could ransomware not be detected by anti-virus?
Those points are there because they make sense. While having an up-to-date system and anti-virus software isn't a silvet bullet, it's certainly better than nothing.
Static signatures are increasingly pointless as malware is rebuilt often.
Heuristics don't work against ransomware because they act like a well behaved program. Search for files, open file, overwrite file. All could be done as non-privileged user.
Ransomware is truly scary but the proper advice is:
1. Don't run untrusted software
2. Proper backups (e.g. not just a mirror)
3. Proper permissions on network drives that are mapped. Ransomware is devastating to small offices.
AVs will detect ransomware approximately as easily as any other malware family. Ransomware shares plenty of traits with regular malware.
The problem is that there are so many cheap services out there for malware distributors to automatically "crypt" (pack) their payloads, that the chances of getting a completely fresh sample are pretty high.
AVs are also less effective against ransomware because they have to catch it before it first runs on the system, otherwise there's nothing it can do.
Just because it is not 100% accurate doesn't mean it is security theory. Security is about taking many measures to help mitigate threat. There is never a pragmatic, completely effective safe guard.
That being said, keep everything up to date and don't reuse passwords or use guessable ones :)
That is somewhat of an unfortunate myth. Computer security is not a matter of withstanding force (where "adding an additional wall" might help) but one of correct logic. One of the best ways to achieve the latter is to get rid of unnecessary logic altogether. AV software does the opposite: It adds tons of more logic that gets into contact with untrusted data, and thus adds exploitation risk to the system (aka "attack surface"). Also, there is a very specific reason why AV really is more an annoyance filter than a security measure: It's a blacklist.
For some practical examples for why AV is risky, see also:
Indeed. Or even "don't click on suspicious emails or visit suspicious websites" which are actually always harmless. How about simply "don't run a program you don't trust" and we wouldn't need virus scanners at all.
Or at least cause you to consider the risk of loss compared to the value of using the software while not panicking when you receive a spam email with a suspicious looking xls file attached.
Well, I just checked and found information about Java being disabled by default in Firefox and Chrome.
The only resources I found on IE were about how it is difficult to disable.
Because of this, I am going to assume that it is enabled by default on IE. Correct me if I'm wrong.
IE has about an 18-20% share of the browser market [1]. A significant amount of targets by any measure!
So as long as it is true that a large percentage of the target market could benefit from "Don't visit/view!" security advice then it makes sense to include such advice.
Java's sandbox is no more secure than it was before, but because of Firefox and Chrome adding in a ton of mitigating features like requiring "click to play" by default, disabling it as soon as it goes out of date, and Oracle adding the same features internally, it's definitely way less of a threat right now.
Drive bys are still of course possible via Adobe Flash and Reader exploits, the occasional IE exploit, and the rare Firefox exploit.
Depends on who's measuring. IE has over/about half of the browser market. Corporate cubicle farms are dominated by IE, as are aunt's, uncle's, and grandma's computers.
When one talks about an n-byte key in cryptography one typically means an n-bytes combinatorial space, not a string of length n representing n decimal digits.
That's what the cybercriminal needs to learn to distinguish :-)
I was wondering where "RSA-464" in the article came from.. and found calculation formula, which makes this number to seem incorrect?
bmax - a maximum number of bits required for a decimal number is calculated by this formula:
bmax = ceil(d(log(10)/log(2)))
(where d - number of digits).
Yep, namely <54 bytes. Just for ease of comparison.
~54 bytes vs 128 bytes.
Considering it's a logarithmic measure (every bit adds x2 difficulty for cracking) and 128 bytes is rather tight... gives an idea of the weakness of this key.
"The name "digit" comes from the fact that the 10 digits (ancient Latin digiti meaning fingers) of the hands correspond to the 10 symbols of the common base 10 number system, i.e. the decimal (ancient Latin adjective dec. meaning ten) digits."
Digit means base 10 numerals. It would have to be a string of 128 characters, not 128 digits.
Malware aside, it's annoying that people still think Bitcoin payments come "from" an address. It's not something you can rely on or expect in Bitcoin, and certainly shouldn't be used to identify payments by a client. A unique address per payment requested is the proper, expected method.
Sure. You essentially can't rely on a particular wallet sending from an address they know about, or even from an address they can control.
The classic example is of a service using a shared wallet like Coinbase does. Coinbase maintains control of the keys of every piece of Bitcoin their clients own, and they have an external database that contains a record of how much Bitcoin they are holding on behalf of their clients. This allows them to keep the vast majority of the funds offline where they are invulnerable to attack. This system means that the "from" address is likely never correlated to the sender, and they have no control of where they send "from". Relying on a client to provide this information usually ends in disaster, as does sending refunds to an address you were sent "from".
Even for the reference client Bitcoin-QT addresses are disposable and almost never linked. Change from one transaction is sent to an entirely new address which done invisibly from the users perspective. There's more information about that on the wiki, change addresses in themselves are quite confusing.
For all intents and purposes, they do though. Using as an input that was originally an output sent to an address is practically the same thing as coming from the address itself. It only really breaks down for more complicated transactions.
The problem is that most clients are in control of a ton of addresses. Transactions often will come from a combination of several of the addresses. And the user has no control over which addresses are used. So a user cannot enter what address(es) a transaction will come from before the transaction is sent.
Bitcrypt works around this problem by having the victim enter the address after the transaction is sent. But this also has a problem. The victim can simply go to this page http://blockchain.info/address/1HKCHx1RFhNHuF3NxLviHdrjNFzJb... and watch for when a different victim sends a new transaction to that address. Then the first victim can claim that payment as their own.
The more cryptographic version is to sign a challenge with the private key that allows spending of the bitcoins on that address to prove that you own the address. Or you know, do what most people do and have a unique bitcoin address for each person in order to identify them.
It always seems a little odd to me that bitcoin is associated with criminal enterprise. Surely with the transaction record public, it's rather easier for the police to "follow the money" than with cash etc?
You can "follow the money" electronically, but unlike bank transfers there's no physical connection. Going from imaginary point 1 to imaginary point 2 doesn't really tell you anything.
But some transactions are ultimately linked to the physical world, and that gives a window through which more can be pinned down over time. Operating from just the blockchain doesn't tell you very much, but combined with other things it's a lot more informative than cash movements. You're never leaking less than you think.
Bitcoin mixers can make it almost impossible for people to follow bitcoin transactions, providing that the number of coins in the mixer far exceeds the amount you are trying to mix.
Again, you're never leaking less information than you think. I also expect that using bitcoin mixers will be prosecutable under AML laws in the medium term, if they aren't already.
>So, things were clear: the cybercriminal wants 0.4 Bitcoin, which made about 260 Euros at the time of infection, but only 89 Euros at the time of writing (Once again this shows how unreliable the Bitcoin money is, but that is something else).
Sigh. The author is using the MtGox price. Mtgox is one of the smaller Bitcoin exchanges these days. Due to their legendary incompetence, they got hacked a while back and disabled Bitcoin withdrawals. As a result, their "Bitcoin" trading price fluctuated from 1/2 to 1/6th that of other exchanges. The current market value of Bitcoin on all other exchanges is actually 400+ euros right now.
Is it just me, or a random new aes pwd for each file makes perfect sense? Otherwise once you brute force one file you could decrypt all the other ones.
I don't understand what you're saying. Brute force is always possible. Succeding is only a matter of time. Suppose you find the password for one of those files, then you would be able to decrypt all your ransom data.
When it comes to recovering your data, you might be ready to have a brute force running for long long long time 😊
Technically, if the universe went on forever, yes, you could brute force AES. However, with a well-chosen key (i.e., 256 random bits, and not merely a weaker password that was expanded into a 256-bit key), the odds are pretty decent that all life in the universe will end before you guess the key.
A listener to Security Now wrote in to episode 340 with this for perspective:
I took 256-bit encryption and assumed that the only way to crack it was, as we
currently believe, a brute-force attack against the 256-bit key. ... So let's
say the tricksy government has a secret algorithm that somehow allows them to
weaken the strength to one trillionth of the original. That's a good number,
one trillionth. And let's say they had a computer that can try 100 trillion
guesses per second. And let's say this computer was one cubic millimeter in
size, and let's say they build a cracking complex the size of the entire Earth
made out of these one cubic millimeter crypto cracking computers. If I did my
math right, it would still take 34 trillion years to crack.
I've double-checked the math, that's how long it takes to exhaust the 256-bit keyspace, even in an unreasonably-generous scenario. You could halve that time to get the average time it takes to find any given 256-bit key, since you won't, on average, have to search the entire key space.
We trust AES 256 because, as long as the algorithm is sound, it is actually impossible to brute-force in any useful time frame, for even insane definitions of "useful". Even in some scenarios where the algorithm isn't sound, as above, it's still impossible.
The author of BitCrypt didn't use AES 256, however. They used AES 192, which is drastically weaker. According to the same calculations, it would take 0.00067 days to brute-force an AES 192 key. With a planet-sized cracking machine, impossibly fast computers, and a substantially weakened algorithm.
However, it gets better - the author of BitKeeper didn't actually choose a 256-bit key, they chose a 16-character password that was expanded into a key, and that's what we can crack to decrypt an individual BitCrypt file. In our hypothetical (yet unrealistic) scenario, this can be done in under a second.
So: brute-forcing well-implemented AES (good key, good key length) is impossible, no matter how you slice it. Brute forcing AES with a questionable key length is still impossible with anything remotely resembling the technology we'll see in our lifetimes.
Brute-forcing a file encrypted by low-quality malware is absolutely possible, as the article shows :)
nb: crashplan will encrypt & back up your stuff locally & remotely (in multiple locations) and keep a version history, which pretty much nips this sort of crap in the bud.
(not affiliated with those guys, just a happy user)
> So, things were clear: the cybercriminal wants 0.4 Bitcoin, which made about 260 Euros at the time of infection, but only 89 Euros at the time of writing (Once again this shows how unreliable the Bitcoin money is, but that is something else).
Could you expand your comment a little beyond "Fail." to explain to those of us who aren't totally clued up on BitCoin what is wrong with that statement?
The author is using the MtGox price. MtGox is one of the smaller exchanges, and due to their incompetence, their trading system was hacked and Bitcoin withdrawals are disabled. As a result, the price of Bitcoin on Mt. Gox is about 1/5th what it is on all other exchanges. The author is using the mtgox price.
The cash value of Bitcoin declined since last fall, meaning the hacker is making less 'real' money now, if they try to trade the Bitcoin for cash. By hardcoding the asking amount of 0.4 Bitcoin, they are susceptible to the many ups and downs of the Bitcoin/$ ratio.
The day-to-day value of Bitcoin, and therefore its utility as a proper currency, certainly isn't reliable.
For me personally, the time when people can (and do) reliably list prices in BTC (which do not float with BTC/USD exchange rate) is the time when I take Bitcoin's use as a currency seriously.
I've been thinking about ways to create an offline-equivalent backup, so that it can be automated. One way would be to have a computer that is only connected via serial cable, which only accepts new files to be backed up. (No ability to delete via the serial cable.)