That bug is not necessarily related to issue of the libkeyutils.so.1.9 file. Though, it doesn't help that a PoC was released so quickly. There are always local kernel roots, always. It is commonplace to want to link 2 known issues together, but very important to keep in mind that until evidence has shown otherwise, the cause remains entirely unknown.
Additionally, deleting the lib is not the only action that you should take. Ideally you will rebuild your server and never use any of the same passwords again, as it is believed to possibly send your username and password via UDP port 53 to a remote host by way of bogus DNS queries if using password auth.
This is the information that I independently discovered yesterday after first investigating the issue:
When you ssh into a server that has the libkeyutils.so.1.9 file linked to sshd, you may see 1 or 2 outbound UDP port 53 packets destined for a host at 72.156.139.154, like this:
Code:
[root@host ~]# tcpdump -Annvvs 1500 -i any host 72.156.139.154
Code:
07:54:48.233159 IP (tos 0x0, ttl 64, id 31281, offset 0, flags [DF], proto: UDP (17), length: 91) x.x.x.x.43089 > 72.156.139.154.53: [bad udp cksum d7a9!] 4619+ A? 6196g8f43a4facd3561de4gec736fb.y.y.y.y. (63)
.
Code:
07:54:48.273047 IP (tos 0x0, ttl 64, id 31321, offset 0, flags [DF], proto: UDP (17), length: 95) x.x.x.x.54872 > 72.156.139.154.53: [bad udp cksum 4e0e!] 4619+ A? 8236g7ab5b6e67g4632bc5ec31egc54ee7.y.y.y.y. (67)
.
(Ignore the extra "." at the end of the 2 packets, as I've added it simply to expand the boxes since they were cutting off the bottom line in my browser).
"x.x.x.x" is the IP address of the machine that is ssh'd into
"y.y.y.y" is the IP address of the machine that is ssh'd from
The random string that appears to the left of "y.y.y.y" is believed to possibly be the obfuscated username (e.g., "root", from the first packet), and the password (from the second packet). Note that the string is not a fixed length. You can try logging in a user with a very short username, or with a user who has a very short password, and you'll see the size of the string change (it shortened in my testing).
So, when you log into a server via sshd that is linked to the lib, it is suspected that the username and password used to log in, including the host that you logged in from, are sent to another host, disguised as an A record lookup in DNS.
What does this mean?
A) Logging into sshd as root continues to be a terrible idea
B) If you reuse your passwords, and if the lib is sending password data, check everywhere that you've used that password - especially if you logged in from a machine that has a public facing sshd.
It is common to see applications such as sshd directly backdoored once an attacker has root access to a host. For example, oftentimes attackers will replace /usr/sbin/sshd with a copy of their own which has been modified to store usernames and passwords, to bypass logging to syslog, to allow remote root access with a secret password, etc. However, detection of such an attack is trivial, as the size of the sshd binary, its checksum, etc will change.
In this case, a different but also common tactic has been deployed: instead of trojaning the application directly, trojan one of its libraries. Combined with a tiny amount of seemingly innocuous but blatantly malicious DNS traffic, this is an effective attack.
How could this attack have been detected? One way would be through careful monitoring of all RPM packages. This is good output, if we are trust the rpm utility on the host from which it is being run:
Code:
[root@host ~]# rpm -V keyutils-libs
[root@host ~]#
whereas this indicates that the libkeyutils.so.1 symlink has been changed:
Code:
[root@host ~]# rpm -V keyutils-libs
....L... /lib64/libkeyutils.so.1
Further inspection showed that /lib64/libkeyutils.so.1 was no longer a symlink to /lib64/libkeyutils-1.2.so but to /lib64/libkeyutils.so.1.9 .
Additionally, you'll note that the malicious library contains networking related code:
Code:
[root@host ~]# strings libkeyutils.so.1.9 | egrep 'connect|socket|inet_ntoa|gethostbyname'
gethostbyname
socket
inet_ntoa
connect
whereas the original lib does not:
Code:
[root@host ~]# strings libkeyutils-1.2.so | egrep 'connect|socket|inet_ntoa|gethostbyname'
[root@host ~]
Again, the cause remains unknown. According a thread on WebHostingTalk, many types of servers using various control panels have seen this attack. Those servers are surely also using different operating systems, different kernels, some with virtualization software and some without. Some are surely running daemons that others are not, and some - many, I'd wager - have already had user level break-ins at some point like so many hosting boxes do. They are also using a wide variety of software repos, and managed by folks who practice different security policies (e.g., some folks reuse the same password on all of their servers, while some strictly use key based auth).
At this time the origin of attacks remains unclear, and there is always the possibility of multiple attack vectors.
I hope this information is helpful.
LinkBack URL
About LinkBacks
SSHD Rootkit
Reply With Quote
Originally Posted by egillette
I have deleted the file libkeyutils.so.1.9 before 2 days ago, but Today Its placed in /lib folder again. I doubt its 0 day openssh exploit. I have installed the snoopy as per the Steven advice, I can see the hacker running the following commands in server. 
