Hi,
i'm not much afraid of this. I run all servers i take care of with tight 
SELinux policies.
I dont think this poses a threat to a secured server.

Don't get me wrong, i'm not saying i'm a 'master knowing all, afraid of 
nothing' :] I know, i'm not, that's why i've got everything backed up 
and barebone reinstall procedure in place - in case, disaster happens 
(box is hacked, burnt, stolen, 3rd WW started - in this case i also have 
a bottle of whiskey in my stash :D)

And if all this is in vain, then you should at least have a good 
insurance, if your business is really critical.

Biggest threat to any Linux box server (IMHO) is still at the social 
(engineering) level, like exceptions with weak passwords for some 
'special' users, stolen laptops, secretary giving away her pw to any guy 
who says he needs it because he's from IT department .. etc etc :]


-- 
*Karel Lang*
*Unix/Linux Administration*
[log in to unmask] | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz


On 12/09/2014 07:23 PM, Yasha Karant wrote:
> I am attempting to discover the degree of penetration of the following
> compromise methodology into EL systems, particularly SL 6 and SL 7.  I
> apologize for including the actual article in addition to the URL;
> however, if the URL should be compromised or removed, the material is of
> sufficient importance to be retained.  At the moment, I do not have time
> to research this item; however, I suspect that there are subscribers to
> this list who have more detailed information.   There is mention of a
> tool called YARA that will help in the detection (albeit evidently
> neither the quarantine nor removal of the infection) -- has anyone used
> this tool and is it effective?
>
> Yasha Karant
>
> From: https://securelist.com/blog/research/67962/the-penquin-turla-2/
> The 'Penquin' Turla
>
> A Turla/Snake/Uroburos Malware for Linux
> By Kurt Baumgartner, Costin Raiu on December 8, 2014. 7:05 pm
>
> Recently, an interesting malicious sample was uploaded to a
> multi-scanner service. This immediately triggered our interest because
> it appears to represent a previously unknown piece of a larger puzzle.
> That puzzle is "Turla", one of the most complex APTs in the world.
>
> We have written previously about the Turla APT with posts about their
> Epic Turla operations
> <http://securelist.com/analysis/publications/65545/the-epic-turla-operation/>
> and Agent.btz inspiration
> <http://securelist.com/blog/virus-watch/58551/agent-btz-a-source-of-inspiration/> .
> So far, every single Turla sample we've encountered was designed for the
> Microsoft Windows family, 32 and 64 bit operating systems. The newly
> discovered Turla sample is unusual in the fact that it's the *first
> Turla sample targeting the Linux operating system* that we have discovered.
>
> This newly found Turla component supports Linux for broader system
> support at victim sites. The attack tool takes us further into the set
> alongside the Snake rootkit
> <http://www.baesystems.com/what-we-do-rai/the-snake-campaign> and
> components first associated with this actor a couple years ago. We
> suspect that this component was running for years at a victim site, but
> do not have concrete data to support that statement just yet.
>
> The Linux Turla module is a C/C++ executable statically linked against
> multiple libraries, greatly increasing its file size. It was stripped of
> symbol information, more likely intended to increase analysis effort
> than to decrease file size. Its functionality includes hidden network
> communications, arbitrary remote command execution, and remote
> management. Much of its code is based on public sources.
>
> *Md5* 	*Size* 	*Verdict Name*
> 0994d9deb50352e76b0322f48ee576c6 	627.2 kb 	N/A (broken file)
> 14ecd5e6fc8e501037b54ca263896a11 	637.6 kb 	HEUR:Backdoor.Linux.Turla.gen
>
> General executable characteristics:
>
> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
> linked, for GNU/Linux 2.2.5, stripped
>
> Statically linked libraries:
>
>   * glibc2.3.2 - the GNU C library
>   * openssl v0.9.6 - an older OpenSSL library
>   * libpcap - tcpdump's network capture library
>
> Hardcoded C&C, known Turla activity: *news-bbc.podzone[.]org*
> The domain has the following pDNS IP: *80.248.65.183*
>
> 80.248.65.183 aut-num:        AS30982 announcement:   80.248.65.0/24
> as-name:        CAFENET descr:          CAFE Informatique et
> telecommunications admin-c:        YN2-AFRINIC tech-c:
> AN39-AFRINIC org:            ORG-CIet1-AFRINIC mnt-by:
> AFRINIC-HM-MNT mnt-lower:      CAFENET-NOC source:         AFRINIC #
> Filtered
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 11
> 	
> 80.248.65.183
> aut-num: AS30982
> announcement: 80.248.65.0/24
> as-name: CAFENET
> descr: CAFE Informatique et telecommunications
> admin-c: YN2-AFRINIC
> tech-c: AN39-AFRINIC
> org: ORG-CIet1-AFRINIC
> mnt-by: AFRINIC-HM-MNT
> mnt-lower: CAFENET-NOC
> source: AFRINIC# Filtered
>
>
> Note: the C&C domain is currently sinkholed by Kaspersky Lab.
>
>
>     Functional description
>
> The sample is a stealth backdoor based on the cd00r sources
> <http://www.phenoelit.org/stuff/cd00r.c>.
>
> This Turla cd00r-based malware maintains stealth without requiring
> elevated privileges while running arbitrary remote commands. It can't be
> discovered via netstat, a commonly used administrative tool. It uses
> techniques that don't require root access, which allows it to be more
> freely run on more victim hosts. Even if a regular user with limited
> privileges launches it, it can continue to intercept incoming packets
> and run incoming commands on the system.
>
>
>       Startup and Execution
>
> To start execution, the process requires two parameters: ID (a numeric
> value used as a part of the "magic packet for authentication") and an
> existing network interface name. The parameters can be inputted two
> different ways: from STDIN, or from dropper a launching the sample. This
> is NOT a command-line parameter, it's a real prompt asking the attacker
> user to provide the input parameters. After the ID and interface name
> are entered and the process launched, the backdoor's process PID is
> returned. Here is a screenshot of this simple interface:
>
> Penquin_2
>
> While there is no initial network callback, a section of code maintains
> a hardcoded c2 string "news-bbc.podzone[.]org". This fully qualified
> domain name was first set up in 2010, suggesting that this binary is
> fairly recent in the string of Turla campaigns. Also, while we haven't
> seen additional file download activity from this server by this tool, it
> likely participated as a file server of sorts.
>
>
>       Magic Packets for Remote Command Execution
>
> The module statically links PCAP libraries, and uses this code to get a
> raw socket, applies a filter on it, and captures packets, checking for a
> specific condition (the *original cd00r first used this method, based on
> ports and SYN-packets). This condition is expressed here (it is based on
> the ID value input at startup by the attacker):
>
> ID = 123 Filter = (tcp[8:4] & 0xe007ffff = 0xe003bebe) or (udp[12:4] &
> 0xe007ffff = 0xe003bebe) ID = 321 Filter = (tcp[8:4] & 0xe007ffff =
> 0x1bebe) or (udp[12:4] & 0xe007ffff = 0x1bebe)
>
> In simple terms, it checks for an ACK number in the TCP header, or the
> second byte from the UDP packet body.
>
> If such a packet is received and the condition check is successful,
> execution jumps to the packet payload contents, and it creates a regular
> socket. The backdoor handles this socket as a file with read/write
> operations. It's not the typical recv/send used in this code. It uses
> this new socket to connect to the source address of the "magic packets".
> Then it reports its own PID and IP to the remote address, and starts an
> endless loop for receiving remote commands. When a command arrives, it
> is executed with a "/bin/sh -c " script.
>
> Further analysis of the sample's functionality will be updated here.
>
>
>     Conclusions
>
> Although Linux variants from the Turla framework were known to exist, we
> haven't seen any in the wild yet.
>
> This specific module appears to have been put together from public
> sources with some added functionality from the attackers. Some of the
> malicious code appears to be inactive, perhaps leftovers from older
> versions of the implant. Perhaps the most interesting part here is the
> unusual command and control mechanism based on TCP/UDP packets, as well
> as the C&C hostname which fits previously known Turla activity.
>
> The discovery of this Turla module rises one big question: how
> many other unknown Turla variants exist?
>
> *Update:* Since the publishing of this blogpost, we have discovered
> another Linux Turla module, which apparently represents a different
> malware generation than the previously known samples:
>
>  From another URL:
>
> http://arstechnica.com/security/2014/12/powerful-highly-stealthy-linux-trojan-may-have-infected-victims-for-years/
>
> Administrators who want to check for Turla-infected Linux systems can
> check outgoing traffic for connections to news-bbc.podzone[.]org or
> 80.248.65.183, which are the addresses of known command and control
> channels hardcoded into the Linux trojan. Admins can also build a
> signature using a tool called YARA <https://plusvic.github.io/yara/>
> that detects the strings "TREX_PID=%u" and "Remote VS is empty !"
>