BlueHost Server Problem

Avast Free Antivirus / Premium Security
1

I’m developing a web site for a customer, which is housed on BlueHost.

A number of pages don’t yet exist, but have links to them. If I click on such a link, Avast! 4.8 Home Edition. Build 4.8.1335, intercepts the normal `page not found’ message. On my browser screen, instead of the error message, I get a pop-up from Avast!, stating that the page (which is not even on the server) is infected with JS:Bulered (Trj).

As an experiment, a few minutes ago I paused the Avast! Web Shield; when I did that and clicked on the same link that had stated the page was infected, I got the expected message that the page was not found on the server.

What do I need to do to fix this, problem, which has existed through the past several days’ Avast! updates? I still have a few pages on my own ISP’s server, and when I click on a link to a non-existent page on my ISP, I get the expected `file not found on server’ message, rather than the interception from Avast!

[A few minutes later]
I suppose someone might want some very “minor” further information, which happens to be http://patrickallenmohnphotography.com/

2

Can you give the full path that avast is alerting on so we don’t have to go looking, note the comments #### below. Check the avast! Log Viewer (right click the avast ‘a’ icon), Warning section, this contains information on all avast detections. C:\Program Files\Alwil Software\Avast4\ashLogV.exe - Or check the source file using notepad C:\Program Files\Alwil Software\Avast4\DATA\log\Warning.log

When posting URLs to suspect sites, change the http to hXXp so the link isn’t active (clickable) avoiding accidental exposure.

3

Update - OK I believe I have found your problem the 404 page has been hacked and it is that which is causing the alert.

There is a huge chunk of obfuscated javascript after the closing html tag, a standards no, no, so I guess you didn’t put that there. It is on a single line which I have broken down so it can bee seen easier in the image1.

You also don’t have a favicon.ico file (or it has been deleted) which browsers try to find and display in the address bar and that too triggers the custom 404 error page, image2.

So it looks like your site has been hacked as I mentioned in my first post.

4

DavidR: Thanks much.

A few days ago, some of my .html files had been hacked. I had to figure out how to get to them on the BlueHost server, which I’d never done before. In talking with TechSupport at BlueHost, the support person did say that a number of their sites were having problems.

It did not occur to me to look at the 404 file; in fact, until a moment ago, I did not even notice that such files were in my BlueHost domain. The 400s and the one 500 all had been attacked. I just looked againat my own domain: There are no other files, such as 404 files, there; apparently my ISP handles this differently than does BlueHost. Thus, until you raised the issue, not expecting to see those files there, I had simply ignored their existence in the BlueHost domain.

I knew that the problem was not with the files on my computer, which were all clean and which, until several days ago, had been on my ISP’s server for development and testing purposes, and had never had a single trojan/virus problem. (Yes, I had been getting errors about an .ico file, which has never existed on the site, nor on my test site, nor locally; I have wondered what that error was about, too.)

This is the first time I’ve ever had a single file attacked on a server. While I don’t do a large amount of web programming, I have been doing some since around 1993 or so, when I created what I believe was the first-even fire-service related web site.

Ironically, earlier today I had sent an e-mail to the photographer, saying that I was cerrtain that BlueHost was sending some improper data, but that I had no idea from where it was actually arising. You found it, for which I again express my appreciation.

I’ve had enough frustration creating this site: Learning new programming skills, trying to decipher the mysteries of PayPal, dealing with the photographer (who is quite talented) but has no understanding of computers, html, etc.; to have files hacked on BlueHost certainly has not helped.

Earlier today, I was trying to figure out why the one order page that I’ve posted on BlueHost (my development page, waiting–and waiting and waiting…–for the photographer to come up with the rest of his shipping costs) was generating a certificate error on IE7 (never saw this with Firefox). Turned out that the cause was a 1x1 image from PayPal that they use for internal auditing! Still waiting for someone on the PayPal developer forum to explain, if possible, why this should be happening, but have read that the code for the .gif is optional.

There, that should suffice for complaints, gripes, whining, grousing, moaning, at least for a few minutes, so I’ll conclude by again expressing my sincere appreciation for assisting this medieval historian/teacher/coach/fire chief with a bit of arcania of the Internet.

5

You’re welcome.

It can be a bit of a pain in the rear finding this type of thing as normally it is all pages hacked, but some are a little more sneaky using the custom pages, like the 404 error page in combination with deleting the favicon.ico file to trigger it, but because you hadn’t yet completed the site other missing pages would trigger it.

If you use any content management software (PHP, WordPress, SQL, etc.) on the site you should ensure that it is up to date as old versions can be vulnerable to attack/exploit. You should also consider changing any password/s for ftp, content management control panel, etc. just in case these might have been captured.

  • 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.