The case for AV for Linux: Linux/Rst-B

2008-08-01

Billy McCourt

Sophos, UK
Editor: Helen Martin

Abstract

A high prevalence of Linux/Rst-B seen recently on hacked Linux boxes is not due to ingenious spreading mechanisms or Linux users swapping binaries, but due to a proliferation of infected hacking tools. Billy McCourt has the details of this real, in-the-wild Linux threat.


In February, researchers at SophosLabs noted that Linux/Rst-B seemed to be very common on hacked Linux boxes [1]. The prevalence of this particular virus is not due to ingenious spreading mechanisms or Linux users swapping binaries, it is due to a proliferation of infected hacking tools. The fact that the virus replicates equally well on older and newer kernels will have added to its longevity – a characteristic that isn’t always found in other Linux viruses.

Linux/Rst-B

We became interested in Linux/Rst-B when we noticed that around 70% of executable files downloaded to one of our honeypots were infected. Underneath the Linux/Rst-B infection were various tools such as flooders, SSH scanners and, more often than not, an IRC bot.

A particularly interesting feature of Linux/Rst-B is that it attempts to download a page from a specific IP address if it is executed as root. The Ethereal screenshot in Figure 1 shows the request being made to 207.66.xxx.xxx/~telcom69/gov.php.

Figure 1: Request being made to 207.66.xxx.xxx/~telcom69/gov.php.

Figure 1. Figure 1: Request being made to 207.66.xxx.xxx/~telcom69/gov.php.

This call-home technique provides the opportunity to assess the number of Linux/Rst-B root-compromised Linux boxes in the real world. The call home IP address falls under the control of Accretive Networks, who kindly agreed to assist us with our research.

Data tracking

Since the beginning of May, we have had the call-home IP address hooked up to a web server and connection attempts to the specific URL have been logged. From this data, we can cross-reference the infected IP address with WHOIS data to find out details such as the country and company of an infected host. The data presented in this article is based on roughly five weeks’ worth of logs.

One of the first sets of statistics that we generated was the number of infections by country. We take a single instance of each IP address that has called home and look up which country it came from:

CountryUnique infected IPs
USA1,271
China622
Germany428
Brazil389
Taiwan264
Korea247
France240
Italy212
India209
Poland176

Table 1. Number of infected IPs by country.

This data helps to show that this is a global problem. When these statistics were generated there were IP addresses from over 125 different countries calling home.

Figure 2 highlights that Europe is pretty badly hit. Each red marker represents a single IP address.

Location of infected IP addresses.

Figure 2. Location of infected IP addresses.

Another way to look at the data is to examine the frequency of each IP address calling home. Table 2 shows the most common IP addresses calling home. This is an interesting result since it allows us to monitor activity tied to specific hosts. The most common call home attempts were made by computers in Germany. (Note that the first two IP addresses were from the same provider so could really be considered as a single IP address with a total of 28,748 hits.)

IP address IDCountryCount
62.93.xxx.xxxGermany21,877
62.93.xxx.xxxGermany6,861
216.147.xxx.xxxUSA5,498
75.26.xxx.xxxUSA1,748
206.191.xxx.xxxCanada838
62.141.xxx.xxxGermany749
66.175.xxx.xxxUSA649
88.146.xxx.xxxCzech Republic505
59.175.xxx.xxxChina381
65.163.xxx.xxxUSA152

Table 2. The most common IP addresses calling home

It would be nice to assume that these figures are the number of infected machines but it is clearly not that straightforward (due to computers behind NAT gateways etc. where many computers will be represented by a single IP address). Also, whilst a server that is never turned off will only ever call home once, a computer that is rebooted daily will call home after each reboot (assuming appropriate binaries have been infected, but this is a fair assumption if the virus has been executed as root).

Germany therefore may simply have more Linux computers being used as workstations and being rebooted frequently. However, even if we assume that every machine is booted up at least once a day, this still suggests that there are over 750 root-infected machines sitting behind two IP addresses alone.

It is also important to remember that we can only gather statistics for root-compromised computers. Our honeypots show that hackers are happy to gain access to standard user accounts (we don’t allow root to SSH in) – only a tiny percentage of attackers have downloaded and executed a root exploit before downloading their other tools. From this we can safely assume that the actual number of infected Linux boxes is far higher than our results suggest.

AV for Linux?

Hopefully every Linux AV scanner is able to detect Linux/Rst-B. It has been around for over six years and, according to our research, it is the virus you are most likely to encounter as a Linux user. Simply running an on-access scanner would prevent most hacking attempts from achieving anything destructive. Whilst on-access scanners don’t address any underlying security issues (weak passwords, vulnerable web applications etc.) they should at least make you aware of hacking attempts without major damage being done.

Unfortunately, it is probably only script-kiddie-level hackers that use hacking tools infected with Linux/Rst-B. Hackers with financial motivation will no doubt be more meticulous with their choice of tools, providing more of a challenge for AV vendors to detect proactively.

We chose to investigate this particular virus partly due to its call-home feature (it gives a fairly accurate picture of real-world infections), but also since it is a real, in-the-wild, Linux threat. The longevity of these infections indicates that system administrators are not even running on-demand scans or file integrity checkers, despite appropriate tools being readily available on many common distributions.

It doesn’t take much searching to find a Linux zealot claiming that malware is only a Windows problem – hopefully these figures will make users reconsider their approach to Linux security.

Bibliography

[1] Botnets, a free tool and 6 years of Linux/Rst-B. http://www.sophos.com/security/blog/2008/02/ 1062.html.

[2] Accretive Networks. http://www.accretive-networks.net/.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.