I was hit by this, or a variant, at my place of business. Hundreds of thousands of files on our shared drive were overwritten, about 2 TB worth of files. Office documents, PDFs, and Adobe documents like PSD and INDD were encrypted. JPEGs were altered but still viewable. All files increased in size by a few hundred bytes.
Pull-only backups were the savior here, although because we didn't notice until the next day, the pulled backups on that system were also overwritten with encrypted/corrupt files. Luckily we had VSS versioning on the pull-only backup location. There was a close call in that the 2 TB or so of "new" data ended up pushing VSS over quota and we almost lost our good versions of the files that way. If not for the VSS versions, we would've had to resort to cold backups which would've been a bit older. As it stood, no file recovered was more than a few hours old.
Auditing on the file share indicates which workstation was infected. Pertaining to that: it surprises me that in 2013, a default install of Windows will not log any useful information about shared folders by default. You must enable object auditing in Group Policy and specifically declare which users or groups are subject to said auditing on a share-by-share basis. In a world without logrotate, I suppose a sensible default is to just let a bunch of shit happen without recording it.
What gets me wound up most of all is the amount of engineering involved for an average home user to protect themselves. I thought a Mac with Time Machine was enough, but a similar virus would easily corrupt those backups if they were available to it over a mapped drive.
It is the goddamn 21st century, and users are still losing work by overwriting documents by accident, or opening a document as an e-mail attachment and not being able to find the actual file they edited. Should people really need an IT guy with ten years of experience to be protected from simple mistakes? Google has made progress on that front with the Chromebook, I suppose.
Something like CrashPlan provides good protection against this sort of thing for home users. It includes versioned, off-site backups -- either on their servers for around $6 a month, or on a "friend's computer" for free. Either way, the backups are saved via crashplan, not with direct drive access, so it should be safe against this kind of thing.
> opening a document as an e-mail attachment and not being able to find the actual file they edited
I'm so sick of this. The "open/save" dialog is in sore need of being revamped. There's really no such thing as "open" anyway -- it's really "save to some obscure profile temp directory and then open". Try explaining "you can't open a file that's not first saved to disk" to a user, though.
But sometimes you want to just "open" a file. The fact that your computer may choose to save it is an implementation detail. In fact, most systems don't actually 'save' it in many senses of the word. Instead they write it to the file system in a way that indicates that it may be removed at any time without notifying the user. In fact, on Linux (I can't speak to any other OS), it is common for these temporary files never to actually be saved to the disk. Instead they are loaded into a RAM based file-system (tmpfs), usually found at "/dev/shm"
In a way, that's worse! You'll have someone "open" a file, maybe make some edits to it, save it -- and it won't indicate a problem with that because it's considered as a file on disk somewhere -- and then when they go to send it, they can't find it and it may have been overwritten / deleted.
If the file is opened read-only, then programs should fall back to save as. Unfourtuantly, the only standard way to signal read-only is with file permisions. This will work, but many programs would likely have report a permisions error prior to the save as. Also it will cause problems for programs that transparently modify the file on disk while viewing.
I suppose you could hard code the read only parameter into the command that is used to execute the external program. Or have the external programs check if they are in a tmp-directory.
Presumably it's doing something like encrypting just the file headers or a part of the file, that way it can "lock" more files in a shorter time. JPEGs seem to be quite robust in being partly recoverable even when parts of a deleted file have been over-written - sorry I don't know the details.
For science, I will try to find one that is acceptable to share and post a before/after, or just the results of the comparison.
What I recall from my initial investigation was that the binary was completely different, but opening the image did not indicate any changes. Almost like it was converted from RGB to CMYK or something.
I went back and found that I was mistaken. JPG files that were altered were in fact completely unreadable.
In the confusion, I missed that JPGs with certain naming patterns were encrypted and others were left alone. I took two unrelated facts, 1) that plenty of images were readable, and 2) that plenty of images had binary differences, and put them together to arrive at a faulty conclusion. I am not going to be too hard on myself based on how that day was going for me.
IMG_????.jpg and presumably DSC?????.jpg were encrypted and other patterns were left alone. I presume this is to inflict damage as quickly as possible without getting bogged down encrypting stuff from "Temporary Internet Files" for hours.
I wonder if they'd improve their conversion rate by leaving behind a thumbnail to remind people of how much they liked their pictures that now risk being gone forever.
I really don't think we should try to dumb down UX for the benefit of less experienced users. You run the risk of creating a false understanding of how a computer works which can cause harm down the line, as well as frustrating and confusing more advanced users who do know what happens when you save a word document. Besides, as the user population ages it's becoming less of a problem.
I mentioned cold backups -- those just would've been a little older.
The pull-only archive w/ VSS versions really is massively convenient. It is the first line of defense against the scenario that comes up almost all of the time: "Help, I messed up this important file!"
Pull-only backups were the savior here, although because we didn't notice until the next day, the pulled backups on that system were also overwritten with encrypted/corrupt files. Luckily we had VSS versioning on the pull-only backup location. There was a close call in that the 2 TB or so of "new" data ended up pushing VSS over quota and we almost lost our good versions of the files that way. If not for the VSS versions, we would've had to resort to cold backups which would've been a bit older. As it stood, no file recovered was more than a few hours old.
Auditing on the file share indicates which workstation was infected. Pertaining to that: it surprises me that in 2013, a default install of Windows will not log any useful information about shared folders by default. You must enable object auditing in Group Policy and specifically declare which users or groups are subject to said auditing on a share-by-share basis. In a world without logrotate, I suppose a sensible default is to just let a bunch of shit happen without recording it.
What gets me wound up most of all is the amount of engineering involved for an average home user to protect themselves. I thought a Mac with Time Machine was enough, but a similar virus would easily corrupt those backups if they were available to it over a mapped drive.
It is the goddamn 21st century, and users are still losing work by overwriting documents by accident, or opening a document as an e-mail attachment and not being able to find the actual file they edited. Should people really need an IT guy with ten years of experience to be protected from simple mistakes? Google has made progress on that front with the Chromebook, I suppose.