[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Attack using php+apache



	Our Firewall policy is very restricted. Outgoing connections are
blocke, only a few ports are possibly to connect and the incomming
connections are very restricted.

On Sun, 16 Nov 2003, Dion Mendel wrote:

> 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.
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>



Reply to: