Slashdot Mirror
Malware Attack Infected 25,000 Linux/UNIX Servers
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."
April fools is here early
Here's the complete check from http://www.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"
A weak root password and public facing root SSH access is bad?
Managing a Linux box with a publicly facing web based interface bad?
Installing untested web based applications released as freeware with no idea what the code does is bad?
Having to work for a living is the root of all evil.
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.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
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.
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.
There's no place I could be, since I've found Serenity...
OpenSSH 6+ will print "unknown option" instead of "illegal option", hence the "grep -e illegal -e unknown" ;)
The summary states:
but I think this is an inaccurate summary since the Trojan is being installed on machines where the attackers already have root credentials.
Perhaps some unknown vulnerability is also being used to gain root access, but the report does not claim this.
The real "Libtards" are the Libertarians!
I have (grudgingly) admin'ed such a server, and will readily admit it as a form of public shaming (though not of myself, as you'll soon learn).
/usr/local/bin) had both the directory and everything contained within world-writable (no, I didn't have the option of fixing that - it would have broken "features" of the reason this box existed, as I'll soon explain).
As TFS points out, the attackers didn't use a zero-day exploit. They didn't use an unpatched old exploit. They didn't even use the fact that huge "trusted" swaths of the filesystem, including standard executable paths (such as
This system ran a fairly popular POS software suite, and absolutely depended on all its serious security flaws. The vendor had even installed what amount to pre-compromised binaries for "convenience" in diagnosing end-user problems (connect to the right port, bam, you can monitor any user's session). But even that egregious level of incompetence didn't cause the breach.
No, the breach came from the fact that the vendor had their own company name as the root password (and had it hard-coded in literally dozens of (world-readable) scripts, so I couldn't just change it). And did I mention, the vendor required this box have a publicly facing IP or they'd refuse to honor their SLA?
Needless to say, my first action on learning all this, I blocked it at the firewall and told the vendor that we'd let them in when, and only when, we needed assistance. That, amazingly, enough kept the box safe for about a year (and floored me that we hadn't gone down long before I got stuck with that albatross)...
Until an upgrade. Took a total of half an hour. Didn't matter, because we had someone in as root in a tenth that time.
But, distant past. Couldn't happen again, and no other vendor would ever have such an extreme level of cluelessness, right?
So, currently, I work with (but thank Zeus, don't have to administer) a CRM system by an entirely different vendor, running on an outdated Linux distro. Pretty much everything I just said applies to this box. But hey the firewall keeps it safe, except the once-a-year the vendor demands access to audit our license compliance...
So yeah, Linux systems get hacked - For reasons that wouldn't protect the otherwise-most-secure system on the planet. You want to make it stop? Tell your vendors to go fuck themselves when they rationalize having a weak root password, and piss-poor system-wide security, and ban patching known vulnerabilities because it "might" break something the vendor used. Really that simple.
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.
There's no place I could be, since I've found Serenity...