Pokemon-Themed Umbreon Rootkit Targets Linux Systems On ARM and x86 (pcworld.com)

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

Comments

How is this a "rootkit"?

[93 Escort Wagon]

On Windows, are malicious DLLs now being referred to as "rootkits" as well?

It's malware, sure.

Re:How is this a "rootkit"?

[Anonymous Coward]

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.

Time to go back to a.out for system utilities?

[Anonymous Coward]

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.