Pokemon-Themed Umbreon Rootkit Targets Linux Systems On ARM and x86 (pcworld.com) 96
New submitter Kinwolf writes: Security researchers have identified a new family of Linux rootkits that, despite running from user mode, can be hard to detect and remove. Called Umbreon, after a Pokemon character that hides in the darkness, the rootkit has been in development since early 2015 and is now being sold on the underground markets. [It targets Linux-based systems on the x86, x86-64 and ARM architectures, including many embedded devices such as routers.] According to malware researchers from antivirus firm Trend Micro, Umbreon is a so-called ring 3 rootkit, meaning that it runs from user mode and doesn't need kernel privileges. Despite this apparent limitation, it is quite capable of hiding itself and persisting on the system. The reports adds: "The rootkit uses a trick to hijack the standard C library (libc) functions without actually installing any kernel objects. Umbreon hijacks these functions and forces other Linux executables to use its own libc-like library. This puts the rootkit in a man-in-the-middle position, capable of modifying system calls made by other programs and altering their output. The rootkit also creates a hidden Linux account that can be accessed via any authentication method supported by Linux, including SSH (Secure Shell). This account does not appear in files like /etc/passwd because the rootkit can modify the output of such files when read, the Trend Micro researchers said in a blog post. Umbreon also has a backdoor component called Espereon, named after another Pokemon character, that can establish a reverse shell to an attacker's machine when a TCP packet with special field values are received on the monitored Ethernet interface of an affected device."
Re: (Score:1)
No. The solution is NetBSD with verified exec.
How is this possible? (Score:2, Interesting)
Linux is supposed to be impervious to such attacks..
Re: (Score:3)
Re: (Score:2)
Any system is vulnerable if the user has physical access to the system. There is absolutely nothing stopping you from taking a sledgehammer to the system, too.
Who said anything about physical access? Installing something manually simply means that the installation isn't script-driven. AFAICT, there was nothing mentioned in either TFS or any of the comments so far that states or even implies physical access.
Re: (Score:1)
Actually yes, manual installation of a program that runs in userspace to an otherwise remotely un-compromised system does imply physical access, when you're talking about Linux.
Re: (Score:2)
Actually yes, manual installation of a program that runs in userspace to an otherwise remotely un-compromised system does imply physical access, when you're talking about Linux.
Even when preceded with the qualifier "after compromising them through other vulnerabilities"???
If physical access was required, I would have expected that to say "...after gaining physical access to the server".
See the difference?
Re: (Score:2)
So it's impervious, except not since you quoted how it's not impervious to them. Way to disprove yourself.
Exactly what Imwas going to say.
Re:How is this possible? (Score:4, Informative)
Re:How is this possible? (Score:4, Informative)
Time to go back to a.out for system utilities? (Score:5, Informative)
This was actually a contentious issue when the shift to ELF happened back in the 90s on Linux. There was a debate over whether it was better to have fixed binaries that if improperly programmed could have security issues, but were only trojanable if a successful elevation attack took place, or ELF binaries which would allow all sorts of fun relocation features, help cut down on memory usage by making symbols easier to relocate, which could also be used with dynamic address relocation (not actually available on Linux for quite a few more years.) to enhance security by making stack smashing attacks more difficult. But as a big potential downside in regards to ELF files, they allowed library preloading in a manner indistinguishable from normal operation, which is a boon for ensuring future portability of binaries, but a huge bane for system integrity and security.
And now we have an example of that being true at the unprivileged user level. The only thing I am not sure about is if they can escalate privileges, since suid binaries are explicitly supposed to ignore LD_PRELOAD settings to ensure such trojaning doesn't happen.
Re:Time to go back to a.out for system utilities? (Score:4, Informative)
Re: (Score:1)
No it is not. It is a "user-kit". A rootkit serves to retain root-access.
Re: (Score:2)
Indeed. This has probably been discovered 30 years ago by Unix-hackers and then abandoned as boring. Also not a risk to the system, just to the user that was stupid enough to chose a bad password.
Re:How is this possible? (Score:4, Insightful)
You're misinterpreting what they mean by "manually".
Getting malicious code onto a system involves two things: the malicious code (payload), and a means to get code onto a system (exploit). The two are largely orthogonal: any given exploit can be used with a wide variety of payloads.
This rootkit is just the payload; it doesn't include any specific mechanism to get the rootkit onto the system in the first place.
Re: (Score:1)
Re: (Score:2)
No OS is impervious to user stupidity. In fact, for stupid users, Linux is probably less secure than Windows. For users with some clue, Linux is significantly more secure and this distance increases the more competent the user.
It's this.. (Score:2)
The alternate evolution of alureon?
How is this a "rootkit"? (Score:5, Insightful)
On Windows, are malicious DLLs now being referred to as "rootkits" as well?
It's malware, sure.
Re: (Score:2)
Theoretically, the compromised libc syscalls can be used to fire off system requests as if legit admin user was used, which can be used to execute kernel mode software, such as loading a malicious kernel module.
If it can pretend to be the root account, it can do whatever it wants.
Re: (Score:1)
Re:How is this a "rootkit"? (Score:5, Interesting)
It requires root permissions to install and affects anything that isn't statically linked to glibc, libpcap or a few other libs. Since it patches part of the dynloader, it may even affect those if the program links anything dynamically or tries to use dlopen() manually (such as when loading plugins).
What it doesn't bother doing is infecting the kernel itself. glibc and ld-linux.so contain all the hooks in userspace you'll ever need to match Windows-style kernel rootkits.
It sounds like you can only use this kit on an already seriously compromised system, where the attacker has full root access and SELinux isn't getting in the way.
Re: How is this a "rootkit"? (Score:2)
Re: (Score:2)
Re: (Score:2)
Nice libc hack (Score:3)
Re: (Score:1)
Since this is a ilbc hack, it would seem that docker would be a great way to detect this, since you can get a different libc.
Running: `docker run -P -it -v
gives you a root shell under a different libc with all of your filesystems mounted under
This is of course speculation since I assume I don't have the rootkit installed, but it seems pretty straightforward.
Re:Nice libc hack (Score:5, Interesting)
The blog post also seems to imply that you'd need root access to actually install the exploit. In particular: "However, we found that Umbreon also patches the loader library (/lib/x86_64-linux-gnu/ld-2.19.so as an example) to use /etc/ld.so. instead, where is a 7-character-string, matching the length of “preload”."
So, basically, it needs write access to patch a string in ld.so so that it can hijack the preload functionality. Presumably it does this because a lot of distros will use SELinux to prevent access to /etc/ld.so.preload. The basic idea behind this isn't anything new but, it does seem like it does a number of things to prevent detection.
Re:Nice libc hack (Score:5, Insightful)
The blog post also seems to imply that you'd need root access to actually install the exploit
It's not an exploit, it's a rootkit. A rootkit is a tool for retaining undetected access to a compromised system, not a tool for compromising the system in the first place.
Re: (Score:2)
I'm not sure if I'd call it a rootkit (though, my use of "exploit" was wrong too). It's a pretty amusing use of the preload functionality but, it's not so pervasive that it's difficult to remove. Yeah, it could enable serious badness but, it needs a proper exploit to get onto the system. Anything could cause badness after that.
Static Builds? (Score:3)
So this attack is rendered useless if you don't link against libc?
Re:Static Builds? (Score:5, Interesting)
Correct. And in the old days, /sbin was called /sbin because it meant "static binaries." Now even core system utilities like ls are dynamically-linked, which makes attacks like this work.
Re:Static Builds? (Score:4, Interesting)
The root partition also used to be read-only, which was a very good idea for security. These days, tools require write access to /etc and many other places, which makes these kinds of exploits much simpler.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, you are right. But they also were statically linked because they were meant to be used before /usr is mounted.
Wrong title is wrong (Score:1)
Not just misleading, but plain wrong.
It's not a rootkit and it's not Pokemon-themed.
How about: "Linux malware gets named for Pokemon"
Re: (Score:2)
Not just misleading, but plain wrong.
It's not a rootkit and it's not Pokemon-themed.
How about: "Linux malware gets named for Pokemon"
Dammit what am I gonna do with all these t-shirts I had printed!
From TFA, How to... (Score:5, Informative)
How to detect Umbreon:
/usr directory is located; write privileges are required. /etc/ld.so.. /usr/lib/libc.so.. /usr/share/libc.so...*.so and remove them as well. /etc/ld.so.preload again.
Most of the tools you will find in Linux are written in C. Even programs written in Perl, Python, Ruby, PHP and other scripting languages end up calling GNU C Library wrappers as their interpreters are also written in C. Because Umbreon library hooks libc functions, creating a reliable tool to detect Umbreon would require a tool that doesn’t use libc.
One way is to develop a small tool to list the contents of the default Umbreon rootkit folder using Linux kernel syscalls directly. This bypasses any malicious C library installed by Umbreon. If the output contains one or more files with names starting with libc.so followed by a random integer, this is the red flag that suggests Umbreon is installed in the machine.
We have also created YARA rules that detect Umbreon, which can be downloaded here [trendmicro.com].
Removal Instructions
Umbreon is a ring 3 (user level) rootkit, so it is possible to remove it. However, it may be tricky and inexperienced users may break the system and put it into an unrecoverable state. If you are brave enough to proceed, the easiest way is to boot the affected machine with Linux LiveCD and follow the steps:
Mount the partition where the
Backup all the files before making any changes.
Remove the file
Remove the directory
Restore the attributes of the files
Patch the loader library to use
Umount the partition and reboot the system normally.
Re: (Score:1)
Re: (Score:2)
So how would you remove it from an embedded system that doesn't boot from LiveCD?
Obligatory XKCD (Score:3)
The year of Windows desktop (Score:5, Funny)
When will people wake up and say they had enough? Enough of the soo outdated file menus and high color gradients for old people who don't have touch screens and cell phones on their monitors? Enough of no app stores. Enough of too many options and not someone who can make decisions for you on how you use your system?
If only people learned Windows and saw there is an alternative to Linux.
The year of the Windows desktop is almost here where you do not have these rootkit problems .... Oh wait!?
Re: (Score:2)
Dude, that saveie6.com site is the funniest thing I've seen this year.
Re: (Score:1)
Re: (Score:1)
I believe this comment is linked to linux memory footprint.
This is why no one subscribes to PC World anymore (Score:2)
The rootkit uses a trick to hijack the standard C library (libc) functions without actually installing any kernel objects.
This is literally the only interesting part about this announcement and there is jack-all details about how it's doing this. How does this accomplish what it does on Ring 3? I'd imagine that it uses an inline function hook, but I'd like to know for sure.
Rootkit targets Linux-based systems? (Score:2)
"Umbreon is manually installed onto an affected device or server by the attacker."
So, the device has to be already compromised and requires manual installation, nothing to see here
Aha (Score:1)
You just wasted your time writing this, suckers!! Linux is secure by design/default (take ur pick)
Pokemon themed? (Score:1)
How sad when names from an innocent game about child slavemasters running gladiatorial contests are used for something wicked.
Next they'll be using it to encourage loitering, trespassing, and distracted driving. Just you watch.