Asprox case, yields SQL code similar to the snippet shown in Figure 1. The decoded payload searches the Web server folders for unicode and ASCII files and injects an IFRAME or a script tag in them. The injected content redirects the Web site users to Web servers controlled by the adversary and therefore subjects them to direct exploitation.

We monitored the Asprox botnet over the past eight months, and observed bots getting instructions to refresh their lists of the domains to inject. Overall, we have seen 340 different injected domains. Our analysis of the successful injections revealed that approximately six million URLs belonging to 153,000 different Web sites were victims of SQL injection attacks by the Asprox botnet. While the Asprox botnet is no longer active, several victim sites are still redirecting users to the malicious domains. Because bots inject code in a non-coordinated manner, many Web sites end up getting multiple injections of malicious scripts over time.

Redirections via .htaccess. Even when the Web pages on a server are harmless and unmodified, a Web server may still direct users to malicious content. Recently, adversaries compromised Apache-based Web servers and altered the configuration rules in the .htaccess file. This configuration file can be used for access control, but also allows for selective redirection of URLs to other destinations. In our analysis of Web servers, we have found several incidents where adversaries installed .htaccess configuration files to redirect visitors to malware distribution sites, for example, to fake anti-virus sites as we discuss later.

One interesting aspect of .htaccess redirections is the attempt to hide the compromise from the site owner. For example, redirection can be conditional based on how a visitor reached the compromised Web server as determined by the HTTP Referer header of the incoming request. In the incidents we observed, the .htaccess rules were configured so that visitors arriving via search engines were redirected to a malware site. However, when the site owner typed the URL directly into the browser’s location bar, the site would load normally as the Referer header was not set.

Figure 2 shows an example of a compromised .htaccess file. In this ex-

figure 1. A decoded snippet of the SQL injection query sent by Asprox bots. ¹³

DECLARE @T VARCHAR(255),@C VARCHAR(255)

DECLARE Table _ Cursor CURSOR FOR SELECT a.name, b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype=’u’ AND (b.xtype= 99 OR b.xtype= 35 OR b.xtype=231 OR b.xtype=167) OPEN Table _ Cursor FETCH NEXT FROM Table _ Cursor INTO @T,@C WHILE(@@FETCH _ STATUS=0) BEGIN EXEC(‘UPDATE [‘+@T+’] SET [‘+@C+’]=RTRIM(CONVERT(VARCHAR(4000),[‘+@C+’]))+””’) FETCH NEXT FROM Table _ Cursor INTO @T,@C END CLOSE Table _ Cursor DEALLOCATE Table _ Cursor

 

ample, users visiting the compromised site via any of the listed search engines will be redirected to http://89.28.13.204/ in.html?s=xx. Notice that the initial redirect is usually to an IP address that acts as a staging server and redirects users to a continuously changing set of domains. The staging server manages which users get redirected where. For example, the staging server may check whether the user has already visited the redirector and return an empty payload on any subsequent visit. We assume this is meant to make analysis and reproduction of the redirection chain more difficult. Adversaries also frequently rewrite the .htaccess file to point to different IP addresses. Removing the .htaccess without patching the original vulnerability or changing the server credentials will not solve the problem. Many Web masters attempted to delete the .htaccess and found a new one on their servers the next day.

Taking Over Web Users. Once the adversaries have turned a Web server into an infection vector, visitors to that site are subjected to various exploitation attempts. In general, client exploits fall under two main categories: automated drive-by downloads and social engineering attacks.

Drive-by downloads. In this category, adversaries attempt to exploit flaws in either the browser, the operating system, or the browser’s external plugins. A successful exploit causes malware to be delivered and executed on the user’s machine without her knowledge or concent. For example, a popular exploit we encountered takes advantage of a vulnerability in Microsoft Data Access Components (MDACS) that allows arbitrary code execution on a user’s computer. ⁷ A 20-line Javascript code snippet was enough to exploit this vulnerability and initiate a drive-by download.

Another popular exploit is due to a vulnerability in Microsoft Windows WebViewFolderIcon. The exploit Javascript uses a technique called heap spraying that creates a large number of Javascript string objects on the heap. Each Javascript string contains x86 machine code (shellcode) necessary to download and execute a binary on the exploited system. By spraying the heap, an adversary attempts to create a copy of the shellcode at a known location in memory and then redirects program execution to it.

Social engineering attacks. When drive-by downloads fail to compromise a user’s machine, adversaries often employ social

figure 2. A snippet from the .htacsess file of a compromised Apache server. ¹¹

RewriteEngine On

RewriteCond %{HTTP _ REFERER} .*google.*$ [NC,OR] RewriteCond %{HTTP _ REFERER} .*aol.*$ [NC,OR] RewriteCond %{HTTP _ REFERER} .*msn.*$ [NC,OR] RewriteCond %{HTTP _ REFERER} .*altavista.*$ [NC,OR] RewriteCond %{HTTP _ REFERER} .*ask.*$ [NC,OR] RewriteCond %{HTTP _ REFERER} .*yahoo.*$ [NC] RewriteRule .* http://89.28.13.204/ in.html?s=xx [R,L]

APriL 2009 | voL. 53 | no. 4 | communicAtionS of the Acm

45