Which means the Islamic terrorists coincidentally live upstairs (which I believe is one of the stupidest coincidences of any book I have read and enjoyed.)
But note that's only due to popularity. Socially engineering your way into a user running an executable means that executable will simply run with user privs. No trickery or hacking required, no OS holes. And that will mean that the executable will have full access to do everything a user could do, which will effectively certainly include sending a new encryption key over the network, and encrypting every file that user can get a hold of.
(One of the little problems with the UNIX-style user permissions is that it is designed to defend the OS, not the user. Sure, that little executable may not be able to corrupt "the system", which may amount to 5 or 10 GBs of easily-replaced code, but it will have its way with the 2TB of the single user's media files.)
The only faint defense Linux/UNIX can claim is the slightly higher probability that you'll be on a checkpointing file system and can roll back, and I say only "slightly" because they still aren't very popular yet compared to conventional file systems.
OS X defaults to only running applications that have been signed with a valid developer ID. It’s not difficult to get such an ID, but Apple can also blacklist them, which would prevent the malware from running once Apple notices it. So I think the Mac has a good defense against this kind of attack.
Malware developer can make 256 valid developer IDs, compute 256 signatures and switch them automatically and randomly during the propagation of malware. Once Apple blacklists one developer ID, another one pops out, and so malware continues to propagate.
I would imagine that Apple can also say "this developer ID is owned by this person, and we just blacklisted another one owned by them", then proceed to blacklist all of the IDs they've generated
Still, it's not as easy as the person I was replying to made it sound.
How many Macs would you have to compromise before you randomly stumble upon a registered developer, let alone a registered Mac developer (of which there are far fewer than iOS developers)? And how much more secure is a developer's machine likely to be, and how much less is the user of such a machine likely to fall for common email attachment-based infection attempts?
At some point, the feasibility is low enough not to bother. That's what all security ultimately is, since nothing is foolproof.
I think it's no longer accurate to think of this as "MS-focused attack but only because OS X is not as popular". Today, iOS is used by many more people than OS X as their primary computing device and I would say it's pretty safe from this type of attack.
Only because people can't email you apps to run on your phone. Which, last I checked, is why HN thinks iOS is a terrible, freedom restricting walled garden of evil.
iOS is fantastic if you aren't smart enough to use a computer. Most HN users know better than to run arbitrary apps from email, so for them it is a restriction that only prevents them from using their own device as they wish to use it.
I'm sorry, but if a firm doesn't compartimentalise access and a single infected workstation can bring down everything, then they deserve what they get.
Hadn't been ransomware it could have very well been a disgruntled employee, to the same effect.
It's not truth, it hits residential users all the same. As much as we nerds might wish it, you don't deserve to be extorted because you don't understand computers.
While you're technically right - we are responsible for our security, and we should lock down our networks just like we lock our front doors - this is basically blaming the victim.
What sort of IT infrastructure do they usually have?
-
My gut reaction was that they wouldn't have a need for a server in the first place, but I guess that depends on how small it is.
A simple file-share though, would be rather vulnerable to this.
Have you fully secured your home and office against arson attacks? No? Don't even know how to do so? Didn't think so. Does that mean you deserve what you get if you end up bankrupt in the event of such an attack?
A company I work with was hit when the employee opened a phishing email supposedly from another employee in the same company. It hit about 50 gb of data on the shared drive. We had Crashplan and restored from a few days previous. I then turned on DKIM and enabled quarantining non DKIM emails via DMARC.
The ten thousand readers of HN who don't know these acronyms can use a search engine to look them up, or someone can ask a question and someone else can answer it and save 9,998 other readers the bother.
1 Google search = 1/35 of a boiled kettle.
So asking the question just saved about 285 boiled kettles of carbon footprint.
And having a flamewar on how people should google things for themselves wasted how many kettles? Anyway, if you don't want to tell people things, then don't tell people things, but going on and on on how OP should just google things themselves, is reaching 4chan levels of elitism. It's a really shitty kind of elitism.
DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit. Domain-based Message Authentication, Reporting and Conformance (DMARC) is a technical specification created by a group of organizations to help reduce the potential for email-based abuse, such as email spoofing and phishing e-mails, by solving some long-standing operational, deployment, and reporting issues related to email authentication protocols
Ah, I guess it is time to send the annual email to mom, dad, and the in-laws to be very wary of downloading anything or clicking on links in suspicious emails.
I find this is good insurance against the inevitable phone calls I receive as the only computer-literate member of the family: "Hey Cory, all my documents disappeared and I can't get them back. Do I have a virus?"
In a corporate environment I'd expect crucial data to be on the network drive and snapshotted every few hours. We run ZFS on our network and all the secretaries have to do their doc/excel work on the drive. Nowadays that everybody has a Gigabit Ethernet connection read/writes are extremely quick.
Use ZFS and make read only snapshots that are only accessible to the sysadmins. You'll solve many problems that way. We do snapshots at 6am,noon and 6pm and then keep the 6pm one for 7, 14 and 30 days.
Agreed. At a previous job, I set up a multi-terabyte SMB/NFS file server (Solaris, ZFS) with snapshots taken every 5 minutes. This was incredibly useful. The snapshots (in .zfs directories) were even accessible to end-users so that they could recover from their own mistakes without the help of sysadmins.
With such a setup, the only situation in which sysadmins are required are when end-users accidentally copy sensitive data to the file server, remove it, and need sysadmins to also remove the snapshots to permanently remove the sensitive data.
This is a great solution if you have a good technical staff helping to run a business. The reality is though that this is more likely to affect businesses without technical knowledge, or home users.
In about any corporation you look, crucial data will be in a Windows server (no ZFS available, sorry), and backed up on intervals that are some integer multiple of 24 hours.
Or, better, the above is the best case scenario that IT dreams of achieving some day. In practice, a huge share of the crucial data sits on people's machine, with no backups, and go on vacation every year.
Most corporate windows file servers (since 2003) use shadow copy, which saves previous versions of files every couple of hours. Any decent IT dept will use folder redirection, which redirects deskop, my documents to the local file server.
yup. But the fact they're using bitcoin shows a clever way for ransomware to collect payment with virtually zero-risk; since it's not possible(that I know of) to really trace exactly who, in real life, got those bitcoins. Which means, ransomware might make a strong comeback since the risk is now basically zero, this program isn't that difficult to write and there's real money to be made. Even if you only charged 50 USD, this idea would make hundreds, if not thousands, a month. Change the binary every once in awhile so its signature doesn't match popular anti-virus databases and you got free money coming in for... well ...forever[1]
1. Educating users to stop running random programs in zip files attached to emails, is apparently impossible. Maybe email-clients should scan the contents of any zipfile it receives and if it finds any kind of executable, put up all kinds of warning dialogs saying "You really don't want to run this. There's no reason to get a program in zipped email attachment nowadays. Please go consult your IT-admin or somebody who knows about computers for a 2nd-opinion"
the bitcoin pseudo-anonymity is a plus, but i feel the real value in this new round of ransomware is that the unlocking actually works. Its possible for the ransomware app to verify payment and unlock itself, with no contact or control from the ransomware author, greatly reducing the author's risk. Actually, its easier for the victim too - rather than wiring funds to some bank account in far off lands, a quick anonymous digital payment instead. Im speculating but its possible for the app to query blockchain.info for a deposit for a given address, or (less likely) for the app to download the blockchain itself, and then unlock after a certain balance. If there is high confidence that the data will actually get unlocked, that swings the balance of fight the app or pay the app towards the pay the app side. The author sits back and waits for those wallets to fill up.
The way this ransomware works still requires a centralized command and control server; without one, it would be possible to trigger the "unlock" codepath in the client without paying the authors.
The authors run a key-storage service which notifies the client (and provides a private key) once payment is received.
In this case the authors are still at a substantial advantage, though - as long as enough unlocks work that "just pay up" is the advice given online, they don't have to care if their C+C server is down half the time or the feds take it down, because the money rolls in even when the decryption isn't working.
That won't work, it could be prevented by a man-in-the-middle attack on the victim's own computer. Just spoof the blockchain signatures required as if the payment was sent on an ad-hoc network and the program would unlock itself.
> Educating users to stop running random programs in zip files attached to emails, is apparently impossible.
Imagine something just like the malware we're discussing, but instead of a 72 hour timer, it's a 4 hour timer - and at the end, it pops up a "gotcha! just kidding. but if this were real malware, you would have either lost hundreds of dollars, or all your documents. Don't open attachments like me."
Lower risk, but it probably reduces income: how many people can figure out how to make a bitcoin payment? How long does it take to make a bitcoin payment? The harder it is, the more likely the target is to give up and do without.
I would think their C&C server sets up a random Bitcoin wallet, and waits for a deposit, then allows the private key to be retrieved the next time CryptoLocker phones home.
I think their Bitcoin payment method is actually to facilitate international payments (funny in a dark way) - they also take the popular shady prepaid-debit/cash-wire service GreenDot Moneypak and I'd imagine most US victims paid up that way.
There are a couple of anecdotes on Reddit about Canadians and other non-US residents scrambling to find a physical Bitcoin storefront or Craigslist contact to pay the ransom for them since Moneypak wasn't available in their area.
Actually bitcoin has many strengths, but anonymity is not one of them. There have been multiple papers that go into how easy it is to trace, and even laundering style services like SRO used aren't very good.
This variant seems to - it needs the command and control servers to get the public key.
Particularly evil malware could probably encrypt the data irreversibly if the command and control servers were unavailable, since as long as the decryption works some portion of the time lots of people will pay, but thankfully this particular example doesn't seem to be there yet.
Even if it encrypts regardless, preventing the perpetrators from profiting will remove their incentive to keep spreading this stuff. Once antivirus catches up to the copies in the wild, the problem would be solved. Of course, whether it's actually possible to shut down enough servers to prevent them from profiting is another question. But it seems to me anything that makes it more difficult is a good thing, even though it does suck for those who lose data.
This wouldn't really prevent them from profiting - an unsuspecting user could still pay the ransom, and then never receive a decryption key, so would be both out of the money and lose their data.
Sure, it wouldn't prevent it completely, immediately. But 1) many users will do a search beforehand to see whether paying actually works. The less often it has worked for others, the less likely they will be to pay, and more importantly, 3) it would prevent them distributing new versions of the malware, which would prevent them profiting once antivirus caught up to the existing versions.
sidenote: this virus actually scares me, and it sounds like it actually scares most people who work in IT. This is the shittiest thing anybody has ever seen, it sounds like.
It actually made my skin crawl reading about it. Never had that reaction to such a story before. Interesting...
Edit: It's the BTC aspect that's worrisome. Ransomeware is nothing new -- AIDS Information Trojan did it in 1989, but the (potentially) safe method of payments in crypto currency seem to be a new factor that will attract much more innovation in these type of attacks.
I just though the exact opposite. When I read "Ransomware comes of age with ... anonymous payments." I just thought "Somebody is going for a surprise once he finds out how anonymous Bitcoin really is".
Anyway, what really makes me nervous is Microsoft's insistence of executing any data that a their programs touch.
This type of viruses are nothing new [0]. The only new thing in this case is that it demands BitCoins instead of an SMS to a premium number or something else.
Doesn't Google Chrome run under %AppData% in a default (non-MSI) install? (This is how it's able to silently update itself, even when run as a non-administrator.)
My understanding is they changed that and by default it wants admin rights. Then if that fails, it asks if you want to continue without. (At least, this was my experience the last time I had to install Chrome on a machine without admin rights.)
And that's just as good an idea as executable data segments in a binary format (ie. not a very good idea). It's taken MS literally YEARS to get to half-decent default filesystem permissions in Windows 7 and this kind of thing just undermines it totally.
What do you suggest instead? People who work at BigCorps and have shitty outdated IE installs are motivated to install alternative web browsers, even when they don't have administrative rights (and they almost never do.) Google is motivated to enable them to do so.
The real problem, I think, is that Microsoft thinks requiring admin rights to write to "Program Files" is the be-all and end-all of solving the "application-environment integrity problem." That works for enterprise-wide deploys of sysadmin-supported software, but falls down for user-specific installations. On OSX, "application-environment integrity" can be enforced easily enough, since the OS delineates applications by a line called "the app bundle." OSX can (though I'm not sure it does) just disallow apps from writing into other apps' bundles without a "do you really mean it" prompt. But in Windows, the The Directory Is The Application Bundle[1], and so Windows doesn't know that this directory is special and should be protected from having other apps in other directories tinkering with it.
Doesn't Google Chrome run under %AppData% in a default (non-MSI) install?
Yes, and from a security point of view it should be treated as hostile accordingly.
There is no need to actively circumvent Windows security like this. Firefox, among many other examples, is quite capable of automatically updating itself using a proper Windows service mechanism.
It's long past time that Google were called out on this one. Not only is it a potential security risk, it also interferes with backups of %AppData%, which is generally an area of Windows PCs that you do want to save regularly in case of disasters.
It probably is, but that doesn't make it any better as an idea. There is a good reason why every decent operating system's security model in the past few years has segmented this kind of functionality so only people with elevated privileges can do it.
EDIT: If I want to run/update something (Chrome) in Userland, why should an OS security model stop me? My guess is, Microsoft have successfully confused a common business requirement with a security one.
No, it's a required security feature that goes back decades in some operating systems. You need to be able to trust the code that runs on your system, and to do that you want to ensure only admin can install things.
Of course, Windows has now partially solved that with UAC. Unfortunately you can never know if you can trust the software or not though. However this does stop malware from secretly running without your permission, since it would require a UAC prompt to run. Then we get into uneducated users.
Or you could just not trust the code to begin with. The user should be able to run any program they want to. The OS just shouldn't trust the users programs. (And shouldn't autorun programs that the user didn't request).
Yes, but UAC has the same weakness as Linux permissions - it only protects the OS and programs, not the user-data. Programs can screw with userland data all they like without user permission.
The point is that UAC will (hopefully) prevent installing untrusted code in the first place, there by preventing those types of attacks. Unfortunately, you have to either trust that the user knows what programs are good, or go down the dark road that leads to things like an app store.
An interactive shell (like bash/python/irb) is untrusted code (i.e the user can type whatever the hell they like). But I don't/shouldn't need root to run it.
Wait, but 'install' means 'download' ? So if chrome was a single .py file, which I downloaded, and ran with python. Thats fine. But because it's a .exe, i need root... ?
This. I love Chrome, but their target market is using Windows, and asking them to click "Yes" to upgrade Chrome (or leaving this question up to the administrator) is not a barrier worth circumventing.
You don't even need to do that. You should need administrator access to install software initially, but that installation process can set up a system service that handles any subsequent updates automatically. This then runs independent of any current user on the system, and therefore does not depend on their personal privileges, nor does it need to prompt anyone for permissions for every update.
Clearly there is a risk involved with any process that can automatically download code you will subsequently execute. However, with proper access control, at least a compromised application running in user space can't do things like modifying its own executable so the malware has a place to live or, more generally, anything else that the user couldn't do without elevating their privilege level.
This certainly doesn't get us to an ideal security model. As I noted elsewhere in this discussion, a user on most systems today can probably still do things like e-mailing all the sensitive work documents they can access to a hostile party with just their normal privileges. However, it does at least prevent one common kind of attack.
Installing into %AppData% is, iirc, Microsoft's intended approach with ClickOnce installers (which Chrome uses). The difference is that ClickOnce installers have a far more restrictive permissions model than old MSIs.
ClickOnce-installed applications are limited to "Internet Zone" permissions. This can make them immensely frustrating to develop with, actually, since many of MS's own development frameworks fail miserably in Internet Zone even when they have no reason to do so (mostly they generate temporary files in places they aren't allowed).
I'm not sure how Google Chrome gets permissions to save files into your documents and whatnot from there - I don't recall Chrome requesting a permissions escalation during install or anything.
Fascinating. Thanks for sharing this information. I had no idea this was actually a sanctioned installation option, but clearly it is if you know what to look for[1]. That's actually rather disturbing, from a security point of view...
It surprises me that there is not central update service that every program can use, and that every program instead have to use it's own always on update poller.
It's helpful to add /A (shows .exe files even if they have hidden/system attributes set) and maybe /B (bare format, just the path/filenames without all the header/footer information).
I tried implementing this solution and it has a lot of difficult side effects. Shortcuts on the task bar could not run (with the exception of Chrome oddly enough). If you select run in IE it fails because it saves to temp and some installers failed as well, again because of the use of temp.
Unless the end user is very saavy or has an onsite IT this seems that the better solution is rotating backups.
Alternating days to external hard drives that are then disconnected is the best mitigation.
And having already had one client effected by this is does scare me. Interesting enough he paid and had his files decrypted in about 48 hours.
Unfortunately lots of stuff runs under there including, but not limited to:
GitHub for Windows and dozens of apps it installs in there
F.lux
Anything installed with ClickOnce
Chrome
GMVault
Xamarin's Android Support
Markdownpad
SkyDrive
Join.me
Assuming that everything in there is a virus is too much, I think.
I would think that .Net portable apps are likely also per user executables.. not to mention that there are usually at least one scripting environment even on windows cscript/jscript/vbscript/powershell for example, not to mention Java, Python, Ruby and/or node may be installed.
I tried implementing this solution and it has a lot of difficult side effects. Shortcuts on the task bar could not run (with the exception of Chrome oddly enough). If you select run in IE it fails because it saves to temp and some installers failed as well, again because of the use of temp.
Unless the end user is very saavy or has an onsite IT this seems that the better solution is rotating backups.
Alternating days to external hard drives that are then disconnected is the best mitigation.
If the "1002.exe" sample on Reddit is accurate the installer is unsigned, so forbidding unsigned binaries should be sufficient. The number of legitimate unsigned Windows binaries is small enough that you should be able to whitelist them by hand.
That being said a very restrictive Software Restriction Policy as linked below would mitigate CryptoLocker as it exists today. It has worked well for me so far.
Our company was hit by this yesterday, caused a lot of issues. Thank god we had backups, but they were 2 days old (frustratingly enough, the backup failed the previous day - first time in months...)
While I'd like to think I'm sophisticated enough about security to avoid this, it makes me concerned about the vast majority of people (e.g. my parents, my girlfriend) that are clueless about such dangers.
Are there any recommendations of a simple way to at least enable automated backups of local documents to the cloud on a windows box?
I think that you could use Box for this pretty effectively. With their $15/month business plan, you get 1TB of storage and can apparently set any directory as a "workspace", which presumably includes the home directory. For most users, that would be more sufficient to keep everything backed up and the syncing process is supposed to be the same kind of transparent deal as Dropbox (which would also be a good solution, except that you can't set an arbitrary directory as your Dropbox folder).
until it encrypts the workspace and that gets synced. Although, I suppose you might have a previous revision as I know dropbox supports versioning for some (all?) kinds of files.
Tarsnap is the only sensible backup provider given the recent history of warantless secret searches in America. SpiderOak is also a contender for file sharing. Both use end-to-end encryption knowable only to the end-user.
It's funny you mention that.... I implore 'cperciva to consider a glacier-level service. It is hard to compete with backblaze, but capping network bwdth is proly one way to skin that cat.
The crashplan JARs decompile pretty easily - I had a go a few months ago, and they weren't obfuscated.
Highlights:
The crypto is pretty bad - it's using blowfish in CBC mode with a static IV of 0c22384e5a57412b (convert each byte to decimal...).
The client-server protocol use 32 bit nonces and MACs, which is.
License key validation works by decrypting some packed data from the key after converting the alphabet back to hex. The key is blowfish-cbc encrypted data and the only validation done is verifying the padding - about 1 in 256 randomly generated ones will have valid padding, and the length is not checked.
I like and have used Tarsnap in the past, but it's not like other providers prevent you from uploading encrypted archives, they just don't encrypt them themselves.
There's list of a some backup solutions relevant to personal backup (as opposed to enterprise level solutions) here, costs for most providers given too and a brief overview of differentiating features - http://alicious.com/cloud-backup-solutions/.
I quite like duplicati. Slightly opaque to set-up but I'm using it with SkyDrive for some files as at the time of set-up SkyDrive gave me the most free storage with the lowest level of pain [for me] setting up.
I think the interesting thing here is the shift from the target - the "best" target used to be compromising the OS, so OS's made moves to protect themselves from programs running as unprivileged users. Now, it's trivial to wipe an OS and restore from a backup. The real value is the things people store on a computer, which are usually going to be accessible via a user account.
One trivial solution would be OS level automatic versioning of files (ala Dropbox or Sparkleshare) - the original files would be written to location that is read only to the user and only accessible via the OS, hence, backups could always be restored from it, but never destroyed without admin rights.
Of course, with people having great internet and whatnot, an automatic cloud based solution would be much more likely and useful.
I think with Windows 8.1 and onwards, Microsoft are automatically doing this by setting up the "Documents" type folders in SkyDrive - a great think moving forward.
Backups are, obviously, a much better solution but require extra storage and usually cost money.
So there might be a niche for a freeware product that runs as an admin that automatically versions files - perhaps even as simple as having an admin-owned .git repo for the Documents folder.
The worrying thing about this attack is that targeting user data is trivial on all OSs, because of the way we think about privileges - it could be done to us Linux users through something nasty in our shell rc using GPG or whatever. There is no need to compromise anything.
> Backups are, obviously, a much better solution but require extra storage and usually cost money.
And the virus will encrypt anything writable, so the backup needs to be "pull", if the infected machine is the one doing backups and has write access to a non-cold-storage backup location it will may encrypt the backup itself.
Solved this problem at my startup Nuevo Cloud.. the filesystem is copy-on-write, including deletions.. In the settings you can control how long to keep the copy-on-write log, and then you can jump to any second within the log.
So even if this virus encrypted your backup on Nuevo Cloud, you can just pull up the snapshot from a second before the infection, and restore your files.
Yes, the service doesn't have a 'space limit' setting.. So it's essentially infinite storage. It is deduplicated, so there is some savings there.. And the log only saves your changes.. So the space used would be 100% + % changed during period - % duplicated
We are working on a 'space limit' setting (should be finished shortly).. But if that were enabled, and you exceeded it, you would just get a write error when new data is written.. It wouldn't delete the log.. So if that setting were finished, an you got this virus, the virus might get a write error halfway through.. But your old versions would still be safe.
I do something similar. I keep all my files on an external HD drive. Only thing on my pc are the programs I need.
My impending move to Tails OS is also timely considering this new virus. We just spent two days dealing with this after an exec launched one of these and encrypted a bunch of files on one of our servers. This, after two emails warning about it.
Yup, this is basically what I was thinking - the daemon would run as a system user (e.g. root or something that could access user files) would "commit" the changes on write, pulling from the user's files, creating a read-only copy.
Obviously there are of course issues running stuff like this as root - if the daemon was compromised in any way it's game over.
The only virus I ever got was the SevenDust 666 virus on Mac OS 8. An infected machine would have a "666" extension that couldn't be deleted (it would instantly replace itself) and then start losing files. So losing files as a target has been around for many years.
The interesting change to me is that now viruses have been effectively monetized.
I think the interesting thing here is the shift from the target - the "best" target used to be compromising the OS, so OS's made moves to protect themselves from programs running as unprivileged users. Now, it's trivial to wipe an OS and restore from a backup. The real value is the things people store on a computer, which are usually going to be accessible via a user account.
You make an excellent point, but there is a second and perhaps even more sinister side to it. Encrypting your data and holding it hostage is one thing, but even if you have indestructible backups, there are probably still many sensitive pieces of information that can be acquired by a blackmailer with only user-level privileges: bank details, company trade secrets, personal mail/photos/videos, etc.
Having a back-up of these is important, but probably so is ensuring that they aren't distributed to people they shouldn't be. This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet.
> This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet.
I'm not sure it does require a different model of access control. It just requires people to actually use the access control mechanisms that exist already.
You should not access banking details or any other sensitive information in the same user-level context as you use to generally browse the internet. The privileges needed for each task ("browse the internet" vs. "check bank statements") should be different. I personally have a separate user account on my machine set up specifically for "sensitive" tasks.
Separation of data access via privileges is nothing revolutionary, nor is it something that can't be done on any modern OS. Unfortunately, online services are still behind. For example, I would probably switch to an online banking provider that let me create one account for viewing balances and another for transferring cash. But these services will get there in time.
Your proposal is OK if accessing sensitive information is something you only do occasionally, but it's not very practical to switch users completely if you deal with sensitive information often, which many people do.
On the other hand, if only explicitly authorised applications can create outbound Internet connections at all, and if applications like browsers and e-mail clients need explicit permission to read a general user file (as opposed to, say, accessing their own designated configuration or data files), then you significantly decrease the degree of vulnerability a user has to data leakage attacks (among other types).
Check out qubes os if you don't want to trust your kernel to enforce your mandatory access controls (you DO only allow certain applications/users/groups/roles/OS's/Hypervisors/etc... to do certain things, DON'T YOU??). Xen is a smaller attack surface, and depending on how much of a pain in the ass you consider having all of your files stolen and deleted being, there are many options for locking it down quite a lot. XSM-Flask if you are too paranoid, Hypersafe for control flow attacks + invariant violation detection tools for non-control data attacks over nested hypervisors if you are resolute.
>Your proposal is OK if accessing sensitive information is something you only do occasionally, but it's not very practical to switch users completely if you deal with sensitive information often, which many people do.
$ sudo -u banking gnucash &
$ firefox &
Done. My banking files and my Firefox session are now separated.
And for the 99.7% of users in the real world who drive their computers using a GUI and not a command line? Or those who do use a command line but aren't sufficiently competent with system administration to reliably get sudo-based access control right every time?
What about photos? I could see ransomware being very successful just demanding payment to avoid making a bunch of your personal photos publicly available on the internet. They may not be sensitive per se, but they're still likely not something you want out there publicly. Ditto for email, chat messages, etc., etc.
The problem is seemingly solved by OS X app sandbox and Mac App Store review process (the sandbox alone is not enough, because it allows to declare 'exceptions' like full disk access, so human reviewers are needed to watch out for those).
The sandbox may occasionally be causing some pain (in fact, would be very painful if I had to support OS X 10.7), but at the same time my app can no longer access any user data that the user hasn't explicitly whitelisted, which is a good thing.
Windows Metro apps also live in a sandbox, but they are sort of a different platform (no access to the file system at all, as far as I know). Over time, I can see them gaining some access to a subset of the file system, perhaps via SkyDrive.
> the original files would be written to location that is read only to the user and only accessible via the OS
A versioning filesystem looks much cleaner than a different location. Maybe we should start using those again. (Is there any candidate for ext5 already?)
And yes, partitioning the data permissions for the same user is a much needed change. Nobody got a solution for that yet, and there are lots of people trying. Apple, for example, is just giving up on iOS; Google has a subpar solution on Android that does not actually work on practice (the cyanomod people did improved it a bit) but is the closest we have from something viable.
Been using NILFS2 for 3 years now. Works great, performance is decent. It lacks extended attributes and ACLs, but the automatic snaptshot part is worth it.
Central to the plot in the book Reamde but these guys don't offer a 'pay in WoW gold' choice.
Given the cost of computers these days, at least in business a separate 'browsing' machine and 'business' machine seems to be the best solution. I wonder if you could provide wireless for employees to bring their own laptops which had no 'office' connectivity (but internet connectivity) and machines that were hard wired and MAC filtered to the 'business' network.
but this one seems to do what it claims to do. it's pretty scary for people who don't have decent backup system. but these same people live with the risk of losing their data due to a drive failure, so...
A lot of "decent backup systems" would be vulnerable to this too. Say you back up all your local stuff to a RAID that you've mapped as a drive, as well as a mapped Google Drive?
It's still all toast.
That level of backup would handle any kind of physical failure - a dead drive, the destruction of your house, the failure of Google... but still, this thing would kill it.
There's only so much you can expect from a person when it comes to keeping their personal documents and family photos.
I mean obviously, if you're running a company you need a real backup solution, but for family files or a one-man-show business? There is no reasonable precaution.
This type of thing only works because the backup user has identical permissions to the backup contents as the user being backed up (because they're the same).
It wouldn't work on any system where the backup user is a separate, privileged process that is the only one with write access to the stores of backed up files.
ZFS with a snapshot script is a good way to implement this for a networked drive on Samba, since it's implicit, automatic, and the point at which it hits would be really really obvious since your snapshot sizes would suddenly explode. The same story is true of volume shadow copy (but MS idiotically limits the user's ability to set a known and trustworthy shadow copy schedule).
The article mentions that there is a $100 variant floating around.
Makes me wonder whether they use the $100 variant in markets that $300 would be too much to pay.
If, is as reported, this virus is pulling in around ~$5million / annum, then that is a great basis for setting up a professional organisation to run the virus and extract maximum value from it.
Since the Bitcoin blockchain is public, couldn't you follow the money? Make a list of all wallets that accepted these funds initially, and then do graph analysis, either to see where the money went or provide others with a tool to avoid transactions with those wallets?
Yes, but this is somewhat like saying you could mark the banknotes used to pay off a person that's blackmailing you. If you catch someone with a marked note that doesn't prove they are the perpetrator; it just means that they received your money somehow.
Problem is that doesn't really help you identify the perpetrators. Both mixing services, and the fact that a user can generate unlimited wallets (if someone sends money to a wallet, you can't prove they own the second wallet or if they transferred money to someone else) makes this very difficult.
294 comments
[ 2.9 ms ] story [ 272 ms ] threadhttps://www.goodreads.com/book/show/10552338-reamde
(One of the little problems with the UNIX-style user permissions is that it is designed to defend the OS, not the user. Sure, that little executable may not be able to corrupt "the system", which may amount to 5 or 10 GBs of easily-replaced code, but it will have its way with the 2TB of the single user's media files.)
The only faint defense Linux/UNIX can claim is the slightly higher probability that you'll be on a checkpointing file system and can roll back, and I say only "slightly" because they still aren't very popular yet compared to conventional file systems.
How many Macs would you have to compromise before you randomly stumble upon a registered developer, let alone a registered Mac developer (of which there are far fewer than iOS developers)? And how much more secure is a developer's machine likely to be, and how much less is the user of such a machine likely to fall for common email attachment-based infection attempts?
At some point, the feasibility is low enough not to bother. That's what all security ultimately is, since nothing is foolproof.
http://xkcd.com/1200/
Hadn't been ransomware it could have very well been a disgruntled employee, to the same effect.
This said, I'm not blaming home users, but IT folks who failed to secure corporate data and should have known better.
Translation for techies who aren't familiar with email's many acronyms?
Also, experts often have insights that introductory articles lack. Better to ask the source if they don't mind composing.
I often prefer a succinct summary from an expert to, say, a wikipedia entry.
1 Google search = 1/35 of a boiled kettle.
So asking the question just saved about 285 boiled kettles of carbon footprint.
(http://green.tmcnet.com/topics/green/articles/216400-google-...)
DMARC means: http://en.wikipedia.org/wiki/DMARC
And the person below you doesn't understand how search engines work.
edit: never mind, I thought this was novel. Never heard of ransomware before.
I find this is good insurance against the inevitable phone calls I receive as the only computer-literate member of the family: "Hey Cory, all my documents disappeared and I can't get them back. Do I have a virus?"
Use ZFS and make read only snapshots that are only accessible to the sysadmins. You'll solve many problems that way. We do snapshots at 6am,noon and 6pm and then keep the 6pm one for 7, 14 and 30 days.
(Tested backups are the first three rules of IT.)
IIRC ZFS snapshots are read-only by definition. Clones are the writable ones.
With such a setup, the only situation in which sysadmins are required are when end-users accidentally copy sensitive data to the file server, remove it, and need sysadmins to also remove the snapshots to permanently remove the sensitive data.
Or, better, the above is the best case scenario that IT dreams of achieving some day. In practice, a huge share of the crucial data sits on people's machine, with no backups, and go on vacation every year.
1. Educating users to stop running random programs in zip files attached to emails, is apparently impossible. Maybe email-clients should scan the contents of any zipfile it receives and if it finds any kind of executable, put up all kinds of warning dialogs saying "You really don't want to run this. There's no reason to get a program in zipped email attachment nowadays. Please go consult your IT-admin or somebody who knows about computers for a 2nd-opinion"
The authors run a key-storage service which notifies the client (and provides a private key) once payment is received.
In this case the authors are still at a substantial advantage, though - as long as enough unlocks work that "just pay up" is the advice given online, they don't have to care if their C+C server is down half the time or the feds take it down, because the money rolls in even when the decryption isn't working.
Imagine something just like the malware we're discussing, but instead of a 72 hour timer, it's a 4 hour timer - and at the end, it pops up a "gotcha! just kidding. but if this were real malware, you would have either lost hundreds of dollars, or all your documents. Don't open attachments like me."
1. Immediately kill the messenger, and
2. Continue to open executable mail attachments, because nothing bad has ever happened that didn’t work itself out in the end.
http://shop.wikileaks.org/donate
Now, how the malware-writer goes about verifying payment is beyond my understanding...
There are a couple of anecdotes on Reddit about Canadians and other non-US residents scrambling to find a physical Bitcoin storefront or Craigslist contact to pay the ransom for them since Moneypak wasn't available in their area.
http://fc13.ifca.ai/proc/1-3.pdf http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
Particularly evil malware could probably encrypt the data irreversibly if the command and control servers were unavailable, since as long as the decryption works some portion of the time lots of people will pay, but thankfully this particular example doesn't seem to be there yet.
sidenote: this virus actually scares me, and it sounds like it actually scares most people who work in IT. This is the shittiest thing anybody has ever seen, it sounds like.
Edit: It's the BTC aspect that's worrisome. Ransomeware is nothing new -- AIDS Information Trojan did it in 1989, but the (potentially) safe method of payments in crypto currency seem to be a new factor that will attract much more innovation in these type of attacks.
Anyway, what really makes me nervous is Microsoft's insistence of executing any data that a their programs touch.
https://blockchain.info/wallet/send-shared
(Please note, before downvoting, that I'm not saying that's a bad thing)
[0] - https://www.securelist.com/en/descriptions/old313444
> The first known ransomware was the 1989 "PC Cyborg" trojan written by Joseph Popp
The real problem, I think, is that Microsoft thinks requiring admin rights to write to "Program Files" is the be-all and end-all of solving the "application-environment integrity problem." That works for enterprise-wide deploys of sysadmin-supported software, but falls down for user-specific installations. On OSX, "application-environment integrity" can be enforced easily enough, since the OS delineates applications by a line called "the app bundle." OSX can (though I'm not sure it does) just disallow apps from writing into other apps' bundles without a "do you really mean it" prompt. But in Windows, the The Directory Is The Application Bundle[1], and so Windows doesn't know that this directory is special and should be protected from having other apps in other directories tinkering with it.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/06/20/10176...
Every time my interent connection slows (WiFi) I know it's Chrome Updater so I kill it via Task Manager and everthing is good again.
There doesn't apear to be away to turn it off inside Chrome itself and turning off updates via the registry does not seem to stop it.
You could say it's in its DNA
/ducks
Or try Firefox!
Yes, and from a security point of view it should be treated as hostile accordingly.
There is no need to actively circumvent Windows security like this. Firefox, among many other examples, is quite capable of automatically updating itself using a proper Windows service mechanism.
It's long past time that Google were called out on this one. Not only is it a potential security risk, it also interferes with backups of %AppData%, which is generally an area of Windows PCs that you do want to save regularly in case of disasters.
EDIT: If I want to run/update something (Chrome) in Userland, why should an OS security model stop me? My guess is, Microsoft have successfully confused a common business requirement with a security one.
Of course, Windows has now partially solved that with UAC. Unfortunately you can never know if you can trust the software or not though. However this does stop malware from secretly running without your permission, since it would require a UAC prompt to run. Then we get into uneducated users.
In windows there are too many ways to get elevated. And only one level of elevation.
Do you know one of the most asked questions in Mac OS X user forums from new users is how to disable root?
After all, there are tons of popular projects requesting users to run "curl http://... | sudo sh" and consider that a good idea, too.
I keep trying to teach my nephews that the default answer to that question is no... but of course, "yes" is the way you get anything done.
I fail to see the difference. Sorry.
You don't even need to do that. You should need administrator access to install software initially, but that installation process can set up a system service that handles any subsequent updates automatically. This then runs independent of any current user on the system, and therefore does not depend on their personal privileges, nor does it need to prompt anyone for permissions for every update.
Clearly there is a risk involved with any process that can automatically download code you will subsequently execute. However, with proper access control, at least a compromised application running in user space can't do things like modifying its own executable so the malware has a place to live or, more generally, anything else that the user couldn't do without elevating their privilege level.
This certainly doesn't get us to an ideal security model. As I noted elsewhere in this discussion, a user on most systems today can probably still do things like e-mailing all the sensitive work documents they can access to a hostile party with just their normal privileges. However, it does at least prevent one common kind of attack.
They have had it for ages, presumably to answer your mentioned complaints.
ClickOnce-installed applications are limited to "Internet Zone" permissions. This can make them immensely frustrating to develop with, actually, since many of MS's own development frameworks fail miserably in Internet Zone even when they have no reason to do so (mostly they generate temporary files in places they aren't allowed).
I'm not sure how Google Chrome gets permissions to save files into your documents and whatnot from there - I don't recall Chrome requesting a permissions escalation during install or anything.
[1] http://msdn.microsoft.com/en-us/library/142dbbz4%28v=vs.90%2...
GitHub for Windows and dozens of apps it installs in there F.lux Anything installed with ClickOnce Chrome GMVault Xamarin's Android Support Markdownpad SkyDrive Join.me
Assuming that everything in there is a virus is too much, I think.
If the "1002.exe" sample on Reddit is accurate the installer is unsigned, so forbidding unsigned binaries should be sufficient. The number of legitimate unsigned Windows binaries is small enough that you should be able to whitelist them by hand.
http://technet.microsoft.com/en-us/library/ee424382.aspx
That being said a very restrictive Software Restriction Policy as linked below would mitigate CryptoLocker as it exists today. It has worked well for me so far.
http://www.mechbgon.com/srp/
Are there any recommendations of a simple way to at least enable automated backups of local documents to the cloud on a windows box?
1. http://www.carbonite.com/ 2. http://www.crashplan.com/ 3. http://www.backblaze.com/
"Backup solutions like Carbonite are no good against this as they will commit the encrypted files to the cloud."
You need "cold" backups to get around this without paying.
[1] http://www.reddit.com/r/sysadmin/comments/1mizfx/proper_care...
I do not work for backblaze, but I am a happy user.
Highlights:
The crypto is pretty bad - it's using blowfish in CBC mode with a static IV of 0c22384e5a57412b (convert each byte to decimal...).
The client-server protocol use 32 bit nonces and MACs, which is.
License key validation works by decrypting some packed data from the key after converting the alphabet back to hex. The key is blowfish-cbc encrypted data and the only validation done is verifying the padding - about 1 in 256 randomly generated ones will have valid padding, and the length is not checked.
The test key:
/com/code42/license/LicenseKey.java: private static final byte[] KEY = "Brian in the Conference Room with the Mouse. To be.".getBytes();
I assume this is some inside joke referring to Brian Bispala.
I assume you're using a temp because of the DMCA?... :(
I quite like duplicati. Slightly opaque to set-up but I'm using it with SkyDrive for some files as at the time of set-up SkyDrive gave me the most free storage with the lowest level of pain [for me] setting up.
I have mine set to backup every 4 hours. It versions the files as well so you can restore to a previous backup.
One trivial solution would be OS level automatic versioning of files (ala Dropbox or Sparkleshare) - the original files would be written to location that is read only to the user and only accessible via the OS, hence, backups could always be restored from it, but never destroyed without admin rights.
Of course, with people having great internet and whatnot, an automatic cloud based solution would be much more likely and useful.
I think with Windows 8.1 and onwards, Microsoft are automatically doing this by setting up the "Documents" type folders in SkyDrive - a great think moving forward.
Backups are, obviously, a much better solution but require extra storage and usually cost money.
So there might be a niche for a freeware product that runs as an admin that automatically versions files - perhaps even as simple as having an admin-owned .git repo for the Documents folder.
The worrying thing about this attack is that targeting user data is trivial on all OSs, because of the way we think about privileges - it could be done to us Linux users through something nasty in our shell rc using GPG or whatever. There is no need to compromise anything.
And the virus will encrypt anything writable, so the backup needs to be "pull", if the infected machine is the one doing backups and has write access to a non-cold-storage backup location it will may encrypt the backup itself.
So even if this virus encrypted your backup on Nuevo Cloud, you can just pull up the snapshot from a second before the infection, and restore your files.
We are working on a 'space limit' setting (should be finished shortly).. But if that were enabled, and you exceeded it, you would just get a write error when new data is written.. It wouldn't delete the log.. So if that setting were finished, an you got this virus, the virus might get a write error halfway through.. But your old versions would still be safe.
My impending move to Tails OS is also timely considering this new virus. We just spent two days dealing with this after an exec launched one of these and encrypted a bunch of files on one of our servers. This, after two emails warning about it.
Obviously there are of course issues running stuff like this as root - if the daemon was compromised in any way it's game over.
The interesting change to me is that now viruses have been effectively monetized.
[1]: http://backuppc.sourceforge.net/
You make an excellent point, but there is a second and perhaps even more sinister side to it. Encrypting your data and holding it hostage is one thing, but even if you have indestructible backups, there are probably still many sensitive pieces of information that can be acquired by a blackmailer with only user-level privileges: bank details, company trade secrets, personal mail/photos/videos, etc.
Having a back-up of these is important, but probably so is ensuring that they aren't distributed to people they shouldn't be. This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet.
I'm not sure it does require a different model of access control. It just requires people to actually use the access control mechanisms that exist already.
You should not access banking details or any other sensitive information in the same user-level context as you use to generally browse the internet. The privileges needed for each task ("browse the internet" vs. "check bank statements") should be different. I personally have a separate user account on my machine set up specifically for "sensitive" tasks.
Separation of data access via privileges is nothing revolutionary, nor is it something that can't be done on any modern OS. Unfortunately, online services are still behind. For example, I would probably switch to an online banking provider that let me create one account for viewing balances and another for transferring cash. But these services will get there in time.
User education is a different story.
On the other hand, if only explicitly authorised applications can create outbound Internet connections at all, and if applications like browsers and e-mail clients need explicit permission to read a general user file (as opposed to, say, accessing their own designated configuration or data files), then you significantly decrease the degree of vulnerability a user has to data leakage attacks (among other types).
If we create a script 1:
And then script 2: Then run: Looks like Firefox has access to your banking user :)The problem is seemingly solved by OS X app sandbox and Mac App Store review process (the sandbox alone is not enough, because it allows to declare 'exceptions' like full disk access, so human reviewers are needed to watch out for those).
The sandbox may occasionally be causing some pain (in fact, would be very painful if I had to support OS X 10.7), but at the same time my app can no longer access any user data that the user hasn't explicitly whitelisted, which is a good thing.
Windows Metro apps also live in a sandbox, but they are sort of a different platform (no access to the file system at all, as far as I know). Over time, I can see them gaining some access to a subset of the file system, perhaps via SkyDrive.
A versioning filesystem looks much cleaner than a different location. Maybe we should start using those again. (Is there any candidate for ext5 already?)
And yes, partitioning the data permissions for the same user is a much needed change. Nobody got a solution for that yet, and there are lots of people trying. Apple, for example, is just giving up on iOS; Google has a subpar solution on Android that does not actually work on practice (the cyanomod people did improved it a bit) but is the closest we have from something viable.
Given the cost of computers these days, at least in business a separate 'browsing' machine and 'business' machine seems to be the best solution. I wonder if you could provide wireless for employees to bring their own laptops which had no 'office' connectivity (but internet connectivity) and machines that were hard wired and MAC filtered to the 'business' network.
It's still all toast.
That level of backup would handle any kind of physical failure - a dead drive, the destruction of your house, the failure of Google... but still, this thing would kill it.
There's only so much you can expect from a person when it comes to keeping their personal documents and family photos.
I mean obviously, if you're running a company you need a real backup solution, but for family files or a one-man-show business? There is no reasonable precaution.
This type of thing only works because the backup user has identical permissions to the backup contents as the user being backed up (because they're the same).
It wouldn't work on any system where the backup user is a separate, privileged process that is the only one with write access to the stores of backed up files.
ZFS with a snapshot script is a good way to implement this for a networked drive on Samba, since it's implicit, automatic, and the point at which it hits would be really really obvious since your snapshot sizes would suddenly explode. The same story is true of volume shadow copy (but MS idiotically limits the user's ability to set a known and trustworthy shadow copy schedule).
Makes me wonder whether they use the $100 variant in markets that $300 would be too much to pay.
If, is as reported, this virus is pulling in around ~$5million / annum, then that is a great basis for setting up a professional organisation to run the virus and extract maximum value from it.
How about 300 VND? Seems similar to me. :)