New rootkit for 64-bit Linux: introducing iframe

A few days ago, a message about an interesting malware for Linux appeared on the Full Disclosure mailing list . This is a very curious sample - not only because it is designed for 64-bit Linux platforms and hides its presence on the system using sophisticated methods, but primarily because of the unusual functionality associated with the infection of sites hosted on the HTTP server that was attacked. . Thus, we are dealing with malware used to organize drive-by downloads of malware.


The malicious module was created specifically for the kernel version 2.6.32-5-amd64. This is the newest version of the kernel used in the 64-bit Debian version of Squeeze. The executable file has a size of more than 500 kb, but this is due to the fact that it was compiled with debugging information. Perhaps the module is at the development stage: it seems that some functions are not fully debugged or, perhaps, have not yet been fully implemented.

The malicious program provides its autorun by adding a line to the /etc/rc.local script:
')
insmod /lib/modules/2.6.32-5-amd64/kernel/sound/module_init.ko

After its download to the memory, the rootkit uses one of two methods to get the kernel symbols and write them to the /.kallsyms_tmp file:

/bin/bash -c cat /proc/kallsyms > /.kallsyms_tmp
/bin/bash -c cat /boot/System.map-`uname -r` > /.kallsyms_tmp

It then retrieves the memory addresses of several functions and kernel variables and stores them in memory for later use.



The temporary file is immediately deleted:

rm /.kallsyms_tmp -f

To hide the files and the launch script line that launches the malware, the rootkit intercepts the following kernel functions by splicing or replacing the address in memory with pointers to the malicious functions of the rootkit:

vfs_readdir
vfs_read
filldir64
filldir


In addition to hiding its own module, the malware attempts to hide the following files and streams:

zzzzzz_command_http_inject_for_module_init
zzzzzz_write_command_in_file
module_init.ko
sysctl.conf
/usr/local/hide/first_hide_file/*
/ah34df94987sdfgDR6JH51J9a9rh191jq97811/*

backconnect_command_thread_name
new_backconnect_command_thread_name
read_command_http_inject_thread_name
write_startup_command_thread_name
write_se_linux_command_thread_name
get_http_inj_from_server_thread_name

An interesting mechanism for implementing a floating frame (iFrame): a malicious program replaces the tcp_sendmsg system function, which is responsible for building TCP packets, with its own function. Thus, malicious frames are embedded in HTTP traffic by directly modifying outgoing TCP packets.



To obtain the actual embedded data block, the malware connects to the management server (C & C) using an encrypted password for authentication.



We were unable to connect to the management server through the port used by the malware, however the malicious server is still active; it also contains another toolkit for UNIX-like operating systems, in particular, log cleaning tools.

Until now, in most drive-by-attack scenarios, the mechanism for automatically introducing malicious code has been implemented using a simple PHP script. But in this case, we are dealing with a much more complicated mechanism — the use of a rootkit component of the kernel mode that uses sophisticated interception technologies, which makes the implementation process more transparent (invisible) and low-level than ever before. This rootkit, which is currently under development, demonstrates a new approach to organizing drive-by attacks. Undoubtedly, you can expect the appearance of other similar malware in the future.

An excellent detailed analysis of this rootkit was recently published on the CrowdStrike blog .

Kaspersky Lab products detect this rootkit as

Rootkit.Linux.Snakso.a