[Security] Windigo malware and SSH client compromised

Nh3xus · 03-20-2014, 11:53 PM

Hi folks,

As you may have noticed, 10K Linux servers has been hit by a sophisticated malware aimed at various Linux components like :

Apache
Lighttpd
SSH client

More informations can be found here :

http://arstechnica.com/security/2014...-and-exploits/

The infected marchines are the Linux servers most of the time.

But since Slackware provides both an SSH daemon and client, it's worth checking if your desktop-oriented box is compromised.

On the same article, a bash command is advised to be ran on your Linux machines regardless of the distribution you are using :

Code:

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

As you can see, this code, test whether the ssh client has a "-G" argument. This particular argument doesn't exist on a stock OpenSSH client and is added by the said malware.

I will run this command tommorow and give you the result on my laptop box.

Actually, there's no known way to entirely scan a compromised machine. Which leads you straight to the re-install

Note : If you have uninstalled the OpenSSH client from Slackware or any other distro that you might use, the command will return "System infected" anyway, but it will be a false positive in this case.

Feel free to post your result here

jtsn · 03-21-2014, 05:46 AM

First: Never execute copy & pasted shell commands from the web without understanding them.

Quote:

Originally Posted by Nh3xus

Actually, there's no known way to entirely scan a compromised machine. Which leads you straight to the re-install

If you are unsure whether a system is compromised or not, then it is already compromised. So you can go directly to re-installing. You don't need to check, if your ssh understands option '-G' by accident.

Security works by establishing an uninterrupted chain of trust from the fresh install to the current state of machine and depends on your ability to verify it ("known-good"). If you don't have that, then your security is already broken.

Nh3xus · 03-22-2014, 10:58 AM

Hi,

I'm aware that running unknown commands is a big no-no.

I've not fully grasped the meaning of your "chain of trust".

To me, you meant that you must trust both the administrator and the end users of a Linux machine for keeping it secure.

If I'm somehow wrong with the statement above, can you link me a website or a book that talk about security of a Unix/Unix-like machine ?

In my case, I'm both the admin and the only user of a Linux based laptop that don't run any kind of web services.

Thanks you for your answer, it's really helping me to undestand the ins and outs of the security in IT.

I'm still a student in the IT field.

unSpawn · 03-22-2014, 11:23 AM

Quote:

Originally Posted by jtsn

If you are unsure whether a system is compromised or not, then it is already compromised.

If you are unsure about the integrity of a system then verify it. Only two outcomes: a system is either compromised or it isn't.

Quote:

Originally Posted by jtsn

So you can go directly to re-installing.

No. Verify the system then investigate.

Quote:

Originally Posted by jtsn

You don't need to check, if your ssh understands option '-G' by accident.

Yes you do: you should find the infection vector.
Without knowing how the perp got in you may be exposing the same loophole again and again.

hitest · 03-22-2014, 11:57 AM

I guess I'm more paranoid than most. I don't run SSH on my boxes. I recently updated to the most recent version of rkhunter, version 1.4.2. I scan for root kits.

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

You should run ssh only if you need it. If you don't need it, then don't run it. If you do run it, then keep it up to date and take extra precautions.

jtsn · 03-27-2014, 05:15 PM

Quote:

Originally Posted by unSpawn

If you are unsure about the integrity of a system then verify it. Only two outcomes: a system is either compromised or it isn't.

But you don't ask the malware itself, if your OS compromised. You verify it with a proven method, like using cryptographic checksums and compare them to the known-good state.

Quote:

Yes you do: you should find the infection vector.

You don't do that by executing 'ssh -G' on the infected installation, but by analysing a post-mortem image after taking down the compromised machine.

Lufbery · 03-27-2014, 06:28 PM

Okay, so I just downloaded and reinstalled the openssh Slackware package for Slackware 14.0 and it still shows up as infected.

Does that mean that the Slackware packages are compromised or is something else going on?

55020 · 03-27-2014, 07:46 PM

Quote:

Originally Posted by Lufbery

Okay, so I just downloaded and reinstalled the openssh Slackware package for Slackware 14.0 and it still shows up as infected. Does that mean that the Slackware packages are compromised or is something else going on?

Well, it might be a false positive. What are you doing to check? The original paper is here, work your way through Appendix 1 section A1.1.

Cleanup is described in Appendix 2. Unfortunately much more is entailed than just reinstalling openssh. To quote the paper:

Quote:

In order to install Linux/Ebury on a system, the malware operators need root access. With this level of access, anything is possible. This is why we advise anyone infected to completely wipe their servers and rebuild them from scratch using a verified source. That’s the only way to make sure to get rid of this threat.

It's not just openssh that would need to be reinstalled: it's also keyutils, httpd, bind, and possibly more.

But the next bit is *much* more important:

Quote:

Most importantly, assume that administrator and user credentials have been compromised. Because of this, we advise anyone infected to reset all user and administrator credentials from known clean machines and put a measure in place to prevent users from resetting their passwords to their original ones.

It is important to realize that Linux/Ebury stole the credentials of all login attempts made on an infected server (successful or not). Additionally, it also steals credentials of connections originating from that server, through a trojanized ssh binary, meaning that anyone using the server as an SSH relay will also have the credentials to other servers stolen. Furthermore, ssh and ssh-add will steal passphrases that unlock SSH keys and will save in memory the unencrypted SSH keys so they can be retrieved later by the malware operators. This credential stealing infrastructure is very comprehensive and this is why we advise that infected organizations should take this very seriously and reconsider their server authentication mechanisms."

So they would have your passwords and keys, and can just reach in and re-pwn you if you haven't changed them

I really hope for your sake it's some sort of false positive

unSpawn · 03-27-2014, 08:42 PM

Quote:

Originally Posted by jtsn

But you don't ask the malware itself, if your OS compromised. You verify it with a proven method, like using cryptographic checksums and compare them to the known-good state.

Thanks, I'll mark that as informative. But it's what I have advocated always. *And do feel free to lecture me but please not on the basics: I've been performing incident response here a wee bit longer than you :-]

Quote:

Originally Posted by jtsn

You don't do that by executing 'ssh -G' on the infected installation, but by analysing a post-mortem image after taking down the compromised machine.

While I personally avoid disturbing a (presumed) compromised system it seems some advocate different standards... That said anyone who has done forensics in the field knows you don't always have the luxury of a cold copy of a corpse to work on. In that case the strategy may change and well include executing suchlike commands on a Live system.

ReaperX7 · 03-27-2014, 09:21 PM

RKhunter, chkrootkit, and clamav are all available for Linux servers and clients, and should have the proper definitions to combat such malware. Plus you should also be runnign as a User and not root to prevent certain malware from executing. You can always also simply uninstall the OpenSSH package and re-install it also if it becomes infected and clear the system temp files and other cache.

Lufbery · 03-27-2014, 09:50 PM

Quote:

Originally Posted by 55020

Well, it might be a false positive. What are you doing to check? The original paper is here, work your way through Appendix 1 section A1.1.

It looks like a false positive. Simply typing ssh -G gives this:

Code:

ssh: illegal option -- G
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-W host:port] [-w local_tun[:remote_tun]]
           [user@]hostname [command]

For some reason, the command with the grep doesn't work for me.