My amount of concern depends upon just what this infection can do --
including transmission of sensitive data and/or a root compromise.
From your response, are you assuming a separate stand alone hardware
firewall that is filtering all traffic to the server, or an application
running on the server?
Yasha Karant
On 12/11/2014 06:09 PM, Paul Robert Marino wrote:
> If you are really worried about this put a "web application firewall"
> in front of your server in other words a squid reverse proxy which
> tests the inbound data through a filter application, or if you are
> really brave you can try in line snort in iptables.
>
> I would personally love to see an inline implementation of snort
> hooked into squid instead of iptables.
>
>
>
> -- Sent from my HP Pre3
>
> ------------------------------------------------------------------------
> On Dec 10, 2014 5:16 AM, Karel Lang AFD <[log in to unmask]> wrote:
>
> 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 !"
> >
|
