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.
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.
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.
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.
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.)
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.
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 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.
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.
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.)
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.
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.
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.