Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Trailrunner7 writes "A new Linux rootkit has emerged and researchers who have analyzed its code and operation say that the malware appears to be a custom-written tool designed to inject iframes into Web sites and drive traffic to malicious sites for drive-by download attacks. The rootkit is designed specifically for 64-bit Linux systems, and while it has some interesting features, it does not appear to be the work of a high-level programmer or be meant for use in targeted attacks. The Linux rootkit does not appear to be a modified version of any known piece of malware and it first came to light last week when someone posted a quick description and analysis of it on the Full Disclosure mailing list. That poster said his site had been targeted by the malware and some of his customers had been redirected to malicious sites."

Well, they are suspecting a Russian based attacker, so unless you contract out to Russian jerks then I fear that your supposition is unsupported and is most likely based on wishful thinking. The code was not well hidden, and they didn't strip the symbols in the executable file - hence the programmer still has a lot to learn.

How come neither of the links actually describe how this malware infects the machine in the first place? I'd say that's quite an important piece of information completely missing.

I don't think it's self-replicating or installing itself by some vulnerability, I believe it would have to be installed maliciously (perhaps by an employee, or maybe by someone using an unrelated root exploit), or as a Trojan Horse - many people are happy to blindly install unsigned packages on their system, running the installation as root.

Back in the day, I used to make at least a cursory inspection of the Makefile and sometimes would even look over the source code associated with distributed packages.

Indeed. All it says is thay you're redirected to an iframe. How it breaks out of the browser's sandbox and then obtains root priviledges isn't mentioned either. I'm quite interested in how they achieved this too, since it would mean that there's a huge priviledge escalation in linux that nobody noticed.

Firefox on linux used to be able to execute arbitrary commands from extensions: I wrote one which did that on Firefox 2 and ported it to firefox 3. that means if you can fool someone into installing your extension, you've got them.

Similarly, a *.desktop file (used for Gnome and KDE desktop items) can contain arbitrary shell script. This doesn't need +x, because it isn't executed directly when you click on it, instead the string is passed to system(3). The way I'd use that would be to overwrite a common prog

I think you are confused as to what this is doing. How the malware initially got loaded onto the *NIX box is not discussed in the write-up. The malware does not break out of the browser's sandbox and obtain root privileges. The malware is used to add/change the file being served by the web server. There is no mention of what file the malware was being used to serve up...it could be used just to transparently serve up ads or could be used to serve up some client-side exploits.

To be honest, other than constantly using the word "rootkit", I don't see any references to getting root via this "kit". And the link (this one: https://threatpost.com/en_us/blogs/new-linux-rootkit-emerges-112012 [threatpost.com]) looks like it was written by a computer program pulling random sentences from a malware description and turning it into an article.

I'm going to wait for the dup, hopefully it'll link to an Ars Technica article or something else relatively reputable.

Just curious why the root kit is only targeting 64-bit. Is it specifically targeting the intel 64bit spec that allows for privileged escalation, or something like that? Reading the article makes it sound like it's an exploit of the AMD little endian pointers which, since I don't know hardware on that level, I don't know if that means it's actually a CPU exploit or an OS exploit. And if it's a CPU exploit I don't know if it's all AMD64 based including or excluding Intel.

Just curious why the root kit is only targeting 64-bit. Is it specifically targeting the intel 64bit spec that allows for privileged escalation, or something like that? Reading the article makes it sound like it's an exploit of the AMD little endian pointers which, since I don't know hardware on that level, I don't know if that means it's actually a CPU exploit or an OS exploit. And if it's a CPU exploit I don't know if it's all AMD64 based including or excluding Intel.

Except Intel didn't implement AMD64 correctly 100%. You can read the US-CERT [cert.org] for yourself if you want. For that all you had to do was run a couple of commands and your code could be escalated to kernel level privileges, but only on Intel 64bit. It would be bad to assume that what works on one as an exploit would work the same way on the other. My concern is about this being a flaw in the CPU similar to what happened with Intel 64bit.

"To hook private functions that are called without indirection (e.g., through a function pointer), the rootkit employs inline code hooking. In order to hook a function, the rootkit simply overwrites the start of the function with an e9 byte. This is the opcode for a jmp rel32 instruction, which, as its only operand, has 4 bytes relative offset to jump to," Georg Wicherski of CrowdStrike wrote in a detailed analysis of the new Linux malware.
"The rootkit, however, calculates an 8-byte or 64-bit offset in a stack buffer and then copies 19 bytes (8 bytes offset, 11 bytes unitialized) behind the e9 opcode into the target function. By pure chance the jump still works, because amd64 is a little endian architecture, so the high extra 4 bytes offset are simply ignored."

I read that already, but "By pure chance the jump still works, because amd64 is a little endian architecture" which makes me think this is an exploit of the CPU, and not an exploit of the OS. From what that says it overwrites the start of the function that it's targeting with a relative jump of 32 bits of 1 byte. It then calculates a 64 bit address of 8 bytes I assume this is the address of some Root Level command. It then copies the 8 bytes after the 1 byte rel32 byte and an additional 11 bytes of junk. T

