Browsed by
Category: Encryption

Ransomware

Ransomware

You have probably seen news of businesses and institutions being attacked by ransomware, and having to pay tens of thousands of dollars to get rid of it. Names like CryptoLocker, Fusob and WannaCry have floated by. But, what is ransomware? How does it work? How can I avoid being stung?

Simply defined, ransomware is a specific type of malware that denies its victims the use of their data until a ransom is paid.

Ransomware attacks typically operate as follows:

  • The trojan is installed on the victim computer system
  • It collects a list of the files it can access that it will encrypt
  • It contacts a central server, operated by the attacker
  • The server generates a unique encryption key for that victim, which will be stored on the server and sent to the trojan program on the victim machine
  • The trojan encrypts the targeted files using that key. In modern examples, this encryption is quite strong
  • Once the encryption is complete the trojan destroys its local copy of the key
  • The trojan then communicates to the victim that the files have been encrypted,
  • It offers to provide decryption after a payment is made, usually within a fairly narrow time window.

Ransomware gains access to victim machines through the usual malware routes: users click on dodgy links in email, or open malicious file attachments. Web pages or banner ads that have been compromised can provide “drive-by” downloads of all kinds of malware. Whereas other malware may join victim computers to botnets, get them to start mining cryptocurrency, or participate in distributed denial-of-service attacks, ransomware has the simple goal to get money to its operators immediately.

The files that ransomware encrypts are usually documents and spreadsheets, images, music and video files, HTML and source code files, and ZIP archives. Ransomware does not typically attack the other software on the system. Thus, a victim’s copy of Office and Photoshop may be undamaged, but all their work in those systems will be unusable. Also of note: most ransomware encrypts files on all available network shares as well as the local disk. So a small office can be wiped out from just one infected computer, since small offices often only have a single hierarchy of file shares and everyone can get to them.

If implemented well — and it frequently is — the server-to-trojan protocol of generating a key, encrypting with it and then discarding the local copy of that key is extremely difficult to crack. When a business confronts a ransom demand, often the cheapest way to get back into operation is to pay the attacker. Despite all the larger reasons that this is a horrible idea, the equation of paying $X to get the decryption key against a possible $X00 to $X000 to recreate all the data makes the decision to pay a no-brainer. The sole glimmer of good news here is this: the vast majority of attackers, when paid, actually provide the key and allow recovery of the data. In some cases, they have even provided technical support to assist “customers” having difficulty doing the decryption. Why? If they do not keep up a reputation for providing what is paid for, the “market” will stop paying them and seek alternate means of recovery. And they just want the money.

There is one strong defense against ransomware: backups. The backups should be as current as is practical. Real-time backups are ideal but not always feasible. But if a business is only facing the prospect of recreating one or two days of data as opposed to weeks or years, then a decision not to pay off criminals becomes much more reasonable. To be safe from the encryption of a ransomware attack, backups should be stored somewhere that is not constantly connected to the main systems, or in any case not accessible as a normal file share. So if you run a backup system in the office that places all the backups on a server, do not also use that server to host file shares.

With good recent backups in hand, the strategy for responding to a ransomware attack is much less stressful: clean or re-image the machines affected, restore the data, get back to work. As I am fond of saying, security, done correctly, is almost boring.

Have a Random New Year

Have a Random New Year

Randomness is important.  You use it in the physical world when you shuffle a deck for a game of cards or roll a D12 for a result in Dungeons & Dragons.  But you need it even more in the digital world, and it’s more difficult to come by.  You need randomness to select one-time-use keys that you share for symmetrical encryption, to select strong passwords or passphrases, to run fair games at things like online poker and casino games.

The problem is, that for all the miraculous things it can do with random input, software is very bad at generating it.  Algorithms are deterministic, even if they are designed to be difficult to predict. When you use a function like RAND() in Excel, or get randomized challenges in low-stakes gaming, you’re usually getting the output of what’s called a pseudo-random number generator (PRNG).  The PRNG takes a numerical value, called a seed, and generates a series of new values from it.  If the seed is known, then the new values are easy to predict.  If the seed is not known, it’s a lot more difficult — but not impossible.  If you reuse the same seed you get the same sequence.  This property can be useful sometimes, for example, if you want to be able to reproduce a series of plays in a game.  But mostly, it’s a very bad flaw in any process that needs randomness.

PRNGs are fine when it doesn’t matter.  But when it matters you need to harness the unpredictability of the physical world.  One great Internet resource, random.org, uses atmospheric noise to generate its random numbers.  At that site, random bits are available anytime you want, in many forms.  Some are free and some are available to paid members.  It’s an important function for the safety of the Internet as a whole, and it’s worth supporting.

