incidents where adversaries installed .htaccess configuration files to redirect visitors to malware distribution sites (for example, 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. When the site owner typed the URL directly into the browser’s location bar, however, the site would load normally, as the Referer header was not set.
The following code is an example of a compromised .htaccess file: 11
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]
In this example, users visiting the compromised site via any of the listed search engines are 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 then return an empty payload on any subsequent visit. We assume this is meant to make analysis and reproduction of the redirection chain more difficult. Attackers also frequently rewrite the .htaccess file to point to
different IP addresses. Removing the .htaccess file without patching the original vulnerability or changing the server credentials will not solve the problem. Many Webmasters attempted to delete the .htaccess file and found a new one on their servers the next day.
TAKING OVER WEB USERS
Once attackers have turned a Web server into an infection vector, visitors to that site are subjected to various exploitation attempts. In general, client exploits fall into two main categories: automated drive-by downloads and social-engineering attacks.
Drive-by downloads. In drive-by downloads, attackers attempt to exploit flaws in the browser, the operating system, or the browser’s external plug-ins. A successful exploit causes malware to be delivered and executed on the user’s machine without the user’s knowledge or consent. For example, a popular exploit we encountered takes advantage of a vulnerability in MDAC (Microsoft Data Access Components) that allows arbitrary code execution on a user’s computer. 8 A 20-line JavaScript code snippet was enough to exploit this vulnerability and initiate a drive-by download.
Another popular exploit is caused by 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 attacker 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, attackers often employ social-engineering techniques to trick users into installing and running malware themselves. The Web is rich with deceptive content that lures users into downloading malware.
References:
Archives