There's no "exploit". The emphasized section just says the programmer was incompetent, but by chance his rootkit still (mostly) works.
Again, this is a rootkit. You need root access through some other means to install it. Still a nuisance, though.

If I were a betting person, I'd say the reason why it was built for 64 bit architectures is because most servers use more than 4GB of RAM, which is the limit for 32 bit operating systems. I could be completely wrong on all counts though.

I'm not so sure about that. The kernel module uploaded to the full discosure list happened to be a amd64 module targetting debian kernel 2.6.32-5. But when it's not php, most malware I've seen was distributed as source code, compiled at the target machine to match the targets specifications.

If you dig into the articles to some of the raw analysis you'll discover two things.

1) "It remains an open question regarding how the attackers have gained the root privileges to install the rootkit. However, considering the code quality, a custom privilege escalation exploit seems very unlikely." So it unlikely that they gained root with something new, but it was a web site that was hacked, so the likely vector is something related to what the site it was running. PHP, WordPress, DB Injection, and Apache exploits.

2) "Based on the Tools, Techniques, and Procedures employed and some background information we cannot publicly disclose, a Russia-based attacker is likely."

1) "It remains an open question regarding how the attackers have gained the root privileges to install the rootkit. However, considering the code quality, a custom privilege escalation exploit seems very unlikely." So it unlikely that they gained root with something new, but it was a web site that was hacked, so the likely vector is something related to what the site it was running. PHP, WordPress, DB Injection, and Apache exploits.

That's what I thought, too, but it should be researched more carefully. If the malware in question was injected in the first place via PHP, WordPress or something similar then that makes this much, much less of an important issue. However, if the malware did indeed use one or another exploit in the kernel or the default GNU userland, well, THAT would be truly news-worthy and should raise some serious flags.

It doesn't contain any form of exploit at all. It is a program that has to be executed as root. If you are root, you already can do everything. (Like write to/dev/mem.) No need for exploits.

It isn't even a rootkit. Because "rootkit" implies getting root access from a non-root state.

You're assuming things. I did obviously read TFA. The thing is that the kernel module and its files could be a PART of a rootkit, not that the module itself contains any exploit code. That's why I used the wording "malware in question was injected," ie. the actual infection was done by another entity -- we just do not yet know whether or not it was done by a human person or computer code.

A Russia based attacker eh? Well, when I view the RSS feed through Google Reader, under the article title I see a picture of "Marina 26, Russia" and she does look a little naughty. So, I guess that's that cleared up.

So it isn't a rootkit (rootkit is only class of malware what is made against operating system like Linux [kernel]) but just a malware what needs user to grant it a root rights.

Since TFA doesn't give enough details the kernel module and its files could, in theory, be a PART of a rootkit, but the party that installed the module and its files did all the work and the module is indeed just malware. And well, we don't know if the party that installed it in there was indeed using an unknown exploit or if it was just a person who got inside the server due to poorly-developed websites and/or SQL-injection, and it's much more likely it's just the latter.

An iframe injection that redirects you to a malicious website where you have to download something and run it as root to get infected sounds almost nothing like something that runs as a normal user and exploits local weaknesses to gain privileged access surreptitiously.

It sounds like just plain old malware - maybe it does have a rootkit as part of the package - but still.. iFrame injection and a slew of other functional abilities are not in the domain of a 'rootkit'. The definition of a worm is a malicious program that replicates itself.

So since the "root kit" involves some other vector letting the intruder append something to rc.local (or somehow pivot on whether rc.local ends with an "exit 0") the root kit ins't a root kit but a post-root-promotion exploit.

Linux gets used by the majority since they're smallfry and cash strapped since Linux = free

...yeah cos ibm linux servers just keep falling out the back of various trucks, not to mention all the "cash strapped" geeks in fortune 500 corporations can afford to fill their multi-million dollar datacenters with linux blades

i get microsoft also missed the memo cos even they have linux on azure

Dunno about AC, but first glance seems to be that it exploits shitty PHP code in order to get itself hosted onto the websites.

According to TFA, it appears to target one specific kernel (Debian-based), and tries to do some hokey-pokey with RAM to get itself executed. If you want a better description go to the original report [seclists.org]

The kernel module in question has been compiled for a kernel with the version string 2.6.32-5. The -5 suffix is indicative of a distribution-specific kernel release. Indeed, a quick Google search reveals that the latest Debian squeeze kernel has the version number 2.6.32-5.

The module furthermore exports symbol names for all functions and global variables found in the module, apparently not declaring any private symbol as static in the sources. In consequence, some dead code is left within the module: the linker can't determine whether any other kernel module might want to access any of those dead-but-public functions, and subsequently it can't remove them.

