Re: ping22: can not kill this process

["Mike Wang" <comritesecurity@gmail.com>]

Hi Edwin
          Sorry I forget to reply-all. thanks a lot for the detailed information.
           chkrootkit/rkhunter seems ok, only three of them not ok:

shopping:/proc# chkrootkit
shopping:/proc# rkhunter --checkall --skip-keypress
* Application version scan
   - Exim MTA 3.36                                            [ OK ]
   - GnuPG 1.2.4                                              [ Old or patched version ]
   - OpenSSL 0.9.7e                                           [ Old or patched version ]
   - PHP 4.4.4                                                [ Unknown ]

    the ping22 came after I reboot the machine, enabled SELinux. I only enable apache.pp mysql.pp, my locale.pp at this time.

shopping:/proc# semodule -l
apache  1.4.0
local   1.0
mysql   1.3.0

      my locale.te may not be good, I rushed to enable SELinux only at yesterday. I guess with a good SELinux rules it should be able to constrain the ping22 even to run.

allow fsadm_t self:process execmem;
allow hostname_t var_run_t:dir search;
allow httpd_t dict_port_t:tcp_socket name_connect;
allow httpd_t http_cache_port_t:tcp_socket name_connect;
allow httpd_t http_port_t:tcp_socket name_connect;
allow httpd_t httpd_sys_content_t:file { setattr write };
allow httpd_t httpd_sys_script_exec_t:dir { getattr read search };
allow httpd_t httpd_sys_script_exec_t:file { execute execute_no_trans getattr ioctl read };
allow httpd_t self:process { execmem execstack };
allow httpd_t lib_t:file execute_no_trans;
allow httpd_t man_t:dir { getattr search };
allow httpd_t man_t:file { getattr lock read };
allow httpd_t man_t:lnk_file read;
allow httpd_t port_t:tcp_socket { name_bind name_connect };
allow httpd_t proc_net_t:dir search;
allow httpd_t proc_net_t:file { getattr read };
allow httpd_t shell_exec_t:file { execute execute_no_trans getattr read };
allow httpd_t smtp_port_t:tcp_socket name_connect;
allow httpd_t unlabeled_t:dir { getattr search };
allow httpd_t unlabeled_t:file { getattr read };
allow httpd_t var_lib_t:dir setattr;
allow httpd_t var_log_t:file { append getattr };
allow httpd_t var_spool_t:dir { add_name remove_name write };
allow httpd_t var_spool_t:file { append create getattr lock read rename setattr unlink write };
allow httpd_t var_t:dir read;
allow httpd_t var_t:file { getattr read };
allow hwclock_t tmpfs_t:dir search;
allow iptables_t self:process { execmem execstack };
allow iptables_t var_lib_t:dir search;
allow mount_t initrc_var_run_t:dir { getattr mounton };
allow mysqld_t default_t:dir { add_name getattr read search write };
allow mysqld_t default_t:file { create getattr read write };
allow mysqld_t httpd_sys_script_exec_t:dir { getattr search };
allow syslogd_t device_t:fifo_file { ioctl read write };
allow syslogd_t self:process { execmem execstack };
allow syslogd_t var_lib_t:dir search;


68.87.64.146  is not my ip.

since I killed that ping22, I can not do the coredump at this time. I remembered I check the proc/<PID>/fd, there is nothing ping22, and also did lsof, could not find ping22.

For now I will keep the SELinux locale.t as it is, hope ping22 will exploit my machine again, then I will try to get something as you suggested, and keep it posted on the mailing list.


regards.

Mike

On Dec 30, 2007 3:54 PM, Török Edwin <edwintorok@gmail.com> wrote:

Mike Wang wrote:
> Hi edwin

Hi Mike,
[btw did you mean to cc the debian-security mailing list, or you want to
keep this conversation private?]

>
>        the pstree and ps showed the parent is 1 ( init)
>
>        tried kill -9 again, this time is got killed. strange!

Maybe because you rebooted and enabled selinux?
Try running chkrootkit, and rkhunter, maybe you'll find something.

>        I tried to kill it serveral times before. here is the previous
> screen capture.

I believe you tried ;)

> shopping:/# ps -ef | grep ping
> www-data 16430     1 12 13:56 ?        00:00:00 ping22
> root     16522 30331  0 13:56 pts/0    00:00:00 grep ping
> shopping:/#  kill -9 16430
> shopping:/# ps -ef | grep ping
> www-data 16848     1 16 14:01 ?        00:00:00 ping22
> root     16851 30331  0 14:01 pts/0    00:00:00 grep ping
>
>         the ping22 may be  come back in the future. I'm recently
> troubled by this ping22.  when it was there, I even could not login
> from the console except I reboot the machine.
>
>        And After I put the SELinux there ( put some rules there), the
> harm is  mitigated, since SElinux do not allow it  to  do  {
> name_connect } .
>
> Dec 30 15:12:00 shopping kernel: audit( 1199045520.032:629753): avc:
> denied  { name_connect } for  pid=16848 comm="perl" dest=6667
> scontext=system_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:ircd_port_t:s0 tclass=tcp_socket
>
>         The better way seems need to find how this ping22  get started
> in the first place.

Yes.

>         from the apache2 access.log I seems could not find it.( I am
> not an expert on this) , and I could not find the ping22 file.
>
>
>         Also I did the strace for this before, not sure if it can help
> to find what is ping22.
>

> sin_addr=inet_addr(" 68.87.64.146 <http://68.87.64.146>")}, [16]) = 49

Assuming this is your DNS.

> connect(20, {sa_family=AF_INET, sin_port=htons(6667),

> sin_addr=inet_addr("217.141.180.221 <http://217.141.180.221>")}, 16) =
> -1 EACCES (Permission denied)

> send(20, "M+\1\0\0\1\0\0\0\0\0\0\3irc\7ircgate\3net\0\0\1\0"..., 33,
> 0) = 33

It seems to be connecting to irc.ircgate.net , maybe some irc bot. You
could temporarely add it to your hosts file, and set up netcat on a
machine in your LAN.
Then see what it is sending.

While it is running, try to see what filedescriptors it has open in
/proc/<PID>/fd, maybe it still has the original file (ping22), and you
can dump it to see what it does.

Another possibility would be to attach to the running ping22 (perl), and
tell it to core-dump (after enabling ulimit -c unlimited).
Then open the core dump with a hexeditor (or vi), and look for a perl
file inside.

Best regards,
--Edwin