Security Headsup for ccBill Users

The gfy thread was - http://www.gfy.com/showthread.php?t=554192 - got it wrong in the original post. sorry

So do you have proof that this is CCBill's fault?

Vic, my understanding that this is an issue that was addressed some time ago, my guess is about 2.5 years ago, as the article that you are referencing is from July of 2003. I believe that we had notified/updated the clients that may have been using that script. Please icq me when you have a minute to discuss this, it would be appreciated very much.

Thanks

45471840

yeah i've found that there are lots of script exploits for the bigger processors. they really need to keep the updates coming.

If I had proof I wouldn't use words like "possible". It's a legitimate possibility that ccBill's scripts shared a part of the fault for what happened. I am tracking down exactly what happened - not for the sake of "proof" but just to know what exactly happened, so I can best attempt to not let it happen again.

If it does turn out that they are involved in what happened, then they SHARE the fault with Candid Hosting (for not setting up the server securely - /tmp noexec, etc.), and myself for not giving a high enough priority to security to nail all of these potential holes down BEFORE they caused a problem.

I feel a little slimey for posting about ccBill, but (1) i got no response to my concern when i addressed them by email, and did get a response here, and (2) since it IS a legitimate possibility and a lot of people have ccBill scripts on their servers, they should be aware ('heads up') of the possibility.

Thanks for your reponse. I'll get in touch with you.

The whereami.cgi script that is being exploited with ?g=ls is NOT a CCBILL script.

Hackers use that filename because most installs at the time included that script and when you open it, if you are a layman it just looks like a bunch of code you don't understand. So if I add 1 more line of code you don't understand, you will not have a clue that I did.

Once again, the whereami.cgi?g=ls script and hole have absolutely NOTHING to do with CCBILL in any way other than hackers chose that name and directory to try and hide the script from you. And you did exactly what the hackers wanted. Point fingers at CCBILL and never find the real problem.

I've always felt that ccBill is a good, solid company - and I still feel that way. I'm not pointing fingers at ccBill, as I already said there are a number of entities at fault in what happened with my server recently, and I am certianly one of them, probably the central one.

I've confirmed with ccBill that the whereami.cgi script in fact does still exist, the only thing that has been changed is the name of the file, it is now called wm_000.cgi (where '000' could be any number). It is supposed to be removed from the server after the installation is complete. If you use ccBill it is worth ftp-ing over to your cgi-bin and checking to see if that file is still on your system and get rid of it.

Once again... No matter what the files name is, the only thing that script does is a perl version of the PHP function phpinfo().

Hackers add another line to it and use it as a backdoor shell, but to add the other line they first need a script that is actually vulnerable.

It is good to remove all scripts that you don't use and have no need for though... It makes it a lot harder for hackers to hide something in a script you are familiar with and possibly wrote. When you see an extra line of code in your own scripts it really stands out to you.

If you want to leave something around for possible use in the future, move it to a directory outside of the webroot. Better yet, store it locally on your personal computer and delete it from the server.

for what it's worth, setting /tmp to noexec would not have solved this problem. they'd just find another directory to store the files in. also, there are some things /tmp needs exec for, i believe. i seem to recall it being necessary to do basic things like compile programs or install certain software that writes temporary scripts there.
i felt the same way about paycom/epoch's add-passwd.cgi script (dunno if gfy archives still have that information i posted).

to the original point:

the attacker was able to redirect your google traffic to another site. that indicates that the attacker was able to write files either as you (but that's unlikely since you weren't using suexec) or write to world-writable files.

this is not me accusing the OP, but: way, WAY too many script authors ask you to just go ahead and chmod 777 all directories to make them work with their software. shame on all of them. jmbsoft is at least one company that is good about not requiring this (they list a specific set of directories and files that require this or that permission), i'm sure there are others, but i've seen so many that just say 777 all the way. it's sick.

this is as good a time as any to remind people to check out their site's security periodically. check your permissions and make sure they're not set to be wide open unless absolutely necessary. make a list of software you have installed and go to the author's sites, make sure you're up to date. look for all of the .php and .cgi scripts on your site. generate a new list every week and compare it to last week's -- look for new scripts that you don't recognize.

if you can't do this, talk with a programmer friend who's skilled with unix permisisons and security issues. or hire someone. it's your traffic stream we're talking about here: your money.

there is no magic bullet here. register_globals and magic_quotes_gpc are often mentioned as quick "fixes" to the problem, but they're not. the former is a tool to try and convince programmers to validate input, but doesn't enforce it. the latter munges incoming data in a way that should be done by the programmer anyway (ie, no programmer should rely on server settings not changing, unless they are the only people witih root).

for the programmers out there, here's how i've tackled this problem before. suggestions would be welcome (anything we can do to help secure adult site revenue industry wide, eh, heh) go ahead and turn register_globals off since it might as well be off. then create a .php file that you'll include into every other script. that file would include something like this:

$asserts = array (
'foo' => '/^[0-9]+$/',
'bar' => '/^[a-zA-Z0-9_]+$/',
);

foreach ($_REQUEST as $key => $value) {
if (!isset ($asserts[$key])) {
die ("unchecked _REQUEST['$key'], bailing");
} else if (!preg_match ($asserts[$key], $value)) {
die ("_REQUEST['$key']='$value' failed: $asserts[$key]");
}
}

you probably don't want to use die there, it was just an example (certainly shouldn't die() with the $value unencoded, leaves you open for XSS). anyway, as long as you write your regular expressions right, this should help a lot. note that this code checks GET arguments, POST arguments, and cookies.

woops. long post. sorry.

This is a very interesting post. Its an issue that most webmasters have and one that a lot of people don't even realize is effecting them ?

Is there an effective script that will lock down a server to stop of minimize hacking ?