...doesn't say exactly how, but there is one thing that is entirely left out of the equation... if it's a drive-by download, does it definitely require user involvement, or not? According to the original report, the complaints were that they customers were being redirected to a malicious site, but nothing about a trojan being involved.

Just putexit 0
at the end of your/etc/rc.local and the rootkit becomes unloadable. Just like in Debian Squeeze.

I did not get that. Would you kindly explain that?

Well, it's even in TFA [threatpost.com], and described in more detail here [crowdstrike.com]. According to the guy who analyzed it (Georg Wicherski): "the command is appended to the end of rc.local" and "On a default Debian squeeze install,/etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded". This [blogspot.com] is what happens when you try to install the rootkit on Debian Squeeze.

also, rc.local on my machine (default install of squeeze, no permissions tampering) has write permissions on/etc/rc.local for owner (root) only, so for any malware to write to/etc/rc.local it would have to be running as root anyway (in which case my system would already be fucked).

TFA doesn't make a very clear connection between "iFrame injection mechanism" and full root access on the server, particularly as servers don't usually display iframes in a web browser (that's usually on the client end). sure

Debian does not have SELinux enabled by default. So that is one barrier that frequently they won't have to cross in getting root access.

Debian might also have been targeted for its large market share and not having security extension installed by default. Considering the wide range of uses that Debian is put to it seems like maybe they should create a "public server" install profile that includes things like SELinux enabled and checkrootkit and other routine auditing tools installed.

IMHO, this is one thing they really need to look into fixing to keep up with what threats are out there.

It doesn't matter if they use SELinux or AppArmor. Just use something to limit the context things run in so even if something like Apache gets compromised, even with a way to UID 0, the mischief they can do is limited, be it to a directory or filesystem, or to only a segment of process space.

One thing I like is how sandboxie works on Windows -- a sandboxed program would have a list of executables (either

Dunno about AC, but first glance seems to be that it exploits shitty PHP code in order to get itself hosted onto the websites.

How does "first glance" tell you that? And are you talking about code written in the PHP language or about the PHP implementation? And even if you break into a PHP implementation remotely, how do you make the kernel load the module, assuming the administrator isn't an outright idiot and the PHP process isn't running as root?

I call bullshit on this until they show the code which actually own the Linux kernel. If you could trace this whole thing, I am quite positive it leads to the checkbook of a Mr Ballmer, resident of Redmon, WA, USA.

To be fair to Linux, glibc is not in the Linux kernel. That's why it's important to say GNU/Linux: because Drepper deserves the blame at least as much as Linus. Android, for example, is Linux and uses a FreeBSD libc derivative instead of glibc.

...while it's nice that Linux has gained a reputation as a secure alternative to Windows, the fact of the matter is that no one has really given a shit until now enough to really poke a hole in it.

Frothing at the mouth, Mr. Ballmer? Linux isn't a "a secure alternative to Windows for most folks using it, it runs on everything from wristwatches to the most powerful supercomputers in the world. Most web servers are running Linux. If Linux were easy to exploit, you'd have heard of a LOT of exploits.

I would think that TVs would be the ideal target. Sure, the processing power is low, but nobody even considers watching for malware on TVs. I wouldn't be surprised to find out that the computer running Linux inside my TV never turns off. Of that is the case, a malware writer the targeted TVs would have 100k - millions of low power but always on and never protected computers to run there malware on.

Wrong. A rootkit is code which maliciously takes over certain functionality at root level. How it got installed doesn't matter for its classification as rootkit. Of course most rootkits get installed by some virus, worm or trojan, but a rootkit which some cracker installed by hand is still a rootkit.

There aren't any known, widespread Linux-based viruses or malware, and the few ones that do exist target server software, Java and/or Flash. And even if you found malware that still made its way in your computer via e.g. a vulnerability in the browser's Javascript - implementation that malware would still have to get root privileges in order to properly hide its existence -- there aren't any known, widespread security holes either in the Linux-kernel or the GNU userland, so if you keep your system up-to-date the chances are very, very slim the code would be able to get root privileges.

That is to say that if you e.g. used Firefox without Java and with the Flashblock add-on there'd be more-or-less no chances of you getting anything. Don't get scared by articles like this one because, well, this one doesn't spread via the web browser in the first place -- it was likely installed on the system by hand by someone who got access to it because of poor website implementation.

Then why are you asking?
Did you get new information about some novel and previously unknown exploit for Linux desktop installs?
Nothing is infallible but the historic record has persistently shown the *nix development system delivers a rather robust OS.
So yes stay vigilant on any system that's exposed to the web or (USB) media but also do enjoy some peace from knowing you are running a from a security standpoint better designed OS than the de-facto industry standard for desktops.

ignore that advice all you want, but anyone who understands Python will read it and think "hahahaha there's an indentation bug on the 5th line... what a dumbass!!!!"
particularly because of the arrogant and rediculous context that you repeatedly post it