Slashdot Mirror
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."
The TrendMicro article off-handedly mentions that this malware is installed manually, suggesting physical access to the victim machine is required. This isn't so ridiculous an idea if the victim's machine doesn't have their screensaver set to lock the console (by default, xscreensaver doesn't do this); and if the victim's 'sudo' timeout is sufficiently long (default: 15 minutes).
Editor, A1-AAA AmeriCaptions
It doesn't even need sudo access. It sounds like it does s LD_PRELOAD on libc and then traps any calls that would identify it.
I read the internet for the articles.
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.
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.
Politics; n. : A religion whereby man is god.
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.