Turla, a Trojan that has infected hundreds of 32- and 64-bit Windows computers at government institutions, embassies, military installations, educational institutions, and research and pharmaceutical companies over the years, has been found on Linux systems, Kaspersky Lab reported.
The company has discovered two variants of the malware running on Linux.
The first is a C/C++ executable statically linked against multiple libraries, which increases the size of its files, Kaspersky Lab said. It was stripped of symbol information, probably to make it more difficult to analyze.
Much of the first module’s code is based on public sources, and its features include hidden network communications, arbitrary remote command execution and remote management.
Kaspersky hasn’t provided details about the second variant.
It has sinkholed the malware’s command-and-control domain.
Turla Trojans originate in Russia and are believed to be government-funded, remarked Rob Enderle, principal analyst at the Enderle Group.
They “are very elegant and extremely easy to place, and incredibly difficult to discover,” he told LinuxInsider. “People haven’t been aggressively looking for them on Linux, and this one raises the question of how many of these things we have missed.”
Nobody’s safe, Enderle suggested.
“Russia has, in the past, gone after other forms of secure information that the government would then share with its own development teams or Russian companies,” he explained. “Even individuals, if they are part of a large firm or the United States government, are potential victims.”
The Elusive Turla
The first Turla sample targeting Linux is based on cd00r, a publicly available proof-of-concept backdoor that has been around for years and can be used for attack or defense.
The backdoor provides remote access to a system without showing an open port all the time, by using a sniffer on a specified interface to capture packets.
Linux Turla maintains stealth without requiring elevated privileges while running arbitrary remote commands, meaning that even if it’s launched by a regular user with limited privileges it will work.
The malware cannot be discovered using netstat, a command-line administrative tool, Kaspersky Lab said.
It uses techniques that don’t require root access, so it can be more freely run on victim hosts.
Turla for Linux requires an ID and an existing network interface name to begin execution. These can be inputted from STDIN or from a dropper launching the sample. Once the process is launched, the backdoor’s process PID is returned.
The C&C mechanism is based on TCP/UDP packets, Kaspersky Lab said.
The Insecurity of Linux
Although Turla previously has not been found on Linux, it is far from being the first malware targeting it.
The OS has been vulnerable to other viruses, Trojans and worms, as well as Web scripts and buffer overruns.
Several antivirus applications check Linux systems for exploits that typically affect Windows users, including Avast, AVG, Avira, BitDefender, F-Prot, F-Secure Linux and Kaspersky Linux Security.
Antivirus applications that look for Linux-specific threats include chrootkit and rkhunter.
The Threat Posed by Linux Turla
The Linux Turla malware could be more dangerous than its Windows counterpart.
Linux “has an inherently better reputation for reliability and security, but results in a ‘black box’ syndrome when used in businesses without adequately trained administrators to properly lock it down, patch it and monitor it,” said Richard Westmoreland, director of security architecture at SilverSky.
“Compromising Linux boxes gives any APT (advanced persistent threat) an advantage, due to this overtrust of non-Windows-based systems,” he told LinuxInsider.
Kaspersky Lab’s sinkholing of the Linux Turla’s C&C domain does not guarantee safety because “the Trojan is designed to make reverse-engineering difficult, so there may be built-in mechanisms to circumvent sinkholing that have not yet been discovered,” Westmoreland warned. “There could also be unidentified variants of this Trojan with different C&C domains.”
A Kaspersky Lab spokesperson was not immediately available to provide further details.
This is why, 11+ years after SELinux became part of the kernel, it’s simply unacceptable that the vast majority of servers/services for Linux will tell you *first thing* to disable SELinux, when by now they should have figured out how to work *with* it.
Any chance anyone can confirm selinux will stop it?