Beware of Linux SSHD rootkit to steal SSH credentials in server

[2014-01-08] Information about an updated version of the SSHD rootkit called Ebury added.

Since the end of Feb 2013, some server administrator found the SSHD rootkit infection on RPM based Linux server in the wild. German CERT team   discovered that 38 IP addresses in HK had connected to one of this rootkit’s command and control server (C&C) and these Linux servers might have been   infected by a SSHD rootkit. HKCERT received their report and informed to the owners of affected server to check and clean up their servers.

 SSHD Rookit

SSH is the major tool on Linux for remote administration and it is a critical security risk if this application is compromised. This SSHD rootkit is not caused by SSH vulnerability and the initial attack vector is still unknown. The rootkit must be installed on a root compromised server and it replaces the legitimate keyutils library with a trojanized library (i.e. rootkit file). The rootkit links with SSHD daemon to collect credentials of authenticated SSH users and may not leave any trail on audit log.

 Besides, the rootkit implements a DGA (Domain Generation Algorithm) which creates the random looking domain names in the .biz, .info and .net top level domains (in this order) and send a DNS packet containing collected credentials to the target domains which are generated by the rootkit in daily. If the domains are not yet registered by the attacker, the DNS packet is sent to the hard-coded IP address “78.47.139.110” or “72.156.139.154″.

What is the impact of infected servers?

The infected servers may have the following impact:

• Steal user credentials on system


• Steal SSH private keys for outgoing SSH connections


• As a backdoor to access at any time


• Used for sending spam

How to check if your Linux server is infected?

[2014-01-08] According to CERT-Bund, an updated version of the rootkit called Ebury was discovered, and following is the detection method:

1. Ebury uses shared memory segments (SHMs) for interprocess communication. To show a list of currently existing SHMs, run the command ‘ipcs -m’ as root.


2. If the output shows one or more large segments (at least 3 MB) with full permissions (666), the system is most likely infected with Ebury. Sample output:
   

   ------ Shared Memory Segments --------

key shmid owner perms bytes nattch

0x000006e0 32763 root 666 3018428 0

0x00000469 65538 apache 666 4313584 0

0x0000047a 131072 smmsp 666 3966496 0

   
   

   Please note that Ebury often changes the ownership of segments to arbitrary users existing on the system (like ‘apache’) to make the segments look legit.

[For older version of SSHD rootkit] The following checking can help you to verify if your Linux server is infected.

• Locate the network activity issued by the trojanized keyutils library

Check the output of following command (in one line):

#find /lib* -name libkeyutils\* -exec strings \\ \; | egrep 'connect|socket|inet_ntoa|gethostbyname'

If there is any output, your server is infected.

If there is no output, proceed to next step.

• Check the file integrity of keyutils library

Check the output of the following command:

#rpm -Vv keyutils-libs

If you see output similar the list below, it means that the package is infected:

........ /lib/libkeyutils-1.2.so
S.5..... /lib/libkeyutils.so.1
........ /usr/share/doc/keyutils-libs-1.2
........ d /usr/share/doc/keyutils-libs-1.2/LICENCE.LGPL

If the server is not infected, you should only see dots in left column:

........ /lib64/libkeyutils-1.2.so
........ /lib64/libkeyutils.so.1
........ /usr/share/doc/keyutils-libs-1.2
........ d /usr/share/doc/keyutils-libs-1.2/LICENCE.LGPL

 

Solution

If your server is infected

1. We strongly recommend you to reinstall the OS of infected server to avoid any unknown security risk. Due to the attack vector is still unknown, please do the following action to avoid re-infection.
   
   1. Perform the above checking regularly
   
   
   2. Keep monitor the latest patch or security issue relating to this rootkit
   
   


2. However, if you are not able to perform re-installation, please fix the following items under no network connection environment.
   
   1. Re-install libkeyutils (using rpm –replacepkg option) and reboot the server.
   
   
   2. Perform the above checking to ensure that the libkeyutils is replaced by a clean one
   
   
   3. Change the password of all SSH user account.
   
   

Share this:

Beware of Linux SSHD rootkit to steal SSH credentials in server