index.php disappears

[avevevend]

Script URL: http://www.megafon.net/ccount/
Version of script: 1.2
Hosting company: proisp.eu
URL of phpinfo.php: http://www.megafon.net/php/phpinfo.php
URL of session_test.php: http://www.megafon.net/php/session_test.php
What terms did you try when SEARCHING for a solution: "ccount index.php missing", "ccount index.php deleted"

Write your message below:
Every night my index.php file simply disappears, so when I enter url for the ccount script, I get a directory listing. I reupload it, but the next day it has vanished again.

Thx in advance for any help.

Andres

[Klemen]

The only reasonable explanation is that your hosting company is deleting it.

Probably a security software on the server removing file because it has this

Code: Select all

eval(gzinflate(base64_decode(

inside.

While the CCount code is not harmful at all, some antivirus programs mark such code as "potential threat" because some PHP hacking scripts are encoded using the same technique.

Check with your host and ask them to exclude the file from being deleted.

[PPduc]

I have exactly the same problem (albeit with a different hosting company). Overnight the index.php file is missing from the ccount folder (version 1.2).

The hosting company is Nativespace.co.uk

When I asked my hosting support why this is happening, after confirming that it is my IP uploading files and running malware diagnostics (Linux Malware Detect v1.4.1) they say;

"Please consult with your developer as the files are valid and does not contain suspicious code."

"I have thoroughly checked the logs but could not found any reason for automatic deletion of file 'index.php'."

"There are no regular cron jobs set for scanning the files on the server which can check for suspicious content and delete it."

"We are unable to find any other reason for index file deletion."

"I cant find any log of the file being removed, what is worrying is that the file seems to have a huge block of base 64 code being eval'ed in it"


Sorry for all the quotes, I thought it might help unravel this problem. Did Avevevend get a successful resolution to this?

These quotes are after I asked for this file to go on their exceptions list and I pointed them to this post as well.

Hope you can help, whilst re-uploading the index.php file every day isn't the end of the world, it does become tiring.

[Klemen]

Looks like the support staff doesn't know what's running on their server. There is no way the file can delete itself, it's being removed by a process on the server.

[ukcheaphosts.com]

We are a webhost and are using Linux Malware Detect v1.5 which automatically quarantines any suspicious looking scripts and we have had a complaint from a client who is using the PHP Click Counter script whereby each night his index.php file in the /out/ folder keeps getting removed.

We have had a look at the script and there is indeed two sections in the "out" script containing "eval, gzinflate, base64_decode" code.

Here is our log from today showing the warning....



Obviously its not possible for us to simply "whitelist/ignore" these files without knowing what these code snippets do or contain and respectfully but frankly, no serious host should, especially on the "say so" of an unknown (again respectfully) developer.

Can you please provide a workaround or explanation for these encrypted snippets of code?

You have my email address inside my profile if you wish to discuss this privately/in confidence..

[Klemen]

Upgrading to the latest version of click counter should fix the issue.

Some parts of code have been rewritten for the exact purpose of avoiding false alerts like these (any competent PHP developer should be able to reverse that code and verify nothing harmful is going on there for you).

[ukcheaphosts.com]

Upgrading to the latest version of click counter should fix the issue. Some parts of code have been rewritten for the exact purpose of avoiding false alerts like these (any competent PHP developer should be able to reverse that code and verify nothing harmful is going on there for you).

Thank you for quick response. I have advised them now to upgrade to latest version.

[Klemen]

Note that you might need to temporarily enable the index.php file for the upgrade process (to allow them to download a database backup).

P.s.: I do understand your concern and also understand that a host cannot manually examine all the scripts they encounter, hence the code rewrite.