Live data from Hacker News

You’re infected—if you want to see your data again, pay us $300 in Bitcoins

arstechnica.com

131–140 of 295 posts

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#131
post #81

Earlier quoted context omitted.

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

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#132
post #20

You can work to prevent this by creating a group policy that disallows %AppData%\*.exe and %AppData%\*\*.exe A good discussion of this happened here: http://www.reddit.com/r/sysadmin/comments/1mizfx/proper_care... 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.

Here's a command you can run to find out what executables exist in AppData: dir /S /P "%userprofile%\AppData\*.exe" > %userprofile%\Desktop\FoundFiles.txt

Or for PowerShell:

    dir -Path "$env:userprofile\AppData" -Filter *.exe -Recurse > "$env:userprofile\Desktop\FoundFiles.txt"
Useful if your corporate security policy, like mine, has disabled the command prompt but left PowerShell intact.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#133
post #53

Earlier quoted context omitted.

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 o…

"Chrome for Enterprise" is a standard MSI that installs in Program Files for exactly this reason.

They have had it for ages, presumably to answer your mentioned complaints.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#134

Earlier quoted context omitted.

I thought it was so you didn't need admin to install it?

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.

And that good reason is?

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.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#135
post #117
post #62

Earlier quoted context omitted.

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.

CrashPlan supports this, although it is not the default.

It's also not auditable: Tarsnap, while not OSS, has easily available source code for perusal and personal use, if I recall.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#136

Earlier quoted context omitted.

I thought it was so you didn't need admin to install it?

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.

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.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#137
Has anyone attempted to run this using Wine?

As long as you keep all drives (/ or ~/) unmounted, I assume it would be `safe' to test it.

Might be a simpler environment to analyze CryptoLocker in, as apposed to a full Windows install.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#138
post #6

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.

I think the article mentions that it's small businesses that are at risk. Most mom and pop shops don't have the greatest IT infrastructure.

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.

Re: You’re infected—if you want to see your data again, pay us $300 in Bitcoins

#140
post #20

You can work to prevent this by creating a group policy that disallows %AppData%\*.exe and %AppData%\*\*.exe A good discussion of this happened here: http://www.reddit.com/r/sysadmin/comments/1mizfx/proper_care... 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.

Don't do that, that's crazy. If you don't want your users running random binaries turn on applocker: http://technet.microsoft.com/en-us/library/dd723683(v=ws.10)...

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.

Post reply on HN