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

Re: ping22: can not kill this process

Hi Jan
     thanks a lot. Happy new year to all!

     I checked cron/at job, nothing related to ping22.

     And I checked my previous kill -9 ( see the previous post), it was generated like the following:
shopping:~# ps -ef | grep ping
www-data  6455     1 29 20:53 ?        00:07:53 ping222x
shopping:~# kill -9 6455

          after killing this 6455, there immediately has two ping222x,
shopping:~# ps -ef | grep ping
www-data  8891  8887 28 21:20 ?        00:00:00 ping222x
www-data  8893  8891  0 21:20 ?        00:00:00 ping222x
              trace back the ppid of 8887, it is apache process 709:
                    pid  ppid
>www-data   709  4059  0 19:33 ?        00:00:00 /usr/sbin/apache2 -k start   ( may corrupted or hacked apache process or respawning helper )
->www-data  8887   709  0 21:20 ?        00:00:00 [sh] <defunct>
->www-data  8891  8887 28 21:20 ?        00:00:00 ping222x
->www-data  8893  8891  0 21:20 ?        00:00:00 ping222x
->www-data  8893     1 35 21:20 ?        00:00:24 ping222x

             so look like the apache2 709 is a helper. finally the ping222x made itself looks like respawned from 1 (init).

             I killed 709, since then it did not came back. keep finger crossed.:)



On Dec 31, 2007 8:03 AM, Jan Luehr <jan@stephan.homeunix.net> wrote:

Am Montag, 31. Dezember 2007 schrieb Mike Wang:
> hi
>      Now this ping2 comes back, this time as ping222x. Yah it must come in
> by exploiting perl or php cgi. the running user is www-data.

This implies some things (likely):
1. The system (as whole), has not been comprimised. All corruption can be
limited to things www-data has access to.

If so, root privilges would have been acquired and ping222x would be hidden,
executed as root, etc. (There is a slight chance that the binary drops its
privileges down to www-data as an act of deception, but there are better ways
for deception/hiding if root-privileges are gained)

2. The respawing binary has to be kept somewhere. A few explainations are
a) It is kept in ram or memory and respawns by some kind of helper applcation.
If so, and above statement is true, either a runnig "spawn"-helper a process
(run by www-data or some users with less priviliges www-data is allowed to su
to, eg "nobody" / 65534) ought to be visible, or there are any cron-jobs,
at-Commands installed by www-data.
b) It is respawned by a corrupted cgi-script there ought to be traces in some
cgi-Scripts. Diff 'em to your backups.
c) "a) is true" does not imply "b is false": If a respawn-helper is used,
corrupted cgis are also possible.

In order to exclude a) you can shut down your apache for a moment and look if
ping22 is able to respawn.

Keep smiling

To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Best Regards

Reply to: