Re: Attack using php+apache

[Dion Mendel <quietude@iinet.net.au>]

A quick analysis.

* After testing that the php hole works (id;uname -a) and (cd /tmp;ls),
  the attacker downloads an executable 'c4'.  This executable is then
  run.

  A quick reverse of this executable shows it to simply exec a shell and
  bind to port 5678.  Googling gives us this link to equivalent source:
       http://hysteria.sk/sd/f/junk/bindshell/bt.c 

* Presumably the attacker couldn't log in, because 20 minutes later he
  is back and downloads and executes the executable 'bd'.

  This is a reverse bind shell.  It binds to a shell, then connects back
  to the attacker (IP 200.214.140.237 port 4444).  This way it gets
  around firewalls that filter incoming connections but allow all
  outgoing connections.

* After some fussing about in which we assume that attacker couldn't
  get the shell to connect, the attacker downloads and executes
  'telnetd'.  Which is a hacked in.telnetd that listens on port 14589. 

* We don't hear any more from this attacker - so presume he either got
  in, or gave up.

* More probing occurs later from different IP addresses (200.214.138.79
  and 200.147.146.16).  These are probably different attackers.


So what to do now?  If /tmp was mounted ro, then none of the attacker's
tools could run (from this attack anyway)  so there is no need to
rebuild the machine.  (To the rest of deb-sec, please don't take this as
advocacy for ro /tmp, I've had enough of that flame war).

What is your firewall policy?  If no incoming connections are allowed
(except to provided services) and outgoing connections are restricted to
a small set of allowed ports, then assume this attacker didn't get in.

Otherwise, assume he got in with the hacked telnetd.  Also assume he got
root.

Standard security cleanup procedure should follow.

Dion.

-- 
Dion's Maxim:  If you are ever surprised at just how stupid people can be,
               then you haven't understood Dion's Maxim.