__/ [ Baho Utot ] on Sunday 01 October 2006 21:56 \__
Hi. Thanks for the prompt followup.
> Roy Schestowitz wrote:
>
>> Hi, folks. I am fairly sure I have been cracked.
>
> Yep [see below]
>
>> And yet, quite fortunately, the damage appears to be minimal.
>
> How do you know?
> You can not trust any binaries on the system.
> Use a liveCD to have a look at it.
The server is own by my Web host. I'm on a shared server.
>> I run Apache 1.3.x on a Red Hat server. Some observations follow.
>>
>
> What version of RH?
I can no longer tell from CPanel (well, actually let me check).
$ uname -a
Linux banana.catalyst2.com 2.4.20-30.9smp #1 SMP Wed Feb 4 20:36:46 EST 2004
i686 i686 i386 GNU/Linux
No, still won't say which version, but it used to be Red Hat 9 (*gasp*) when
I had access to this information. That was last year and I notice that a 2.4
kernel is still in use. Other services that are used:
clamd up
cpsrvd up
exim (exim-4.52-7_cpanel_smtpctl_av_rewrite_mm2_mmmtrap_exiscan_md5pass) up
eximstats up
ftpd up
httpd (1.3.37 (Unix)) up
imap up
mysql (4.0.27-standard) up
named up
pop up
spamd up
syslogd up
>> I assume the file was only injected to a subdirectory under ~/public_html.
>> It is a PHP index, which supercedes the HTML index in Apache (default
>> configurations).
>
> Yikes!
Yikes indeed. But panic I do not. I know it has been a while since the
incident and it took a while to have it noticed.
>> How it got there I haven't a clue.
>> Don't know how long
>
> Aug 5 2006
Yes, I could later see this. I composed the message as I was obtaining shell
access to get further details. The file has now been removed and I haven't
noticed anything else which was fishy since.
>> for and whether a file exists elsewhere in the site as well.
>
>> How can this be avoided?
>
> Proper configuration and file/directory permissions.
> Updated daemons wouldn't hurt either.
Absolutely. Bear in mind that I am not the sysadmin.
>> Could it be associated with some locally-installed software?
>
> No, Unless someone rooted you.
It's a possibility, but this vector of attack, as well as its location, seems
to indicate that files could not be altered, but only created.
>> Other people with the same host or on the same server?
>
> Possible.
I would hope so. Better a cockroach you can stomp in your own back yard than
one that comes and goes. But if search engines produce results that come
from a diverse number of locations, it seems unlikely.
>> Do the details that follow remind anyone of a common vulnerability?
>>
>
> Nope, But (s)he has been busy search google for HaCKeD By_cl24zY
>
>> A quick check reveals the following:
>>
>> -rw-r--r-- 1 schestow schestow 450 Jun 6 2005 index.htm
>> -rw-r--r-- 1 nobody nobody 1.5K Aug 5 20:58 index.php
>> -rw-r--r-- 1 schestow schestow 32K Oct 1 20:13 resindex.htm
>
>
> Looks like apache put it there, See the nobody user.
> Open your httpd.conf and find out which user apache runs under
> I think it will be nobody
Can only root check this? I doubt I have access to this file. Is it a
aper-user config file? If so, I am not sure what path it's under.
> I would take the server down and reinstall and apply the updates.
>
> The following applies to a stand alone web server
> Firewall the box so as http is the only thing that gets out, Don't allow
> the web server to initiate connections to the internet.
> Using iptables deny all outbound port connections and limit inbound
> connections to port 80 (internet face).
>
> You could look for a root kit but whats the point?
> I doubt you would find him anyway and if you did what would you do with
> him?
I really appreciate all your help. I will possibly contact my host shortly.
With kind regards,
Roy
--
Roy S. Schestowitz | Oracle: Linux adoption to accelerate
http://Schestowitz.com | Free as in Free Beer ¦ PGP-Key: 0x74572E8E
Cpu(s): 21.0% user, 2.9% system, 1.0% nice, 75.1% idle
http://iuron.com - semantic engine to gather information
|
|