PHPJunkyard support forum

Script URL: www.flyalaska.com/ccount
Version of script: 1.0, but now updated to 1.2
Hosting company: Lunarpages.com

ccount is very useful to me and has been a great help in reporting basic stats to my various advertisers and in making text adjustments to increase the hits on some advertisers' websites.

ccount 1.0 which I have had installed on my website since 2004 recently was exploited by some kind of php hacking script which installed a bunch of superfluous files in the ccount folder and then, hidden URLs (search-engine fodder) at the bottoms of most of my website pages which could only be seen by using "view source." This exploitation was apparently implemented as a php hack done through the address bar on my browser.

I have updated to 1.2 but am wondering if any vulnerabilities exists in 1.2 and/or if there are any measures I can take to reduce the possibility of this happening again.

Hi,

I'm not aware of any security issues with neither CCount version 1.0 or the 1.2 one nore have any exploits been reported. Since CCount checks all data before using it the problem could be somewhere else.

I would strongly recommend that you check with your host (or in your raw log files) how they uploaded the "hacking" (shell?) script. Chances are they used some other exploit (which still exists on your server!) to upload files to your server (such shell scripts can list writable files and folder on the server and CCount has 2 writable files (clicks.txt and ids.txt) but to exploit them one would already need to have a shell script on the server). It's possible any files are also in your other folders.

Nevertheless having all the software up to date is an essential part of keeping your server secure.

I have a quick question do you have wordpress on that server? this is the first that comes to mind as many have it. This blog based script is one of the most hacked scripts it seems, and I have found a lot of problems and have seen complete server breaches that were allowed to happen with wordpress, thats not to say that they dont fix and or update it but it does get hacked a lot, and has many dif exploits in many dif versions and must always be checked for its version. Im just tossing that at you in case you do, because maybe that was your breach point.

Who told you that ccount was the breach point? did the host show you logs that document this? if I was you, as Klem said I would really look over the logs very carefully.

I can tell you this I have never heard ccount had a problem and if it did or does it will be addressed but i doubt that this was the entry point, as Klem is very good at keeping his code up to date one instance I remember was older versions of hesk, this was fixed very quickly as soon as a problem was found and documented.

In fact not even a hacking problem, I found a bug in a script which happens and as soon as this was verified it was fixed almost as fast as I reported it.

So theres no Junk here in the Junkyard :-)

DC

In his logs there are a bunch of XSS attempts like this trying to get harmful code: While many support technicians would see this as a red flag and blame the script note that this couldn't have been the entry point as CCount checks each ID before handling it any further and if anything but a number is entered for the ID it throws an error:

Just adding to that.

Ah so you saw the logs? Ok this is good and yes he must know that just because you see attempts made ... many times are just test points "I see this all the time" does not mean that those attemps were a success and yes I saw that in the script you wrote, so a url injection like that would not be a success, however it could be a success with any other script he may have that may not check that our _GET in this case, is infact valid and has ben sanitized as you have done.

DC

Did you change the default names for the log.txt and clicks.txt files.

It makes hacking easier if a script user doesn't bother to change from default filenames.

This can many times be true ... we never want it to be too easy, however I feel its important to make sure that even if you know the names you can't access any dat or txt files directly at all, to me that is best as many do not change the file names.

DC