10,000 Linux servers hit by malware (ars technica)

[Posted March 18, 2014 by ris]

Ars technica takes a look at an ongoing criminal operation infecting more than 10,000 Unix and Linux servers with malware that sends spam and redirects end users to malicious Web pages. "Windigo, as the attack campaign has been dubbed, has been active since 2011 and has compromised systems belonging to the Linux Foundation's kernel.org and the developers of the cPanel Web hosting control panel, according to a detailed report published Tuesday by researchers from antivirus provider Eset. During its 36-month run, Windigo has compromised more than 25,000 servers with robust malware that sends more than 35 million spam messages a day and exposes Windows-based Web visitors to drive-by malware attacks. It also feeds people running any type of computer banner ads for porn services." See Eset's white paper [PDF] for details.

to post comments

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 3:24 UTC (Wed) by linuxbuzz (guest, #87623) [Link] (1 responses)

One of my server has been infected. It's very dangerous rootkit. I'm looking source of infection.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 12:29 UTC (Wed) by Darkmere (subscriber, #53695) [Link]

Assume that all keys leading in and out of that machine are compromised, all passwords in and out of that machine are compromised, and thus you should enforce a global key & pass change on all machines.

Just because they aren't exploited now doesn't mean they aren't logged and stored for future expansion of the botnet.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 6:21 UTC (Wed) by imgx64 (guest, #78590) [Link] (4 responses)

I'm surprised that AV companies haven't jumped at this opportunity to sell "antivirus for Linux servers" to clueless sysadmins like they did for Android phones.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 7:14 UTC (Wed) by palmer_eldritch (guest, #95160) [Link]

The market's probably not as juicy, compare the number of clueless android devices users to the number of clueless linux sysadmins and you should notice that there isn't that much money to be made there.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 12:54 UTC (Wed) by bvanheu (guest, #88814) [Link]

ESET actually have a product for Linux users, so feel free to try it if you want ;)

We've also released various IOCs for the Windigo components. You can find them on Github:

https://github.com/eset/malware-ioc/tree/master/windigo

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 13:24 UTC (Wed) by andrewtappert (guest, #53615) [Link]

For those interested in a less brittle, non-signature/non-IOC method for detecting infections like this, check out Second Look (http://secondlookforensics.com). It uses memory forensics to verify that all programs running on a system are unmodified distro-provided software (or custom/third-party software you explicitly allow).

10,000 Linux servers hit by malware (ars technica)

Posted Mar 20, 2014 17:29 UTC (Thu) by drag (guest, #31333) [Link]

They actually try, but it really wouldn't make any difference if there was good antivirus for Linux.

ssh -G ?

Posted Mar 19, 2014 9:17 UTC (Wed) by The-Grue (guest, #96055) [Link] (3 responses)

The article as well as the PDF mentions "ssh -G":

$ ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"

The man page as well as ssh --help doesn't mention '-G' and OpenSSHs ssh doesn't understand it. What am I missing?

ssh -G ?

Posted Mar 19, 2014 9:20 UTC (Wed) by osma (guest, #6912) [Link] (2 responses)

I noticed the same. My guess is that the -G option was added to the trojaned/backdoored version of openssh. At least the existence of this option is used to determine whether the server is infected.

ssh -G ?

Posted Mar 19, 2014 9:26 UTC (Wed) by The-Grue (guest, #96055) [Link]

Ah, I see. I thought they'd grep some "valid" ssh output but it's only the error message (doh).

ssh -G ?

Posted Mar 19, 2014 12:32 UTC (Wed) by redden0t8 (guest, #72783) [Link]

That's exactly it. See section 4.4.2. of the whitepaper.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 9:43 UTC (Wed) by gioele (subscriber, #61675) [Link] (37 responses)

From the whitepaper:

> No vulnerabilities were exploited on the Linux servers; only stolen credentials were leveraged.
> We conclude that password-authentication on servers should be a thing of the past

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 10:39 UTC (Wed) by gerdesj (subscriber, #5446) [Link] (35 responses)

In case anyone thinks that simply better passwords are needed, this is from further down the pdf - note the max, median and averages:

Number of unique passwords 2,145
Number of passwords containing only alphabetic characters 190
Number of passwords containing only numeric characters 36
Number of passwords containing only alpha numeric characters 1,422
Number of passwords with special characters (non alpha numeric) 723
Minimum password length 3
Maximum password length 50
Median password length 10
Average number of characters in a password 11.1

See Page 16, Table 3.7

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 10:40 UTC (Wed) by gerdesj (subscriber, #5446) [Link] (11 responses)

... note the use of the words average and median in the same analysis!

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 15:27 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (10 responses)

Am I missing something? They're both different statistical measures which can provide useful information (though the mean is much more useful with a standard deviation). Why would providing both be an issue?

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 16:50 UTC (Wed) by riking (subscriber, #95706) [Link] (9 responses)

gerdesj is just saying that providing both is rare (because it is) and should be commended.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 22:11 UTC (Wed) by creemj (subscriber, #56061) [Link] (8 responses)

Or gerdesj is picking up on that 'average' is not a particularly well defined term and any one of the median, mode, arithmetic mean, or some other measure of 'typicalness' or 'middleness' is an average. It is not uncommon to find reports (particularly from government departments of the English speaking country I reside in) where 'average' is written and one digs down into the data to find it is something other than the arithmetic mean (often it is the median).

10,000 Linux servers hit by malware (ars technica)

Posted Mar 20, 2014 5:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

That makes me really want to see "harmonic mean" reported as the "average" then see who figures it out :D .

10,000 Linux servers hit by malware (ars technica)

Posted Mar 20, 2014 15:08 UTC (Thu) by Wol (subscriber, #4433) [Link] (6 responses)

Eggsackerly.

The word "average" is one of the most abused words in the heavily abused realm of statistics. When someone quotes "the average" at me, my immediate reaction is "which average? What misdirection are you trying to get past me now?".

My instant reaction on seeing the post pointing this out was to smile at the report's author being outed as being clueless to what he was writing ...

Cheers,
Wol

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 3:37 UTC (Fri) by plaxx (guest, #53703) [Link] (5 responses)

I'm afraid that we were not being clueless but instead we had a language barrier issue. The ones who wrote the report, myself included, are Canadian French with French being our tongue language. In our language the mean is 'moyenne' but 'moyenne' when writing or speaking in English is much more commonly translated into average than into mean (probably because mean is precise whereas average is not). We were never really exposed to the difference I guess..

Anyway, we simply have no way to differentiate average and mean in French and we've made a mistake. We are sorry. We'll remember this one.

Oh and by the way, we really did mean the mean (no pun intended).

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 18:39 UTC (Fri) by Wol (subscriber, #4433) [Link]

Sorry to impugn you. I have a low tolerance for native speakers who abuse the language, but a high tolerance for foreigners (who almost always speak my language far better than I speak theirs!). I didn't realise this was written by non-native-speakers.

That said, "average" is *not* a word to use when you wish to precise about statistics :-)

Cheers,
Wol

10,000 Linux servers hit by malware (ars technica)

Posted Mar 22, 2014 3:09 UTC (Sat) by creemj (subscriber, #56061) [Link] (3 responses)

When I read the statistics on passwords (other than wondering about 'average') I immediately thought that measure such as mean, median, and whether they contain numbers in addition to letters, etc., are not particularly great measures of password security. Even if a password is 10 (or more) characters long with both letters and digits, if all those characters are either 'a's or '1's then that is a useless password. Indeed, knowing that a password is required to contain at least one capital and at least one digit provides information to reduce the search space (if searching all possible passwords).

Some measure of randomness would be interesting to see. So I suggest the Shannon entropy, s = \sum_i p_i \log p_i, where the p_i is the probability of the ith character appearing in a password, be calculated over all passwords, and the mean Shannon entropy of the passwords be calculated.

(If it is hard to determine the probability of a character appearing in a password then maybe start with the probabilities of a character occurring in a natural language for some appropriate natural language. And modify that a bit by some known transformations, e.g. that a one is often substituted for an el biases ones up and els down.)

If the Shannon entropy is small then the passwords, even though reasonably long, are predictable, thus easily cracked. If the Shannon entropy is large then the passwords have much randomness thus are difficult to predict. What constitutes small or large depends on the base of the logarithm chosen. If base 2 is used then that estimates the minimum number of bits required to express the password. Compare that against the actual number of bits (say 6 or so bits to represent upper and lower case, digits and a couple of symbols) per character to represent the password.

Now that would give a much better measure of password security (assuming a reasonable assignment of prior probabilities to password character selection in the calculation).

10,000 Linux servers hit by malware (ars technica)

Posted Mar 22, 2014 9:45 UTC (Sat) by Jandar (subscriber, #85683) [Link] (2 responses)

This doesn't take into account the order of characters. The password "password" is much weaker than "ospswadr". Even if I make every of my passwords to consist of the same 255 characters (0x01-0xFF) and only reorder them randomly, the resulting strength is more than enough.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 22, 2014 23:07 UTC (Sat) by creemj (subscriber, #56061) [Link] (1 responses)

You are correct. I haven't taken account of the order of characters and that does matter. But, note, that is only a fault in the calculation of the p_i; using entropy is *not* the fault here, as entropy, when properly calculated, is a measure of manifest disorder.

The difference between what I proposed and what should be proposed is analogous to the difference between calculating the entropy of an ideal gas (in which particles do not interact together) and the entropy of a real gas (in which particles interact together if sufficiently close). Thus fixes to the calculation of entropy could be that one should be using p_{i,i-1}, that is, the probability of the ith character occurring given the (i-1)th character. That may be enough to deal with the "password" versus "ospswadr" example, but probably not enough to deal with the preponderance of passwords that consist of a series of letters followed by two or three digits. Thus the p_i may need to be also dependent on the position in the password.

This is now at the point where one needs an extensive password database to calculate the p_i (and the p_{i,i-1}, etc.) but, apparently, some extensive password databases have been posted to the Internet (admittedly by unscrupulous sources), thus calculating these probabilities would appear to be not out of the question.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 22, 2014 23:56 UTC (Sat) by Jandar (subscriber, #85683) [Link]

If there were a global counter used for all passwords on the world, the passwords computed as echo $((++n)) | sha512sum, the entropy based on previous probabilities regarding neighboring characters and so on would be perfect without the merest real disorder.

The problem with such formal tests is the detection of hidden order an attacker knows about.

But that's nitpicking ;-). Any test which prevents most of stupid passwords is welcome.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 15:09 UTC (Wed) by psusi (guest, #95157) [Link] (2 responses)

A stolen password is not a cracked/guessed password. The best password in the world is useless if you are dumb enough write it down where someone can find it.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 19, 2014 15:25 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

Sure it is, modern password hashing can slow down the attacker but most password storage isn't even using the toughest hashing algorithms, so the amount of time it buys you is often short, regardless of how challenging you think your password is to cracking.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 20, 2014 2:03 UTC (Thu) by rahvin (guest, #16953) [Link]

The statistics are interesting. We've got a median password length of 10 characters. But out of 2145 passwords 226 of them used only alpha characters or only numbers. That's a little better than 10% of the passwords were probably trivial for a dictionary attack.

Now 1422 had a mix of numbers and letters and with that high of a median and average length combined with another 723 that included special characters you've got pretty good odds that better than 50% of the passwords would be difficult to crack with a dictionary attack. On top of that there was at least one password in the list with 50 characters.

That is at least 26,024 Linux servers cracked using passwords where more than 50% of the servers had password policies in place that required mixed alpha/numeric (though they don't indicate whether case was used), allowed special characters and had an median/average password length better than 10 characters.

That's bloody scary.

I'd like to see the captured password list and run it against the largest password dictionary I'm aware of (I don't recall the name of the list offhand but it's something like darkhorse.txt). When I was evaluating my own server security I grepped slight variations or the straight up password of almost every password I used in the list. Shortly after this I switched to passphrases with numbers and special characters added to the phrase.

I want to believe very strongly that this happened because the passwords are common enough to be in major cracker dictionaries because otherwise it might mean some very scary things about any text based authentication.

One thing I couldn't get from the PDF when I skimmed it. Does each server run all the exploits (ie. ebury, cdorked, etc) or is it possible you could be only running one of the packages and it's necessary to check for every single identified piece? It seemed like to me you need each package because each of the exploits performed a specific function. For example without ebury they have no SSH access to the server.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 20, 2014 17:36 UTC (Thu) by drag (guest, #31333) [Link] (19 responses)

> In case anyone thinks that simply better passwords are needed, this is from further down the pdf - note the max, median and averages:

I haven't looked at the paper yet, but I feel this is a good time to note this:

The length of passwords, or if you are using SSH keys or Kerberos or OTP or any of that stuff is largely irrelevant if the machine you are using those credentials on is compromised.

For example:

SSH (desktop) --> SSH (infected server) --> SSH (non-infected server)

Now means that your passwords are known by the attacker. If you use the same password on multiple systems then those systems will likely be compromised also.

If you do this:

SSH (desktop) --> SSH (infected server) --> SSH (non-infected server) --> SCP (back to desktop)

Then your desktop is now likely compromised and thus every single machine you will use is likely compromised as well.

So do not ssh from one machine to another. Only ssh from desktop out. Also use unique passwords on each machine so that one machine compromised will not cause all your systems to be compromised.

Yes; this is a pain the ass.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 20, 2014 19:36 UTC (Thu) by jwakely (subscriber, #60262) [Link] (16 responses)

> Now means that your passwords are known by the attacker.

Only if I enter a password to login to either server though, right?

If I have my public key in authorized_keys on both servers, and have ForwardAgent=yes, is anything compromising exposed to the infected server?

(I don't understand why anyone runs sshd with PasswordAuthentication=yes anyway.)

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 4:06 UTC (Fri) by plaxx (guest, #53703) [Link] (7 responses)

> Only if I enter a password to login to either server though, right?

Or ssh keys passphrases. The malware will grab passphrases and the unencrypted keys associated to them (after the passphrase decrypted them). But this happens only if you have ssh keys on the infected server, it can't do anything with keys on your non-infected desktop.

> If I have my public key in authorized_keys on both servers, and have ForwardAgent=yes, is anything compromising exposed to the infected server?

You are prone to ssh-agent hijacking but so far we have not noticed the malware take advantage of that. It didn't needed to so far.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 5:58 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

I think, ssh-agent hijacking was used to compromise kernel.org servers.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 10:34 UTC (Fri) by PaXTeam (guest, #24616) [Link] (4 responses)

interesting, do you know something that the rest of us still doesn't? ;)

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 10:59 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

No, I just have a good memory.

>What the attackers did do was to snoop operations on ttys and record usernames and passwords. They installed trojan ssh and sshd binaries and, seemingly, were able to exploit ssh agent forwarding to move on to new machines.
(c) https://lwn.net/Articles/464233/

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 11:43 UTC (Fri) by PaXTeam (guest, #24616) [Link] (2 responses)

ah, that, but then it's still just folklore, 'seemingly' not evidence of anything ;).

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 11:45 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Well, definitely feel free to share how you compromised kernel.org. We're all listening!

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 12:12 UTC (Fri) by PaXTeam (guest, #24616) [Link]

haha, don't let paranoia get the best of you, i was merely wondering if you had learned something since that i missed but clearly you were just parroting the same non-information out there ;).

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 16:30 UTC (Fri) by jwakely (subscriber, #60262) [Link]

> Or ssh keys passphrases.

Yes, basically if I type anything on a compromised server it can be read, but if I only use agent forwarding then I'm (somewhat) safer. That's what I thought, thanks for confirming it.

I asked because drag's comment seemed to imply otherwise, but as I thought it only applies if you're typing in passwords/passphrases on remote hosts, and my first thought was to wonder why people are still doing that.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 16:30 UTC (Fri) by drag (guest, #31333) [Link] (7 responses)

> Only if I enter a password to login to either server though, right?

The situation I was describing was if you SSH from a compromised system into one that is not.

In that case the attacker can, if they are looking for it, compromise any form of credential they want. This includes SSH keys, Kerberos tickets, SSH certificates, or one time passwords.

> If I have my public key in authorized_keys on both servers, and have ForwardAgent=yes, is anything compromising exposed to the infected server?

I am not sure about how forward agent works, but I believe so. Could be wrong. The local ssh client is compromised so any credentials that it can use has the potential for being intercepted.

> (I don't understand why anyone runs sshd with PasswordAuthentication=yes anyway.)

Because managing ssh keys for more then a small handful of users is a nightmare.

Imagine if you are running a company and fire somebody. How are you going to ensure that you've revoked all his SSH keys? Write a shell script that goes through every account's home directory on every system and make sure there is no unknown ssh keys lurking around hidden in anybody's authorized_keys file?

There is no easy way you can ever be sure that you removed access completely.

It's much better policy to disable ssh keys in the servers and force people to use passwords. This makes it much easier to manage individual's access to systems.

If you want to 'up the security' then Kerberos is a option. Also SSH has a newer certificate system* that you can take advantage of with the ability to revoke certs. This way you can manage people's access in a proactive manner.

* http://blog.habets.pp.se/2011/07/OpenSSH-certificates This approach gives you certificates with a certificate authority. It's not SSL, you cannot delegate authority. But it allows you to centrally manage auth and create revocation lists.

But either of these approaches require additional configuration on client's machine and it's not supported by all commonly used ssh protocol client programs so unless you are managing those people's desktops then you probably won't be able to take advantage of them..

... and even if you are able to take advantage of non-password forms of auth you probably won't be able to get rid of passwords anyways due to the wide variety of circumstances people have to deal with in the real world.

Regardless of all of this:

The reality is that if your client system is compromised then so is your account and any account you access from that system. There is nothing you can really do to avoid this.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 16:47 UTC (Fri) by jwakely (subscriber, #60262) [Link] (3 responses)

> I am not sure about how forward agent works, but I believe so. Could be wrong. The local ssh client is compromised so any credentials that it can use has the potential for being intercepted.

I think you're wrong, the local ssh client doesn't have the credentials.

> Imagine if you are running a company and fire somebody. How are you going to ensure that you've revoked all his SSH keys? Write a shell script that goes through every account's home directory on every system and make sure there is no unknown ssh keys lurking around hidden in anybody's authorized_keys file?

Presumably the fired employee no longer has access to your network, so the problem you describe implies every system is exposed to the internet. If they can only reach a single gateway or VPN server then you revoke access there, and it doesn't matter how many keys they still have on internal-facing hosts.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 17:05 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

> I think you're wrong, the local ssh client doesn't have the credentials.

Yes, I should of read the other posts first before replying.

They did, however, say that the possibility for agent hijacking does exist, so presumably if forwarding was more widespread then it can be compromised. Though it isn't in this specific case.

> Presumably the fired employee no longer has access to your network,

That's a big assumption. It all depends on the specifics of the org in question.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 20:15 UTC (Fri) by jwakely (subscriber, #60262) [Link]

> It all depends on the specifics of the org in question.

True, but "disable ssh keys in the servers and force people to use passwords" would never be on my shortlist of ways to improve security :)

10,000 Linux servers hit by malware (ars technica)

Posted Mar 23, 2014 0:29 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

That presupposes firee hasn't any insiders...

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 23:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> There is no easy way you can ever be sure that you removed access completely.

SSH keys + TOTP?

10,000 Linux servers hit by malware (ars technica)

Posted Mar 22, 2014 19:13 UTC (Sat) by buchanmilne (guest, #42315) [Link] (1 responses)

Because managing ssh keys for more then a small handful of users is a nightmare.

No more so than managing the passwords.

Imagine if you are running a company and fire somebody. How are you going to ensure that you've revoked all his SSH keys? Write a shell script that goes through every account's home directory on every system and make sure there is no unknown ssh keys lurking around hidden in anybody's authorized_keys file?

You configure sshd_config with AuthorizedKeysFile to be somewhere secure (writable by root only), e.g. /etc/ssh/keys
Add sshPublicKey attributes to the user entries in your LDAP directory
Deploy openssh-ldap for use as the AuthorizedKeysCommand (in recent versions of OpenSSH, before those there was a patch for OpenSSH, usually called LPK).

If you have some instances where you require specific unattended user accounts to be able to run specific commands remotely, create e.g. /etc/ssh/keys/apache.pub

Otherwise, when someone leaves, you archive and delete their LDAP entry, and possibly audit /etc/ssh/keys if they had root access.

Dealing with (locally managed) password expiry and lockout for 50 users over 100 servers is a lot more effort than in the case of (1) without (2) and (3) above.

There are still some arguments against ssh public keys, such as no easy solutions to forcing keys to be changed, or to ensure that the private key is always protected with a passphrase.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 25, 2014 6:55 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

This is a nice setup. Is this in a wiki or blog post somewhere for future reference? Am LWN comment is nice, but tends to age poorly as new things arise.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 4:00 UTC (Fri) by plaxx (guest, #53703) [Link] (1 responses)

If you want to ssh between machines then use SSH Agent Forwarding. This stuff works. The private material resides on your initial host which responds to a challenge sent by the server and the private key is never exposed to the middle man.

This illustrated guide explains really well how this works: http://www.unixwiz.net/techtips/ssh-agent-forwarding.html...

However, as the guide notes, agent hijacking is still possible. BUT having to do agent hijacking in order for this malicious operator to gain access to more servers is really raising the bar. On one side you have stolen keys and credentials which are working all the time and from everywhere. Loosely coupled with timing. On the other side you have agent hijacking which requires good timing from the right infected host. Also, the malware would have to be a lot more noisy and scan users' environment variables and /tmp/ all the time.

A different point on your comment: the malware is "manually" deployed (scripted but not instantaneous through the same SSH connection). So unless your desktop's port 22 is exposed to the Internet you'll most likely not be backdoored.

Full disclosure: My name is on the report. I hope you liked it :)

10,000 Linux servers hit by malware (ars technica)

Posted Mar 21, 2014 16:32 UTC (Fri) by drag (guest, #31333) [Link]

Very good. Thank you.

10,000 Linux servers hit by malware (ars technica)

Posted Mar 22, 2014 13:43 UTC (Sat) by ballombe (subscriber, #9523) [Link]

One can expect that some of those were stolen by trojaned ssh server,
when the actual strength of the password is irrelevant.
So it is hard to draw a conclusion.

Better URL to we-live-sec pages on Operation Windigo

Posted Mar 19, 2014 11:15 UTC (Wed) by hmh (subscriber, #3838) [Link]

Stable short-URL to the we-live-security pages on Operation Windigo:

http://welivesecurity.com/windigo