CCGI Hacked ?

[#1]

Has anyone else found files they did not upload on the CCGI server "crofters" I have found over 150 files that I did not upload they all seem to be related to Dial tones. I opened a ticket over 24 hours ago (23906929) and was told "I am passing this to our Networks team to try and investigate further for you; please monitor progress of this Question via the Help Assistant." and have not yet had any updates on this issue.
The directories the new folders and files were created in had permissions set to 755 so anyone else shouldn't really be able to upload files to them.
Whatever is placing these files on the server is putting them deep in the directory paths I had to list deep in directories to find them. I am also at a loss to know if I should leave these files on the server for inspection by F9 staff or if I should delete them.

[#2]

Is there anything significant about the file names or folder names - e.g. they all begin with 'fgh' - something that I could search for in my own ccgi area?

[#3]

Quote from: Marteknet

The directories the new folders and files were created in had permissions set to 755 so anyone else shouldn't really be able to upload files to them.

I suspect you've fallen foul of this which can still be a problem irrespective of your permissioning.

[#4]

I have made a copy of the whole of my ccgi area (31MB) to my hard drive.
I have looked at the folder/directory structure and can not see anything that I do not recognise.
Have you any example filenames?

[#5]

Here are a few of the 75 html file names. these seem to be repeated in other directories as well. Directories do not have a common name.

Thanks for looking Tony here are a some file names for you.
alltel-1.html
alltell.html
blackberry-1.html
bollywood-1.html
boost-1.html
boost-2.html
boost.html
boostmobile.html
cheap-1.html
cheap.html
classical.html
composer-1.html
converter-1.html
converter.html
country-1.html
cricket-2.html
free-1.html
in these html files there is escaped javascript that when unescaped shows a url redirect to
"http://noril.info/noru.php?kwa=9&dfkw=alltel&crdt=070101&said=stb07&rf=" + document.referrer;
Thanks for the Info Bob. I will be checking my websites user inputs and make sure every one of them uses some form of input validation for all potentially malicious data. I am fairly sure that this is in place but will be checking it anyway to make sure that the weekness is not in my scripts.
Moderators note by James_H : Made link unclickable

[#6]

Thank you for the filename list. I generally only use .HTM so it was easy to do a search of the area looking for .HTML
It seems that I am not affected.
Have you got any further with finding out how you got this? Searching Google for bits of the unescaped address turns up nothing useful.
As you say, putting some of the filenames into Google confirms that they are ringtone related, but does not give any indication of why they should be in your ccgi area.

[#7]

I suspect these are to do with SPAM emails using my domain www.martek-net.co.uk as the cover domain for a spoofed email address these emails may link to the code on the ccgi server, these in turn redirect to another domain and having followed the trail I find that these again redirect to a final URL.  As for how the files were uploaded I have no definite answer and I am hoping F9 support can supply some info on this. I would then be able to find ways to impede or disable the method these people are using to upload the files.

[#8]

You could look at the creation dates and see if they are recent. They may have been created a long time ago and be no longer a threat.
Also, you could delete them and see if they later appear.
If there any way with the (CHMOD) permissions that they can not be read/overwritten/modified by the perpetrators?

[#9]

Yes that’s how I thought it worked I set the permissions to 755  Owner = read, write and execute: Group = read and execute: World = read and execute:
This should protect the directories from being altered across domains. But as Bob pointed out there may be issues with web page inputs and someone may be priming an input with code that bypasses the cross domain protection. Once the script have been up loaded via the input it may be stored in a sql database or on a dynamic web page and then when called this will then execute the script on the server and hay presto because it is now essentially on the same domain it has full access. Weather the html page with the input is on one of my pages is uncertain, but to be sure I will be taking a look at all my input page routines and make sure that I have code to parse them for script content. Not a small job. I am not too sure if once someone has got access to a users ccgi web space they can access everyone’s web space on the same server but I guess it may be possible. 
I have been contacted by support (24 + hours after reporting) and asked NOT to delete the files. I am still awaiting more feedback from them on this issue.
dates of the files are:
19/11/07
20/11/07
13/12/07
17/01/08
so this is an ongoing thing, I will be looking at my tracking for yesterday (17/1/08) to see if i can find out if there was any unusual traffic on any web pages i own.
I will post any relevant info here as I get it.

[#10]

Quote from: Marteknet

Not a small job. I am not too sure if once someone has got access to a users ccgi web space they can access everyone’s web space on the same server but I guess it may be possible.

No this isn't possible AFAIK (It used to be to a certain degree with the old CGI platform).

Quote

I have been contacted by support (24 + hours after reporting) and asked NOT to delete the files. I am still awaiting more feedback from them on this issue.

I don't hold too much faith that we'll be able to help aside from perhaps pointing out some vulnerabilities in your scripts. Identifying the origin of the attack if it is XSS related is likely to be impossible.

[#11]

Hi Bob, F9 support were a great help in this matter they pointed out to me which script had been used to insert the files on the ccgi web space. I have disabled this and will be looking more closely at any other input routines I have on all my pages. The only let down was the length of time between replies to my ticket or more precisely that there was no acknowledgement from the Network team that they were indeed looking in this when the ticket was escalated.
But all in all they were a great help. Thank Bob for the Info and the link you gave in your earlier post to this thread.