New 64-bit Linux Rootkit Doing iFrame Injections

corpus

Found this article in securelist
https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections

There is also a detailed analysis of the rootkit here
http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-rootkit.html

Corey

@corpus said: Found this article in securelist

https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections

There is also a detailed analysis of the rootkit here

http://blog.crowdstrike.com/2012/11/http-iframe-injecting-linux-rootkit.html

Nice - I'll be sure to let all the devs at work know about this.

kbeezie

"The malware module was specially designed for the kernel version 2.6.32-5-amd64, which happens to be the latest kernel used in 64-bit Debian Squeezy."

I guess mainly impacts you if you're running Debian on desktop, dedicated server or KVM/Xen-HVM. (since otherwise you're running a kernel of the host typically CentOS specifically for OpenVz, etc).

Mun

The question is if you need to browse to it, or if it can be forced upon the server.

gsrdgrdghd

@Mun said: The question is if you need to browse to it, or if it can be forced upon the server.

Huh? It's used by acquiring root on a server (that runs a HTTP server) and then hooking the tcp_send function to inject the HTML for the iframe into every (n-th) website that is serverd by the server

eastonch

This could be an interesting issue!

zhuanyi

@kbeezie said: "The malware module was specially designed for the kernel version 2.6.32-5-amd64, which happens to be the latest kernel used in 64-bit Debian Squeezy."

Silly question, in general is 32 bit safer than 64 bit? Or the other way round?

craigb

@zhuanyi the short version is that - in general - reliable exploitation of memory corruption bugs (e.g. stack/heap overflows) with modern platform protections enabled on a 64bit arch is harder (i.e. initial exploit creation is more time consuming/expensive)

kbeezie

@zhuanyi I don't know if you could say one or the other is "safer", I would imagine that like windows vs osx vs linux and so forth, most hackers are going to target more popular platforms, with servers out there with larger amounts of memory (and personal preference), 64bit is generally going to be more available as such they would become more targeted.

It probably won't be long before certain packages are released more slowly for 32-bit only platforms, so I'd imagine server wise people are going to stick with 64bit as a choice even if they don't stand to utilize it's benefits.

Raymii

How would this get on your system?

kbeezie

@Raymii usually by downloading it and installing it with another piece of software, much like how most malware infects your system.

http://news.techworld.com/security/3412075/linux-users-targeted-by-mystery-drive-by-rootkit/

http://seclists.org/fulldisclosure/2012/Nov/94

This article seems to suggest it's targeted at the nginx webserver, but as other's mentioned it just hooks onto the tcp_send which would occur with any outbound webserver.

None of the sources I can find seem to suggest that they were installed via a security exploit (meaning infection done from outside of the box without user's interaction). And it seems to be very specific, as in it was probably written to target a particular group/etc (which would kind of go in hand with the whole cybercrime by pushing phishing/etc sites).

Simply put, the people looking at it, probably just don't know yet in terms of the delivery method to an infected machine.

qhoster

Fast check on OpenVZ nodes:

grep insmod /vz/private/*/etc/rc.d/rc.local

Nothing so far - good.

Maounique

Does look like something BTO.
rc.local launch, ewwww...

zhuanyi

@kbeezie said: I don't know if you could say one or the other is "safer", I would imagine that like windows vs osx vs linux and so forth, most hackers are going to target more popular platforms, with servers out there with larger amounts of memory (and personal preference), 64bit is generally going to be more available as such they would become more targeted.

I see, so it is more like a interests kind of thing

Mun

Any ideas how to patch?

HalfEatenPie

@Mun said: Any ideas how to patch?

Start with some needles and some thread and some cloth.

MrDOS

If you remove its initialization line from /etc/rc.d/rc.local and reboot, it's effectively neutralized.

@qhoster said: Fast check on OpenVZ nodes:

If the exploit relies on kernel hooks, wouldn't it be non-functional inside an OpenVZ container?

gsrdgrdghd

@MrDOS said: If the exploit relies on kernel hooks, wouldn't it be non-functional inside an OpenVZ container?

Compromised guest OSes couldn't lead to an infection, however a compromised node could.

Kuro

@ everyone talking about checking/modifying /etc/rc.d/rc.local

Quote from first link in OP:

In order to hide files and the startup entry, the rootkit hooks the following kernel functions, either by inline hooking or by replacing their addresses in memory with pointers to its own malicious functions:

vfs_readdir
vfs_read
filldir64
filldir

Thus, the only reliable method of doing such is to boot from another kernel&filesystem (rescuecd/livecd) and mounting your filesystem there.