Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Index.php Injected to Site by Cracker

__/ [ 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 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

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index