I might be wrong, but I don't think there exists and flyby worm/virus/rootkit for Linux where clicking a link will automatically get you infected, without any user input.
They're about as easy to make as for Windows. It's just that Windows targeting is more profitable for mass malware, and the technical user base leads to shorter half life.
Any links/info on people making them? I was just looking for some, and didn't find any reports of such things in a few minutes of looking. Seems like the overall field is light, partly because there isn't any large company to pay out rewards for exploits, the huge variety of distros in the installed base, and the weak ecosystem as a result of the previous two.
There probably are plenty of holes, but they might be only found by big-money efforts aimed at compromising particular computers, meaning essentially government spying.
The major difference between your common Windows user and Linux user is that Windows users are often logged in as Administrator. So if arbitrary-code-execution happens that code owns the whole system - checkmate.
The typical Linux user is not running their Windows Manager or browser as root. The worse that can happen is stuff to your home dir(which can be very bad too). Even this article title calling this a "userland rootkit" is kinda odd, since
"/etc/ld.so.preload"(and the whole /etc dir) is a root-only writable. No matter how secure your OS is, if you're tricked into running an evil program as root/admin... it's game over.
The usage-pattern for this happening on Windows is much, much higher than Linux since Windows users are already admin to start off with. Also, from my observation of Windows users over my 10+ year career, they always click "Ok" on every pop-up dialog box without even reading it. I think that UAC thing from Windows Vista enforced that behavior even more.
"Userland" as opposite of "kernelland". I only had a quick skim of the article, but there doesn't seem to be any kernel module loaded by this rootkit. Hence, an userland rootkit, because everything happens outside of kernel.
> Running "make install" will inject the live kit into your system. While removal is not impossible, it's an unnecessary and painful procedure, not to mention you may forget to remove it.
Why even have an install step for this? Actually, why does it exist?
>Azazel hooks ptrace() and returns -1, hence denying any debugging from occuring. The message displayed to the sysadmin is really more of a joke than anything and will definitely set off alarms that something is wrong.
Okay, that's interesting - how would you remove this hook?
Can you explain in a more newbie friendly language?
How do you detect this? Then how do you remove this?
This type of high level tools becoming more mainstream as time passes. Today there is not much generic anti-tools for this or the upcoming ones!
Firstly, this is not some virus or worm that works it's way onto your machine. It's a payload that someone puts there possibly among other things. This means that if you have this on your machine, or if you have reason to think you have this on your machine, simple removal is not an acceptable solution. Whoever put the rootkit on the machine could have done almost anything else while he did it, and you are not guaranteed to find it all. If you find this on your machine, you need to produce a data-only backup of the machine, kill the partitions, and set it up again.
As these rootkits are designed by rather smart people to overcome all existing tools, there simply cannot be generic tools that catch them all. If you get hit by a bunch of script kiddies using outdated tools, things like rkhunter and chkrootkit can help. Modern rootkits are almost by definition undetectable by them. If it's actually new, the way you find out about it is typically either a separate NID box between the machine and the wall that alerts, or the behaviour of the box changing.
So for a low traffic Web server like application, we might be running the OS itself (/) from a read only filesystem (e.g. making a 'live' CD-ROM or USB image) and having read/write only for user files and logs?
End user here: I just have a Linux laptop, interested in servers on the 'wild' web
Adding to that: Most Linux distributions will have a ready-compiled "busybox" in their repositories (which is a "swiss-army-knife" program incorporating the functionality of a lot of the common utilities). Of course taking it from a potentially infected machine doesn't makes sense, but you might want to copy it over with a usb-stick.
$ ldd /usr/bin/busybox
not a dynamic executable
$ ls -l /usr/bin/busybox
-rwxr-xr-x 1 root root 1795976 Jan 20 14:21 /usr/bin/busybox*
$ file /usr/bin/busybox
/usr/bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=76e26ac5c916fc1e715c9a49c10db3405b26a22c, stripped
$ busybox
BusyBox v1.22.1 (2014-01-20 17:20:52 MSK) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as.
Currently defined functions:
[, [[, addgroup, adduser, adjtimex, ar, arp, arping, ash, awk, base64,
basename, beep, blkid, blockdev, bootchartd, brctl, bunzip2, bzcat,
bzip2, cal, cat, catv, chat, chattr, chgrp, chmod, chown, chpasswd,
chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond,
(...)
uudecode, uuencode, vconfig, vi, vlock, volname, wall, watch, watchdog,
wc, wget, which, who, whoami, whois, xargs, xz, xzcat, yes, zcat, zcip
It's an LD_PRELOAD so it's likely either:
1. a environmental variable for the user, in which case you just need to clear their rc files.
2. In /etc for all users. In which case you'll just have to remove the file. To get around hiding you can use debugfs point to block device (/dev/sda1?). Navigate to find the offending file and mv it.
As someone else points out, all statically linked binaries are immune to this technique since they don't load preloads.
Another warning is don't muck around with /etc/ld.so.preload unless you know what you're doing. It's possible to get in a state that everything you executes segfaults.
OpenBSD does not have loadable kernel modules, so the techniques described for FreeBSD most likely do not apply.
As for the Azazel rootkit, it uses LD_PRELOAD. According to the ld.so manpage[1] it is ignored for setuid/setgid executables. This looks like the behaviour is not exactly that of the Linux ld.so so perhaps this limits the rootkit's impact.
LD_PRELOAD and friends are also ignored on linux for setuid/setgid binaries, otherwise privilege escalation would be trivial, just start any dynamicly linked setuid binary with LD_PRELOAD and go to town.
In theory, something similar can be developed for any operating system IMHO, OpenBSD or otherwise. What varies is the amount of technical difficulty involved.
Curiously, I use that variation as well. I tried to look it up to find out where I could have picked it up, but couldn't get any interesting results. Does anyone else uses that?
Yes, that's one of the defining features of an "eggcorn", that it does make sense. Or even more sense than the original. Here's a more thurough definition: http://eggcorns.lascribe.net/about/
I thought that Vernor Vinge greatly exaggerated hackability when he wrote Fire in the Deep, but now I see he was right and I was wrong. Go read it now.
The title suggests there is a new virus for Linux, but I see a wiki listing features from the malware and even linking to source code on Github. Was this thing engineered as some sort of demonstration? Or how else did they get the source code?
Yeah, it's a demonstration of various techniques used in more modern rootkits. As such, certain bits and pieces, like its masking of ptrace() is set to an obvious message. The blog post regarding the release -- http://www.chokepoint.net/2014/02/detecting-userland-preload... -- is much more useful than this wiki page in discussing how certain things are accomplished.
I think it was mentioned on a comment, but just to make it clear:
A rootkit is not a virus nor a way to obtain privileges on a Linux box, but a set of tools providing various features to keep hidden a root access to the hacked box.
This rootkit provides various backdoors allowing to get root ssh access and advanced anti-detection features, but as far as I know, this package won't hurt you badly as far as you don't manipulate it with a privileged user.
> Allowing root ssh is [...] your machine's security.
Taking stuff out of context is fun!
He said it won't hurt you badly as long as you don't run it as root. From that, I understand that it can't install itself unless it's run as a privileged user.
I'm reading the entry on blackhatlibrary. It seems you first have to get root access to copy in (overwrite?) libselinux.so. Then it gets you all sorts of backdoors that gives you root access on a machine.
71 comments
[ 2.9 ms ] story [ 135 ms ] threadGod says... energy I_could_be_wrong not WooHoo poor husband baffling crash_and_burn how_could_you guppy youre_welcome charged I_veto_that employee hobnob sex what_have_you_done_for_me_lately wazz_up_with_that Ramsay astounding What_are_you_doing_dave basket_case slumin humongous pet I_didn't_see_that repeat_after_me
There probably are plenty of holes, but they might be only found by big-money efforts aimed at compromising particular computers, meaning essentially government spying.
The major difference between your common Windows user and Linux user is that Windows users are often logged in as Administrator. So if arbitrary-code-execution happens that code owns the whole system - checkmate.
The typical Linux user is not running their Windows Manager or browser as root. The worse that can happen is stuff to your home dir(which can be very bad too). Even this article title calling this a "userland rootkit" is kinda odd, since "/etc/ld.so.preload"(and the whole /etc dir) is a root-only writable. No matter how secure your OS is, if you're tricked into running an evil program as root/admin... it's game over.
The usage-pattern for this happening on Windows is much, much higher than Linux since Windows users are already admin to start off with. Also, from my observation of Windows users over my 10+ year career, they always click "Ok" on every pop-up dialog box without even reading it. I think that UAC thing from Windows Vista enforced that behavior even more.
edit: Just created this account to answer this question. Otherwise I'm only on HN to lurk.
Why even have an install step for this? Actually, why does it exist?
Okay, that's interesting - how would you remove this hook?
As these rootkits are designed by rather smart people to overcome all existing tools, there simply cannot be generic tools that catch them all. If you get hit by a bunch of script kiddies using outdated tools, things like rkhunter and chkrootkit can help. Modern rootkits are almost by definition undetectable by them. If it's actually new, the way you find out about it is typically either a separate NID box between the machine and the wall that alerts, or the behaviour of the box changing.
End user here: I just have a Linux laptop, interested in servers on the 'wild' web
$ ldd /usr/bin/busybox not a dynamic executable
$ ls -l /usr/bin/busybox -rwxr-xr-x 1 root root 1795976 Jan 20 14:21 /usr/bin/busybox*
$ file /usr/bin/busybox /usr/bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=76e26ac5c916fc1e715c9a49c10db3405b26a22c, stripped
$ busybox BusyBox v1.22.1 (2014-01-20 17:20:52 MSK) multi-call binary. BusyBox is copyrighted by many authors between 1998-2012. Licensed under GPLv2. See source distribution for detailed copyright notices.
Usage: busybox [function [arguments]...] or: busybox --list[-full] or: busybox --install [-s] [DIR] or: function [arguments]...
You could also use asm to directly invoke sys_ptrace, since this rootkit doesn't have any kernel components.
As someone else points out, all statically linked binaries are immune to this technique since they don't load preloads.
Another warning is don't muck around with /etc/ld.so.preload unless you know what you're doing. It's possible to get in a state that everything you executes segfaults.
As for the Azazel rootkit, it uses LD_PRELOAD. According to the ld.so manpage[1] it is ignored for setuid/setgid executables. This looks like the behaviour is not exactly that of the Linux ld.so so perhaps this limits the rootkit's impact.
[1] http://www.openbsd.org/cgi-bin/man.cgi?query=ld.so§ion=1
http://www.openbsd.org/cgi-bin/man.cgi?query=lkm
LD_PRELOAD and friends are also ignored on linux for setuid/setgid binaries, otherwise privilege escalation would be trivial, just start any dynamicly linked setuid binary with LD_PRELOAD and go to town.
...and we broke it.
This is, for all intended purposes, a static page. When will people learn to put a caching nginx in the front... that's all it takes, really.
Scary.
A rootkit is not a virus nor a way to obtain privileges on a Linux box, but a set of tools providing various features to keep hidden a root access to the hacked box.
This rootkit provides various backdoors allowing to get root ssh access and advanced anti-detection features, but as far as I know, this package won't hurt you badly as far as you don't manipulate it with a privileged user.
> This rootkit provides various backdoors allowing to get root ssh access
followed by:
> this package won't hurt you badly
Allowing root ssh is the ultimate death of your machine's security. Having this installed hurts you badly.
Taking stuff out of context is fun!
He said it won't hurt you badly as long as you don't run it as root. From that, I understand that it can't install itself unless it's run as a privileged user.
So what he's saying is that there's no privilege escalation exploit packaged with this rootkit. Gotcha.
Still I wouldn't mention "this package won't hurt you" along with such a tool. Many userland exploits exist.
I said that "it won't hurt you" as a reaction to people saying "I won't even click on that link" in some comments.
As a matter of fact, is it possible to get stuff like nsswitch working without dynamic linking on Linux?
I know kernel tracing is cheating for this kind of backdoor, but it can be easy ;-)