I've made some headway... perl supports "sitecustomize.pl" which can
be used to execute code when any perl script is run. It doesn't seem
to be enabled by default, so I had to add the following line to
/usr/ports/lang/perl5.8/Makefile's CONFIGURE_ARGS:
-Dusesitecustomize \
As a temporary measure, my sitecustomize.pl has:
system "echo $$ $ENV{'PWD'} $0 ". (localtime) . " >>/tmp/scripts_used.lst";
(found this in another thread somewhere)
So, hopefully the next time this spammer comes back, I will see the
original working directory, etc. before the process forks itself.
Fingers crossed!
Patrick
On Sat, Oct 31, 2009 at 9:13 AM, patrick <gibblert...@gmail.com> wrote:
> 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"
