Thousands of Linux servers hijacked by Operation Windigo

metaschima · 03-18-2014, 07:35 PM

Quote:

While some experts have spotted elements of the Windigo cybercriminal campaign, the sheer size and complexity of the operation has remained largely unrealised by the security community.

“Windigo has been gathering strength, largely unnoticed by the security community, for over two and a half years, and currently has 10,000 servers under its control,” said ESET security researcher Marc-Étienne Léveillé. “Over 35 million spam messages are being sent every day to innocent users’ accounts, clogging up inboxes and putting computer systems at risk. Worse still, each day over half a million computers are put at risk of infection, as they visit websites that have been poisoned by web server malware planted by Operation Windigo redirecting to malicious exploit kits and advertisements.”

Interestingly, although Windigo-affected websites attempt to infect visiting Windows computers with malware via an exploit kit, Mac users are typically served adverts for dating sites and iPhone owners are redirected to pornographic online content.

An Appeal To Sysadmins To Take Action Against Windigo

Over 60% of the world’s websites are running on Linux servers, and ESET researchers are calling on webmasters and system administrators to check their systems to see if they have been compromised.

“Webmasters and IT staff already have a lot of headaches and things on their mind, so we hate to add to their workload – but this is important. Everyone wants to be a good net citizen, and this is your chance to play your part and help protect other internet users,” says Léveillé. “The last thing anyone should want is to be part of the problem, adding to the spread of malware and spam. A few minutes can make the difference, and ensure you are part of the solution.”

How To Tell If Your Server Has Fallen Foul Of Windigo

ESET researchers, who named Windigo after a mythical creature from Algonquian Native American folklore because of its cannibalistic nature, are appealing for Unix system administrators and webmasters to run the following command which will tell them if their server is compromised or not:

Code:

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

http://blog.eset.ie/2014/03/18/opera...ckdoor-trojan/
http://arstechnica.com/security/2014...-and-exploits/
http://it.slashdot.org/story/14/03/1...uxunix-servers

Z038 · 03-18-2014, 10:51 PM

That command the article gave to check to see if your system is compromised gives me "System clean", but I'm not sure it really works. ssh has no -G switch. At least, not my version of ssh, which is reported by ssh -V as OpenSSH_6.1p1, OpenSSL 1.0.1f 6 Jan 2014.

descendant_command · 03-19-2014, 01:02 AM

Because it changes the ssh functions.

Quote:

Originally Posted by http://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/

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.

Z038 · 03-19-2014, 01:03 AM

Quote:

Originally Posted by descendant_command

Because it changes the ssh functions.

Good to know. Thank you.

Habitual · 03-19-2014, 10:18 AM

So, is

Code:

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

reliable or not?

Smokey_justme · 03-19-2014, 10:50 AM

It is from what I gather.. if the -G option is reported as unknown, the ssh client is infected.. If it's reported as illegal then the client is clean..

LE: Scratch that, if ssh is reporting either an "illegal option" or "unknown option".. then the ssh client is clean.. If it doesn't complain at all (just prints the usage, then it's infected)

Habitual · 03-19-2014, 11:05 AM

Well.......
-G here is definitely illegal here, but the command given says "clean"

Code:

OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012

from openssh-6.1p1-x86_64-1 on Slackware 14

NOTE:
Changing the grep -e statements a little to

Code:

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

“System infected”

Smokey_justme · 03-19-2014, 11:26 AM

You need to use:

Code:

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

Quote:

Originally Posted by man grep

In basic regular expressions the metacharacters ?, +, {, |, (, and )
lose their special meaning; instead use the backslashed versions \?,
\+, \{, \|, $, and $.

Habitual · 03-19-2014, 12:00 PM

<mumble>
I don't enough about RE
</mumble>

“System clean”

Thank you.

sundialsvcs · 03-20-2014, 07:38 AM

I dunno, this smells like folklore to me.

descendant_command · 03-20-2014, 02:19 PM

Quote:

Originally Posted by sundialsvcs

I dunno, this smells like folklore to me.

Indeed - and it's not even April yet

metaschima · 03-22-2014, 08:54 PM

Checking for Ebury SSH backdoor may be a better way to detect it:
http://www.welivesecurity.com/2014/0...of-linuxebury/
http://docs.cpanel.net/twiki/bin/vie...ion/CompSystem

I know the media tends to blow things out of proportion when it comes to Linux security, especially lately, but it is still best to take server compromise seriously.

Devious · 03-29-2014, 12:34 AM

So what you are saying is that in running this

Quote:

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

Should result in print "System Infected"

Anything else would indicate a need for concern?

salasi · 03-29-2014, 03:42 AM

The point is that this particular piece of malware substitutes a version of ssh which has an added option (-G) for the genuine one. So, it is true that if you find a -G option, there is something badly wrong. However:

if (presumably easy) a new version of this malware were to be authored that uses a different switch from -G, this method of detecting the evil twin version of ssh would fail
if using Linux, there are other ways of checking the ssh binary; you could do, eg, rpm -Va on an rpm based system. Note that 'rkhunter', if you run that, does this verification anyway (err, it only does some good, if you actually check the log file, which of course you do, don't you?).

Smokey_justme · 03-29-2014, 03:34 PM

Actually, metaschima's links provide interesting info about other verification methods... It seems to mangle with the rpm packages so that simple verifications won't raise suspicions...