Print

[Hein Traag]

Hi gang,

I recently setup a coppermine gallery for a group called ScoutLink, which is a international group of scouts who know each others through the internet.

The cpg was taken offline by the admin of the server where we are hosted because apparently there was a perl script run through our cpg setup.
I installed the latest stable and had some plugins there. Captcha - Contact - Fullsize control - Onlinestats - Updatestats. Running the classic theme with the horizontal filmstrip.

Our server admin provided the following log file

Code: [Select]

apache    9491     1  0 May10 ?        00:00:00 /usr/bin/perl /tmp/dp
11457
 irc.dalnet.ru 6667

 leeuwarden ~ # lsof -p 9491
 COMMAND  PID   USER   FD   TYPE             DEVICE     SIZE       NODE
 NAME
 perl    9491 apache  cwd    DIR               8,24     4096    5016680
 /scoutlink.net/users/www/pictures.scoutlink.net
 perl    9491 apache  rtd    DIR               8,21     4096          2 /
 perl    9491 apache  txt    REG               8,21  1169776     250999
 /usr/bin/perl5.8.8
 perl    9491 apache  mem    REG                0,0                   0
 [heap] (stat: No such file or directory)
 perl    9491 apache  mem    REG               8,21   107378     961231
 /lib/ld-2.3.5.so
 perl    9491 apache  mem    REG               8,21   101521     961248
 /lib/libpthread-0.10.so
 perl    9491 apache  mem    REG               8,21    84688     961150
 /lib/libnsl-2.3.5.so
 perl    9491 apache  mem    REG               8,21    11240     961233
 /lib/libdl-2.3.5.so
 perl    9491 apache  mem    REG               8,21   569744     961165
 /lib/libm-2.3.5.so
 perl    9491 apache  mem    REG               8,21    23216     961172
 /lib/libcrypt-2.3.5.so
 perl    9491 apache  mem    REG               8,21    11144     961291
 /lib/libutil-2.3.5.so
 perl    9491 apache  mem    REG               8,21  1253024     961230
 /lib/libc-2.3.5.so
 perl    9491 apache  mem    REG               8,21    19512     933207
 /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/auto/IO/IO.so
 perl    9491 apache  mem    REG               8,21    23440     933397
 /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/auto/Socket/Socket.so
 perl    9491 apache  mem    REG               8,21   119488     933379
 /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/auto/POSIX/POSIX.so
 perl    9491 apache  mem    REG               8,21    44336     961279
 /lib/libnss_files-2.3.5.so
 perl    9491 apache    0r   CHR                1,3             1239861
 /dev/null
 perl    9491 apache    1w  FIFO                0,5          1224272810
 pipe
 perl    9491 apache    2w   REG                8,2 35277515    2097155
 /var/log/apache/error_log
 perl    9491 apache    3u  IPv4         1224272819                 TCP
 *:11457 (LISTEN)
 perl    9491 apache    6u  unix 0xffff810029240300          1224148386
 socket
 perl    9491 apache    7u  unix 0xffff81000e062300          1224166291
 socket
 perl    9491 apache    8u  unix 0xffff8100071a70c0          1224153462
 socket
 perl    9491 apache    9u  unix 0xffff8100071a7ac0          1224184001
 socket
Apparently the "hacker" managed to write a perl script into the tmp dir and start it from there with the shell_exec()) command (we think).

As far as i know there is no cpg plugin which can be used to run a perl script. And we keep a tight security when it comes to passwords for admin accounts and ftp accounts.  I really have no clue what went on but until i find out what happened the site stays offline. I personally think it is not cpg to blame but something else, i would appreciate input from people who know their way around cpg and apache webservers.

* update* we also grepped for anything related to shell. We found this

Code: [Select]

*****@leeuwarden ~/pictures.scoutlink.net_renamed $ grep -Ri shell_exec * | more
plugins/minicms/fckeditor/editor/dialog/fck_spellerpages/spellerpages/server-scripts/spellchecker.php: if( $aspellret = shell_exec( $c
md )) {
*****@leeuwarden ~/pictures.scoutlink.net_renamed $ I assume this can not be used by outsiders who mean to harm our cpg ?

Thanks for the input
Hein

[Joachim Müller]

I have no idea wether the miniCMS plugin could be abused to launch such an attack.

[Hein Traag]

I think so to but i want to rule that out entirely if possible. I now also posted this on Donnoman's board cpg-contrib.

[Hein Traag]

Donnoman gave his explanation on the cpg-config.org board. It's what i thought. No picture in the CPG that was hit has a naming which looks like image.pl.gif so i think we're in the clear.

Donnoman's reply:

the most common way to run a maligned script is to rename it such that it abuses apache's mod_mime.

I would look for images that have been uploaded by users with "perl" in the contents of the file.

files could be named something like image.pl.gif  or whatever extension is mime's perl extensions.

Coppermine's naming usually prevents this.  However if you allow all kinds of file types like .rar and .zip someone can slip something past you like xyz.php.rar.

With mod mime since it doesn't know how to handle rar files but it continues searching the filename for more mime hints and gets php.

well it knows how to handle php, and it sends the uploaded image which contents are a php script right to the php processor. or perl or whatever.

The best way to defend against this is use the latest version of coppermine, and use the confiig restrictions to restrict it to just image files

[Joachim Müller]

However if you allow all kinds of file types like .rar and .zip someone can slip something past you like xyz.php.rar.

Has been adressed in cpg1.4.9. Malevolent users no longer can use this apache vulnerability to execute script files that way. Please review the corresponding announcement for details.