HTML Iframe-inf

[system]

when people go to log onto my site AVAST blocks them and gives this:
File name: hxxp://fostermountain.net
Malware name: HTML:Iframe-inf
Malware type: Virus/Worm
VPS version: 100208-0, 02/08/2010

This has been going on for nearly a year. I researched the Iframe-inf stuff found examples of it on the web.
My web site is clean as I have stated over and over again in emails to AVAST. I have even deleted my web site data and
reloaded the site.
Whats your problem? Why will you not update your data base? If you think I have this virus/worm then show it to me.
As I have said, I have send you many many requests to do something about your database, it’s very apparent that you don’t look at the site content because if fires off it’s blocking message when I delete all coding from the site.

[system]

Hi tickedoffuser, welcome to the forum

Could you please modify your link to make it unclickable (i.e. chage http to hXXp) to prevent others potentially becoming infected.

This kind of detection is very common these days, with many ‘legitimate sites’ becoming hacked to distribute malware:

Every 3.6 seconds a website is infected

Unfortunately it would appear that the site has been hacked. That page contains a hidden iframe that links to a site that is known to host malware.

http://www.UnmaskParasites.com/security-report/?page=fostermountain.net
http://www.google.com/safebrowsing/diagnostic?site=warpiln.net

---

A post worth reading by DavidR

@DavidR post:2

Actually cleaning the file is not going to resolve why you got hacked it will only clean the file (well avast doesn’t clean the file just alerts to it, you have to find and strip out the injected code) and not the cause, you need to contact your host, see below.

– HACKED SITES - This is commonly down to old content management software being vulnerable, see this example of a HOSTs response to a hacked site.

We have patched up the server and we found a weakness in PHP which was helping aid the compromise of some domains. We updated it, and changed some default settings to help prevent these coding compromises. The weaknesses were not server wide but rather just made it easier on a hacker to compromise individual end user accounts.

I suggest the following clean up procedure for both your accounts:

1. check all index pages for any signs of java script injected into their coding. On windows servers check any “default.aspx” or
   “default.cfm” pages as those are popular targets too.

2. Remove any “rouge” files or php scripts uploaded by the hackers into your account. Such scripts allowed them to make account wide
   changes, spam through your account, or spread their own .htaccess files through all of your domains in that end user.

3. Check all .htaccess files, as hackers like to load re-directs into them.

4. Change all passwords for that end user account. The cp password, the ftp password, and any ftp sub accounts. Make sure to use a
   “strong” password which includes upper case, lower case, numbers and NO COMPLETE WORDS OR NAMES!

This coupled with our server side changes should prevent any resurfacing of the hackers efforts. In some cases you may still have coding which allows for injection. All user input fields hidden or not should be hard coded, filtered, and sanitized before being handed off to php or a database which will prevent coding characters from being submitted and run through your software.

Also see, Tips for Cleaning & Securing Your Website, http://www.stopbadware.org/home/security.

[DavidR]

• Please ‘modify’ your post change the URL from http to hXXp or www to wXw, to break the link and avoid accidental exposure to suspect sites, thanks.

Sorry but it looks like your site may have been hacked (unless you know about this iframe), there is a hidden iframe tag outside of the closing HTML tag, a standards no, no and highly suspicious, see image (I have broken the single line to show in the image.

avast is not alone in considering that page infected, http://www.virustotal.com/analisis/30f47cfba4eea4d30009ca0b907162b1e37ae0f444eb8a66ec6d55c51a1f74d5-1265646996.

[system]

David, how do you grab the tmp file? On my system it is gone before I can refresh explorer to see it ???

[DavidR]

I have sent you an IM Scott.

[system]

Thanks David

[system]

Ok, I was wrong. I have egg on the face… Yuck. :-[

I had been looking at my html files that I wrote and unloaded to the site.

David I saw the size of the size you linked to and it showed a small html that couldn’t be right.
It wasn’t and it wasn’t mine. Thank David.

For anyone else. You may what to see if you have a “at-domain” html file in your system.

Thanks for the help.

[DavidR]

No problem, glad I could help.

Welcome to the forums.

[system]

Quite often we’re seeing these iframes injected as a result of a virus on a PC with FTP access to the infected website.

The virus works by stealing the FTP login credentials from the PC, especially if the PC is using Filezilla which stores all FTP credentials in a plain text file. The virus sends the FTP credentials to a server which then infects whatever websites it has access to.

So, just cleaning the file and updating the CMS software, etc. won’t necessarily keep the website clean. Changing FTP passwords won’t either because the virus will just steal it again. We’ve seen this over and over again.

You have get rid of Filezilla (Unmaskparasites has a great article on this issue: http://blog.unmaskparasites.com/2009/09/23/10-ftp-clients-malware-steals-credentials-from/ and use FTP that encrypts the stored usernames and passwords. In this instance, even changing from FTP to SFTP or FTPS won’t help as quite often the hacker’s server is logging in using valid credentials.

The hackers also like to install backdoors so when you clean and remove the virus that steals FTP passwords, the hackers can still infect the website.

Often times we’ve seen code that contains: eval(base64_decode in .php file. It’s usually found at the top or the very bottom of the .php file. Often times this code is used to remotely inject malscripts into websites. Other times we’re seeing a variety of Perl files used to reinfect websites.

Just thought you’d like to know…