Another use of physical randomness is in EFF’s Dice passphrase scheme.  If you read the instructions, you’ll see that they really don’t want you using a computer — which might be compromised — in any step of the selection of a password/passphrase that matters.

Internet companies have to generate thousands of strong keys per second for encrypted sessions.  Cloudflare, for example, found a very groovy way to solve this problem:

[Photo: Dani Grant]

So my New Year’s wish to you: keep it random!

 

Cloudy With a Chance of Information Security

Cloudy With a Chance of Information Security

The Cloud! It sounds so… ethereal. We’re all going to have computers floating around in the air? What’s going on here, really? Today, let’s look at data storage “in the cloud” and how we can use it more safely.

A sticker on my laptop says, “There is no Cloud. It’s just someone else’s computer.” At its most basic, that’s what we mean when we talk about “the Cloud” for any computing or data storage need. We can host the website on a server we buy and maintain, or we can pay someone to host it on their server. We can store our photos and music on disks we buy, connected to computers we own, or we can pay someone to store them for us. When we pay for the service in money or personal info or both, then we’re users of “the Cloud.” If you keep music, video, pictures or documents in Google Drive, DropBox, SpiderOak, OneDrive or iCloud, you’re a cloud user. If you host a website on SquareSpace, Weebly, GoDaddy or any similar services, you’re also a cloud user.

Of course, the fact that it’s someone else’s computer means that we don’t have as much control as we might over how the data we store there gets handled. This is where the security considerations require more thought. Every cloud service will tell you how secure they are. Every one will tell you about their use of encryption. Encryption matters, a lot. But what matters more is a careful consideration of the “What-Ifs”. It’s what we securty guys call “threat modeling.” You have to imagine the ways in which your information could get compromised, and see if the security measure in place actually protect against the threats you care about. So when DropBox tells me that they have strong encryption I have to think, what is encrypted, and how are the keys handled? When I poke a little further, I learn that they encrypt the data I send there “in transit” and “at rest.”

“In transit” means, when I send the data from my computer to Dropbox’s, it travels over an encrypted connection. That’s good. But my “what-ifs” didn’t seriously include, “What if someone eavesdrops on my network connection while I upload the file?” What I did wonder was, “What if someone hacks access to Dropbox’s data center and can go wandering around on their servers, looking at stuff?” The fact that my data arrived there safely last week doesn’t help me now, does it? So now I consider the fact that they also do “at rest” encryption. That means the data is encrypted while stored on their disks waiting to be retrieved. OK, that’s pretty good. But then one more thing bugs me: DropBox controls the keys needed to open those encrypted files and retrieve them in their original state. If those files are my tax returns, or sexy shots of my lover, I certainly don’t want anyone with access to the keys to be able to look at that! Yet, in this hacker-in-the-DropBox-servers scenario, that is exactly what becomes possible, because the same baddies who can get to my at-rest data can also probably get to those keys.

When I decided to use DropBox (or any of the similar services), I considered these kinds of things. A compromise I made when I decided to go ahead and use their service was, accepting that the data I stored there would indeed be vulnerable to this kind of threat. I also knew I had two ways to mitigate the risk, and I use a combination of both. The first and most important is, I am simply cautious about what I put in there. I put things there that I want to share, that I want available from my mobile devices, and that I don’t care that strongly if they were disclosed. No tax returns, and no cheesecake shots of my sweetie. Yes to pictures of my cats, social media memes or raw materials for blog posts.

The other mitigation is what I apply to the few things that do need protection but also need to be more widely available: I add my own encryption. If you think of encryption as a secure box to which you hold the key, then you’ll see why this helps. I encrypt my secret data — I put it in a box and lock it. Then I send it to DropBox. DropBox gets a file from me, encrypts it with their key, and stores it. Now, it’s a box within a box. If someone hacks DropBox’s data center, they can open the box locked with DropBox’s key only. When they get to what’s inside, it’s still locked with my key. And I never send that to DropBox, so my secrets are safe.

Encryption is a lock. Who holds the key, that’s what really matters.

The easiest way to add your own encryption to a file or several is to use one of the widely available utilities that create “Zip” or similar archives out of files or batches of them. All of these, in their latest versions, have the option to encrypt the resulting archive with a very strong and reliable system called AES – Advanced Encryption Standard. Just make sure you create a good strong password or phrase (as I wrote about here). And record that passphrase anywhere but in the cloud service where you store the resulting archive.