Malware Attack Infected 25,000 Linux/UNIX Servers 220
wiredmikey writes "Security researchers from ESET have uncovered a widespread attack campaign that has infected more than 25,000 Linux and UNIX servers around the world. The servers are being hijacked by a backdoor Trojan as part of a campaign the researchers are calling 'Operation Windigo.' Once infected, victimized systems are leveraged to steal credentials, redirected web traffic to malicious sites and send as many as 35 million spam messages a day. 'Windigo has been gathering strength, largely unnoticed by the security community, for more than two and a half years and currently has 10,000 servers under its control,' said Pierre-Marc Bureau, security intelligence program manager at ESET, in a statement.
There are many misconceptions around Linux security, and attacks are not something only Windows users need to worry about. The main threats facing Linux systems aren't zero-day vulnerabilities or malware, but things such as Trojanized applications, PHP backdoors, and malicious login attempts over SSH. ESET recommends webmasters and system administrators check their systems to see if they are compromised, and has published a detailed report presenting the findings and instructions on how to remove the malicious code if it is present."
There are many misconceptions around Linux security, and attacks are not something only Windows users need to worry about. The main threats facing Linux systems aren't zero-day vulnerabilities or malware, but things such as Trojanized applications, PHP backdoors, and malicious login attempts over SSH. ESET recommends webmasters and system administrators check their systems to see if they are compromised, and has published a detailed report presenting the findings and instructions on how to remove the malicious code if it is present."
Re:FreeBSD 9.1 (Score:5, Informative)
Here's the complete check from http://www.welivesecurity.com/... [welivesecurity.com]
The command ssh -G has a different behaviour on a system with Linux/Ebury. A clean server will print
ssh: illegal option -- G
to stderr but an infected server will only print the typical “usage” message. One can use the following command to determine if the server he is on is compromised:
$ ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"
The state of Linux (Score:5, Informative)
Linux is now big enough with all the Android deployments on top of the server infrastructure that there is going to be increasing amounts of effort aimed at exploits. Unfortunately there is a lot of pressure to hurry applications to market and make upgrades to the OS. That means more pressure and opportunities to create exploitable errors. Unless both the Linux community and the application developers up their game we're going to be in the era of owned Linux handhelds and boxes.
From the Article (Score:5, Informative)
From the Article
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
http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf
Nuff said.
Re:next they will say Mac's get viruses (Score:4, Informative)
Back in the late 90s, Macs had over a 1000 viruses, linux, less than 10. (It's been a few years, I forget the exact numbers.)
Did those infections occur a lot? No, but it did happen sometimes.
After all, there's a huge benefit to NOT being the most common user OS. Those scum writing the malware usually want to hit as many victims as possible, and if there's an OS that has 70% or more of the desktops out there, it's pretty obvious what they will aim for.
If you want to continue to believe marketing and fanboys, that's up to you, but don't be surprised when you get infected by some kind of malware for not taking the proper precautions because you believe in computing myths and the protective power of obscurity is magically unbeatable.
By the way, I've done the tech support, and have seen the reality, this isn't just some random opinion. If you don't believe me, that's your problem.
Re:From the Article (Score:5, Informative)
What other fucking form of authentication is there? Certs? Those are just strings - like a password. Encrypted certs? What are you encrypting them with?
It all comes down to a secret someone has too know. Call it a key, a cert, a token, whatever, it's a fucking password at the end of the day.
If your auth'ing with a username / password on an infected server you're actually *sending* your credentials to the server. This is not he case wih a cert auth, especially when you use ssh-agent to hop to other servers.
You know *nothing* about security (Score:5, Informative)
Um, no, You're *FULL* of bullshit if you talk about certs that way. You obviously don't have a clue.
Key differences between public key auth ("certs") and password auth (no particular order): /. users I know...).
1) You can re-use your public key with multiple sites and even if one of them is actively malicious, it doesn't help them break into the others. Not so with passwords.
2) Passwords, or at least verifiers for them, must be stored by all sites you use the password with. Public keys don't do an attacker any good at all even if they compromise a service on which you used the same credentials as their real target.
3) Public/Private keypairs are automatically generated by programs that filter the results for security. Passwords are often generated by people who don't know a thing about security (like some
4) Passwords are short, intended to be remembered and typed. Asymmetric keys are long, meant to be transported as files (or certificate blobs). The former is vastly easier to brute force (an extremely strong password might take weeks on typical commodity hardware but most would only take minutes) than the latter (factoring some sub-1024-bit RSA public keys - weaker than any in serious use today - has been an open challenge for *years* and the best we've managed before required the resources of a university supercomputer working for weeks).
5) Public Key Infrastructure certificates include mechanisms like expiration and revocation. Passwords have no such protection and must be manually changed or reset in the event of a potential compromise.
6) Private keys can (and should be) protected with passwords, making them in effect a form of two-factor authentication (you HAVE the key, you KNOW its password). Passwords are a single factor.
7) A password gets much harder to use as its length increases, and the strength doesn't always increase as a factor of length because long passphrases are more likely to be generated with predictable rules to aid memorization. Public keys can be made thousands of times as strong without making them any less convenient for the user (aside from an increase in the one-time generation time, a slight increase in authentication time, and a bit more bandwidth used).
8) A password is, almost by definition, short enough to memorize or at least write down in a reasonable time. Very few humans could ever manage to memorize even a 1024-bit key pair; anything much stronger is right out. Calling it "a secret someone has too[sic] know" is simple idiocy.
9) Certificates can be used over unsecured connections (in fact, they're how we establish secure connections). Passwords sort-of can (SRP) but the typical usage of them requires a protected channel as an eavesdropper otherwise can steal your credentials, and SRP requires that the password be communicated to the server out-of-band (typically over a connection secured with public key crypto...)
Don't get me wrong, passwords have advantages (mostly in matters of convenience at a cost to security, but a secure system that is so inconvenient to use that nobody ever does so isn't any better than no system at all). I'm not saying we should do away with them. It was just painful to read the complete nonsense in your post, and I felt I had to set the record straight lest some other ignorant fool mistakenly believe you to know what you're talking about.
Re:FreeBSD 9.1 (Score:4, Informative)
Re:next they will say Mac's get viruses (Score:4, Informative)
Re:The state of Linux (Score:4, Informative)
Except if you had read the report, you would realize that this is not about a security exploit, this is about stolen administrative credentials. No one is using new vulnerabilities in the Linux operating system. This is malware that works on *nix specifically, but what it ends up doing is not *nix specific - it simply steals passwords and uses them to manually propagate the infection.
In the end, the blame lies with server administrators running networks porous enough to be infected at deployment time, and who are not using two-factor auth to guard the keys to the castle. This isn't about the "Linux community" so much as it is about organizations and their admin practices.
Re:So is it 10,000 or 25,000? (Score:3, Informative)
Read, or don't read the article, your choice. But the level of sophistication will blow your mind.
No, no it really won't.
That article read like the opening page of a third-rate techno-thriller. Once you get past the alarmist dross, you see that people are busy pwning servers just as they always have. Only today - shock, horror - there are more servers around, and some of them are really badly maintained.
25,000 servers is a pretty useful resource for someone with malice in mind. And admittedly, it takes a certain amount of cleverness to amass that many. So yes, these guys aren't completely useless. But in the larger scheme of things, that number represents the lowest of the low-hanging fruit in the Linux ecosystem, and it's sufficient unto the day to know that if you (or your sysadmin) have half a clue, you'll likely not be bothered by this threat.
HTH, HAND
Re:next they will say Mac's get viruses (Score:4, Informative)
While OS X is based heavily on NeXTSTEP (and most developer API class names on the Mac are prefixed "NS"), I wouldn't go so far as to say there is no relationship between the "classic" Mac OS and OS X. OS X's standard filesystem is HFS+, which was released in 1998 with Mac OS 8.1, and which shares the same format as its predecessor, HFS. And decisions and limitations from those days still unfortunately put their marks on OS X. For instance, the Labels feature from Mac OS which was bolted back onto OS X (after much public outcry) are still stored in the same place on the filesystem, and in the same format (bit fields), as they were in 1988! And the new tagging feature introduced in Mavericks, for the sake of backwards compatibility with Labels, uses this same area and format [arstechnica.com] to record Tag information! And of that, only three bits are available for storing color information on HFS+. This is why Labels-cum-Tags are limited to the same seven damn colors Mac OS had when Ronald Reagan was still president of the USA.
Re:From the Article (Score:5, Informative)
Probably more accurate to say that you mathematically prove that you have your credentials, but you never actually send them to the server.
Re:The big problem with Linux security. (Score:5, Informative)
Not sure where the "proper ACLs had to be bolted on" comes from, as ACLs predate even Unix, much less Linux. The Unix-style ACLs were well established when Linux, or even it's inpiration Minix, was first created. I'll readily grant the clumsiness of the 12-bit ACL system, though.
On *nix systems, file system objects *are* how processes, sockets, and so on are represented. Not sure about synch objects, but in general, Linux does in fact have access controls on most of the same types of things as NT, because those things are accessed using the file system, and are protected by the file system access controls. NT took a different route, making the entire file system be children of the common root (which also has devices, registry hivs, and so on) instead of using the unified root of the file system as the common root of all securable objects the way *nix does it.
These days, though things like SELinux, Linux actually has better support for the PoLP than NT does. That's not to say it's widely used to its full effect, but that's true on both platforms.
Don't get me wrong, I like the NT model. But I don't like it so much I'm going to just ignore the flaws in what you say.
Re:next they will say Mac's get viruses (Score:2, Informative)
God Damn people!
XNU operating system is not FreeBSD based! It use parts of the FreeBSD but is not based to that!
Parts from FreeBSD are filesystems and network stack. Everything else in XNU operating system is Mach microkernel and I/O Kit.
The FreeBSD filesystem and network stack is just 1/5 of the XNU operating system and not even the most important part the microkernel (or as lazy would call, kernel).
In other hand, can we call Android is Linux based? Sure. Can we call Android is Linux based OS? No. Why not? Because the Linux kernel is the operating system in Android. Linux kernel is monolithic operating system what operates completely from kernel space and there is no other software doing the OS functions (no matter how GNU fans want to believe, but it is just a believe like religion for them, not a technical fact) and same thing is with FreeBSD what is as well a monolithic operating system. You can take features from monolithic operating system and turn them as servers for Server-Client operating system like XNU. You just have to then have every other OS function from monolithic OS replacing the features as servers and microkernel.
Re:next they will say Mac's get viruses (Score:5, Informative)
That's assuming the malware is targeting end user workstations... The malware discussed in this article explicitly targets servers, and linux is far from an obscure platform when it comes to servers.
There are many other reasons than lack of desktop users why there is less malware for linux... Linux users are far less likely to be running with admin privileges, linux users have to take extra steps to execute a random binary, linux users are less likely to want to execute random binaries due to the prevalent use of repositories, linux users are generally more savvy than windows users, linux users are more likely to have updated their applications (again due to repositories)...
Also the idea of "security through obscurity" is usually promoted by proponents of closed source, who somehow think that restricted distribution of the sourcecode will prevent people from finding exploitable holes.
Re:From the Article (Score:5, Informative)
The cert provides the server with your public key and an attestation from a third party that the public key belongs to a particular party. Once the server is satisfied with the validity of the cert for this particular account, it does this:
Most notably, at no time did your actual credential, the private key, exist in any place except in your machine. For bonus points, you can password-protect that private key, which will involve using your password as a key to a symmetric cipher to encrypt your private key.