New Linux userland rootkit with anti-debugging, new backdoors and pcap hiding | Hacker News Reader

New Linux userland rootkit with anti-debugging, new backdoors and pcap hiding

blackhatlibrary.net

142 pointsadamnemecek68 comments

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.

Maybe I misunderstood the grammar somehow, but did you just say:

> 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.

> 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.

Thanks for that, I guess I misread a bit.

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.

Sorry, I wrote my comment quickly, this is what I meant.

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.

I agree with that, I'd be wary of it.

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.

The site seems to be getting hammered by HN so here's the google cache http://webcache.googleusercontent.com/search?q=cache:8o5FkN6...

And link to source on github: https://github.com/chokepoint/azazel

>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?

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.

Use statically-linked utilities compiled elsewhere.

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.

Usage: busybox [function [arguments]...] or: busybox --list[-full] or: busybox --install [-s] [DIR] or: function [arguments]...

		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

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

Booting from an unchangeable image is the Joyent SmartOS approach, IIRC.

Typically when you're compromised, you don't bother trying to fix the problem. You wipe the device and start over from a believed-good backup.

Even wiping device might not be the solution. What if that softwate injected into boot or any other microcontroller of a hw part.

Or use dlopen, dlsym to get the real function.

Yes, as long as dlopen and dlsym aren't also hooked.

You could also use asm to directly invoke sys_ptrace, since this rootkit doesn't have any kernel components.

LD_PRELOAD perhaps? I wonder if that would run last, rather than the rootkit?

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.

> 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?

You're supposed to install it on a VM to study it, and then throw away the VM

I think I may do this at some stage.

Interestingly, there's a "removal" section in the article, with only the instructions to delete ld_preload.so. Was that meant as a joke?

> Website is offline No cached version of this page is available.

...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.

The phrase is "for all intents and purposes", although your variation also fits, very interesting!

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?

But "intended purposes" actually makes sense in context.

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/

It does imply the existence of unintended purposes.

http://webcache.googleusercontent.com/search?q=cache:8o5FkN6...

I wonder if all-statically-linked Linux distros will become popular on the server as a defense against userland rootkits like this.

That would be cool. Are there any? I'm aware of sta.li, but it doesn't seem to be there yet.

As a matter of fact, is it possible to get stuff like nsswitch working without dynamic linking on Linux?

They won't.

Just a quick test with LTTng (lttngtrace part of lttngtop) : http://pastebin.com/rvebt7rp

I know kernel tracing is cheating for this kind of backdoor, but it can be easy ;-)

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.

Scary.

http://www.amazon.com/Fire-Upon-Deep-Zones-Thought/dp/081251...

I don't even want to click on this.

It's a wiki with a link to github repo. You need to compile it first.

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.

Nope.

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.

The nice thing about sudo is that it asks for a password, thereby mitigating the involuntary click OK reflex that affects Windows.

I think you can set Windows to do it too.

it's a wiki

was a joke

What are some applications for this?

Security research, malware analysis, etc

Keeping a hacked server pwned?

Will this work on OpenBSD?

No, this is very much Linux-only.

But in theory could something similar have been developed for OpenBSD?

There is even a book about designing FreeBSD rootkits: http://www.amazon.com/Designing-BSD-Rootkits-Introduction-Ha...

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.

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=ld.so&section=1

openbsd does have loadable kernel modules

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.

OpenBSD's kernel modules are for development only. They require a securelevel change and a reboot to enable.

In theory, something similar can be developed for any operating system IMHO, OpenBSD or otherwise. What varies is the amount of technical difficulty involved.

No?

lol , is ptrace() hooking only technique that backdoor has as a anti-debugging feature? If so , i will shit to my pants.

someone from blackhatlibrary.net here?

Ping.

edit: Just created this account to answer this question. Otherwise I'm only on HN to lurk.

Reply on news.ycombinator.com