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

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

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

Started by htgguy, April 06, 2008, 10:04:11 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Llama8668

I only run three stock scripts on the pages. Coppermine, cutenews and invision powerboard. The first directory which when down had all three. The second one had only Coppermine and Invision are running.

Is the best course of action to turn the gallery off (or simply redirect all traffic through .htaccess) until there's a patch (this hack is effecting a lot of files as it hits all PHP files on the site)?

Also how malicious is the code that's injected (it loads boxes only is that due to the file not working correctly or is it being included on pages as planned)? Could it be simply waiting to reach a large number of infected pages and then be turned on (to distribute a virus or something)?

marian

Quote from: Llama8668 on April 10, 2008, 04:52:18 AM
So is this definitely a Coppermine issue (and if so is it worth disabling it until a fix is found
That is the real question. Without the answer how does one stop it happening again?

jo1985

Hi, I've had a look through help files and such but can't seem to find anything that'll help me out. My problem is quite involved. Firstly I logged onto my site earlier and found that the extremely annoying 'cdpuvbhfzz' hack has attacked all the php files on my server after a google search I found this thread (http://forum.coppermine-gallery.net/index.php?topic=51671.msg250202) and decided to upgrade as was sugested. Then as I was uploading the new files about half way through my FTP just kept saying "File Error" and now won't let me upload anything to that server (my others are fine). So I manually finished the upgrade but now all I get is a blank page, no matter what I do. I checked the index.php file source and all there is is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>
<BODY></BODY></HTML>

I downloaded my entire gallery a few months ago and have kept my copy updated so I tried to put the code back into the index.php but when I save it and then re-open it the coding is gone again. So now I'm stuck, can't use FTP, can't update the files and haven't got a clue.

I'd really appreciate any help since my gallery have over 3000 pictures in it and I'd hate to have to start from scratch uploading them again.

shiftsrl

Quote from: Nibbler on April 09, 2008, 03:48:16 PM
Question for the affected: Do you all have URI uploads enabled?

This shit happened again with the only difference that this time the 142739_298w3 file is not present on the directory indicated /userpics/1001/142739_298w3.jpg. I'm the admin of my gallery and the only one that can upload. in any case I had URI upload enabled for the administrator and I've disabled it.

Let us all know of any patch to avoid this...

Thanks
Shift Srl
*Link Removed*

Hein Traag

Behind the scenes work is underway to get this fixed. In the mean time disable URI uploads as Nibblers suggests.

Jon F


Craig Walsh

QuoteWhat we could use is a report from someone who was already running cpg1.4.16 (and only coppermine) on his webspace before the infaction happened.

I had a problem yesterday with intermediate (mid-size images) not displaying properly.  Turns out the solution to this was to simply shut off the EXIF data display --- which I did.  This is in a separate forum posting.

As part of trying to figure out the mid-size image problem, I realised I hadn't updated the gallery to 1.4.16 (I was running 1.4.12).  I updated successfully to 1.4.16 yesterday afternoon, UK time, and all was well.  Once I turned off the EXIF data display, the website --- www.bark.ch --- seemed to be working perfectly.

I woke up this morning with Kaspersky growling at me.   Seems that when I try to go to www.bark.ch with IE7 I get what Kaspersky says is "Trojan-Downloader.Java.OpenStream.c."  Kaspersky also mentions ..//cdpuvbhfzz.com/dl/loadereadv598.jar/Matrix.cl and ..//cdpuvbhfzz.com/dl/java.jar/GetAccess.class

It seems that our CPG site has been hacked.  And we were running 1.4.16 at the time, and the only thing we have on the www.bark.ch domain is CPG.  This, however, runs on a dedicated Linux server with our other websites, which include other CPG galleries (all fine --- so far), and some BB's (also fine).

As I'd installed 1.4.16 yesterday, it was quite easy to find files that had been amended since the update.  I removed these files from our server, and I saved them --- safely --- in a folder on my workstation.  I can zip them up and attach them here if they'd be helpful.

I then proceeded to re-install 1.4.16, as I'd done yesterday.  It seems to have installed an updated correctly --- no warning signs or other flags.  But the problem is still there when trying to view the site with IE.

As we have a managed server, I've contacted our hosting company and they are in the process of trying to track this down for me.

I'm afraid that much of the intricate workings of CPG and PHP are over my head --- which is why, at least with PHP, we rely upon the folks who manage our server. 

If I can help in any way, please let me know.  I'll also continue to watch this posting to see if others have been able to solve this problem --- and find a way to prevent it from happening again.
Craig Walsh
CPG Photo Gallery - www.bark.ch
Member of the Association of Photographers (AOP)

Hein Traag

Craig , don't forget to follow up on Nibblers advice of disabling URI upload possibility. And thanks for the post.

Craig Walsh

Thanks for that.  I had already (this morning) disabled the URI upload possibility.

Now waiting for our server people to see what they can find --- and/or the folks here who are working on this. 

Craig Walsh
CPG Photo Gallery - www.bark.ch
Member of the Association of Photographers (AOP)

sharpo

May not be relevant, but thought I would mention it just in case. I am with the same host as the original poster - 1&1 (in the UK)
Sharpo (not an expert, just a Coppermine user)
3 live galleries, first started in 2006.
http://www.sharpos-world.co.uk/BB3cpg/ with over 8,000 images.
http://www.sharpos-world.co.uk/cpg/ with over 25,000 images. 1.6.25
http://www.sharpos-world.co.uk/kc/ with over 300 images. 1.6.25

Llama8668

Would it be possible to get instuctions on how to disable URI uploads (is it just a case of setting the upload slots to 0?) and is that enough to stop the hack?

Is it possible to prevent the mass writing of files if the script is run (re uploading the coppermine folder isn't too much of a hassel but the writing of code to hundreds of files outside of the gallery folder is a nightmare). Is there anyway to automate the removal of code from the files in a similar automated way?

For the moment I've got a .htaccess redirect on all gallery scripts (so anyone hitting the /gallery/ directory is pointed back to the root). Is that enough to stop the hack. Is it overkill for the problem (ideally I'd like to have the galleries at least accessible whilst a patch is found).

If it helps I get similar trojan errors from the bach.ch site when viewing it in IE7 (the follow is the output from the AV. The source code shows the iframe still present at the top of the site.

j_taubman


What I have done is

Added a php.ini to the gallery directory,  using the openbase_dir option to lock scripts in that directory to that directory and below.

I also did the same for all my other products.  I think the effectiveness of this will depend on the ISP allowing extra php.ini files, you can check by using the phpinfo option in Coppermine to check if it's picked up.

To disable URI uploads the only place I could find was the Groups Panel in the Admin menu.   

Nibbler

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

You should not have your entire website writable by PHP scripts if you can avoid this. Coppermine only needs certain things writable, other apps are the same.

Note that the cause is known and the fix has been identified so there is no need to post random bits of helpful information or code. It's just cluttering the thread which is long enough already.

Llama8668

The problem is that I'd need step by step instructions as to how to tidy things up (for example effected files are chmod to 644 so would preventing writing be done by switching register_globals off?). I guess this doesn't matter if it's being patched but the impact of the hack suggests that myself and others might not have setup directories and files correctly.

I know that coppermine is freeware and the problem may have been identified by coppermine admins, but this code is being served on hundreds of pages (there's several in here that have reported being affected) so if it targets site visitors it'd be nice to get an official note as to what and how (even if it's not it'd be nice to get an understanding of wether this is a coppermine issue alone or if it's effecting other PHP scripts and code).


Imko

I have the same issue since last night. We have been hacked as well and besides only the Coppermine php files it has infected all php files on the server including our WordPress installation. I hadn't made a database backup in a long time which is extremely stupid. I wanted to know if it would hurt to backup the database right now with the php files on our server being infected. Or does this virus also infect the Mysql databases? Our host, which is GoDaddy.com told us they could fix our website from one day earlier but they will charge us $150 us dollar. Is that normal?

I have no idea on how to get this mess sorted out and cleaned up by myself.

darkpollo

Quote from: Nibbler on April 10, 2008, 01:46:43 PM
Disable uploading on the groups page. You should disable uploading completely for untrusted users (anonymous + unverified registrations) to be safe until the next version is released.

I had disabled uploading on my site when this happens, but i had not the last version of cpg instead...
Just to help.
I have updated to the new version and close the folder on the server until a fix is founded.
Thanks.


Imko

I just found out that 'debugger.inc.php' is the only file not affected with the virus. I am probably late on this but I thought I'd report it.

Nibbler

That's deliberate. If the malware were appended there the gallery would break.

marian

Quote from: Craig Walsh on April 10, 2008, 11:49:53 AM
I had a problem yesterday with intermediate (mid-size images) not displaying properly.  Turns out the solution to this was to simply shut off the EXIF data display --- which I did.  This is in a separate forum posting.
We had the same problem but EXIF was already off. In our case it was being caused by the intermediate pic size having been changed to 1 pixel. We changed it back to 600 and all is well in that respect.

mentalist3d

Quote from: j_taubman on April 09, 2008, 12:48:36 PM
I probably get in trouble for posting this,  but I thought I might be able to help someone, I was running 1.4.13,  so I am not asking for help, just to help others in my situation.

If you get the damage to your files, what I did was the the script posted earlier and modified it to remove the last line of any affected files.    Please note it worked for me, but I have no idea if it will cause any additional problems.

killorcure.php

<?php 
function fileExtension($file) {
    
$fileExp explode('.'$file);
    
$filetype $fileExp[count($fileExp)-1];

return $filetype;
}

function 
parse($path) {
$dir_array = array();
if ($handle opendir($path)) {
while (false !== ($file readdir($handle))) { 
if ($file != "." && $file != "..") { 
$try_dir $path.$file.'/';
if(is_dir($try_dir)) {
array_push($dir_array$try_dir);
}
else {
if ($path[strlen($path)-1] != '/') {
$path.= '/';
}
$f_ext fileExtension($file);
if($f_ext=="php" || $f_ext=="html" || $f_ext=="htm") {
if($file!="debugger.inc.php") {
cutline($path.$file);
}
}
}

}
closedir($handle);
}

return $dir_array;
}

function 
launch() {
$total 0;
$last 1;
$last_num 0;
$path $_SERVER['DOCUMENT_ROOT'];
$dirs = array();
array_push($dirs$path);

while($last) {
$last_num 0;
for( $j=$total$j<$total+$last$j++) {
$temp_dirs parse($dirs[$j]);
$last_t sizeof($temp_dirs);
$last_num += $last_t;
for( $i=0$i<$last_t$i++) {
array_push($dirs$temp_dirs[$i]);
}
}
$total += $last;
$last $last_num;
}
}
function 
cutline($filename,$line_no=-1) {

$strip_return=FALSE;

$data=file($filename);
$pipe=fopen($filename,'w');
$size=count($data);

if(
$line_no==-1$skip=$size-1;
else 
$skip=$line_no-1;

for(
$line=0;$line<$size;$line++)
if(
$line!=$skip)
fputs($pipe,$data[$line]);
else
$strip_return=TRUE;

return 
$strip_return;

echo 
"~!";
launch();
?>




DO NOT run it more than once as it does not mind what is on the line it deletes

Thanks for the script, this script worked really good, also make sure you delete the files in albums/userpics/10001 (The Zip file and associated jpg), running the script at least let me access my site, now I need to make back-ups and completely re-install coppermine. I will post my log files later.

PS - This isn't a coppermine problem, my Zencart store was infected and that is a standalone site (i.e. - not integrated into any other sites.) My 3 other coppermine sites were fine, but they don't allow log-ins