Hell House Vic

I recently started a thread about how our server got hacked. (http://www.securityfocus.com/archive...1/2003-07-07/0) One of the main themes there was whose fault was it? Some were saying it was Candid Hosting's fault, some were saying it was my fault. I've been tracking things done and have some rather disturbing info to share with you so you can hopefully not have the same thing happen to you

The exact problem: Traffic to our site from google was being redirected to a url that would attempt to download a trojan to the client.

How it happened: Candid's tech support traced it to someone writing an executable into /tmp - and said that it would be possible to do so by exploiting poorly written server side script.

What I didn't like: I write all the scripts. I was pissed (and embarrased).

How we fixed it: Recompiled apache and php. Upgraded the php. And changed some security settings. In doing so I was investigating running the domains as suexec - and realized that ccBill's scripts are actually the only scripts on our sites that I have not written. I was researching ccBills compatibility with suexec when i found this thread

If you only read one paragraph: It seems very likely that ccBill's cgi scripts open the security hole which allows the hack that happened to us. The most offending script is one called whereami.cgi - which ccbill seems to have changed the name recently to wm_000.cgi (where 000 is any number). I am setting the permissions on this script to '000' - making it unexecutable and useless. I can't see that this would fuck anything up, so you might seriously consider doing the same.

And read that thread for important details.

I'm alerting ccBill to this as well.

__________________

Contact Me - ICQ: 206851710 eMail vic (at) hellhousemedia (dot) com
'Satanism is like Capitalism for teens' - Ty HellHouse

Hell House Vic

The gfy thread was - https://gfy.com/fucking-around-and-business-discussion/554192-trojan-infected-webserver.html - got it wrong in the original post. sorry

__________________

Contact Me - ICQ: 206851710 eMail vic (at) hellhousemedia (dot) com
'Satanism is like Capitalism for teens' - Ty HellHouse

Harrison Richard

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

corvette

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

__________________
If you need a good company for check writing services, then check out checkissuing, and for webhosting, check out Phoenix NAP

johnnyhey

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

__________________
CandyDreams.com



shooter for hire

info[at]candydreams.com
ICQ:96563638
AIM: johnnyhey

Hell House Vic

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.

__________________

Contact Me - ICQ: 206851710 eMail vic (at) hellhousemedia (dot) com
'Satanism is like Capitalism for teens' - Ty HellHouse

Hell House Vic

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

__________________

Contact Me - ICQ: 206851710 eMail vic (at) hellhousemedia (dot) com
'Satanism is like Capitalism for teens' - Ty HellHouse

V_RocKs

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.

Hell House Vic

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.

__________________

Contact Me - ICQ: 206851710 eMail vic (at) hellhousemedia (dot) com
'Satanism is like Capitalism for teens' - Ty HellHouse

V_RocKs

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.

salsbury

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.

__________________

imageman

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 ?