Thanks for playing: New Linux ransomware decrypted, pwns itself Ransomware targeting Linux servers has been thwarted by hard working security boffins, with help from the software itself, mere days after its existence was made public. The Linux.Encoder.1 ransomware seeks Linux systems to encrypt and like others of its ilk demands owners pay BitCoins to have files decrypted. But the first …
"I thought that was secure?"
As you hinted at, it's not news that over recent years there have been far more holes in commercial Linux distributions that on average take longer to get patched (more days at risk) than current Windows versions. Whilst Windows is a worse world for malware on the desktop where user interaction is involved, If you look at hacks of internet facing servers where user interaction is not involved, you are statistically roughly 4 times more likely to get successfully hacked running Linux than Windows Server...So standby for likely lots more of these server side attacks on Linux with every new zero day vulnerability!
"you are statistically roughly 4 times more likely to get successfully hacked running Linux than Windows Server."
This is roughly in line with the ratio of Microsoft vs Non Microsoft web servers out there on the internet, so the lesson really is - if you run a web server, chances are you're gonna get hacked at some point no matter which web server or OS you're running, unless you're one of the rare breed who are able to securely lock down your environment.
"This is roughly in line with the ratio of Microsoft vs Non Microsoft web servers out there on the internet"
It's not. According to Netcraft, Microsoft have over 30% of the webserver market. The 4 times mentioned above is already adjusted for relative market share.
Here are some similar stats:
http://zone-h.org/news/id/4737?zh=1
Operative System Defacements
Linux 1126987
Windows 2003 197822
FreeBSD 46992
Win 2008 15083
F5 Big-IP* 14000
Unknown 7840
Win 2000 6097
Solaris 9⁄10 2373
MacOSX 1038
> unless you're one of the rare breed who are able to securely lock down your environment.
Or run a web server with stuff on that nobody cares about (and doesn't do PHP, flash, run any sort of CMS and isn't using apache..).
What's that you say Skippy? The webserver has fallen down the well?
Microsoft fix all malware issues on Windows so that you don't have to develop the skills to do it yourself?
Linux community wins because using open source Linux helps you to develop the skills (If you want to delve into it) to do this kind of thing - Windows does not help you in any way to do that!
@ kryptylomese
Look , it dosent matter what OS you are using , or how many friends you have , how good you are at coding, or how much source code is available - if your data is encypted in AES256 you are screwed .
Its only becuase this time you Linux users got *really* *really* lucky due to inept coding that anyones getting their data back
The obliteration of Linux.Encoder.1 comes days after BitDefender released a preventative tool that would prevent the reigning ransomware kings Cryptowall and CTB Locker from executing on victim systems. It does so by preventing executables running from the Windows AppData and Startup folders.
Erm, https://www.foolishit.com/ has had cryptoprevent out for about 2 years now helping stop ransomware on Windows PC.
Catch up, Bitdefender
"This information can be easily retrieved by looking at the file’s timestamp [and] is a huge design flaw that allows retrieval of the AES key without having to decrypt it with the" attacker's key, he says."
Thanks for the tip, I'm sure future attackers will note that one :mad:
"Thanks for the tip, I'm sure future attackers will note that one :mad:"
Easy fix - use gettimeofday() to get the microseconds field and use that as the seed. So then even if you can see the file timestamp you'll have a million different possibly keys. Hardly impossible to solve but beyond most users. Or if they wanted to be really sneaky do some system op which will never take exactly the same number of microseconds to accomplish and use this further time interval as extra noise for the key.
you'll have a million different possibly keys
A 20-bit key is eminently crackable using brute force, especially if the file is of a known type. (<insert shell one-liner calling 'file' program on each one here>)
What you need to do is use "cryptographically secure" RNG like reading /dev/random (which may give the game away) or gather entropy from the running system in much the same way that the kernel and other RNG seeding functions do. Definitely don't use something like the time as the sole value for seeds.
.... and you make your life a lot less stressful to start with. Then it doesn't matter what holes any server side scripting may have then , the worse it'll do is get local user privs and mess up that users - probably "webadmin" or similar - data. Which you will have backed up , right?
Hardly the panacea you describe. Give me the ability to execute as the webserver and I'll probably be able to pull off all sorts of dreadful things that would knock your share price into the gutter. Getting the same access to your database that your legitimate web pages have sounds like a fine starting point to me. And there's plenty more where that came from. You lack imagination when you talk about "mess up that user's data". First thing I'd do with these "holes" you think aren't serious, is start collecting your visitor's information - usernames, passwords, et al. Then depending on how valuable or not that is, I'd start using your site(s) to distribute my malware.
I mean sure, don't run your webserver as root if you don't need to, but the way you write it is that "it doesn't matter what holes any server side scripting may have then" if you've "backed up". That isn't so.
"The secure random keys and initialisation vectors generate information from the libc rand() function, and are seeded with the current system timestamp at the point of encryption. This information can be easily retrieved by looking at the file’s timestamp"
I guess that these muppets failed Crypto-101.
That's a *much* better solution. I was thinking portable as in cross-platform and considered using grown up tools like /dev/random /dev/urandom some what detached from the Heath Robinson spirit of the question.
using a monotonically increasing composite clock something like
struct clock
{
uint32_t cs; // sessions since last restart
uint32_t ci; // inputs in current session, wraps to zero on {cs,cn} increment
uint32_t co; // outputs in current session wraps to zero on {cs,cn} increment
uint32_t cn; // restarts
} prng_clock;
char buf[16] = {0};
memcpy(buf,&prng_clock,sizeof(buf));
sha3(buf,buf,len);
The values of {cs,ci,co,cn} vary from run to depending on whatever rubbish was on the stack, the exact same run is needed to generate the same sequence, meaning if one was to stop the program running that has used this sequence, one has little chance of reproducing the run.
It gives a better period than rand, and it's crapness is it's strength, it's not reliable, so unless you capture the initial run, good luck getting same inputs.
That said, upvoted as /dev/urandom is indisputably better.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
