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
I get 'Ambiguous output redirect.' with:
/dev/null && echo “System clean” || echo “System infected”
$ ssh -G 2>&1 | grep -e illegal -e unknown >
FreeBSD 9.1-RELEASE-p7 FreeBSD 9.1-RELEASE-p7
Is FreeBSD at risk?
'I don't know what it's called. I just know the sound it makes, when it takes a man's life.' ~ Four Leaf Tayback
there just isn't any. at all.
TFA is useless as far as understanding the problem in a straightforward manner for 1. detecting an intrusion and 2. removing the malware.
It was my understanding that nobody's ever denied that Linux servers have serious security concerns they typically need to address (as much as anybody running a server architecture does) and it was rather the Linux desktop folks who used the "security" of Linux in contrast to Windows to provide a case for how it might be "easier" for the casual user (since less viruses and all that)?
Da Google am confused? Your search -ÂÂssh -G 2>&1 | grep -e illegal -e unknown >Â/dev/null && echo âoeSystem cleanâ || echo âoeSystem ...Â- did not match any documents. It am hacked???!!!
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.
http://www.eset.com/us/downloa... So buy our software to stay safe!
There is not a single OS that is not vulnerable to a trojan. If this was a virus, drive-by download, or infection of a repository, then that would be disconcerting, but there will always be people who fall for trojans and the OS they use has little to do with it.
The best locks in world, which Linux does come with, do not help if the door is left unlocked.
Microsoft OTOH has no doors.
The biggest threat to linux in the last five years has not been the architecture of linux, but the willingness of programmers, in particular weak programmers from the WIndows world coming over and applying the same philiosophies to linux development.
Malware infected 25,000 unpatched Wordpress installs.
Shoulda hired me instead, suckers!
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...
Click here to return to the classic version of Slashdot, but then I get the beta again every time I click on an article: how stupid is that?
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.
Ah come on, there are none Linux virus at all, EVER. Anybody that doesn't use Linux is a fool.
So is it 10,000 or 25,000? I can't be arsed to read the article, because as another poster succinctly observed "oh no, thousands of infected unpatched Wordpress installations", but it sounds like the ESET people trying to make a quick buck off of some FUD can't even get their FUD straight. As if tripwire hasn't been available for a couple of decades...
“The Ebury backdoor deployed by the Windigo cybercrime operation does not exploit a vulnerability in Linux or OpenSSH,” continued Léveillé. “Instead it is manually installed by a malicious attacker. The fact that they have managed to do this on tens of thousands of different servers is chilling. While anti-virus and two factor authentication is common on the desktop, it is rarely used to protect servers, making them vulnerable to credential stealing and easy malware deployment.”
From above:
Private keys can (and should be) protected with passwords
Far too many of the people that think security only means "use keys not passwords" forget that it's a damn good idea to have a password on the key. Having the password on the key means that is someone steals a laptop or USB stick with the key on it they still can't get in.
Obvious red flag showing no clue about the topic - it's just buzzword bingo throwing impressive sounding verbage around with a lack of understanding.
If it was a fanboy they really need to lift their game if they want to avoid other fanboys laughing at them.
If it was some "media studies" person acting as a paid social media shill then whoever paid them got ripped off.
Tips / Thoughts Always change the default password and default keys. A lot of exposed *nix processes should be sandboxed, jailed, or at the very least chrooted. The file system itself should support role-based and / or mandatory access control and have permissions set accordingly. Centralized control with periodic audits should be regular practice. There should always be a baseline and deviations should always be documented. For machine-to-machine communication, asymmetric key pairs should be part of the equation. This is already built into certificate-based mechanisms. There was also a recent addition enhancement to OpenSSL for stronger ECDSA keys. It should be some time before elliptic-curve cryptography isn't enough. Another option available for SSL and TLS is that both sides must have key/certificate pairs before communication is possible. More exotic is placing HTTPS certs on load balancers so that traffic is encrypted there instead of the actual web servers. Doing this allows inspection of inbound HTTPS. Intrusion detection systems normally can't see this due to the encryption. Load balancers also do a great deal to control exactly where traffic goes. Network traffic should always be monitored and profiled. For an interactive session, go with multi factor authentication. There are a lot of cool services out there. Duo Security is a great example. The YubiKey authenticates are cheap and because they've open-sourced a lot of their software, it's easy to integrate many applications with that type of authenticator. Even ssh. You can even run your own (protected) YubiKey server to control the authentication. Authy is another option which is easier to implement. SmartCards are also an option if you have deep pockets. Randomized and one-time-passwords are also great but are tricky to implement. Most organizations that use these end up with enterprise password repositories. As long as these are protected by layers of security, they are usually a good idea. There are various situations where you wouldn't want someone to have a password that could be used more than once. This is the stuff I've learned while working in the cyber security field for the past year. I've also learned that most organizations don't do any of this proactively. Phew. Typed all this using my thumbs on an insecure iPhone.
....woosh....
"Windigo .. malware components are designed to hijack servers, infect the computers that visit them, and steal information"
Why don't these compromised UNIX servers go on to hijack Linux client desktops.
Sigh... At account setup time, the server generates the verifier using the password. The password can then be safely discarded, the server need never (and should never) see it again post-setup. However, that initial process - getting the verifier stored in the server's database - does require an out-of-band communication of password-equivalent material (if you want to be really pedantic about it). Unless that communication is secured in some way - probably public-key auth, if done over the Internet - an attacker could intercept that material in transit to steal and/or modify it.
There's no place I could be, since I've found Serenity...
No whoosh - whatever clueless turd wrote that was deadly and boringly serious.
Perhaps I deserve to lose my Geek Card, but I don't get it.
Table-ized A.I.
Having said that, your users will surely allow some clown on board because THEY lost THEIR creds; so watch your permissions, etc., and back up their crap for them regularly and with a long timeline so they can change creds and you can restore them to sanity after some wackjob deletes all their stuff.
Mostly, that's it. For the hardcore, use no canned public-facing solutions. If you want zero vulnerability, don't use Other People's Code.
I've fallen off your lawn, and I can't get up.
You (Baloroth) have taken his (cbhacking) argument and declared it to be false, but you only provide a straw-man argument as your evidence.
Lets break it down to its three statements;
"Passwords are short, intended to be remembered and typed" - you don't refute this, so we can ignore it. ..." - you don't refute this either - ignore this too. ... - at this point you claim the statment is false but cbhacking only said that passwords are "vastly easier to brute force [than certs]", not that "strong passwords are easily brute forced".
"Asymmetric keys are long
"The former is vastly easier to brute force"
If you think "over ~10 characters long" makes a password unbreakable by brute force then you're crazy.
If you think certs cant be brute forced, you're also crazy - eventually there will be enough hardware to brute force them.
If you think that (relatively) certs are many magnitudes harder to brute force than passwords, then you'd probably be correct, and therefore you agree with cbhacking.
MrKiwi.
Perhaps I deserve to lose my Geek Card, but I don't get it.
Ah, then no need to run the scans, just purchase and install the AV in that case.
No, sorry, such a sarcastic put down of linux users clearly has aims other than being funny, which is just as well because it doesn't come close to being funny. The "just a joke" bullshit is usually just a defence put up by people after they are taken to task for being offensive after they've found someone of the ethnicity they are making fun of in their audience and they need to backtrack.
Old wisdom still applies. Only system thats secure is not connected to anything, not even ac-power. No power - no data movement.
Heck even Windows is secure, untill you install it on something...
Sysadmin should always be on lookout on anything thats unusuall to system and figure it out when theres something that should not be happening.
What vendors and/or products? Why protect them?
A "nerds suck" troll is not a joke.
The announcement and write-up were sensationalist drivel.
If the exploit involves some unknown vector to install a trojan SSH server then, by all means, let me know; this is news! That's an important announcement.
If the exploit involves password dictionaries employed to get root access, well - DUH.
If you are enlightening me to the new fact that OpenSSH can be trojaned to collect passwords, leave your security badge on the desk and "here's your sign (Jeff Foxworthy)".
Like this whitepaper that actually contains some details about the malware and how it spreads rather than "OMG! Your server might be infected! Run this shell script to check!".
to then attack Windows systems...
Wonder where the credentials came from in the first place... Windows maybe?
let's see. the first system i used with unicode support was in 1992.
talk about slashdog lag.
So when I use the command supplied in the article; it says this:
#ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo “System clean” || echo “System infected”
“System clean”
Weeeeeeeeee! I'm free from certain doom. However, if I change:
ssh -G to ssh -g
I get this reversal of fortune:
ssh -g 2>&1 | grep -e illegal -e unknown > /dev/null && echo “System clean” || echo “System infected”
“System infected”
It gets rather confusing since there's no -G in the man pages. However, there is only a -g which means:
"-g Allows remote hosts to connect to local forwarded ports."
So how can you truly test if your infected or not? This website helped immensely:
http://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/
You're upmodded +5 for it too, after years of LIES spread here (see my 'p.s.' below on THAT note)? Give me a break:
"Microsoft OTOH has no doors." - by MouseTheLuckyDog (2752443) on Tuesday March 18, 2014 @08:55PM (#46521019)
Oh, really? Guess again, moron -> http://www.bing.com/search?q=%... (those articles are by YOURS TRULY, & yes, they actually work to "security-harden" Windows...)
* Truth is, ANY MODERN OS has facilities for it pretty much & the CIS Tool I used as an easy to use tool for helping users do so operates on many of them!
APK
P.S.=> Of course, YOUR B.S. is merely the years of FUD around here of "Windows != Secure, & *NIX = secure" & it's ALL crashing around your ears all around you, now (for years of outrageous FUD bullshit from you "Pro-*NIX" types that infest this forums with your outright lies)...
... apk
OpenBSD is known for it's correct coding, security and stability, issues that are paramount for OpenBSD. We've often criticized the Linux distributions because of the crappy coding of applications. It's unfortunate that the Linux community has sold itself short (FSF) and vanished the core principles of correcting issues that have plagued closed source vendors OSes and apps. Apparently correct coding is not part of the methodology of the providers of linux, hence the kernel panics from PHP and or Apache.
Perhaps you may not have experienced the issue of unstable apps had you used the OpenBSD versions.
Run Windows 95
MANDATORY ACL, not DISCRETIONARY ACL...
APK
P.S.=> Before that, Linux really didn't HAVE that in place... apk
Linux server vulnerabilities can be mostly boiled down to a few things:
1. Weak passwords
2. PHP
3. Poor web app programming, mainly, but not exclusively PHP.