Thanks for the info! It works in my test case, but this spammer popped
again, and unfortunately, I still couldn't reveal the source:
The ps listing shows:
www 29488 5.7 0.2 14144 5360 ?? Ss 7:47AM 37:24.83
./jug.pl (perl5.8.8)
And the lsof -p 29488 -a -d cwd only shows:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl5.8.8 29488 www cwd VDIR 0,83 512 2 /
I don't understand how the cwd could be /, as there was no jug.pl
there, and the www user cannot write to the root.
Could there be another trick being employed? I'm actually a little
puzzled by the ps listing. It shows the interpreter at the end in
parentheses, but if I invoke a similarly-named script from the shell,
it lists it as "/usr/bin/perl ./jug.pl".
I also cannot find any traces of these perl scripts anywhere on the
machine, though my tests show that you can safely delete the script
after it is loaded by the interpreter.
*trying something...*
Okay, so I've written a little script to reproduce what I'm seeing:
#!/usr/bin/perl
$pid = fork();
if ($pid)
{
unlink("test.pl");
exit(0);
}
else
{
chdir "/";
print "Hello world\n";
sleep 300;
}
This must be what is happening. When I do an lsof, I get:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
perl5.8.8 95492 patrick cwd VDIR 0,83 512 2 /
And there's no trace left of my script because I unlink()ed it.
This seems like it's going to be awfully hard to track down. I've gone
through every access_log to see if I can see anything suspicious. So
far, nothing yet, but I guess I'll keep plugging away at it.
*sigh*
Patrick
On Thu, Oct 29, 2009 at 8:48 PM, Dan Nelson <dnel...@allantgroup.com> wrote:
> In the last episode (Oct 29), patrick said:
>> Is there any way to get the cwd of a process? We had the situation
>> recently where a perl script was called from an infiltrated Wordpress
>> installation, but we weren't able to determine which of the hundreds of
>> Wordpress blogs was the source. The ps listing showed:
>>
>> www 63968 2.4 0.2 26092 5008 ?? Rs 5:36PM 93:10.67
>> ./mrf.pl (perl5.8.8)
>>
>> The procfs entry was no help because it does not seem to provide a cwd.
>> The cmdline entry just showed "/usr/local/bin/perl ./mrf.pl".
>>
>> We had to kill the process, and who ever was responsible did a good job of
>> hiding their tracks. But should this happen again (and we expect it
>> will), we'd like to be able to find the source.
>
> /usr/bin/fstat will tell you the inode of the cwd, and you can use "find
> -inum" to locate it. You can also install lsof from ports, which will dig
> into the kernel and try and fetch the name itself:
>
> (d...@dan.21) /home/dan> fstat -p $$ | grep wd
> dan zsh 77611 wd / 474264 drwxr-xr-x 533 r
> (d...@dan.21) /home/dan> lsof -p $$ -a -d cwd
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> zsh 77611 dan cwd VDIR 60,504234031 533 474264 /usr/home/dan
>
>
> --
> Dan Nelson
> dnel...@allantgroup.com
>
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
